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
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 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
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 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: > 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
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
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
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
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 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: > 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 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
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
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
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
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
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 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
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 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
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 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 4:08 PM, Adam Williamson wrote: > On Sat, 2010-08-14 at 19:44 +0200, Martin Sourada wrote: > >> The only thing I don't understand completely (but can accept without >> complaining nevertheless) is why this applies to *new* packages as well >> -- they didn't existed in repos before and anything is better than >> nothing... > > Same objection as 'nothing is worse than a broken package'; it's not > true. They could have bad conflicts / obsoletes, or they could be set to > run on startup after being installed and crash the system...there's > various ways in which an entirely new package could stuff things up. > Very true. New packages are black boxes, for which you aren't exactly sure what you will get until you start using them in production. Our reviewers are doing a great job, but there have been issues that have been missed during the review, which is quite normal, especially for bigger packages. As an example, I submitted the clementine media player package to testing on July 25th. We got a crash report on the 26th. This was fixed and a new update is submitted to testing. Then I realized that some files got compiled in without the "-g" flag because upstream overrides compilation flags. Another update was submitted to testing. Then another crash was reported on August 6th. This was fixed and an update got pushed to testing yesterday. Now for pushing to stable, I will wait another two weeks to make sure the application works reasonably well for people. As you might see, 7 days isn't even enough in certain cases. I would have preferred a 14-day testing period. Some people prefer 0. I criticized FESCo a lot in the past for being biased (especially for not calling the Gnome spin "The Gnome spin"). However I think FESCo did a good job this time in finding the middle ground. Orcan -- 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:44 +0200, Martin Sourada wrote: > The only thing I don't understand completely (but can accept without > complaining nevertheless) is why this applies to *new* packages as well > -- they didn't existed in repos before and anything is better than > nothing... Same objection as 'nothing is worse than a broken package'; it's not true. They could have bad conflicts / obsoletes, or they could be set to run on startup after being installed and crash the system...there's various ways in which an entirely new package could stuff things up. -- 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
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. > * 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. > * 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.) Are you seriously trying to say that you updated your own machine to Fedora 9 (KDE 4) 7 (!) months after it was rolled out? I have no words. Good work using everybody else as your test subjects: when they have ironed out all the bugs, you finally update your own computer. M.T. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
New packages can break existing systems. Leak ram, eat filesystems, leak
personal data, leak root, dos a system, etc...
--
Sent from my Android phone. Please excuse my brevity, lack of trimming, and top
posting.
"Martin Sourada" wrote:
>On Sat, 2010-08-14 at 19:14 +0200, Kevin Kofler wrote:
>> Martin Sourada wrote:
>> > Seeing your mail, you more or less agree with this. So why exactly are
>> > you against the policy explicitly requiring either positive karma or
>> > some minimal time in testing (setting aside some current shrotcommings
>> > of the implementation like resetting the timer on bug update when you
>> > just add/remove fixed bug or edit update comment)?
>>
>> There are changes needing a lot (2+ weeks) of testing (e.g. upstream minor
>> feature releases, such as Qt 4.n+1). There are changes needing some (~1
>> week, at most 2, of) testing (e.g. upstream bugfix releases / point
>> releases). There are changes needing no testing (e.g. trivial one-line fixes
>> for a regression in a previous update which need to go out ASAP to fix the
>> regression). The maintainer is best qualified to know which applies. The
>> maintainer is also much better at judging the quality of his updates than
>> some semi-arbitrary number computed out of tester feedback ("karma"). (He
>> knows what he changed, he has access to feedback from other places, e.g.
>> Bugzilla, IRC, mailing lists, upstream's bug tracker, other distros' bug
>> trackers, anonymous Bodhi feedback not counted towards karma etc. – all
>> places which can confirm a single patch to fix a reported issue –, he has
>> experience from previous updates, and he is able to make an educated
>> judgement call based on all that information.) We are very far from software
>> being more intelligent than people, so we should let people decide, not
>> software. And the people should be able to decide on a case by case basis,
>> not some inflexible bureaucratic policy (which is so dumb that it can even
>> be enforced by software).
>>
>Hrm, I see that software as means to gain feedback for my updates --
>noone can be 100% sure his changes are bugfree, otherwise we would have
>bugfree software. In the ideal case scenario (which we are far from)
>this would be used to catch the regression *before* making that update
>stable in the first place. Testers are also giving reasons why they put
>-1 karma if they did so. IMHO each change requires at least minimal
>testing (and yes, finding at least +1 karma point for one line fix
>should not be very hard).
>
>The only thing I don't understand completely (but can accept without
>complaining nevertheless) is why this applies to *new* packages as well
>-- they didn't existed in repos before and anything is better than
>nothing...
>
>Martin
>--
>devel mailing list
>devel@lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/devel
--
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: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... > * 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. > * 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... > > 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). > 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 signature.asc Description: This is a digitally signed message part -- 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:14 +0200, Kevin Kofler wrote:
> Martin Sourada wrote:
> > Seeing your mail, you more or less agree with this. So why exactly are
> > you against the policy explicitly requiring either positive karma or
> > some minimal time in testing (setting aside some current shrotcommings
> > of the implementation like resetting the timer on bug update when you
> > just add/remove fixed bug or edit update comment)?
>
> There are changes needing a lot (2+ weeks) of testing (e.g. upstream minor
> feature releases, such as Qt 4.n+1). There are changes needing some (~1
> week, at most 2, of) testing (e.g. upstream bugfix releases / point
> releases). There are changes needing no testing (e.g. trivial one-line fixes
> for a regression in a previous update which need to go out ASAP to fix the
> regression). The maintainer is best qualified to know which applies. The
> maintainer is also much better at judging the quality of his updates than
> some semi-arbitrary number computed out of tester feedback ("karma"). (He
> knows what he changed, he has access to feedback from other places, e.g.
> Bugzilla, IRC, mailing lists, upstream's bug tracker, other distros' bug
> trackers, anonymous Bodhi feedback not counted towards karma etc. – all
> places which can confirm a single patch to fix a reported issue –, he has
> experience from previous updates, and he is able to make an educated
> judgement call based on all that information.) We are very far from software
> being more intelligent than people, so we should let people decide, not
> software. And the people should be able to decide on a case by case basis,
> not some inflexible bureaucratic policy (which is so dumb that it can even
> be enforced by software).
>
Hrm, I see that software as means to gain feedback for my updates --
noone can be 100% sure his changes are bugfree, otherwise we would have
bugfree software. In the ideal case scenario (which we are far from)
this would be used to catch the regression *before* making that update
stable in the first place. Testers are also giving reasons why they put
-1 karma if they did so. IMHO each change requires at least minimal
testing (and yes, finding at least +1 karma point for one line fix
should not be very hard).
The only thing I don't understand completely (but can accept without
complaining nevertheless) is why this applies to *new* packages as well
-- they didn't existed in repos before and anything is better than
nothing...
Martin
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/14/2010 07:17 AM, Till Maas wrote: > On Fri, Aug 13, 2010 at 07:07:44PM -0400, Luke Macken wrote: > >> I just pushed out a fix that should allow you to edit updates with your >> local development instance. > > Thank you very much, it works. Patches for the autokarma javascript will > soon be attached to bodhi's trac. With these, there is only a cosmetic > issue left afaics. Excellent, thank you! > Btw. would you mind if I triage some Bodhi tickets and close the ones I > think are fixed in the current version? If they are not, the original > submitter can still re-open them. That would be great. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Martin Sourada wrote:
> Seeing your mail, you more or less agree with this. So why exactly are
> you against the policy explicitly requiring either positive karma or
> some minimal time in testing (setting aside some current shrotcommings
> of the implementation like resetting the timer on bug update when you
> just add/remove fixed bug or edit update comment)?
There are changes needing a lot (2+ weeks) of testing (e.g. upstream minor
feature releases, such as Qt 4.n+1). There are changes needing some (~1
week, at most 2, of) testing (e.g. upstream bugfix releases / point
releases). There are changes needing no testing (e.g. trivial one-line fixes
for a regression in a previous update which need to go out ASAP to fix the
regression). The maintainer is best qualified to know which applies. The
maintainer is also much better at judging the quality of his updates than
some semi-arbitrary number computed out of tester feedback ("karma"). (He
knows what he changed, he has access to feedback from other places, e.g.
Bugzilla, IRC, mailing lists, upstream's bug tracker, other distros' bug
trackers, anonymous Bodhi feedback not counted towards karma etc. – all
places which can confirm a single patch to fix a reported issue –, he has
experience from previous updates, and he is able to make an educated
judgement call based on all that information.) We are very far from software
being more intelligent than people, so we should let people decide, not
software. And the people should be able to decide on a case by case basis,
not some inflexible bureaucratic policy (which is so dumb that it can even
be enforced by software).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
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. * 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. * 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.) > 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. 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. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, Aug 13, 2010 at 07:07:44PM -0400, Luke Macken wrote: > I just pushed out a fix that should allow you to edit updates with your > local development instance. Thank you very much, it works. Patches for the autokarma javascript will soon be attached to bodhi's trac. With these, there is only a cosmetic issue left afaics. Btw. would you mind if I triage some Bodhi tickets and close the ones I think are fixed in the current version? If they are not, the original submitter can still re-open them. Regards Till pgpSp3QZmqmdO.pgp Description: PGP signature -- 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 10:32 +0200, Kevin Kofler wrote: > Martin Sourada wrote: > > There are also bazillion distributions out there who are on the bleeding > > edge. > > But none that have the current stuff without blatant breakage as updates to > the stable releases, and ship the exciting but disruptive changes in new > releases every 6 months, while still supporting the previous release for 7 > more months from that point. > > There's a balance between bleeding edge and conservativeness. Fedora was > exactly where I, and many other people, who chose Fedora exactly for that > reason (just look at some of the user feedback, e.g. Adam Williamson's poll > on the Fedora Forums, some mails to the k...@lists.fp.o ML etc., I'm not > inventing that "many other people" part), wanted it to be on that balance > (except for some odd packages like Firefox and OO.o where the maintainers > did their own thing, basically already following what the new unwanted > policy will be). Now new policies are tilting the scale way too far towards > conservativeness, to the point where we don't distinguish us anymore from > other distributions; Rawhide, on the other hand, is way too far on the > bleeding edge end to be usable for daily use, and this is exactly the issue > with other "bleeding edge" distributions as well. > > Not all new upstream versions are equal. New versions with major changes, > especially feature regressions, are NOT suitable as updates to a stable work > environment. Version upgrades WITHOUT such breakage ARE suitable, and > actually WANTED as updates. For example, people EXPECT to be able to use the > latest Firefox (and have complained about the Firefox maintainer being too > conservative with his updates), the latest KDE (and have praised KDE SIG for > being so effective at pushing new versions) etc. > Hehe, I agree here with a lot of what you say, as well as disagree with a lot of what you say. I generally don't think we should ban enhancement updates completely, but things like major firefox/kde/gnome/Xorg/kernel are usually too much. In the past, when I was still using firefox, I wasn't especially thrilled with it's stability, especially with new major releases, I still remember the epic fail of having KDE 4.0 in stable fedora and I now I'm experiencing the trying to push immature GNOME 3.0 (luckily it was decided in time to push it back another half a year)... 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. Martin signature.asc Description: This is a digitally signed message part -- 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 11:07 +0200, Kevin Kofler wrote: > David Malcolm wrote: > > I think that a distinction can be made between core packages that many > > different components depend upon versus "leaf" packages that do their > > own thing and no other component relies on. I do think we should be > > conservative when updating core components in released versions of > > Fedora; with rawhide much less so. But perhaps "leaf" packages can have > > a less conservative policy. > > Well, a backwards-compatible update to a core library isn't normally a > problem. Of course it doesn't make sense to push a soname bump of something > like Boost to a stable release. An update of something guaranteeing > backwards binary compatibility, e.g. Qt or KDE, on the other hand, is quite > safe to push, after adequate testing. And "leaf" also needs to be qualified, > a library that's used by only a small number of applications can be updated > to a binary-incompatible version in a grouped update with the affected > applications: for example, this has often been done to add new hardware > support to libmtp and a few other such libraries, and those updates have > been very nice for the people with the affected hardware and didn't cause > any trouble for anyone else. > IMHO, labriaries should be updated in stable release only if there's no backwards-incompatible change or if there's a really strong reason to update that outweights the problems caused by API/ABI change. We could probably be much more lenient with end-user apss, but proper testing is always a must (and yes, more testers would be *very* helpful). Seeing your mail, you more or less agree with this. So why exactly are you against the policy explicitly requiring either positive karma or some minimal time in testing (setting aside some current shrotcommings of the implementation like resetting the timer on bug update when you just add/remove fixed bug or edit update comment)? Martin signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Sat, 14 Aug 2010 11:33:02 +0200, Kevin wrote: > > I've always warned about mass-pushing updates to multiple dists, > > and I'm glad I'm not the only one. > > EPEL is an entirely different matter, since: > * there are literally YEARS between the RHEL releases and > * RHEL has a very conservative update model, exacerbating the differences > between releases. > > This kind of trouble is much less likely in Fedora (proper) than in EPEL. IMO, that's splitting-hairs. Since I don't have the time to fill this list with dozens of messages, probably this one will be the last for today in this thread. It doesn't matter much if it's "less likely" or "likely". We've had minor version upgrades of libraries that broke the API and the ABI and lead to app misbehaviour at run-time. Syncing all of Fedora N with Fedora N+1 is not an option, or else we would arrive at the rolling-release model and would not need to prepare "final releases" and distinguish between Fedora N and N+1. If only *some* components are replaced after the final dist release, we basically need to redo the integration testing for each and every update. And that hasn't been done so far. Not for changes in Python modules, and not for other packages either. Broken deps are just the tip of the iceberg. An unresolvable dep is a show-stopper, as it makes installing an update impossible. But packagers, who mass-build upgrades to multiple dists and mark them "stable" without testing for each of the targeted dist, make it worse. It's a packager's attitude problem. Mass-building updates for multiple dists bears risks. Adding EPEL as additional target for the same updates adds an extra problem. [Currently, some EPEL packagers admit they haven't done any testing at all because they don't run a corresponding EL dist installation.] P.S. I'm not completely positive about the extra hurdles in bodhi either (or crap like inheritance of Update Notes), but that is unrelated to my view about "testing" and lack thereof. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
W dniu 14.08.2010 00:12, Kevin Fenzi pisze: > On Fri, 13 Aug 2010 23:17:39 +0200 > Sven Lankes wrote: > >> On Fri, Aug 13, 2010 at 07:21:50PM +0200, Martin Sourada wrote: >> >>> 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? >> >> I don't think that this about the KDE SIG at all. >> >> Not everyone is as passionate (or stubborn) as Kevin. > > I agree. > >> Most fedorians I talk to are watching all the discussions to see if >> the fedora that is currently being formed with all the changes that >> are happening is still a distribution that they're comfortable >> contributing to. And as the only way to get heard is to fuel a >> flamewar on fedora-devel they just stay silent. > > I think the flamewars are making people think this is a bigger deal > than it really is. > >>> [...] I'm for more testing and more conservative update policy in >>> general in stable branches. >> >> I don't oppose the ongoing changes in general but still - when I read >> through fesco meeting logs I am often disappointed by the amount of >> politics going on and more than once I wished that FESCO as a whole >> would grow a pair. > > Can you expand on that? I'm not sure what you mean... > >> I for one have decided that I'm going to stop contributing if the >> 'Stable Update Vision' is going to be implemented as currently >> discussed. If the powers that be are going to stop maintainers from >> issuing updates that are not security or bugfix updates then fedora >> will have turned into a distro that I'm not interested in. > > Bring your concerns to the Board that issued the vision statement? > > I personally think the "just security and bugfixes" is too strong. > I am going to try and push for an exceptions process that takes into > account upstreams that don't release in a way thats compatible with > fedora's release cycle. > > I hope you won't be hasty and will try and work with whatever framework > we end up with and help us adjust it. > > kevin > One should also keep in mind that asking maintainers to backport bugfixes effectively raises the bar for being one. While some large projects (firefox, gnome) maintain older branches and issue fixes to them, the vast majority of smaller projects just leave the old releases out cold, requiring the maintainer to do all the work which could be simply avoided by tracking upstream. I, for one, have next to none coding skills and I'm pretty sure I won't be able to backport bugfixes if the code paths diverge too much. Why can't we just leave that up to maintainers whether an update can be introduced smoothly enough to a released fedora? One size fits all will basically make us rhel with a more frequent release cycle. Also, how often was a huge breakage introduced by kde sig? They track upstream closely, and how does that work out? Julian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
W dniu 14.08.2010 11:08, Kevin Kofler pisze: > Adam Williamson wrote: > >> On Fri, 2010-08-13 at 17:54 +0200, Kevin Kofler wrote: >>> in the past due to regressions which are already fixed in the current >>> edited version. (Yes, update groups will be edited instead of obsoleted >>> if we >> >> Please stop mixing minor bugs in the process in with high-flown rhetoric >> about the bureaucratic Board and whatever. This is simply a bug (or, >> possibly, an incomplete design; whatever you want to call it), in Bodhi. >> I think it's even already been reported and is planned to be addressed >> in future Bodhi. Luke? > > How do you want to address this? By resetting the karma to 0 on any edit? > That just makes the problem even worse, because it means editing will also > lose all the positive karma. > > Kevin Kofler > This is just a consequence. If the timer is to be reset, so should be the karma or vice-versa. Julian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Michael Schwendt wrote: > +1, +10, +1000 … happens with Fedora and also with Fedora EPEL. > I've always warned about mass-pushing updates to multiple dists, > and I'm glad I'm not the only one. EPEL is an entirely different matter, since: * there are literally YEARS between the RHEL releases and * RHEL has a very conservative update model, exacerbating the differences between releases. This kind of trouble is much less likely in Fedora (proper) than in EPEL. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 13 Aug 2010 12:12:47 -0400, seth wrote: > On Fri, 2010-08-13 at 18:07 +0200, Kevin Kofler wrote: > > Al Dunsmuir wrote: > > > You are assuming that it is somehow a good idea to push release Fn, in > > > spite of no (or negative) testing. > > > > Yes I am! If I build the EXACT SAME specfile for all F*, then I don't see > > why testing on ANY F* isn't sufficient. Please don't bring the same old > > argument that "sometimes" breakage happens only on some releases even with > > the same specfile: in practice this is so rare that it doesn't matter at > > all, it's much more likely that regressions slip through despite the > > testing. > > > Last week I pushed a yum update to f12, f13 and f14 - same pkg, same > patches, same config. > > On f12, however, the version of sqlite that f12 had handles an error > condition differently than on f13 and f14. It meant that instead of > raise an exception and letting us move along that it raised an exception > and then exited. > > So - the pkg checked out on f13 and f14 just fine but not on f12. > > I had to issue a new update for all of them to keep them in sync. > > That's a real world case that happens all the time. +1, +10, +1000 … happens with Fedora and also with Fedora EPEL. I've always warned about mass-pushing updates to multiple dists, and I'm glad I'm not the only one. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Adam Williamson wrote: > On Fri, 2010-08-13 at 17:54 +0200, Kevin Kofler wrote: >> in the past due to regressions which are already fixed in the current >> edited version. (Yes, update groups will be edited instead of obsoleted >> if we > > Please stop mixing minor bugs in the process in with high-flown rhetoric > about the bureaucratic Board and whatever. This is simply a bug (or, > possibly, an incomplete design; whatever you want to call it), in Bodhi. > I think it's even already been reported and is planned to be addressed > in future Bodhi. Luke? How do you want to address this? By resetting the karma to 0 on any edit? That just makes the problem even worse, because it means editing will also lose all the positive karma. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
David Malcolm wrote: > I think that a distinction can be made between core packages that many > different components depend upon versus "leaf" packages that do their > own thing and no other component relies on. I do think we should be > conservative when updating core components in released versions of > Fedora; with rawhide much less so. But perhaps "leaf" packages can have > a less conservative policy. Well, a backwards-compatible update to a core library isn't normally a problem. Of course it doesn't make sense to push a soname bump of something like Boost to a stable release. An update of something guaranteeing backwards binary compatibility, e.g. Qt or KDE, on the other hand, is quite safe to push, after adequate testing. And "leaf" also needs to be qualified, a library that's used by only a small number of applications can be updated to a binary-incompatible version in a grouped update with the affected applications: for example, this has often been done to add new hardware support to libmtp and a few other such libraries, and those updates have been very nice for the people with the affected hardware and didn't cause any trouble for anyone else. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Sven Lankes wrote: > I for one have decided that I'm going to stop contributing if the > 'Stable Update Vision' is going to be implemented as currently > discussed. If the powers that be are going to stop maintainers from > issuing updates that are not security or bugfix updates then fedora will > have turned into a distro that I'm not interested in. I'm also considering this, but I don't really know what distro I could switch to. The Fedora way was a unique way, there's really no other distribution working that way. That's why I have such strong feeling, I see something unique being taken away from under us, in favor of something that's just a boring clone of Ubuntu. In fact, that vision reads like a precise description of Ubuntu. I think that Fedora is going to lose many contributors and users over those changes. Those that remain will be drawn to third-party repositories providing updates, just like Ubuntu's PPAs. (They may or may not use the repos.fedorapeople.org infrastructure for that, depending on how well you manage to make it not suck. Right now, it offers little to no benefits over infrastructure people can come up with themselves.) Maintainers will push their stuff to Rawhide and to a third-party repository for releases and just not support it in releases at all, closing all the bugs as RAWHIDE. (We cannot realistically expect maintainers to backport all the bug fixes when upstream no longer supports the branch that shipped in the given Fedora release, and in fact most of the proponents of conservative updates don't even want them to do that, they often want only "critical" bugs fixed, or only bugs explicitly filed in our Bugzilla (which is already not feasible for some packages by backports only).) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Martin Sourada wrote: > There are also bazillion distributions out there who are on the bleeding > edge. But none that have the current stuff without blatant breakage as updates to the stable releases, and ship the exciting but disruptive changes in new releases every 6 months, while still supporting the previous release for 7 more months from that point. There's a balance between bleeding edge and conservativeness. Fedora was exactly where I, and many other people, who chose Fedora exactly for that reason (just look at some of the user feedback, e.g. Adam Williamson's poll on the Fedora Forums, some mails to the k...@lists.fp.o ML etc., I'm not inventing that "many other people" part), wanted it to be on that balance (except for some odd packages like Firefox and OO.o where the maintainers did their own thing, basically already following what the new unwanted policy will be). Now new policies are tilting the scale way too far towards conservativeness, to the point where we don't distinguish us anymore from other distributions; Rawhide, on the other hand, is way too far on the bleeding edge end to be usable for daily use, and this is exactly the issue with other "bleeding edge" distributions as well. Not all new upstream versions are equal. New versions with major changes, especially feature regressions, are NOT suitable as updates to a stable work environment. Version upgrades WITHOUT such breakage ARE suitable, and actually WANTED as updates. For example, people EXPECT to be able to use the latest Firefox (and have complained about the Firefox maintainer being too conservative with his updates), the latest KDE (and have praised KDE SIG for being so effective at pushing new versions) etc. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri 13 August 2010 11:36:09 Chris Adams wrote: > Once upon a time, Kevin Kofler said: > > If we really are the only ones true to Fedora's original principles > > As I recall, "upstream, upstream, upstream" was one of those principles > that you are demanding others now break. And the same policy that YOU (you as in the Board and FESCo, not Chris Adams in particular) are asking us to break with the updates policy and general distaste for a fast moving distro. When it comes down to it, KDE and The Board's Fedora simply don't work together, and that is basically what Kev is getting so miffed about, as far as I can tell. Yes, he's loud, yes he's fiery, but damn, at least he cares, and I don't blame him for caring. He's put a lot of heart and a lot of effort into Fedora, as has everyone in the KDE SIG, and the entire Project. We could fork, hell the KDE SIG has talked about it in the past, but it hurts everyone involved. Everyone. I've put a lot of thought into simply stepping away from Fedora, at least on the KDE end of things if these changes go through because, in some ways, the Board's vision will change things for us, and for me in particular. I joined Fedora as a distribution whose goals and processes catered towards creating a KDE environment which simply kicked ass, was always on the edge of what was 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? If we're a distro pushing the development of open source, shouldn't we be pushing it towards those types of users? We could make rawhide usable, but that can stub development of some major features, it's a tough medium. We could fork Fn+1 even earlier, and make it stabler and have 12 months in Rawhide... There are solutions to our problems, but endless bickering and "oh you should just leave!"s aren't going to solve anything and just leave everyone in a pissy and unproductive mood. Personally, it depresses the hell out of me. Btw, everyone seems to be acting really unexcellent to each other... I'm not calling anyone, but both "sides" of this are really getting out of control... Please keep the mailing list friendly. We don't "have" hall monitors anymore, but reading this mailing list shouldn't effect my blood pressure as much as it does. Ryan "just another POV, back to the shadows" Rix -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == == http://rix.si/page/contact/ if you need a word == signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 2010-08-13 at 17:54 +0200, Kevin Kofler wrote: > Till Maas wrote: > > Bodhi also allows you to edit the stable karma value and unless it is > > implemented differently (or has changed again), you can just use a > > stable karma value of 1 and ask someone except the update submitter to > > provide the +1 karma and the update can be pushed to stable. This is > > imho reasonable even after only a one line change to a build. > > You still need to get somebody to +1 the update, and more if people -1ed it This is *really* not an onerous requirement. It simply means 'have one other person - any other person in the world with a FAS account - run your code and make sure it actually works before you release it'. If you don't think that's a good idea, well, I'm not sure what to say. > in the past due to regressions which are already fixed in the current edited > version. (Yes, update groups will be edited instead of obsoleted if we Please stop mixing minor bugs in the process in with high-flown rhetoric about the bureaucratic Board and whatever. This is simply a bug (or, possibly, an incomplete design; whatever you want to call it), in Bodhi. I think it's even already been reported and is planned to be addressed in future Bodhi. Luke? -- 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
On 08/13/2010 10:16 AM, Till Maas wrote: > On Thu, Aug 12, 2010 at 05:57:28PM -0400, Luke Macken wrote: > >> - Show 7 days worth of entries in our RSS feeds, as opposed to 20 >> entries (https://fedorahosted.org/bodhi/ticket/339) > > This is nice, I forgot to add myself to the CC list, so I did not notice > this before. > >> - Only verify the autokarma thresholds if it is enabled (Thanks to >> Till Maas) > > This is still faulty. Is there a way to get access to a running bodhi > instance that I can patch and test directly? A local instance set up > according to > https://fedorahosted.org/bodhi/wiki/Development > does not allow to edit updates, because of tagging problems. Making this > possible would of course be great. I just pushed out a fix that should allow you to edit updates with your local development instance. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 2010-08-13 at 16:12 -0600, Kevin Fenzi wrote: > On Fri, 13 Aug 2010 23:17:39 +0200 > Sven Lankes wrote: > > > On Fri, Aug 13, 2010 at 07:21:50PM +0200, Martin Sourada wrote: > > > > > 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? > > > > I don't think that this about the KDE SIG at all. > > > > Not everyone is as passionate (or stubborn) as Kevin. > > I agree. > > > Most fedorians I talk to are watching all the discussions to see if > > the fedora that is currently being formed with all the changes that > > are happening is still a distribution that they're comfortable > > contributing to. And as the only way to get heard is to fuel a > > flamewar on fedora-devel they just stay silent. > > I think the flamewars are making people think this is a bigger deal > than it really is. > > > > [...] I'm for more testing and more conservative update policy in > > > general in stable branches. > > > > I don't oppose the ongoing changes in general but still - when I read > > through fesco meeting logs I am often disappointed by the amount of > > politics going on and more than once I wished that FESCO as a whole > > would grow a pair. > > Can you expand on that? I'm not sure what you mean... > > > I for one have decided that I'm going to stop contributing if the > > 'Stable Update Vision' is going to be implemented as currently > > discussed. If the powers that be are going to stop maintainers from > > issuing updates that are not security or bugfix updates then fedora > > will have turned into a distro that I'm not interested in. > > Bring your concerns to the Board that issued the vision statement? > > I personally think the "just security and bugfixes" is too strong. > I am going to try and push for an exceptions process that takes into > account upstreams that don't release in a way thats compatible with > fedora's release cycle. I think that a distinction can be made between core packages that many different components depend upon versus "leaf" packages that do their own thing and no other component relies on. I do think we should be conservative when updating core components in released versions of Fedora; with rawhide much less so. But perhaps "leaf" packages can have a less conservative policy. When it comes to package updates, I don't think "one size fits all". I wrote up some notes on other possible variables that should be considered back in March here: http://dmalcolm.livejournal.com/5013.html My hope is that it ought to be possible to take the variables I mention in that blog post and come up with some kind of coherent policy that everyone is happy with, or, at least, not unhappy. > I hope you won't be hasty and will try and work with whatever framework > we end up with and help us adjust it. Agreed Hope this is helpful Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 13 Aug 2010 23:17:39 +0200 Sven Lankes wrote: > On Fri, Aug 13, 2010 at 07:21:50PM +0200, Martin Sourada wrote: > > > 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? > > I don't think that this about the KDE SIG at all. > > Not everyone is as passionate (or stubborn) as Kevin. I agree. > Most fedorians I talk to are watching all the discussions to see if > the fedora that is currently being formed with all the changes that > are happening is still a distribution that they're comfortable > contributing to. And as the only way to get heard is to fuel a > flamewar on fedora-devel they just stay silent. I think the flamewars are making people think this is a bigger deal than it really is. > > [...] I'm for more testing and more conservative update policy in > > general in stable branches. > > I don't oppose the ongoing changes in general but still - when I read > through fesco meeting logs I am often disappointed by the amount of > politics going on and more than once I wished that FESCO as a whole > would grow a pair. Can you expand on that? I'm not sure what you mean... > I for one have decided that I'm going to stop contributing if the > 'Stable Update Vision' is going to be implemented as currently > discussed. If the powers that be are going to stop maintainers from > issuing updates that are not security or bugfix updates then fedora > will have turned into a distro that I'm not interested in. Bring your concerns to the Board that issued the vision statement? I personally think the "just security and bugfixes" is too strong. I am going to try and push for an exceptions process that takes into account upstreams that don't release in a way thats compatible with fedora's release cycle. I hope you won't be hasty and will try and work with whatever framework we end up with and help us adjust it. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 13 Aug 2010 15:39:59 -0400 Toshio Kuratomi wrote: > I'm negative towards this change and not part of the KDE SIG but don't > really like to clutter up the mailing lists with a bunch of negative > energy. And I don't like the way it makes me feel about Fedora to > continually try to get a compromise solution that accomodates > everyone when none of the parties with the power to change things > want to be reasonable. (This is probably an oversimplification I > know at least one person who sat on FESCo at the time of this change > being passed feeling the same way I do about needing a compromise and > not being heard when they tried to ask for one. Ironically, they are > right that they were drowned out by the combative voices on both > sides... I don't even remember when they mentioned the compromise > solution there were so many other strident voices.) Yeah. I for one appreciate your collecting ideas and helping to try and broker a compromise, even though this didn't end up happening. ;( Sorry you feel negative about the changes. > 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. I would like folks to keep in mind a few other things: 1. We are changing things to help improve stability of our stable releases. These changes may fail to help, or may be too far toward the stable side of things. We can adjust them and revise them, but give them a chance first? 2. FESCo is working on implementing the Board's "Stable release vision": https://fedoraproject.org/wiki/Stable_release_updates_vision and our implementation containers: https://fedorahosted.org/fesco/ticket/382 https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas Not to pass the buck, but if you have issues with the Stable release updates vision from the Board, you can talk to them on their list about it. If you have issues with our implementation of it, feel free to chime in with constructive ideas above or on this list. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, Aug 13, 2010 at 07:21:50PM +0200, Martin Sourada wrote: > 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? I don't think that this about the KDE SIG at all. Not everyone is as passionate (or stubborn) as Kevin. Most fedorians I talk to are watching all the discussions to see if the fedora that is currently being formed with all the changes that are happening is still a distribution that they're comfortable contributing to. And as the only way to get heard is to fuel a flamewar on fedora-devel they just stay silent. > [...] I'm for more testing and more conservative update policy in > general in stable branches. I don't oppose the ongoing changes in general but still - when I read through fesco meeting logs I am often disappointed by the amount of politics going on and more than once I wished that FESCO as a whole would grow a pair. I for one have decided that I'm going to stop contributing if the 'Stable Update Vision' is going to be implemented as currently discussed. If the powers that be are going to stop maintainers from issuing updates that are not security or bugfix updates then fedora will have turned into a distro that I'm not interested in. -- sven === jabber/xmpp: s...@lankes.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
W dniu 13.08.2010 01:12, Orcan Ogetbil pisze: > On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote: >> - Minimum time-in-testing requirements >> - Every day bodhi will look for updates that have been >> in testing for N days (fedora: N=7, epel: N=14), and will >> add a comment notifying the maintainer that the update is >> now able to be pushed to stable. > > Suppose I submit a package to testing and it gets pushed. Six days > later, I find a terrible bug in the package (or a user reports this to > me). I fix the package and edit the update, request the fixed package > to be pushed to testing again and it gets pushed the next day. > > Now without any further testing the package can be pushed to stable, > which contradicts the purpose of this whole change in bodhi. > > I think, for packages that are modified during the testing period, > this N should be calculated from the day the last push was made to > testing. > > Orcan Is the karma getting reset upon an edit? Julian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 2010-08-13 at 20:14 +0200, Kevin Kofler wrote: > Martin Sourada wrote: > > 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? > > If we really are the only ones true to Fedora's original principles, who > don't want us to become yet another redundant conservative distribution > (like all those bazillion others out there), that's really sad. :-( > Oh, yeah, to that fedora where every third upgrade broke half of desktop and another had broken deps... (sarcastic exaggeration intended). There are also bazillion distributions out there who are on the bleeding edge. Being conservative with our stable releases while innovative in rawhide is what fedora should strive to be (with the usually friendly atmosphere among the contributors and "upstream, upstream, upstream"). > Kevin Kofler > (who wants the Fedora he learned to love back!) Martin Sourada (who wants *stable* releases of Fedora to be stable and not another rawhide) signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 2010-08-13 at 20:17 +0200, Kevin Kofler wrote: > Martin Sourada wrote: > > 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? > > Oh, and FYI, Ralf Corsepius is not in KDE SIG. Yet, he also doesn't like > this policy, as you can clearly see from his replies in this thread and > elsewhere. So your impression is wrong. > My bad... Martin signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, Aug 13, 2010 at 07:21:50PM +0200, 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? > > Basically from both user and maintainer point of view I'm for more > testing and more conservative update policy in general in stable > branches. > I'm negative towards this change and not part of the KDE SIG but don't really like to clutter up the mailing lists with a bunch of negative energy. And I don't like the way it makes me feel about Fedora to continually try to get a compromise solution that accomodates everyone when none of the parties with the power to change things want to be reasonable. (This is probably an oversimplification I know at least one person who sat on FESCo at the time of this change being passed feeling the same way I do about needing a compromise and not being heard when they tried to ask for one. Ironically, they are right that they were drowned out by the combative voices on both sides... I don't even remember when they mentioned the compromise solution there were so many other strident voices.) 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. -Toshio pgp6RdOoVGLZF.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, Aug 13, 2010 at 08:20:04PM +0200, Kevin Kofler wrote: > Chris Adams wrote: > > What if it isn't a bug, but just different behavior? > > Do you really think it's acceptable for a library to terminate the whole > application when an error happens??? There's a reason rpmlint complains > loudly about "shared-library-calls-exit". > The way I read skvidal's post was that the exception being issued changed. Yum was coded to catch the exception that was being issued with later versions of sqlite. Testing on f12 discovered that the older sqlite used a different exception. -Toshio pgpEoCYaDd4t4.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Bug or not, changing the behavior of a library is not something to be done without coordination and consideration and cooperation. Our releases are not rawhide, stuff can't be rammed in whenever upstream bumps a number. We are off on a tangent here, the point is that our releases have different software versions and act different in real life ways. This is just the current example. -- Sent from my Android phone. Please excuse my brevity, lack of trimming, and top posting. "Kevin Kofler" wrote: >Jesse Keating wrote: >> Doing so would have changed behavior and broken software that relied upon >> that behavior. Sounds like a great way to run the distro > >Software relying on an error in a library to terminate the whole >application, as opposed to raising an interceptable exception? Is there >really such a thing?! > >Kevin Kofler > >-- >devel mailing list >devel@lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Jesse Keating wrote: > Doing so would have changed behavior and broken software that relied upon > that behavior. Sounds like a great way to run the distro Software relying on an error in a library to terminate the whole application, as opposed to raising an interceptable exception? Is there really such a thing?! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Once upon a time, Kevin Kofler said: > If we really are the only ones true to Fedora's original principles As I recall, "upstream, upstream, upstream" was one of those principles that you are demanding others now break. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Till Maas wrote: > The same people that provided the -1 karma can provide a +1 karma. And > you only need have of these people to change their karma vote to get > back to zero karma. This should also not be a major problem, unless > there are people providing unjustified -1 karma to cause problems. But > you did not mention this. People often provide well-meaning, but ultimately unjustified -1 karma. E.g. we've often had -1 votes for regressions caused by some other package in a completely different update or update set, or even for Bodhi or PackageKit bugs which affect all updates and which don't affect the functionality of the update in any way, just its display. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Martin Sourada wrote: > 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? Oh, and FYI, Ralf Corsepius is not in KDE SIG. Yet, he also doesn't like this policy, as you can clearly see from his replies in this thread and elsewhere. So your impression is wrong. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Chris Adams wrote: > What if it isn't a bug, but just different behavior? Do you really think it's acceptable for a library to terminate the whole application when an error happens??? There's a reason rpmlint complains loudly about "shared-library-calls-exit". Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/13/2010 01:23 PM, Jesse Keating wrote: > Doing so would have changed behavior and broken software that relied upon > that behavior. Sounds like a great way to run the distro > With that attitude, how would we ever change gcc versions in a stable release? ;) -J > "Kevin Kofler" wrote: > >> seth vidal wrote: >>> and that's what the testing helped with. The bug was noticed. It was >>> patched upstream to accomodate the versions of sqlite that act >>> differently and we moved along. >>> >>> So, in fact, testing worked exactly as we wanted it to. >> But if SQLite had consistently been tracking upstream bugfix releases, this >> F12-only breakage wouldn't have happened in the first place. >> >> Kevin Kofler >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel -- - in your fear, speak only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 2010-08-13 at 20:14 +0200, Kevin Kofler wrote: > Martin Sourada wrote: > > 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? > > If we really are the only ones true to Fedora's original principles, who > don't want us to become yet another redundant conservative distribution > (like all those bazillion others out there), that's really sad. :-( > > Kevin Kofler > (who wants the Fedora he learned to love back!) It is not the fedora you think it is. You can go form your own distro. Please leave us to work on ours in peace and relative quiet. I hear Bero could use some help with arklinux. kthxbai -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Doing so would have changed behavior and broken software that relied upon that behavior. Sounds like a great way to run the distro "Kevin Kofler" wrote: >seth vidal wrote: >> and that's what the testing helped with. The bug was noticed. It was >> patched upstream to accomodate the versions of sqlite that act >> differently and we moved along. >> >> So, in fact, testing worked exactly as we wanted it to. > >But if SQLite had consistently been tracking upstream bugfix releases, this >F12-only breakage wouldn't have happened in the first place. > >Kevin Kofler > >-- >devel mailing list >devel@lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/devel -- Sent from my Android phone with. Please excuse my brevity and top posting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
seth vidal wrote: > and that's what the testing helped with. The bug was noticed. It was > patched upstream to accomodate the versions of sqlite that act > differently and we moved along. > > So, in fact, testing worked exactly as we wanted it to. But if SQLite had consistently been tracking upstream bugfix releases, this F12-only breakage wouldn't have happened in the first place. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Martin Sourada wrote: > 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? If we really are the only ones true to Fedora's original principles, who don't want us to become yet another redundant conservative distribution (like all those bazillion others out there), that's really sad. :-( Kevin Kofler (who wants the Fedora he learned to love back!) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 2010-08-13 at 12:43 -0500, Chris Adams wrote: > Once upon a time, Kevin Kofler said: > > I tried many things, even running for FESCo and getting voted in. As you > > can > > see, it didn't achieve anything either. > > Is it impossible for you to accept the fact that not everybody agrees > with you on the direction of Fedora, and that maybe (just maybe) you are > in the minority? Yes. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Once upon a time, Kevin Kofler said: > The people who voted them in were a small minority As were the people that voted you in. Does that invalidate your FESCo standing as well? > I tried many things, even running for FESCo and getting voted in. As you can > see, it didn't achieve anything either. Is it impossible for you to accept the fact that not everybody agrees with you on the direction of Fedora, and that maybe (just maybe) you are in the minority? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Once upon a time, Kevin Kofler said: > Jesse Keating wrote: > > This is where Kevin blames the scenario on not having the same sqlite on > > all of the Fedora releases, which is another evil plot hatched by the > > devils of FESCo > > Right. If F12 has a buggy SQLite, then that SQLite should be fixed! What if it isn't a bug, but just different behavior? To do such an update in F12, you need to audit the other users of SQLite (of which there are many) and check them against a new version, possibly updating many dependent packages as well. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 2010-08-13 at 13:30 -0400, Al Dunsmuir wrote: > On Friday, August 13, 2010, 1:11:49 PM, Kevin wrote: > > Jesse Keating wrote: > >> This is where Kevin blames the scenario on not having the same sqlite on > >> all of the Fedora releases, which is another evil plot hatched by the > >> devils of FESCo > > > Right. If F12 has a buggy SQLite, then that SQLite should be fixed! > > Kevin Kofler > > If the SQLite bug can be fixed, then it should be done and the package > that found the bug should be updated to list that version as a minimum > requirement. That dependency change requires at least an install > test. > > If the bug can not be fixed in F12 in a compatible way, then the > package that found the bug may need to take a different approach and > find a new way of doing things that works in all supported SQLite > releases. > > In either case, releasing things to stable before the regression is > eliminated should not be an option. > Al and that's what the testing helped with. The bug was noticed. It was patched upstream to accomodate the versions of sqlite that act differently and we moved along. So, in fact, testing worked exactly as we wanted it to. -sv -- 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, 1:11:49 PM, Kevin wrote: > Jesse Keating wrote: >> This is where Kevin blames the scenario on not having the same sqlite on >> all of the Fedora releases, which is another evil plot hatched by the >> devils of FESCo > Right. If F12 has a buggy SQLite, then that SQLite should be fixed! > Kevin Kofler If the SQLite bug can be fixed, then it should be done and the package that found the bug should be updated to list that version as a minimum requirement. That dependency change requires at least an install test. If the bug can not be fixed in F12 in a compatible way, then the package that found the bug may need to take a different approach and find a new way of doing things that works in all supported SQLite releases. In either case, releasing things to stable before the regression is eliminated should not be an option. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
seth vidal wrote: > On f12, however, the version of sqlite that f12 had handles an error > condition differently than on f13 and f14. It meant that instead of > raise an exception and letting us move along that it raised an exception > and then exited. Jesse already anticipated my reply there. :-) The SQLite in F12 needs to be fixed, and in fact should ALREADY have been fixed by proactively pushing upstream bug fixes instead of waiting for a Fedora user to complain. > I had to issue a new update for all of them to keep them in sync. Isn't that what the -n.fc12.1 versioning scheme is for? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, Aug 13, 2010 at 05:54:30PM +0200, Kevin Kofler wrote: > Till Maas wrote: > > Bodhi also allows you to edit the stable karma value and unless it is > > implemented differently (or has changed again), you can just use a > > stable karma value of 1 and ask someone except the update submitter to > > provide the +1 karma and the update can be pushed to stable. This is > > imho reasonable even after only a one line change to a build. > > You still need to get somebody to +1 the update, Yes, this is what I wrote. And I think it is reasonable. Especially with the whole Plasma SIG, which are probably more than two people, you should have no problem finding them. >and more if people -1ed it > in the past due to regressions which are already fixed in the current edited > version. (Yes, update groups will be edited instead of obsoleted if we The same people that provided the -1 karma can provide a +1 karma. And you only need have of these people to change their karma vote to get back to zero karma. This should also not be a major problem, unless there are people providing unjustified -1 karma to cause problems. But you did not mention this. Regards Till pgpVhyJdPobbH.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
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? Basically from both user and maintainer point of view I'm for more testing and more conservative update policy in general in stable branches. Cheers, Martin signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Jesse Keating wrote: > This is where Kevin blames the scenario on not having the same sqlite on > all of the Fedora releases, which is another evil plot hatched by the > devils of FESCo Right. If F12 has a buggy SQLite, then that SQLite should be fixed! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Luke Macken wrote: > The only case for update starvation that I can think of is if you keep > adding/removing builds from an update before it reaches a week in > testing or the karma thresholds. For any large update group, that's just always going to happen. There's always another important fix you need to get in. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/13/2010 06:45 PM, Luke Macken wrote: > On 08/13/2010 01:57 AM, Ralf Corsepius wrote: >> On 08/13/2010 01:23 AM, Luke Macken wrote: >>> On 08/12/2010 07:12 PM, Orcan Ogetbil wrote: On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote: > - Minimum time-in-testing requirements > - Every day bodhi will look for updates that have been > in testing for N days (fedora: N=7, epel: N=14), and will > add a comment notifying the maintainer that the update is > now able to be pushed to stable. Suppose I submit a package to testing and it gets pushed. Six days later, I find a terrible bug in the package (or a user reports this to me). I fix the package and edit the update, request the fixed package to be pushed to testing again and it gets pushed the next day. Now without any further testing the package can be pushed to stable, which contradicts the purpose of this whole change in bodhi. I think, for packages that are modified during the testing period, this N should be calculated from the day the last push was made to testing. >> >> This would very unhelpful. >> >>> Yes, this was my initial intention. However, looking at the code a bit >>> closer, your scenario would currently be allowed, as it currently only >>> calculates the time-in-testing based on the first push to testing. >> This behavior is helpful, because otherwise updates would "starve". > > The only case for update starvation that I can think of is if you keep > adding/removing builds from an update before it reaches a week in > testing or the karma thresholds. C.f. my other mail - Such cases happen. Another scenario I haven't mentioned yet is packaging bugs. One day, a packager fixes one, 4 days later he (or a tester) notices another one, fixes it, 6 days later the next one is being fixed, ... ad infinitum. Now take dependency chains into account ... Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/13/2010 05:10 PM, Kevin Kofler wrote: > Ralf Corsepius wrote: I think, for packages that are modified during the testing period, this N should be calculated from the day the last push was made to testing. >> >> This would very unhelpful. >> >>> Yes, this was my initial intention. However, looking at the code a bit >>> closer, your scenario would currently be allowed, as it currently only >>> calculates the time-in-testing based on the first push to testing. >> This behavior is helpful, because otherwise updates would "starve". > > +1 > > Once again, we're in violent agreement! Real world case I've occasionally encountered: I submitted a package to testing. It did not receive any feedback, however I started using it. Several weeks later, I notice another (often minor) bug and fix it with a "few liner patch" rsp. upstream releases a new "minor bug fix release". With the new procedure, I have 2 choices: 1. Push the known to be buggy package to avoid this timer to be reset, knowingly exposing the users to this bug and the bugs this update was supposed to fix. 2. Push an update comprising resetting the timer. => Users will have to wait another timeout period for the bugs they are waiting to see fixed. Neither of both choices are helpful. With the timer not being reset, I could push the package with the "new bug fix applied", knowing the package would not immediately malfunction and would have the "new fix" applied. Another similar, scenario is upstreams releasing packages in a higher frequency than fedora can handle them. Though these cases are fairly rare, I also have seen them happen (Classical case: upstream release update, package makes it into Fedora, Several weeks/months later, upstream notices major problems and releases "hot fix releases" at high frequency). Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/12/2010 07:47 PM, Orcan Ogetbil wrote: > On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote: >>- Minimum time-in-testing requirements >>- When someone tries to push an update to stable, bodhi will >> look to see if it has the appropriate karma, or if it has >> been in testing for more than N days. > > I have another question: > > What happens if a package is submitted to testing the same day on > F-(x) and F-(x+1), then the F-(x) package reaches +3 karma the next > day and is automatically pushed to stable? Let's say the F-(x+1) > package still has 0 karma (or maybe even negative karma). > > The F-(x) package will have higher EVR than the F-(x+1) one. This > will break the upgrade path. Is there any measures to prevent this? Bodhi checks for broken upgrade paths upon submission, but this would not mitigate the breakage that you describe here. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Nathanael D. Noblet wrote: > However you don't want to let other people decide anything. You want > patches FF and kernel in so you get to do it, you want to push updates > without any testing required so you get to. To hell with whatever anyone > else wants, and when there is an organization put in place to dictate > the rules by which we all play. They have the right to dictate these > rules because the group voted them in, and the majority of them decide > one way. It just happens not to be with what you think. The people who voted them in were a small minority (most eligible contributors don't vote), plus they didn't necessarily have the choice of candidates they'd have liked to have (I know I didn't, to me those candidates were a choice between the devil and the beelzebub). Our voting system just doesn't work. I tried many things, even running for FESCo and getting voted in. As you can see, it didn't achieve anything either. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/13/2010 01:57 AM, Ralf Corsepius wrote: > On 08/13/2010 01:23 AM, Luke Macken wrote: >> On 08/12/2010 07:12 PM, Orcan Ogetbil wrote: >>> On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote: - Minimum time-in-testing requirements - Every day bodhi will look for updates that have been in testing for N days (fedora: N=7, epel: N=14), and will add a comment notifying the maintainer that the update is now able to be pushed to stable. >>> >>> Suppose I submit a package to testing and it gets pushed. Six days >>> later, I find a terrible bug in the package (or a user reports this to >>> me). I fix the package and edit the update, request the fixed package >>> to be pushed to testing again and it gets pushed the next day. >>> >>> Now without any further testing the package can be pushed to stable, >>> which contradicts the purpose of this whole change in bodhi. >>> >>> I think, for packages that are modified during the testing period, >>> this N should be calculated from the day the last push was made to >>> testing. > > This would very unhelpful. > >> Yes, this was my initial intention. However, looking at the code a bit >> closer, your scenario would currently be allowed, as it currently only >> calculates the time-in-testing based on the first push to testing. > This behavior is helpful, because otherwise updates would "starve". The only case for update starvation that I can think of is if you keep adding/removing builds from an update before it reaches a week in testing or the karma thresholds. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/13/2010 11:29 AM, Till Maas wrote: > On Fri, Aug 13, 2010 at 01:27:18AM +0200, Kevin Kofler wrote: > >> "fix" breaks that. Plus, edits can also be only to the description or bug >> references, Bodhi doesn't allow me to edit those without editing the whole >> update. > > Bodhi also allows you to edit the stable karma value and unless it is > implemented differently (or has changed again), you can just use a > stable karma value of 1 and ask someone except the update submitter to > provide the +1 karma and the update can be pushed to stable. This is > imho reasonable even after only a one line change to a build. I think this is currently a viable option. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/13/2010 07:20 AM, Michael Schwendt wrote: > On Thu, 12 Aug 2010 17:57:28 -0400, Luke wrote: > >> A new version of bodhi has just hit production. This release contains >> a number of bugfixes and improvements, along with some important process >> changes. > >> - Minimum time-in-testing requirements >> - Every day bodhi will look for updates that have been >> in testing for N days (fedora: N=7, epel: N=14), and will >> add a comment notifying the maintainer that the update is >> now able to be pushed to stable. > > This sent notifications also for packages in "pending". > > | bodhi - 2010-08-12 21:09:52 (karma: 0) > | This update has reached 274 days in testing and can be pushed > | to stable now if the maintainer wishes Yes, this happened due to a last-minute tweak I made in the approve_testing_updates job. I have since reverted this change. Ideally, we shouldn't have obsolete updates in the pending state. I think when an update is unpushed, it currently gets moved back to pending. I'll most likely change this to make it 'obsolete' the update instead. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
This is where Kevin blames the scenario on not having the same sqlite on all of the Fedora releases, which is another evil plot hatched by the devils of FESCo "seth vidal" wrote: >On Fri, 2010-08-13 at 18:07 +0200, Kevin Kofler wrote: >> Al Dunsmuir wrote: >> > You are assuming that it is somehow a good idea to push release Fn, in >> > spite of no (or negative) testing. >> >> Yes I am! If I build the EXACT SAME specfile for all F*, then I don't see >> why testing on ANY F* isn't sufficient. Please don't bring the same old >> argument that "sometimes" breakage happens only on some releases even with >> the same specfile: in practice this is so rare that it doesn't matter at >> all, it's much more likely that regressions slip through despite the >> testing. > > >Last week I pushed a yum update to f12, f13 and f14 - same pkg, same >patches, same config. > >On f12, however, the version of sqlite that f12 had handles an error >condition differently than on f13 and f14. It meant that instead of >raise an exception and letting us move along that it raised an exception >and then exited. > >So - the pkg checked out on f13 and f14 just fine but not on f12. > >I had to issue a new update for all of them to keep them in sync. > >That's a real world case that happens all the time. -- Sent from my Android phone. Please excuse my brevity and top post. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 2010-08-13 at 18:07 +0200, Kevin Kofler wrote: > Al Dunsmuir wrote: > > You are assuming that it is somehow a good idea to push release Fn, in > > spite of no (or negative) testing. > > Yes I am! If I build the EXACT SAME specfile for all F*, then I don't see > why testing on ANY F* isn't sufficient. Please don't bring the same old > argument that "sometimes" breakage happens only on some releases even with > the same specfile: in practice this is so rare that it doesn't matter at > all, it's much more likely that regressions slip through despite the > testing. Last week I pushed a yum update to f12, f13 and f14 - same pkg, same patches, same config. On f12, however, the version of sqlite that f12 had handles an error condition differently than on f13 and f14. It meant that instead of raise an exception and letting us move along that it raised an exception and then exited. So - the pkg checked out on f13 and f14 just fine but not on f12. I had to issue a new update for all of them to keep them in sync. That's a real world case that happens all the time. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Al Dunsmuir wrote:
> You are assuming that it is somehow a good idea to push release Fn, in
> spite of no (or negative) testing.
Yes I am! If I build the EXACT SAME specfile for all F*, then I don't see
why testing on ANY F* isn't sufficient. Please don't bring the same old
argument that "sometimes" breakage happens only on some releases even with
the same specfile: in practice this is so rare that it doesn't matter at
all, it's much more likely that regressions slip through despite the
testing. (And I have years of experience with KDE updates to draw from when
making that assertion. Sadly, I can't really prove it because Bodhi deletes
all the records for EOL releases, so you'll have to rely on my memory.
Release-specific regressions happened only 1 or 2 times overall (and the 1
time I remember was a maintainer using string comparisons for %{fedora}
which broke on the 9→10 transition, something that 1. can't cause breakage
again until Fedora 100 and 2. shouldn't happen to an experienced maintainer,
I'm sure that particular maintainer won't make that particular mistake ever
again after me yelling at him for the breakage ;-) ), regressions missed by
testing, despite lots of positive karma, were much more frequent. In fact,
we completely ignored the karma value for our KDE updates so far, it doesn't
really say anything about the quality of the update!) Testing will NEVER be
a 100% perfect process anyway, so why do we care about some .001% chance of
breakage? It's much more important to be able to rapidly fix things when the
testing failed, and that's exactly what direct stable pushes are needed for
and what the new process breaks.
> A saner approach would be that for related changes, release Fn-1
> should not be pushed to stable until release Fn is _also_ ready to go.
> This prevents the EVR problem, and ensures that regressions caught on
> release Fn that are also applicable to release Fn-1 will not escape.
This can stall updates for ages waiting for all the branches to get the
required testing. Testing requirements quickly multiply: e.g. if you require
2 karma, of which 1 proventester (which is what's required for "critical"
packages), requiring it on all branches makes this a requirement of 6 karma,
of which 3 proventesters! It takes a VERY long time to get so many karma
points, plus they need to be on the correct releases or they'll be
worthless.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Till Maas wrote: > Bodhi also allows you to edit the stable karma value and unless it is > implemented differently (or has changed again), you can just use a > stable karma value of 1 and ask someone except the update submitter to > provide the +1 karma and the update can be pushed to stable. This is > imho reasonable even after only a one line change to a build. You still need to get somebody to +1 the update, and more if people -1ed it in the past due to regressions which are already fixed in the current edited version. (Yes, update groups will be edited instead of obsoleted if we change what we're pushing. It's the only practical way to handle them. That's why we have this discussion about edits in the first place.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/13/2010 09:08 AM, Kevin Kofler wrote: > Jaroslav Reznik wrote: >> It would hurt all sides - it would hurt Fedora, the new distribution, our >> work in Red Hat, users and so on. And I don't understand why we can't work >> under one roof - to make Fedora the best OS. Maybe more autonomy for SIGs >> could help as Kevin proposed? > > Yeah, the SIGs are the ones who do the actual work, FESCo and the Board are > just political bureaucrats. Proper meritocracy means the SIGs get to decide. > However you don't want to let other people decide anything. You want patches FF and kernel in so you get to do it, you want to push updates without any testing required so you get to. To hell with whatever anyone else wants, and when there is an organization put in place to dictate the rules by which we all play. They have the right to dictate these rules because the group voted them in, and the majority of them decide one way. It just happens not to be with what you think. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Jaroslav Reznik wrote: > It would hurt all sides - it would hurt Fedora, the new distribution, our > work in Red Hat, users and so on. And I don't understand why we can't work > under one roof - to make Fedora the best OS. Maybe more autonomy for SIGs > could help as Kevin proposed? Yeah, the SIGs are the ones who do the actual work, FESCo and the Board are just political bureaucrats. Proper meritocracy means the SIGs get to decide. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Rahul Sundaram wrote: > I expect more fine tuning will be needed for these changes but thanks for > all your work on this. No thanks from me. By implementing FESCo's diktats defying common sense, you broken updates for everyone. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Ralf Corsepius wrote: >>> I think, for packages that are modified during the testing period, >>> this N should be calculated from the day the last push was made to >>> testing. > > This would very unhelpful. > >> Yes, this was my initial intention. However, looking at the code a bit >> closer, your scenario would currently be allowed, as it currently only >> calculates the time-in-testing based on the first push to testing. > This behavior is helpful, because otherwise updates would "starve". +1 Once again, we're in violent agreement! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, Aug 13, 2010 at 01:27:18AM +0200, Kevin Kofler wrote: > "fix" breaks that. Plus, edits can also be only to the description or bug > references, Bodhi doesn't allow me to edit those without editing the whole > update. Bodhi also allows you to edit the stable karma value and unless it is implemented differently (or has changed again), you can just use a stable karma value of 1 and ask someone except the update submitter to provide the +1 karma and the update can be pushed to stable. This is imho reasonable even after only a one line change to a build. Regards Till pgppAfMCVAWDS.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Hello Kevin, On Thursday, August 12, 2010, 8:04:12 PM, Kevin Kofler wrote: > Orcan Ogetbil wrote: >> The F-(x) package will have higher EVR than the F-(x+1) one. This >> will break the upgrade path. Is there any measures to prevent this? > No. In fact FESCo specifically refused to consider this as an issue, they > say separate releases need separate testing and so they refuse to accept the > Fn karma as grounds to push the Fn+1 update. No amount of arguing helped. > Such broken upgrade paths are now going to be extremely common with this > useless, broken and inflexible procedure. > Kevin Kofler You are assuming that it is somehow a good idea to push release Fn, in spite of no (or negative) testing. My understanding is that _that_ is what FESCo refused to consider. A saner approach would be that for related changes, release Fn-1 should not be pushed to stable until release Fn is _also_ ready to go. This prevents the EVR problem, and ensures that regressions caught on release Fn that are also applicable to release Fn-1 will not escape. Al -- 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 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... Jaroslav > Kevin Kofler -- Jaroslav Řezník Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
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. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Rahul Sundaram wrote: > I expect more fine tuning will be needed for these changes but thanks > for all your work on this. Indeed! Thanks Luke. Bodhi became much more useful with this update even if there are a few nay-sayers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, Aug 13, 2010 at 3:27 AM, Luke Macken wrote: > A new version of bodhi has just hit production. This release contains > a number of bugfixes and improvements, along with some important process > changes. > > https://admin.fedoraproject.org/updates > > I expect more fine tuning will be needed for these changes but thanks for all your work on this. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Thu, Aug 12, 2010 at 05:57:28PM -0400, Luke Macken wrote: > - Show 7 days worth of entries in our RSS feeds, as opposed to 20 >entries (https://fedorahosted.org/bodhi/ticket/339) This is nice, I forgot to add myself to the CC list, so I did not notice this before. > - Only verify the autokarma thresholds if it is enabled (Thanks to >Till Maas) This is still faulty. Is there a way to get access to a running bodhi instance that I can patch and test directly? A local instance set up according to https://fedorahosted.org/bodhi/wiki/Development does not allow to edit updates, because of tagging problems. Making this possible would of course be great. Regards Till pgppw7ztTMQ73.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Thu, 12 Aug 2010 17:57:28 -0400, Luke wrote: > A new version of bodhi has just hit production. This release contains > a number of bugfixes and improvements, along with some important process > changes. >- Minimum time-in-testing requirements >- Every day bodhi will look for updates that have been > in testing for N days (fedora: N=7, epel: N=14), and will > add a comment notifying the maintainer that the update is > now able to be pushed to stable. This sent notifications also for packages in "pending". | bodhi - 2010-08-12 21:09:52 (karma: 0) | This update has reached 274 days in testing and can be pushed | to stable now if the maintainer wishes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
