Request for Comments: Proposed changes to Fedora development cycle

[Hans de Goede]

Jesse Keating wrote:
> On Tue, 16 Oct 2007 19:45:56 +0200
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
>> Why does this deeming good have to be done by rel-eng? Thats creating
>> both a bottle-neck and a hoop to jump through.
> 
> Because past has proven that given our huge number of maintainers that
> not everybody notices we're in a freeze, or cares, and leads to broken
> trees.

Broken as in not depclosing / containing conflicts I assume? That can be 
checked with scripts, why not revert the process and allow rel-eng to kick out 
bad builds instead of make all the good people suffer because of a few bad apples?

>> Isn't our new slogan "freedom is a feature", then I say no to a small
>> club making the decisions, thats an autocracy. I say power to the
>> people (power to the maintainers).
> 
> The past has burned me on having that much trust in /every/ maintainer
> thinking that deeply into every change they make at the end game.  More
> often than not I just see blanket "build for new upstream release"
> happening across every active branch at any time during the process
> with no thought to freezes or release cycles.  That's the type of thing
> we just don't want to land in our trees during the final stages.
> 

I say that depends on the package, for an obscure package the latest upstream 
might be the best, even if that means it replaces a much better tested release. 
For example today I've been preparing a new scorched3d release, based on a 
brand new upstream release, and after some quick testing I will build this for 
the F-8 release tree. Why? Because its a network based multiplayer only game, 
which changes its network protocol each release (GRRRR), and all the official 
servers update to the latest release pretty quickly, so unless users set up a 
private server anything but the latest upstream is useless.

Vavoom on the other hand tends to new upstream releases with a rough edge, and 
the current release is working fine, so there I've requested early branching 
and only build the new upstream for what will become rawhide after F-8 release.

You see, the maintainer knows best. Currently we have near 5000 packages, if we 
grow like Debian has, we might end up with 20000, you really cannot expect a 
small team to handle all the updates which are "good enough" for release 
inclusion, unless they will blindly believe what the maintainer says, and then 
you might as well get rid of the man in the middle.

> The process /does/ have 3 exit points.

No it doesn't it has 2 exit points where one is multiplexed, with the 
multiplexing requiring human interaction. One might as well argue that windows 
3.11 had no stability issues, because as long as a human was present to press 
the reset button when it hang, it would be back up in no time.

> I'm more than happy to add more people to the releng team that would be
> willing to make these kinds of decisions so that we have round the
> clock/world coverage.  I'm just not ready to leave the collection open
> for joe random builder to build things in when we're trying to get a
> release out.

We do not have joe random builder, we only have sponsored contributers, who 
during the sponsor process have had to prove their packaging skills. We may 
need to educate them further, calling them "joe random builder" is not going to 
help them become better, nor will it help us grow our community.

All in all to me it looks like we need more automated checks, where a package 
which fails them gets a special tag and needs manual tagging during the whole 
cycle. I know depclosing the whole of Fedora takes ages, but how about a script 
which looks at the current provides for a package, and compares them to the 
provides of a new version, if some provides go away (say a .soname) the script 
would disallow automatic pushing and give the package a special tag. After this 
the maintainer would need to ask rel-eng to re-tag it with the normal tag, 
explaining why the provides is gone.

Regards,

Hans