Quoting Pekka Savola <pekkas@xxxxxxxxxx>: > On Thu, 2 Jun 2005, Eric Rostetter wrote: > >> If one distribution version of a package has one VERIFY vote, all the > >> versions will automatically be released after a timeout of XX (where > >> I suggest XX is 2 weeks) from the first VERIFY -- except if someone > >> identifies issues which require discussion or more work. > > > > You might as well just publish them without testing then. One verify vote > > isn't significantly different than no verify votes. I'd say any plan > > that requires only one verify vote is worthless. > > I disagree. I'm wondering if I misunderstand what you are proposing. But I'm not sure. If you mean that it only takes 1 verify vote for any version of an update to publish an update (across all versions) than I stand by what I said. Otherwise, I'd have to ask that you clarify what you mean. > Patches are typically very similar across all the > versions. The sanity of the patches has already been checked at > PUBLISH. Checking that the program actually works in one platform is > definitely better than nothing. I didn't read your statement that way earlier. If you mean we get enough verify votes for a version, then publish the rest, fine. But I thought you said if we have one, single, lonely vote we should publish just because of a timeout, which is bad. For example, one of our first (if not our first) kernel updates published had to be immediately re-issued. It was verified by several people, so it should have been good. But all testers tested it with grub, and the problem was in lilo. So we need to have a larger number of people voting, to make sure we cover enough cases to allow the QA testing to be at all reasonable. Even with our current system, errors get through because the testing sample just isn't big enough. So I'm against anything that in principle allows us to publish with less testing in less-diverse environments. > > I'm not against the timeout, in fact there is supposed to be a timeout > > in the process, though I don't remember what it is. Perhaps we need to > > revisit the timeout issue, with the goal of putting someone in charge of > > watching the packages for timeout conditions. > > AFAIK, there is no timeout, at least it isn't documented. You may be > remembering the situation with RHL72/RHL73 and RHL8/RHL9 where I > recall there was something like a timeout but that case no longer > exists. I don't think there is anything in writing, but I think if we check the mailing lists from long ago this was covered, and a timeout was established. > > Right now, no one is AFAIK > > watching for such situations, so even if something had multiple verify > votes > > and has stalled, no one notices and pushes it out. Seems like another > > essential job waiting to be filled. > > Regardless of the timeout, there exists the case where VERIFY vote has > been given but the fact has not been recorded in the status > whiteboard, so the package is organized in the wrong place in the > issues list. Yes, this is a large part of the problem now (I've never figured out yet how to update the whiteboard). That is why I'm proposing this as a "job" that some one needs to step up and fill (remember we defined some jobs on the web site, most all of which are no filled yet). > As said I disagree with this view, but even with this, a project like > fedora legacy is even more worthless if it doesn't produce anything or > doesn't do it in a sufficiently timely manner. I may just not understand what you mean, so I'll give you that benefit of the doubt for now. > > If people are using testing-updates and not reporting their success, > > then that is the issue, and that is what needs to be fixed. I'm not > > sure if this is the case. If it is, maybe we could make posting a > > success report easier (e.g. a web form they fill out?) > > Well, as I said half a year ago, all this fuss about PGP signatures > and bugzilla turns people away. Most folks don't want to do > self-introductions, pgp generations, register bugzilla accounts, etc. Let's discuss how we can stream-line this then... > But at this point, I doubt there is much more to be done about it. Never know, maybe we can come up with something easier... > >> If something breaks with the update, we'll just > >> fix it afterwards and say "well, you should have tested the update in > >> 2 weeks and reported the problems". > > > > And they will rightly say, "No, FL legacy released it as tested and > > passing QA, so the problem is with FL and not me." > > If the users don't want to involve themselves in helping the project, > I don't see how we should be concerned about "complaints" from such > users. This is why Red Hat went commercial, and look at all the bad press they got from that, and how they got almost no good press. If you want commercial support, buy it from Red Hat or Progeny or someone. Otherwise, if you want "free" support you have to "work" for it. > I am not against posting the URL regularly, but I doubt it'll do much > good. Those that want to know it, already do. Reposting it more than > monthly probably doesn't make any difference. Actually, I think it makes a big difference. I think when it was posted weekly it made a big difference. And I know I look at it when it hits the mailing list, and I pretty much never look otherwise. So it definately has an effect on me. And I'd bet on others too. Getting it on the FL web page would also be a good thing though, and take some of the effort off you and/or others posting it e.g. weekly to the mailing list. Any progress on that yet Jesse? > -- > 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
