On Tue, 16 Oct 2007 20:44:03 +0200 Hans de Goede <j.w.r.degoede@xxxxxx> wrote: > > 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? Because usually it's too late after the brokenness is detected. We have such a huge number of packages that the time it takes to fully multilib out our set and depsolve it is in the order of hours. It's quite costly and certainly can't be ran for every single build that hits. There is a certain amount of hardware that can be thrown at the problem but resources are finite. I'd prefer to avoid the problem in the first place than to play clean up, repeatedly. If we ever get out of the situation where we are pre-calculating multilib and can do more accurate automated post-build validation before tagging I would be more than happy to revisit this item. > > >> 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. When they are actively considering the release processes, the freezes (soft or hard) and the current schedules yes. When they are just using their 5 minutes of free time a week to quickly slap out new versions of all their packages, not so much. I'm trying to prevent people from shooting themselves in the foot (due to ignorance to the current status of things rather than malice). > 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. Other distributions deal with this with sufficiently large package sets, I think we can to, or as I wrote above work on tools to obviate the process. The tools aren't here today, so releng gets to /be/ the tool. > > > 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. We're off in the weeds here. > > > 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, With no real guideline behind /who/ get sponsored, other than "hey I have the rights to sponsor somebody". > who during the sponsor process have had to prove their > packaging skills. And while packaging skills are important, it has absolutely nothing to do with cluefullness to the release process and what freezes mean and how to plan package updates around these constraints. We have /no/ training regarding this that we give to new users, nor very much good documentation. It's growing over time but I'm not likely to want to let chaos reign until we get these things in place. > 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. I didn't think "joe random builder" was derogatory in any manner. I will immediately stop using that phrase. I meant to convey the idea of a packager who maybe has one or two packages they maintain, not a lot of time to work on Fedora, just doing work whenever possible, not able to follow complicated things like release schedules and freezes, etc... and may not be taking these things into consideration when they're using their limited free time to process new releases or builds of their packages. > > 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. We just don't have that in place, and I don't expect to have much of it in place before we'll need it for F9. I'm not saying to not work on it, however I don't have the bandwidth to work on it right now. I have too much other equally important pieces of infrastructure to work on. What I'm trying to provide is a working development model in absence of these things so that we can continue on, and as these things show up adjust our development model to take advantage of them. -- Jesse Keating Fedora -- All my bits are free, are yours?
Attachment:
signature.asc
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
