Updates System

[Ralf Corsepius]

On Wed, 2007-05-16 at 09:11 -0400, Jesse Keating wrote:
> On Wednesday 16 May 2007 03:19:08 Ralf Corsepius wrote:
> > Update 40 packages at once and you'll probably notice why I consider
> > this to be a crack ridden work-flow. 2 steps more per package and one
> > form per package demonstrates the flaws of this workflow.
> 
> Given that the tool allows you to release multiple packages with the same 
> announcement / reasons / bugs / etc it is quite easy to prepare a stack of 
> packages for update, say a flaw in a library is discovered, you have to build 
> a new version of library, and a bunch of downstream packages against said 
> library, you can release the entire stack under a single web form, and now 
> all your updates have context, and it can even autoupdate a bug once it is 
> pushed to the world.

Where is this documented? URL?

> > 0) maintainer tests package's  functionality.
> >
> > > 1) Maintainer checks changes into CVS branch.
> > > 2) Maintainer builds.
> > > 3) Maintainer tests that build.
> > > 4) Maintainer fills out the form with the N-V-R, optional security
> > > (yes/no), optional Bug numbers fixed, and some fills in some details of
> > > what the update is about, then chooses updates or updates-testing.
> > > 5) Submit, where security and/or rel-eng team pushes it through.
> >
> > Now where in this scheme is Will Woods? I don't see him testing
> > anything. All I see is more bureaucracy and more manual steps than
> > before.
> 
> Perhaps this is where we're not communicating clearly enough.  Will isn't 
> going to be doing (all) the testing himself.  However Will is going to be 
> driving a QA team and anybody else who is interested to make use of the 
> public updates-testing repo.
I still fail to understand what he does and how a community package is
supposed to profit from this.

What does he do, what a "package consistency checker" can't and what
can't be achieved by having a repo containing packages?

>   The testing will be the wider audience of those 
> that use updates-testing and who may have configurations or situations beyond 
> what you as the maintainer could test yourself before releasing the updates.  
> It gives you a chance to land the update on more people's machines for wider 
> testing before just lobbing it over the wall at our general user base.  And 
> if the update isn't quite right, well it was in updates-testing so no harm, 
> no foul.  If the update wasn't quite right and you pushed it into -final 
> updates and everybody's machine now you've just given not only yourself a bad 
> name as a maintainer, but you've given Fedora a bad name as a distro too. 
> (yes yes, we all know you consider Fedora to be a horrible distro already, 
> but many of us don't.)

This impression is wrong. I don't consider Fedora to be a horrible
distro - at least technically, otherwise I wasn't using it?

Truth is - and this likely won't taste you - I consider 
* its infrastructure having been introduced with the merger to be a
series of horrible mistakes, the new workflow to be largely
bureaucratic, and the shape this all currently is in to be a shame.
* this all to be a symptom of Fedora leadership to have failed at a
large extend.
* RH to have betrayed opensource and measuring "openness of SW" by
selfish double standards, by having allowed "non-modifiable" firmware in
Fedora while banning other "non-OSI-compliant" SW.

Truth also is: So far, I feel the negative effects of the merger to
outweigh the positive effects.

More pragmatically: Over all these years Fedora exists, it has ever been
a major problem to me to maintain ca. 45 packages over 3-5
versions/distros in FE. Now it is - In short: a regression.

Ralf