New bodhi release in production

Wed Aug 18 03:17:51 UTC 2010

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