Broken upgrade paths in F7

[Ralf Corsepius]

On Tue, 2007-05-15 at 08:43 -0500, Josh Boyer wrote:
> On Tue, 2007-05-15 at 15:23 +0200, Ralf Corsepius wrote:
> > On Mon, 2007-05-14 at 19:38 -0500, Josh Boyer wrote:
> > > On Tue, 2007-05-15 at 00:43 +0200, Ralf Corsepius wrote:
> > > > On Mon, 2007-05-14 at 15:45 -0500, Josh Boyer wrote:
> > > > > Out of the previous report, the following packages have a build sitting
> > > > > in dist-fc7 that would fix the broken upgrade path.
> > > > > 
> > > > > Maintainers, please review this and submit a f7-final tag request to
> > > > > rel-eng at fedoraproject.org if these builds are suitable for Fedora 7
> > > > > final!
> > > > All of my packages have been submitted the ordinary "make build" way
> > > > either through plague or koji and are consistent in CVS. I don't
> > > > consider it my job to sort out this broken release policy.
> > > 
> > > Ok.  Then you can deal with bug reports on your packages if/when users
> > > try to upgrade and they don't work.
> > 
> > When will you understand that I did apply the same procedures as with
> > all Fedora releases before - You report actually points out regressions
> > koji imposes on community maintainers.
> 
> We've been over this before Ralf.  Things change.  It's not a
> regression, it's a change in workflow.
It's an undocumented insane regression in workflow  and a mistake of
release engineering - IMO, it's yet another case of RH having out-ruling
a once functional practice and replaced it with something not helpful to
external contributors.

> > I really don't have a problem in orphaning these packages, because my
> > interest in continuing to struggle with packages in Fedora drops by the
> > minute.
> 
> If you were to do so, that would be quite sad.

You still have your chances to change your workflow to something
sane, ... or at least to document it. 

Right now koji doesn't have any usable documentation nor is the workflow
you are referring to documented anywhere - Not even your contained an
URL to this documentation.

I.e. I consider all these EVR breakages rel-eng's fault and it to be
their job to handle them - period.

> And no, rel-eng cannot just tag them for you.  We need some kind of
> input from the package maintainer as to whether they're safe to enable
> and make sure they don't break dependencies, etc.
... because your work-flow is broken.

You guys should have branched rawhide before the freeze (BTW: you guy
now also seem to have inconsistencies been rawhide and the buildsystem.
Yesterday, I was facing packages which built in rawhide but failed in
the buildsystem).