Re: New bodhi release in production
On Fri, 2010-08-13 at 22:59 +0200, Julian Sikorski wrote: > Is the karma getting reset upon an edit? I don't have an answer to the question, but FYI, there is an open ticket about it: https://fedorahosted.org/bodhi/ticket/388 -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Sat, Aug 14, 2010 at 13:09, List Troll wrote: > On Sat, Aug 14, 2010 at 8:05 PM, Kevin Kofler wrote: >> Martin Sourada wrote: >>> I still remember the epic fail of having KDE 4.0 in stable fedora >> >> * I still think the KDE 4.0.3 we shipped in F9 wasn't that bad. We fixed all >> the showstoppers before F9 was released, and were also quick to ship updates >> fixing more annoyances, including updates to later 4.0.x releases. Yes, I >> used F9 with 4.0.x myself, one one machine. > > Wow, you actually used F9 yourself (on one machine)? What an accomplishment. > Stop. This is neither useful, being excellent or anything else beyond throwing ape-cakes to see who else gets caught up in it. -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. "We have a strategic plan. It's called doing things."" — Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Sat, 2010-08-14 at 19:57 +0200, Martin Sourada wrote: > On Sat, 2010-08-14 at 19:05 +0200, Kevin Kofler wrote: > > * Version updates, the very ones you complain about, brought that 4.0 up to > > 4.1 and later 4.2. I used F9 on my main machine from F8's EOL up to F9's > > EOL. F9 with KDE 4.2 (and IMHO even 4.1) was rock solid, actually one of > > the > > stablest Fedoras I used. (For example, F10 had issues with my hardware's > > ALSA driver affecting PulseAudio, F11 with the graphics driver.) > > > Well, the problem was that you pushed KDE 4.0 in the first place. Given > the state of things, you had very *strong* reasons to update to KDE 4.1 > and 4.2. And yes, pulseaudio was IMHO pushed one release earlier than > would be ideal as well... But note, that nothing in the Fedora update policy changes would prevent from the same push during the _development_ phase either. So you might be dissatisfied with the KDE-4.0 in F9 but this can happen with other packages or package stacks in new Fedora releases regardless of the update policy changes. So it is completely irrelevant to the debate here. And actually with the 'conservative update' policy once something like KDE-4.0 is in the _final_ release of a Fedora, it will have to stay there till the EOL of the release. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Toshio Kuratomi (a.bad...@gmail.com) said: > So I've kept my voice out of this... and hopefully, now that you know that > it's not just hte KDE SIG, I can go back to doing so again. ... how does that help? You've mentioned that you don't like 'this change' ... which part of it are you referring to? The changes in what critical path entails? The change to handling of non-critical path? The entire idea of bodhi? etc. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Friday, August 13, 2010 07:21:50 pm Martin Sourada wrote: > On Fri, 2010-08-13 at 17:17 +0200, Jaroslav Reznik wrote: > > On Friday, August 13, 2010 05:09:17 pm Kevin Kofler wrote: > > > Jaroslav Reznik wrote: > > > > Then we have to push broken updates, policy says so and it's ok, so > > > > let's do it > > > > > > > > :( > > > > > > A policy requiring us to push something broken is broken. I'm not going > > > to push broken shit. > > > > Just irony but it feels like... > > I wonder why I get the impression that the only ones who strongly oppose > this change are you folks from KDE SIG... Are you doing things > differently from anyone else in fedora - the rest of us are either more > or less neutral or positive towards this new change? Yes, we do it in a completely different way and I would say it's even much more strict but still very flexible. All bigger and important updates go through kde-unstable, kde-testing repository for some time, then it usually takes a few weeks in updates-testing and we collect input from users, testers (and lot of us test latest bits too). Final push to stable is team decision! We have bug trackers as blockers etc. And even our own steering committee for hard decisions ;-) But it's still flexible - if we need quick fix for some minor issue - it's possible (it's still team decision!). Most problems in updates are task for Auto QA, not a very strict policy (I would say it's more strict than RHEL updates :))). And I'm not completely against it - it's reasonable to try to have best update experience but... As David Malcolm said in the thread - one size fits all. And we don't have one size, ten, hundred but thousands... It's open source!!! > Basically from both user and maintainer point of view I'm for more > testing and more conservative update policy in general in stable > branches. That's exactly our aim. To try to balance latest upstream bits (with thousands fixes) with stability in terms of regressions - it's hard task and I admit we even failed once (4.4 & akonadi) but still it's the only way how to support Plasma Desktop. Jaroslav > Cheers, > Martin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Ryan Rix (r...@n.rix.si) said: > available (sometimes in front of it)... Yet even now, we can't keep up with > what (some of) our users want: the latest KDE, on KDE's release day, whether > it's a major release, or a point release. Yes, not every one of our users is > this way, but many are, and many use Fedora for this very reason. How do we > keep everyone happy? I think the simplest way is to start with a stable repo, for those that want that, and then build something on top of that? You can build some faster-moving feature packages on top of a stable base for those that want it. You can't do the reverse. (See the 'optional repo for feature updates' that's in the propsal... I suspect that people would love help in getting that set up and running sanely.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Saturday, August 14, 2010 07:57:27 pm Martin Sourada wrote: > On Sat, 2010-08-14 at 19:05 +0200, Kevin Kofler wrote: > > Martin Sourada wrote: > > > I still remember the epic fail of having KDE 4.0 in stable fedora > > > > * I still think the KDE 4.0.3 we shipped in F9 wasn't that bad. We fixed > > all the showstoppers before F9 was released, and were also quick to ship > > updates fixing more annoyances, including updates to later 4.0.x > > releases. Yes, I used F9 with 4.0.x myself, one one machine. > > Well, I believe most people would disagree with you here. Many of KDE > user switched temporarily to other DEs because of this, or stayed with > F8... I switch to KDE 4.0 in early beta and from that time, I couldn't use any other DE ;-) Just a users preference. > > * KDE 4.0 wasn't an update at all! It was what was shipped with a NEW > > release. We intentionally DID NOT update F8 to KDE 4.x. Not 4.0, not 4.1, > > not ever. This kind of changes is exactly what we have releases for and > > why rolling release models are not usable for production. > > KDE 4.0 wasn't feature complete, I would call it at the very best Beta > of KDE4. And yet you pushed it to *stable* release. Yes, during the > development time, not as an update, but still have done it. KDE 3.x was just EOL. Maybe upstream should wait with 4.0 release but we wouldn't have very nice and stable KDE 4.5 right now... It's open source, the way how it works... And as Kevin said - that's why we have two releases in the wild - one stable (F8), one progressive (F9). Otherwise we don't need more than one release out there (maintenance overhead). > > * Version updates, the very ones you complain about, brought that 4.0 up > > to 4.1 and later 4.2. I used F9 on my main machine from F8's EOL up to > > F9's EOL. F9 with KDE 4.2 (and IMHO even 4.1) was rock solid, actually > > one of the stablest Fedoras I used. (For example, F10 had issues with my > > hardware's ALSA driver affecting PulseAudio, F11 with the graphics > > driver.) > > Well, the problem was that you pushed KDE 4.0 in the first place. Given > the state of things, you had very *strong* reasons to update to KDE 4.1 > and 4.2. And yes, pulseaudio was IMHO pushed one release earlier than > would be ideal as well... And we did it - now we can slow down - we'd like to go with one major update for a Fedora release. Not only PA, the whole desktop stack ;-) > > > I like that Fedora is bleeding edge in rawhide, recieves good deal of > > > testing *before* release and is more or less conservative when it comes > > > to important stuff after release. That way we can provide our users > > > with *stable* but sufficiently modern stuff (in many areas even a few > > > months ahead of other distros). And I think the new policy aligns > > > pretty well with this. > > > > KDE 4.0 was a result of "Fedora [being] bleeding edge in rawhide", this > > was NOT pushed "after release". And it DID receive a "good deal of > > testing *before* release". We were very hard at work fixing showstoppers > > resp. getting them fixed upstream, it would have been much worse > > otherwise! If you had compared the pre-4.0 prerelease which was > > initially imported into Rawhide with the 4.0.3 + patches we shipped in > > F9, you'd have noticed that there were worlds of differences in > > reliability and glitch-freeness! A lot of the bugs that were fixed were > > reported by Rawhide or kde-redhat unstable users, some of them were > > fixed by Fedora developers. > > Well, KDE 4.0 was an example of what should have been reverted during > the stabilization pre-release phase (similar to what's now happening > with gnome 3.0, although with gnome it's the upstream that is sane > enough to not release it yet). It was not ready for prime time, IMHO. > And as outlined above, I believe that 4.1 and 4.2 were necessary > updates, precisely the type where there are strong reasons to push them > despite the big number of changes (but require *a lot* of testing). Yes - upstream decision. KDE upstream decided to go with 4.0... Gnome did not. We couldn't support old KDE. And I heard - Gnome guys now have big troubles - everyone is working on 3.0 and no one wants to take care about old one, even still official and supported one! But it's a decision. I don't want to rule all, we are not Microsoft :D Jaroslav > > The NON-conservative updates are what brought 4.1 and 4.2 to the F9 > > release, resolving many of the complaints users had about 4.0. > > No, given the situation, these were semi-conservative. They fixed > zillions of regressions and bugs... > > Martin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Bill Nottingham wrote: > You can build some faster-moving feature packages on top of a stable base > for those that want it. In theory you can. In practice that turns out to work rather poorly. It's the model several other distros are using; their "feature updates" repositories are always underused by maintainers, poorly supported, used by many users in a selective fashion (which causes dependency issues) etc. It also means there are effectively 2 incompatible versions of "Fedora n", unless we ban library upgrades altogether, which makes it impossible to provide e.g. a current KDE (something which also plagues other distros' implementations of this idea; often, KDE updates are in yet another separate repo etc.). I think the way we've been handling this – upgrade or get lost – is the only one that works. That said, of course I prefer having an 'optional repo for feature updates' than not being allowed to push them on Fedora infrastructure at all. It's just that I doubt about the viability of the idea. I also have some concern about the actual implementation: I've read that one idea that was floated was to shut down updates-features for Fn after the Fn+1 release. But that means people who use updates-features effectively have their support cycle cut by half! (It is not feasible to downgrade to the conservative updates, and the stuff installed from updates-features also requires security fixes!) (And in fact this kind of second-class support is exactly one of the problems of having the features relegated to a separate repo.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Jaroslav Reznik wrote: > And we did it - now we can slow down - we'd like to go with one major > update for a Fedora release. Maybe you do. :-) I don't. I believe that all Fedora releases deserve the same kind of update support until their respective EOL. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Tomas Mraz wrote: > But note, that nothing in the Fedora update policy changes would prevent > from the same push during the _development_ phase either. So you might > be dissatisfied with the KDE-4.0 in F9 but this can happen with other > packages or package stacks in new Fedora releases regardless of the > update policy changes. So it is completely irrelevant to the debate > here. And actually with the 'conservative update' policy once something > like KDE-4.0 is in the _final_ release of a Fedora, it will have to stay > there till the EOL of the release. Right, that's exactly why that conservative policy is broken. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Tue, 2010-08-17 at 13:29 +0200, Jaroslav Reznik wrote: > Most problems in updates are task for Auto QA, not a very strict policy (I > would say it's more strict than RHEL updates :))). And I'm not completely This is clearly hyperbole. Really, we've pointed out multiple times that all you need to do is have someone from KDE team become a proven tester - anyone can sign up - and +1 your updates as soon as you push them (and, hopefully, they actually *test* them). That's nothing like as strict as the RHEL system, where you have to get approval from real paid QA people (and jump through lots of bureaucratic^H^H^H^H^H^H^H^H^H^H^H^Himportant hoops about defining the problem and documenting the update and all that foobar). As several people have pointed out, there's a fundamental inconsistency in your position - you can't simultaneously claim that lots of people are frothing at the mouth for new releases of KDE, but it's really hard to find anyone to test the updates. If there's so many people who want KDE updates, it shouldn't be hard to find *two* people (just one of whom has to be a proven tester) to test the updates before they get pushed. Really, if you want to have anyone from the KDE team apply to be a proven tester, I will sponsor their application personally. It's not intended to be a hard process to use. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Adam Williamson wrote: > As several people have pointed out, there's a fundamental inconsistency > in your position - you can't simultaneously claim that lots of people > are frothing at the mouth for new releases of KDE, but it's really hard > to find anyone to test the updates. If there's so many people who want > KDE updates, it shouldn't be hard to find *two* people (just one of whom > has to be a proven tester) to test the updates before they get pushed. In theory that may be so. In practice, finding karma is extremely hard. Users do not give karma on Bodhi. They do not even have a FAS account and are not interested in signing up for one. It's just how things are. I've been soliciting for karma for this update: https://admin.fedoraproject.org/updates/kdevelop-4.0.0-3.fc14 on #fedora-kde. It's a straight rebuild, it doesn't really need ANY testing at all. It got only karma 2, and one of those was mine (the update was submitted by somebody else, so it's not a self-vote). The update was submitted (again: not by me) with a stablekarma of 3. Over 5 days have passed now. The repeated claims that those karma requirements are a pure formality are a LIE. In practice this update is unlikely to get to +3 before the 7 day timeout, and if it does, it'll just be because of this message and I do not believe that nagging the devel ML for each update is going to scale! (And in addition, 5 days is already too long. Though in this particular case the neverending Alpha freeze would have kept it from going out to stable anyway, but that's just another broken process.) And thankfully this one is not critical path, so at least there IS a timeout here! Some stuff, e.g. kdelibs, has been arbitrarily termed "critical path" (FESCo forced KDE SIG to provide them a list of "critical" packages, even though our position was clear: we do not see a use for this process for KDE at all!) and will get stuck in testing even longer, potentially forever. > Really, if you want to have anyone from the KDE team apply to be a > proven tester, I will sponsor their application personally. It's not > intended to be a hard process to use. Rex Dieter has applied months ago, before the initial seeding even happened. https://fedorahosted.org/fedora-qa/ticket/75 He is still not in the group. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Wed, 2010-08-18 at 01:37 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > As several people have pointed out, there's a fundamental inconsistency > > in your position - you can't simultaneously claim that lots of people > > are frothing at the mouth for new releases of KDE, but it's really hard > > to find anyone to test the updates. If there's so many people who want > > KDE updates, it shouldn't be hard to find *two* people (just one of whom > > has to be a proven tester) to test the updates before they get pushed. > > In theory that may be so. In practice, finding karma is extremely hard. > Users do not give karma on Bodhi. They do not even have a FAS account and > are not interested in signing up for one. It's just how things are. But there's two of you KDE developers posting in this thread. The two of you together are enough to get any update approved, if one of you takes ten minutes to go through the proven testers application process: https://fedoraproject.org/wiki/Proven_tester (Admittedly, yeah, +1ing an update you did yourself is bad form. But surely there's more than two people on the KDE team?) > I've been soliciting for karma for this update: > https://admin.fedoraproject.org/updates/kdevelop-4.0.0-3.fc14 > on #fedora-kde. It's a straight rebuild, it doesn't really need ANY testing > at all. It got only karma 2, and one of those was mine (the update was > submitted by somebody else, so it's not a self-vote). The update was > submitted (again: not by me) with a stablekarma of 3. Then advise the KDE team to submit updates with a lower threshold. 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. > Over 5 days have > passed now. The repeated claims that those karma requirements are a pure > formality are a LIE. 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. > In practice this update is unlikely to get to +3 before > the 7 day timeout, and if it does, it'll just be because of this message and > I do not believe that nagging the devel ML for each update is going to > scale! 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. > (And in addition, 5 days is already too long. Though in this > particular case the neverending Alpha freeze would have kept it from going > out to stable anyway, but that's just another broken process.) 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. > And > thankfully this one is not critical path, so at least there IS a timeout > here! Some stuff, e.g. kdelibs, has been arbitrarily termed "critical path" > (FESCo forced KDE SIG to provide them a list of "critical" packages, even > though our position was clear: we do not see a use for this process for KDE > at all!) and will get stuck in testing even longer, potentially forever. > > > Really, if you want to have anyone from the KDE team apply to be a > > proven tester, I will sponsor their application personally. It's not > > intended to be a hard process to use. > > Rex Dieter has applied months ago, before the initial seeding even happened. > https://fedorahosted.org/fedora-qa/ticket/75 > He is still not in the group. I replied to his 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
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
Re: New bodhi release in production
On Wed, Aug 18, 2010 at 1:53 AM, Adam Williamson wrote: > On Wed, 2010-08-18 at 01:37 +0200, Kevin Kofler wrote: >> Adam Williamson wrote: >> > As several people have pointed out, there's a fundamental inconsistency >> > in your position - you can't simultaneously claim that lots of people >> > are frothing at the mouth for new releases of KDE, but it's really hard >> > to find anyone to test the updates. If there's so many people who want >> > KDE updates, it shouldn't be hard to find *two* people (just one of whom >> > has to be a proven tester) to test the updates before they get pushed. >> >> In theory that may be so. In practice, finding karma is extremely hard. >> Users do not give karma on Bodhi. They do not even have a FAS account and >> are not interested in signing up for one. It's just how things are. > > But there's two of you KDE developers posting in this thread. The two of > you together are enough to get any update approved, if one of you takes > ten minutes to go through the proven testers application process: > > https://fedoraproject.org/wiki/Proven_tester > > (Admittedly, yeah, +1ing an update you did yourself is bad form. But > surely there's more than two people on the KDE team?) I'm part of the KDE SIG. I will apply today for proventester to become the KDE proventester. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Adam Williamson wrote: > 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. Editing isn't what I want though, I want to have a newer update in testing while keeping the old one not obsolete because it should go out to stable ASAP. Bodhi only allows this if it's already queued for stable when the new update is submitted, otherwise it automatically obsoletes the old one. >> The non-critpath packages still have a hard +1 requirement. > > Indeed, but that's not a difficult standard to meet. That's what I dispute. Especially if you expect people to actually meet the testing criteria for a +1. (It's easy and fast to just "swap +1 votes" or something like that, but it defeats the purpose of the process.) >> 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. Only 2 testers can often miss an issue, it's good to have at least 3 pairs of eyes. Only 3 testers can often miss an issue, it's good to have at least 4 pairs of eyes. Only 4 testers can often miss an issue, it's good to have at least 5 pairs of eyes. … (ad infinitum) Where do we stop? NO amount of testers will catch ALL issues. In addition, the maintainer certainly won't submit something he thinks is broken, so the proventester is already a second pair of eyes. Each time we decide that one person is not enough (but n are needed), we multiply the required manpower to do any work by a factor n! This is not something to be taken lightly. We DO NOT HAVE the manpower for this kind of QA. It takes VERY LONG to get any kind of positive karma for anything. (Negative one can sometimes be gotten quite fast, just screw up blatantly enough. ;-) ) And FWIW, I also dislike the fact that our QA process focuses almost exclusively on testing (well, there will be AutoQA too soon, but the manual checks will still be limited to just testing). I have found proofreading (even self-proofreading, but proofreading by another person can be even more effective) to be a much more effective form of QA than testing. I have found many issues when proofreading changes (both mine and other people's, and both for RPM specfiles and actual code) which would almost certainly never have been caught through testing (but were still real issues). I always proofread my changes before I commit them and I also proofread the specfile changes done by comaintainers. IMHO, that should already be sufficient ground for validating the resulting update, but according to our process I'm not supposed to +1 an update I have "only" proofread the changes of and not also tested. (That also reminds me of Knuth's "Beware of bugs in the above code; I have only proved it correct, not tried it.". :-) ) It often takes much less time to proofread the spec changes than to do testing with any kind of reasonable coverage (especially for something like KDevelop), and it is much more likely to find issues (because you just can't test everything: For example, how many testers actually check for unowned directories? A trained proofreader catches these quite reliably, especially if the change being proofread is the one making the directory unowned. And do you really think you can exhaustively test ALL the features of a powerful application? Proofreading can evidence that you broke one (e.g. by dropping a required BuildRequires), or that you made only trivial changes extremely unlikely to break anything at all). Also a FYI: Often it is also useful to have a look at the build.log in addition to the specfile, that will evidence complaints by the package's build system (CMake, autoconf-generated configure or whatever) about missing optional build requirements (and thus missing features). Those are again issues which testing generally does not catch. > 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. Well, now that we basically force everything through testing (though there can theoretically still be stuff which gets queued for stable before reaching testing if karma comes really quickly), it is not such a big problem anymore, but before, we had the paradoxical situation where urgent fixes queued directly for stable did not become available whereas unimportant stuff went out to testing just fine. :-/ Banning direct stable pushes entirely strikes me as the entirely wrong solution for this issue, basically solving the wrong problem. > except that systemd
Re: New bodhi release in production
Thomas Janssen wrote: > I'm part of the KDE SIG. I will apply today for proventester to become > the KDE proventester. Actually, Rex Dieter already started the application process, so you'll probably become "a" KDE proventester, not "the" KDE proventester. ;-) But the more proventesters we have, the better! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Wed, Aug 18, 2010 at 9:51 PM, Kevin Kofler wrote: > Thomas Janssen wrote: >> I'm part of the KDE SIG. I will apply today for proventester to become >> the KDE proventester. > > Actually, Rex Dieter already started the application process, so you'll > probably become "a" KDE proventester, not "the" KDE proventester. ;-) I'm glad to see you still know how to make friends ;) BTW I'm already "a" proventester. Another BTW, if you think you have to write "something", a simple 'thank you for stepping up' would have been enough. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Thomas Janssen wrote: > Another BTW, if you think you have to write "something", a simple > 'thank you for stepping up' would have been enough. Well, yes, thank you for stepping up, your help is very much appreciated! I didn't mean to offend you! (And thanks to Rex Dieter as well, by the way.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Thu, 2012-08-09 at 17:53 -0400, Luke Macken wrote: > - Re-organized the links on the front page, and link to the new Update > Feedback Guidelines Thanks a lot for that! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Luke Macken wrote: > - The submitter of an update can no longer effect the karma (Till Maas) Uh, last I checked, FESCo had agreed that this should NOT be enforced by the software because it is legitimate for the submitter to give karma by proxy when an anonymous tester has done the required testing. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Sat, 11 Aug 2012 18:20:35 +0200 Kevin Kofler wrote: > Luke Macken wrote: > > - The submitter of an update can no longer effect the karma (Till > > Maas) > > Uh, last I checked, FESCo had agreed that this should NOT be enforced > by the software because it is legitimate for the submitter to give > karma by proxy when an anonymous tester has done the required testing. Can you find a cite for that? Last I looked it was not allowed (but not enforced by software) by policy. We can reopen the issue and discuss it again of course... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
