Quoting Pekka Savola <pekkas@xxxxxxxxxx>: > On Fri, 3 Jun 2005, Eric Rostetter wrote: > > Seriously, if we can't get 2 votes for a package, then there is a real > > problem going on. > > It's pretty clear we've had a real problem going on for a long time. Well, the urgency hasn't been made apparent enough. I'm serious here. I'm involved in the project, and I didn't know there was as big a problem as we have. So how would people not involved know? > (A smaller, specific instance of lack of testing seems to be that > sufficiently many people aren't interested in FC1/FC2 and lack of > verifies for those stall the updates for other distros.) That is, IMHO, a separate issue. Lack of votes for any OS is the problem, not lack of votes for a particular OS. We could work around the lack of votes for a particular OS, but we can't work around a total lack of votes. > > That isn't the point of the project though. It would be much better to > > get two votes. Heck, if you do one, and I do one, we're done. The only > > time that would be a problem is the once or twice a year we go on vacation. > > That doesn't seem to have happened all that much, however. Then let's make it happen, okay? > >> That said, I could also live with two verify votes (for any version) > >> plus the similar timeout, but I think timeliness is more important. > > > > I can agree to 2 votes plus timeout. If we give 2 weeks for the votes, > > and 2 additional weeks for the timeout, then everything is done in one > > month. Sounds reasonable to me. > > 4 weeks is a long time for more important security bugs. 2 weeks is > maximum after the stuff has been pushed to updates-testing (which > typically has also taken quite a while). I think if it is a important security bug, it will not need the timeout as much. I don't want to rush the less important updates though. Yes, there's a judgement call as to what is important and what isn't. But let's try the longer timeout and see how it works. If it doesn't work, we can go back and shorten it. > >> FYI, one verify vote is sufficient to VERIFY a distro version right > >> now, so this is why I said one measly verify vote. > > > > I wasn't aware of this; last I knew we still needed two votes. How/when > > did this change? > > A long time ago, maybe a bit over 6 months or so ago. Strange that as the web site, FAQ, etc. maintainer I'm so out of touch with reality. > > But we can try better/harder to get more votes (including say, getting me > > to test/vote more, and getting those who run updates-testing but don't > > vote to vote). > > I encourage you and others to do that. However, IMHO, we've stalled > already long enough with that and folks (yourself included) have > started (or already done) moved away from some releases. Yeah, but I'm not moving away fast. I've still got almost all legacy systems. I've over 100 machines, and only 2 are now non-legacy. Sure by the fall I hope to make that at least half non-legacy. But realistically I'll be legacy for a while, and even if all the machines I run directly are non-legacy I'll probably have to help support others here who still have legacy machines. So, let's not kill the project yet... Besides, the FC project basically guarantees new people will be dropping by, as long as we can provide the service we were formed to provide. > I suggest we make some process changes now (I don't specify which, but > the impact has to be significant), AND you (and others) try to get > more people to do QA as well. Yes, I'm not against that. But I'd like to at least state my input and my reasons behind process changes. What we really have in this project is a communication problem. Review the lists, as well as this thread, and you'll see everyone involved in the project is having communications problems, even at the top level (Warren and Jesse). That would be were I start to change the process. We won't suceed if we can't communicate effectively, and keep people informed about what is going on, including problems. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- Eric Rostetter -- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
