[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Request for Comments: Proposed changes to Fedora development cycle



Jesse Keating wrote:
On Tue, 16 Oct 2007 19:45:56 +0200
Hans de Goede <j w r degoede 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]