On Wed, 2010-08-18 at 03:17 +0200, Kevin Kofler wrote: > That particular update was not submitted by us, but by the guy who did all > the Python 2.7 rebuilds. > > The annoying thing is, I have a newer KDevelop build (an upgrade to an > upstream point release) I want to push to testing, but as long as this one > is not at least queued for stable, I can't push the new build without > obsoleting this one, which I don't want to do (because I want the Python 2.7 > fix to go out ASAP, but the new upstream release to get the testing it > deserves; see, I DON'T want to push everything without testing, I just want > to be able to use my experienced judgement on how much, if any, testing is > needed). To me, that reads more like a problem with the update submission system than anything. I'd like to see far fewer restrictions on it (just like I'd like for koji), so you could edit the existing update to add your packages. This same issue exists even without feedback requirements. > > No, it doesn't, but for important updates that are stuck, you can > > certainly nag -test. And, see above. The +3 requirement is nothing set > > in stone, you can already change it, and we should probably change the > > default. Nothing in my mail said anything about the non-critpath default > > but changeable +3 requirement, I talked about the critpath unchangeable > > +1/+1 requirement. > > The non-critpath packages still have a hard +1 requirement. Indeed, but that's not a difficult standard to meet. > For critpath > it's actually +2, Yeah, that's what I meant by +1/+1 (+1 proventester, +1 anyone). > where 1 must be a proventester (which is really > ridiculous, why isn't a proventester enough?). A single tester can often miss an issue, it's good to have at least two pairs of eyes. > > In what way is it broken? The freeze isn't neverending, it lasts as long > > as it takes to release the Alpha. We can hardly start shoving packages > > into stable until we sign off on the Alpha images, that breaks the whole > > point of the freeze. > > We could compose the Alpha off a f14-alpha tag in Koji and allow dist-f14 to > go on. This is an almost irrelevant distinction; right now we have the Alpha composed off the dist-f14 tag and dist-f14-updates-candidate is 'allowed to go on'. Your proposal really just renames the tags. Well, given how they'd be used afterwards, it's slightly different - and I'd agree slightly better - but it's really not a big change. One thing that has been different for F14 Alpha is that packages submitted to updates-testing during the freeze weren't pushed very quickly; this has nothing to do with the proven testers process, though, it's just because Jesse was away and those covering for him weren't sure whether they were supposed to keep pushing packages to updates-testing while we were doing RCs. AFAIK, as long as we keep pushing builds through to updates-testing while the main repo (which is filled from the dist-f14 tag) is frozen for RC composes, there isn't really a problem, as you can keep pushing fixes into updates-testing, build things on top of other things there, however you like. > Or we could just have allowed stuff into dist-f14 for a couple more > weeks when it was clear that we weren't in a releasable state. Right now > we're stuck with dozens of broken dependencies which have been unfixed for > WEEKS when the fix for several of those has been queued for stable already. > We should at least have gotten the broken dependencies down to a reasonable > number before starting the Alpha RC process. A tree with so many broken > dependencies is not releasable Actually, it is, because we don't really release a tree for the Alpha, we release images (I'm not sure if we stick a full tree frozen in Alpha state up on mirrors, but if we do, it's not something we really *care* about - we'd expect people to use the rolling main F14 tree along with the Alpha images). At Alpha stage, we're fine to release as long as there's no conflicts or dependency issues *within the packages included on the DVD / split CD images*, which is a rather smaller subset of 'everything'. We have a release criterion and a validation test which covers this, and there are no such issues on the RC4 images (except that systemd-sysvinit and upstart-sysvinit conflict, but that's fine as there's no way you can actually cause upstart-sysvinit to be selected for installation, it only gets pulled in because mash pulls in everything that can potentially satisfy dependencies, and they both provide the 'sysvinit-userspace' dependency). As I said above, as long as you can fix dependency issues in updates-testing, the fact that the 'stable' repo is frozen shouldn't really be an issue, right? > , the fact that we're withholding the fixes > because we're trying to release the broken stuff is particularly silly. In > addition, the RC1 and RC2 live images were entirely untestable. Yeah, that was unfortunate. In the past we put a very low priority on live images for pre-releases. There weren't actually live images built as part of Alpha RC1 / RC2, I just designated a nightly build to match each, but as you point out, there were bugs that resulted in them not being usable. It may be worth considering slipping the start of the Alpha process rather than the end if the same kind of case where we're fighting against lots of changes in the tree when we try to start the TC/RC process comes up again, but I'm sure you appreciate the temptation is always to try and get something workable spun and catch up with the schedule... > The whole > Alpha RC process should have been postponed instead of staying in freeze for > so long. whoops, see above. :) Again, though, this seems to be somewhat off the topic of the proven tester process. > > I replied to [rdieter's] application on July 7th - the day we started > > actually accepting proven tester applicants - asking him for the things we > > ask of all applicants (affirm that they've read and will abide by the > > guidelines for proven testers). He has not yet replied to that, so I > > can't approve him. > > Looks like the communication broke down somewhere, I'll nag him next time I > catch him on IRC. Thanks, I'll approve him as soon as he follows up. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
