Adam Williamson wrote:
> Admittedly, yeah, +1ing an update you did yourself is bad form.
Actually, FESCo said that Bodhi should not count such self-voted karma at
all. If it still does, that's a feature which is likely to go away very
soon. :-(
> Then advise the KDE team to submit updates with a lower threshold.
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).
> Admittedly, the Bodhi defaults here could stand to be improved; I don't
> think using the 'auto push' karma threshold as 'approved' makes sense,
> I'd like to see non-critpath updates require simple +1 karma to be
> 'approved'. But that is, again, just a minor bug in the current system,
> not any kind of showstopper.
It's a major bug. I'd even call it a showstopper. It makes this system a
really big PITA.
> Please don't set up straw men. I've said it is not an onerous system,
> that it is not as strict as the RHEL system...I haven't said it's a pure
> formality.
You said (and just repeated) that it's "not an onerous system" which is a
ludicrous enough claim, given the facts.
> 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. For critpath
it's actually +2, where 1 must be a proventester (which is really
ridiculous, why isn't a proventester enough?).
> 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. 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, 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. The whole
Alpha RC process should have been postponed instead of staying in freeze for
so long.
> 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.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
