Jesse Keating wrote:
On Tue, 16 Oct 2007 19:45:56 +0200
Hans de Goede <j.w.r.degoede@xxxxxx> 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
