Plan for tomorrow's (20070604) Release Engineering meeting

[Josh Boyer]

On Mon, 2007-06-04 at 00:33 +0530, Rahul Sundaram wrote:
> Josh Boyer wrote:
> 
> > For this release, it would have been particularly bad to release it
> > before the mirrors had at least synced the new layout.  People would
> > instinctively have done 'yum update' and had yum report that it couldn't
> > find repodata from the mirrors.
> > 
> > (I know the RC release already had that problem but adding to it
> > wouldn't have been good.)
> 
> Pup might give a more informative error or we could explain it better in 
> a help button or something in general. This release indeed had the 
> mirror layout change issue. This alone is not sufficient enough a reason 
> to avoid doing torrent only initial releases in the future.

I didn't say it was.  Just offering one potential example of something
that might prevent early torrent release.

> > There are other disadvantages.  Like the fact that release can't happen
> > until the proper things are filed with the Export office.  Depending on
> > when gold is declared and when it's filed, you might not be able to
> > release anyway.
> 
> I believe that we can't even send to mirrors without export approval and 

That is correct.  However it still takes time to get the mirrors synced.
If they don't even have the release directories available, you still
have the update issue.

> there is always some leaked mirrors where users grab the images earlier. 
> On some occasions they have downloaded the wrong release. We could ease 
> it out a bit by providing them a early path so that the enthusiasts 
> would get things without saturating the mirrors.

Sure.  And you snipped the part where I said it's worth discussion.  I
wouldn't release the torrents immediately, but rather wait at least a
day from it being released to the mirrors.

> > We tried very hard to fix the upgrade paths to do this.  I'd like to see
> > it possible.  We just need all package maintainers to be on the same
> > page here.
> 
> I would go further and like rel eng to consider enforcing strongly a 
> proper update path for all packages from all releases to future ones 
> including test releases. 

Assuming FESCo approves such a guideline, I think that can be done.

Overall, I think for F7 we did pretty well considering all the changes.
The vast majority of packages we fixed up for F7 were simply ones that
had a build sitting in koji that wasn't tagged with f7-final for one
reason or another.  There were only a handful of updates the last time I
ran the report that truly had broken upgrade paths.

> I don't want to lump a lot but there is a 
> number of related issues here. A policy on using Epoch's (there are 
> differing opinions currently ranging from "it's just a number" to "it's 
> the mother of all evil's") would be useful. Are you considering 
> disabling ACL's by default on all packages and letting package 
> maintainer's explicitly request with proper reasons?  Is rel eng, all 
> sponsors and QA team allowed to fix EVR issues when necessary?

That's a decision FESCo needs to make.  It can be discussed at the
rel-eng meeting, but that definitely falls into the realm of FESCo for a
final approval.

josh