Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 03, 2010 at 02:00:59PM -0700, Jesse Keating wrote: On Mon, 2010-05-03 at 18:45 +0200, Kevin Kofler wrote: here will ALWAYS be a need for a way to fasttrack regression fixes! The proposals I've seen include a way to fasttrack. That is you get the required karma between the time the update was submitted to bodhi, and the time a bodhi admin starts the push. In such cases your update would go directly to stable. How is that not a fast track? The Bodhi karma system is a very inflexible tool. Firstly, getting 3 up votes is (probably) easy if you have loads of users like the kernel, and really hard for the rest of us with packages which have only a small number of users. When I have conscientiously tested the package myself on several machines, my vote doesn't count at all. Secondly, a simple linear scale doesn't reflect the complexity of testing packages. I've had people downvote my packages because of FAQ issues or user error or long-standing bugs in some other package that we can't or don't want to fix; and people downvote packages because of serious issues that really deserve a BZ as well or instead. There are also technical problems: You can't fit much text in the Bodhi text box, and it can't be formatted except as a single paragraph, and when you do add a comment to help someone it doesn't seem to be seen by the original downvoter. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, May 4, 2010 at 12:51, Richard W.M. Jones rjo...@redhat.com wrote: Secondly, a simple linear scale doesn't reflect the complexity of testing packages. I've had people downvote my packages because of FAQ issues or user error or long-standing bugs in some other package that we can't or don't want to fix; and people downvote packages because of serious issues that really deserve a BZ as well or instead. That's being worked on, based on the proposals by Doug Ledford and Adam Williamson. There are also technical problems: You can't fit much text in the Bodhi text box, and it can't be formatted except as a single paragraph, https://fedorahosted.org/bodhi/newticket Bodhi is using Markdown to format the update notes, it shouldn't be too hard to format the comments as well. and when you do add a comment to help someone it doesn't seem to be seen by the original downvoter. -- Mathieu Bridon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Jóhann B. Guðmundsson wrote: You must all realize that the ratio of bureaucracy/process burden and quality of maintainers/packagers go hand in hand. The better the maintainers/packagers/components are less bureaucracy/process burden is needed. The worse it gets more bureaucracy/process burden is needed. If ye all feel that the bureaucracy/process burden is increasing that only means that the quality of maintainers and their components is going down.. ( we might be getting more components inn in less quality ). If our maintainers suck, bureaucracy is not a good solution to fix that problem. But we already have a group of trusted maintainers, it's called provenpackager. We could give provenpackagers the power to push directly to stable without any karma requirements. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Jesse Keating wrote: In many cases these do apply. I participate in cases such as this nearly every day, and it's working. We're testing fixes, rejecting bad ones, and getting the right builds into stable. The system is working, but as we all know, no system is perfect. However perfect is the enemy of good. We can't take the position of karma isn't the perfect solution to every update, therefor we should do away with testing all together. You're attacking a strawman!!! I never said we should do away with testing all together! Please, all of you, STOP putting these words into my mouth! (You're not the first one to do it, just look elsewhere in this thread, and in earlier threads, for evidence.) I am saying that SOME updates can be pushed with less or even no testing. This does NOT mean that testing should not be used in most cases. It just means that it should be the maintainer's discretion whether to use it or not. The maintainer knows best how to handle his/her package. A dumb tool automatically enforcing some generic rules which are the same for all packages does not. And distinguishing 2 classes of packages (critical and non-critical) out of our thousands of packages doesn't change this in the least. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Kevin Kofler wrote: I am saying that SOME updates can be pushed with less or even no testing. This does NOT mean that testing should not be used in most cases. It just means that it should be the maintainer's discretion whether to use it or not. The maintainer knows best how to handle his/her package. A dumb tool automatically enforcing some generic rules which are the same for all packages does not. And distinguishing 2 classes of packages (critical and non-critical) out of our thousands of packages doesn't change this in the least. Fedora security updates are regularly given no testing and are pushed directly to stable. Perhaps you should classify your updates with a severity of security. Why should you abuse the system? Because the system is abusing you. While I (and Kevin!) agree that testing is useful, as I became more involved after the dbus debacle, the freedom of packagers to handle their packages freely should be maintained. The recent upswing in policies and requirements is clouding Fedora's vision. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On 05/04/2010 09:50 AM, Kevin Kofler wrote: Jóhann B. Guðmundsson wrote: You must all realize that the ratio of bureaucracy/process burden and quality of maintainers/packagers go hand in hand. The better the maintainers/packagers/components are less bureaucracy/process burden is needed. The worse it gets more bureaucracy/process burden is needed. If ye all feel that the bureaucracy/process burden is increasing that only means that the quality of maintainers and their components is going down.. ( we might be getting more components inn in less quality ). If our maintainers suck, bureaucracy is not a good solution to fix that problem. You keep saying that, and it just shows a complete disregard for testing in general. Asking people to test it and simply flag that they've done so with success (or not) is very much not bureaucracy. But we already have a group of trusted maintainers, it's called provenpackager. We could give provenpackagers the power to push directly to stable without any karma requirements. We trust their intent and their ability, because that's reasonable. We don't trust that they never make mistakes, because that's insane. We all make mistakes. The karma system is an attempt to mitigate the damage when that (very frequent) eventuality occurs. I'm sorry you don't like it, but you've had ample occasion to come up with a better idea, and you have roundly refused to make any attempt at doing so. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On 05/03/2010 12:51 PM, Kevin Kofler wrote: Jesse Keating wrote: On Mon, 2010-05-03 at 14:01 +0100, Matthew Garrett wrote: [1] And I appreciate that I made a mistake with hal-storage in this cycle that caused inconvenience for people maintaining other spins, so I'm not going to claim any kind of perfection in this area Which just adds reason to why we are doing necessary karma and automated testing, because humans make mistakes, no matter how much fun or not fun they are having. Except karma requirements (which were in force due to the critical path process) did NOT prevent this particular regression, nor would a 1 week minimum in testing requirement have prevented it (the update spent 8 days in testing). That process DOES NOT WORK. It just adds extra bureaucracy and delays the fix for the regression. (But thankfully, direct stable pushes are still possible for KDE packages, which allowed us to do one to fix this regression quickly.) Wait just a second - you're arguing that requiring testing doesn't work because nobody tested the KDE spin within 8 days. You might want to rethink this position. -- Peter If you're not part of the solution, then you're part of the precipitate. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, 2010-05-04 at 10:00 -0500, Michael Cronenworth wrote: The recent upswing in policies and requirements is clouding Fedora's vision. Which vision is that? The one where we should produce a generally usable stable operating system every 6 months, one that users can confidently use throughout the life of that release? Making sure our updates given to users are better tested seems to be working toward that vision, not away from it. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On 05/04/2010 01:50 PM, Kevin Kofler wrote: Jóhann B. Guðmundsson wrote: You must all realize that the ratio of bureaucracy/process burden and quality of maintainers/packagers go hand in hand. The better the maintainers/packagers/components are less bureaucracy/process burden is needed. The worse it gets more bureaucracy/process burden is needed. If ye all feel that the bureaucracy/process burden is increasing that only means that the quality of maintainers and their components is going down.. ( we might be getting more components inn in less quality ). If our maintainers suck, bureaucracy is not a good solution to fix that problem. But we already have a group of trusted maintainers, it's called provenpackager. We could give provenpackagers the power to push directly to stable without any karma requirements. Given the requirements FESCo + if they checks on the bugzilla activity of the individual that wants to become a provenpackager and take that into consideration when approving the request I dont see why not. So basically it would be like this.. If you are a provenpackager you have the power to push directly to stable without any karma requirements however if you are not a provenpackager you will have to follow what ever procedure FESCo RELeng and QA come up with at any given time until you have been accepted as a provenpackager by FESCo. Sounds like a draft to a solution everyone can agree with? JBG attachment: johannbg.vcf-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On 05/04/2010 05:55 PM, Jóhann B. Guðmundsson wrote: On 05/04/2010 01:50 PM, Kevin Kofler wrote: Jóhann B. Guðmundsson wrote: You must all realize that the ratio of bureaucracy/process burden and quality of maintainers/packagers go hand in hand. The better the maintainers/packagers/components are less bureaucracy/process burden is needed. The worse it gets more bureaucracy/process burden is needed. If ye all feel that the bureaucracy/process burden is increasing that only means that the quality of maintainers and their components is going down.. ( we might be getting more components inn in less quality ). If our maintainers suck, bureaucracy is not a good solution to fix that problem. But we already have a group of trusted maintainers, it's called provenpackager. We could give provenpackagers the power to push directly to stable without any karma requirements. Given the requirements FESCo + if they checks on the bugzilla activity of the individual that wants to become a provenpackager and take that into consideration when approving the request I dont see why not. So basically it would be like this.. If you are a provenpackager you have the power to push directly to stable without any karma requirements however if you are not a provenpackager you will have to follow what ever procedure FESCo RELeng and QA come up with at any given time until you have been accepted as a provenpackager by FESCo. Sounds like a draft to a solution everyone can agree with? No. a) This would cause the provenpackager group to gradually start suffering from the same issues as the current packager group has (lack of qualification). It would degrade the provenpackager group. b) Members of the current packager group should be qualified enough to judge if their update/upgrade needs an immediate push. It they aren't able to do so, they should reconsider if they are qualified to be a packager at all. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Jesse Keating wrote: So this is kind of funny. You'd rather see testing become/less/ rigorous as the age of a release grows, and you want the most rigorous testing done in rawhide. That's quite the opposite of what many of us are trying to work toward, that is as the release moves from rawhide into branched into released into released-1 the testing gets harder, and the chance of breakage gets lower. Users of older releases aren't there for the fun of it, they need to get real work done, and don't want updates to get in their way of accomplishing that. We should be more careful with our older release than anything else. No, I was stating fact - not opinion. Older releases receive less testing. Bodhi metrics show it if you want something tangible besides my words. So I'd love to have multi-level policy, but in my opinion it should get harder and harder to push an update as the release gets older, not easier. We can't rely on one tester to be able to test older releases through a stringent policy, can we? It's common sense that older releases should be receiving more testing, but here in reality it is the opposite. If I am wrong, please prove it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Peter Jones wrote: I'm sorry you don't like it, but you've had ample occasion to come up with a better idea, and you have roundly refused to make any attempt at doing so. I'm sorry you don't like my plate of Merde Provençale, but you've had ample occation to come up with a better recipe for feces, and you have roundly refused to make any attempt at doing so. See the problem there? (Hint: the basic assumption that you want to eat sh*t in the first place!) You were only interested in better ideas under a very narrow initial assumption which I don't share. Of course I was not interested in trying to coming up with better ideas under those conditions, as I don't believe that to be possible in the first place. You did not give any consideration to the fact that your initial premises may be broken and incorrect (which they happen to be). You keep saying that, and it just shows a complete disregard for testing in general. Asking people to test it and simply flag that they've done so with success (or not) is very much not bureaucracy. I don't believe testing to be the answer to everything. It's far from infallible, it's also not the only possible form of QA. There are changes which don't need testing, for example if a patch was dropped because we thought it wasn't needed anymore, and it turns out the patch is still needed, readding the patch needs no testing whatsoever because the patch has ALREADY been tested, plus it's fixing a regression. This is why the latest qt update went out straight to stable. And no, testing did NOT catch the regression. Right after the update went stable, we got the report. You have to accept that most users will NOT try out a package until after it hits stable. We trust their intent and their ability, because that's reasonable. We don't trust that they never make mistakes, because that's insane. We all make mistakes. The karma system is an attempt to mitigate the damage when that (very frequent) eventuality occurs. You need to prove that very frequent assertion. I don't see this as being true at all, quite the opposite. It almost never happens with the current system. Maintainers ALREADY use testing and keep feedback into account. Why do we need to FORCE them to? We should TRUST our maintainers! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, 2010-05-04 at 19:40 +0200, Kevin Kofler wrote: There are changes which don't need testing, for example if a patch was dropped because we thought it wasn't needed anymore, and it turns out the patch is still needed, readding the patch needs no testing whatsoever because the patch has ALREADY been tested, plus it's fixing a regression. This involved doing another build of the package, which could involve changes in the buildroot and anomalies in the build process. Ask DaveJ some time about what happened to his kernel builds when the build host did a clock adjustment during the build. Shit happens, and making assumptions that just because the build completed that nothing went wrong is a great way to make a fool of yourself. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Michael Cronenworth wrote: Fedora security updates are regularly given no testing and are pushed directly to stable. Perhaps you should classify your updates with a severity of security. That doesn't work because security updates require security team approval (another silly policy which was enforced despite almost everybody on the devel list having been against it, only the security team itself wanted it) and the security team will reject updates which are not actually security updates. (They want to see a specific CVE and even reject updates which fix potential security holes, asking them to be changed to regular bugfix updates instead, unless you can show evidence for a concrete security hole. For example, they had me change a qimageblitz update which fixed qimageblitz requiring an executable stack on x86_64 from security to bugfix.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, 2010-05-04 at 12:04 -0500, Michael Cronenworth wrote: Jesse Keating wrote: So this is kind of funny. You'd rather see testing become/less/ rigorous as the age of a release grows, and you want the most rigorous testing done in rawhide. That's quite the opposite of what many of us are trying to work toward, that is as the release moves from rawhide into branched into released into released-1 the testing gets harder, and the chance of breakage gets lower. Users of older releases aren't there for the fun of it, they need to get real work done, and don't want updates to get in their way of accomplishing that. We should be more careful with our older release than anything else. No, I was stating fact - not opinion. Older releases receive less testing. Bodhi metrics show it if you want something tangible besides my words. Current bodhi metrics cannot be used as a judge. Currently karma is not required, so the path of least resistance is to not provide it. If/when karma is required for an update to go out, or a timeout in -testing, we will see an uptick in karma. We've seen that in branched, we will likely see it in released Fedora's too. How much, and in which release remains to be seen. So I'd love to have multi-level policy, but in my opinion it should get harder and harder to push an update as the release gets older, not easier. We can't rely on one tester to be able to test older releases through a stringent policy, can we? It's common sense that older releases should be receiving more testing, but here in reality it is the opposite. If I am wrong, please prove it. The point of the updates policy is to change reality, not to draft policy around an existing reality. The reality is that updates are going out untested to stable releases and causing real problems to real users. We'd like to change that reality. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, 2010-05-04 at 09:07 -0800, Jeff Spaleta wrote: On Tue, May 4, 2010 at 8:45 AM, Jesse Keating jkeat...@redhat.com wrote: So I'd love to have multi-level policy, but in my opinion it should get harder and harder to push an update as the release gets older, not easier. In general I'm in agreement with this. But at the same time I'm concerned that the policy is going to make it more difficult for me to respond to breakage in my packages created when a maintainer does an update (mistakenly) that one of my packages depend on. Not to harp on any of my peers...so apologizes if to anyone I think I'm picking on in the following case study. I just went through a round of breakage associated with matplotlib and numpy caused by other maintainer action in both rawhide and EPEL. In rawhide it was really easy for me to get fixes out. For EPEL, because of the update policy..it was harder for me...the maintainer who is trying to react to brokenness created by another maintainer. The thing I really need help with as a maintainer is help seeing when a update in testing is a potential impactor for one of the packages I maintain. So I can get ahead of any problems and do the testing I need to do against the update in updates-testing and keep it from hitting stable until I can spin up versions of my packages that work with the update. I don't want to be in a position where I have to react to breakage. I want to be proactive, but I really need a better heads up as to when things that impact my packages are in the que for stable so I can better prioritize my time. -jef If the breakage was in the form of broken deps, the original update would not have been allowed out in the first place. The maintainer would have had to contact all the folks with packages that would break and get them to coordinate the update. If the breakage was more of a functional break and not a dep break, that's where automated testing comes in, and we grow the automated functional testing of updates so that if an update comes along we can detect the breakage and alert both parties. The solution to shit went out and broke my stuff isn't to make it easier to put shit out, it's to make it harder to put /broken/ shit out in the first place. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Michael Cronenworth wrote: It's common sense that older releases should be receiving more testing, but here in reality it is the opposite. If I am wrong, please prove it. Indeed, that's the fact we have to deal with, and IMHO the solution is to push the same changes to all releases wherever possible and to consider them as one change for the purpose of testing, i.e. testing on any release should count for all of them. Of course, this is only an approximation, but it's an extremely good one, and testing can never be flawless anyway. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On 05/04/2010 06:04 PM, Kevin Kofler wrote: Peter Jones wrote: Wait just a second - you're arguing that requiring testing doesn't work because nobody tested the KDE spin within 8 days. You might want to rethink this position. Why? I don't see the contradiction. If nobody tests things, testing doesn't and can't work. Well my logic tells me that if nobody test things it more implies that there is no demand for the product that did not receive that testing not that the testing process was or is flawed in one way or another. JBG attachment: johannbg.vcf-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Jesse Keating wrote: This involved doing another build of the package, which could involve changes in the buildroot and anomalies in the build process. Ask DaveJ some time about what happened to his kernel builds when the build host did a clock adjustment during the build. Shit happens, and making assumptions that just because the build completed that nothing went wrong is a great way to make a fool of yourself. Some risks are so low that they're basically negligible. If the 2 options are keeping an existing regression (which missed testing) in updates for a few more days or risking the off chance that there MAY be another regression with a probability of 1 in a million or something in that order of magnitude, I'll take the risk any day! If that kind of risk is too high for you, I hope you don't ever use a car, it might crash, you know? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, May 4, 2010 at 9:50 AM, Jesse Keating jkeat...@redhat.com wrote: If the breakage was more of a functional break and not a dep break, that's where automated testing comes in, and we grow the automated functional testing of updates so that if an update comes along we can detect the breakage and alert both parties. Yes in this case it was functional breakage. The solution to shit went out and broke my stuff isn't to make it easier to put shit out, it's to make it harder to put /broken/ shit out in the first place. I'm not disagreeing with you. I'm saying that to really to take advantage of the policy as a maintainer and derive the most benefit from the requirement that things sit in testing awaiting karma..I need some help getting a heads up when things I need to be aware of hit the testing repository so I can do my part and get ahead of potential functional breakage...and even write test cases for it. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On 05/04/2010 01:40 PM, Kevin Kofler wrote: Peter Jones wrote: I'm sorry you don't like it, but you've had ample occasion to come up with a better idea, and you have roundly refused to make any attempt at doing so. I'm sorry you don't like my plate of Merde Provençale, but you've had ample occation to come up with a better recipe for feces, and you have roundly refused to make any attempt at doing so. See the problem there? (Hint: the basic assumption that you want to eat sh*t in the first place!) That's a nice analogy; both vulgar and vacuous. Entirely inapt, but clever. You were only interested in better ideas under a very narrow initial assumption which I don't share. Of course I was not interested in trying to coming up with better ideas under those conditions, as I don't believe that to be possible in the first place. You did not give any consideration to the fact that your initial premises may be broken and incorrect (which they happen to be). The initial premise was that we've released several updates that turned out to introduce major bugs. I know you don't agree with that, since you've repeatedly discounted that premise in FESCo meetings and even in this thread, but that doesn't make it not the case. You keep saying that, and it just shows a complete disregard for testing in general. Asking people to test it and simply flag that they've done so with success (or not) is very much not bureaucracy. I don't believe testing to be the answer to everything. It's far from infallible, it's also not the only possible form of QA. Sure, but you're (repeatedly) asserting, essentially, that it can't fix anything and that requiring testing is of no merit because handwave about double checking your own work. There are changes which don't need testing, for example if a patch was dropped because we thought it wasn't needed anymore, and it turns out the patch is still needed, readding the patch needs no testing whatsoever because the patch has ALREADY been tested, plus it's fixing a regression. Don't you realize that the testing also helps test procedural and typographical errors? For instance the case (which I've certainly done before) where a maintainer accidentally adds a Patch: line without a %patch line? This is part of the very scenario which you claim doesn't need testing. My experience is that it clearly does, because it's simple, it's easy to do, and it's trivial to get it right - and I screw it up sometimes. This is why the latest qt update went out straight to stable. And no, testing did NOT catch the regression. Right after the update went stable, we got the report. You have to accept that most users will NOT try out a package until after it hits stable. Nobody is saying that it's a panacea. We're saying that testing can catch things that not testing won't, and that these are important things with substantial consequences. We're not saying it'll catch everything, though every counterpoint you come up with does seem to presume that we are saying that. We trust their intent and their ability, because that's reasonable. We don't trust that they never make mistakes, because that's insane. We all make mistakes. The karma system is an attempt to mitigate the damage when that (very frequent) eventuality occurs. You need to prove that very frequent assertion. I don't see this as being true at all, quite the opposite. It almost never happens with the current system. You had this discussion during the FESCo meeting on the 23rd of February, and several people provided counterexamples to your assertion that it doesn't happen often. It is regretful that you don't seem to have noticed. Maintainers ALREADY use testing and keep feedback into account. Why do we need to FORCE them to? We should TRUST our maintainers! The person claiming we don't trust our maintainers is you. Honestly, I'm not really sure why we're still attempting to have a discussion with you about this, but letting your claims stand seems irresponsible to me. -- Peter RFC 882 put the dots in .com. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, May 4, 2010 at 2:14 PM, Kevin Kofler kevin.kof...@chello.at wrote: Some risks are so low that they're basically negligible. If the 2 options are keeping an existing regression (which missed testing) in updates for a few more days or risking the off chance that there MAY be another regression with a probability of 1 in a million or something in that order of magnitude, I'll take the risk any day! Then do take that risk yourself. And propose to like-minded users that they enable updates-testing. Nothing needs to change in Fedora. Normal users use it as is, danger-loving users enable updates-testing. Everyone gets what they want. You are missing, however, that the risks are much higher, and materialise often. I've seen many obviously correct fixes explode several times in my programming life. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Jesse Keating wrote: If/when karma is required for an update to go out, or a timeout in -testing, we will see an uptick in karma. You keep claiming that. You have no evidence whatsoever for that, and it doesn't seem plausible to me at all. Users only care about having the issue fixed for themselves, if they bother fetching the package from testing or Koji at all, the problem will be solved for them, so why would they care about whether the fixed package will go to stable? We've seen that in branched, we will likely see it in released Fedora's too. The userbase of branched is very different from the one of stable releases. People who use branched tend to be voluntary testers who know that they're using an unfinished released and expected to provide testing. On the other hand, the average user of a release is NOT a tester and will NOT sign up to test things for the benefit of other users. So I don't see the results for branched as evidence for your claim at all. In addition, the new update policy wants to require karma (or a 1 week timeout) even for non-critical packages. We have NO evidence regarding those from branched as the karma requirements were only for critical path packages. And finally, even if you're right, you still have no evidence that the karma was given out based on actual testing and not merely on a plea of please +1 my package. The point of the updates policy is to change reality LOL!!! Good luck! The reality is that updates are going out untested to stable releases and causing real problems to real users. And your evidence is? The evidence given in FESCo meetings was just two isolated incidents, the first of which was a security (!) update and clearly a one-time issue, the second in a package (bind) which is not installed by default and which the vast majority of Fedora users don't have installed at all. Those are just 2 (!) incidents over YEARS of Fedora's history. So I don't see this as a problem needing to be solved at all. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Jesse Keating wrote: The solution to shit went out and broke my stuff isn't to make it easier to put shit out, it's to make it harder to put broken shit out in the first place. Sure, that's a nice theory, but in practice, no matter how much testing you require, there will ALWAYS be regressions slipping through and needing fast response. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Sun, May 02, 2010 at 07:02:23PM -0700, Henrique Junior wrote: Unfortunately, what I have seen over time is that Fedora is changing to something that worries me and that is getting less fun to contribute. I remember the time when I liked to say that fedora was the voice of the community. It's important for individual contributors to have fun, but it's also worth remembering that one person's fun can cause inconvenience to others.[1] We have rules about ABI breaks because we don't want one maintainer to be able to cause distruption that results in several other people having to spend time cleaning up after them. Maybe that's less fun for the library maintainer, but it means that others have less fun overall. The stable packages work is an extension of this. Even if we, as maintainers, have plenty of fun, that's pretty easily wiped out if even a small proportion of our users have to spend time fixing a system that a stable update has broken. And without users who enjoy using and talking about Fedora, the entire exercise is pointless. Fesco isn't introducing rules because it wants our developers to become rule-bound drones, but because it wants our developers to actually be able to see people using what those developers produce and interact with a community of people who *use* Fedora, not just people who develop it. Personally, I think it's reasonable to ask developers to do slightly more work if it means our users have to do significantly less. [1] And I appreciate that I made a mistake with hal-storage in this cycle that caused inconvenience for people maintaining other spins, so I'm not going to claim any kind of perfection in this area -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Matthew Garrett wrote: The stable packages work is an extension of this. Even if we, as maintainers, have plenty of fun, that's pretty easily wiped out if even a small proportion of our users have to spend time fixing a system that a stable update has broken. And without users who enjoy using and talking about Fedora, the entire exercise is pointless. Fesco isn't introducing rules because it wants our developers to become rule-bound drones, but because it wants our developers to actually be able to see people using what those developers produce and interact with a community of people who *use* Fedora, not just people who develop it. Personally, I think it's reasonable to ask developers to do slightly more work if it means our users have to do significantly less. You make it look as if I was out to break people's systems, when actually what I'm arguing for is: * allowing important bugfixes to bypass testing IN SOME CASES (i.e. if they aren't too risky/non-trivial), in order to get very needed bugfixes (e.g. regression fixes) out to our users faster and make them suffer LESS, * allowing trivial changes to bypass testing IN SOME CASES (i.e. if they are important/useful enough) because there's hardly any way they can break anything, in order to get ultra-low-risk improvements out to our users faster and make them suffer LESS, * allowing new upstream releases as updates IF AND ONLY IF THEY DON'T BREAK THINGS (with a very precise definition of break things I don't want to repeat again) and after sufficient regression testing and fixing, bringing both new features and bugfixes to our users without the breakage of an unstable distribution such as Rawhide and thus making them suffer LESS. Please stop attacking a strawman! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 03, 2010 at 04:34:13PM +0200, Kevin Kofler wrote: You make it look as if I was out to break people's systems Actually, I didn't intend to say anything about you. My point was that any increased bureaucracy has not been generated with the intention to reduce the amount of fun that developers have. If developers /do/ feel that their ability to have fun in Fedora has been reduced, I hope that in the long run that that gets more than compensated for by more positive feedback from our users and fewer angry complaints when people's systems break. * allowing important bugfixes to bypass testing IN SOME CASES (i.e. if they aren't too risky/non-trivial), in order to get very needed bugfixes (e.g. regression fixes) out to our users faster and make them suffer LESS, If updates cause regressions in functionality then that indicates that our update testing process failed. The answer to that is to fix the update testing process, not bypass it. * allowing trivial changes to bypass testing IN SOME CASES (i.e. if they are important/useful enough) because there's hardly any way they can break anything, in order to get ultra-low-risk improvements out to our users faster and make them suffer LESS, There is no change too trivial to not require testing. The software industry is full of examples of obviously correct fixes causing hideous breakage. Most developers get to learn that the hard way at some point, but it's still preferable to put processes in place to protect users from accidents. * allowing new upstream releases as updates IF AND ONLY IF THEY DON'T BREAK THINGS (with a very precise definition of break things I don't want to repeat again) and after sufficient regression testing and fixing, bringing both new features and bugfixes to our users without the breakage of an unstable distribution such as Rawhide and thus making them suffer LESS. Regardless of your definition, there were several users who felt that the KDE 4.4 update broke things. That's a problem. It makes us look bad. We'd like to avoid those users being unhappy. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Matthew Garrett wrote: My point was that any increased bureaucracy has not been generated with the intention to reduce the amount of fun that developers have. Let me jump in just to say that I'm not a developer/packager, but it was my intention to become a contributor for Fedora. What scared me was just the huge level of bureaucracy. Submitting patches to the kernel 10 years ago was actually simpler than packaging a trivial rpm for Fedora is today. This is why I decided to not by a packager. I just try to help guys on the lists and open bugs (often ignored, I must add). Best regards. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, 2010-05-03 at 14:01 +0100, Matthew Garrett wrote: [1] And I appreciate that I made a mistake with hal-storage in this cycle that caused inconvenience for people maintaining other spins, so I'm not going to claim any kind of perfection in this area Which just adds reason to why we are doing necessary karma and automated testing, because humans make mistakes, no matter how much fun or not fun they are having. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Matthew Garrett wrote: If updates cause regressions in functionality then that indicates that our update testing process failed. The answer to that is to fix the update testing process, not bypass it. Your assumption there is that it is possible for a testing process to catch ALL regressions. I couldn't disagree more, and so far evidence has proven me right. For example, the critical path process, upon which the new update process is modeled, failed to catch the regressions in non-GNOME spins you caused by splitting out hal-storage-addon to a subpackage. NO amount of testing will EVER catch ALL regressions before they hit users. There will ALWAYS be a need for a way to fasttrack regression fixes! (And in fact a direct stable push is how we fixed the KDE spin.) There is no change too trivial to not require testing. The software industry is full of examples of obviously correct fixes causing hideous breakage. Most developers get to learn that the hard way at some point, but it's still preferable to put processes in place to protect users from accidents. While you do have a point in principle, in practice, our maintainers are quite good at judging the risk of their changes, and often the risk is so extremely low that it is far outweighed by the benefits of getting the change out ASAP. This is always a tradeoff. And 100% bugfreeness doesn't exist anyway, testing is NOT going to catch all issues either. There is a point at which the risk is so low that other real-world risks such as hardware failure are several orders of magnitude larger. So why bother worrying about such a low risk? Regardless of your definition, there were several users who felt that the KDE 4.4 update broke things. That's a problem. It makes us look bad. We'd like to avoid those users being unhappy. It is true that KDE 4.4 wasn't as smooth as we had hoped for some users. This is strange, because for most of us, things just worked! I'll note that KDE 4.4 got A LOT of testing, and all testing indicated that we are good to go. We would NOT have pushed this out if we hadn't been convinced that our update is regression-free. This is just yet another proof that testing will NEVER catch ALL issues. What happened was that: * the Akonadi migration seems to be fragile in some ways, and choke on various corner cases, often of unknown nature. This did not show up during testing. For most of the issues, KDE UserBase offers workarounds. * Akonadi needs manual configuration to work with NFS home directories. We were not aware of this when we pushed 4.4 out and none of our testers was using this configuration. This issue can be worked around by the user by following the instructions on KDE UserBase, which detail the required manual configuration. * we underestimated the annoyance factor of a warning Akonadi pops up if Nepomuk is not running. (This warning is mostly harmless at this time. It just means that some Akonadi functionality is disabled.) This has been remedied by a kde-settings update which enables Nepomuk by default. It shall however be noted that the Akonadi migration is a one-time event (well, there will be a second part in KDE 4.5, but once that's done too, the migration problem is solved), so I don't expect this kind of issues in future KDE upgrades. (In fact, we had NO similar complaints for our previous 4.1, 4.2 and 4.3 upgrades.) And IMHO most of the blame for the roughness of the Akonadi migration goes to upstream KDE. If we had been aware of the issues this is causing, we would have evaluated alternatives (e.g. staying on kdepim 4.3, or shipping the pre-Akonadi kdepim-enterprise4 branch). But all the feedback we got at the time of the decision pointed to the migration being trouble-free, and in fact I still believe that for the vast majority of our users, it was. You only hear from the handful people who ran into trouble. And we also need to weigh those against the people for whom KDE 4.4 fixed their issues. It has fixed thousands of bugs! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Jesse Keating wrote: On Mon, 2010-05-03 at 14:01 +0100, Matthew Garrett wrote: [1] And I appreciate that I made a mistake with hal-storage in this cycle that caused inconvenience for people maintaining other spins, so I'm not going to claim any kind of perfection in this area Which just adds reason to why we are doing necessary karma and automated testing, because humans make mistakes, no matter how much fun or not fun they are having. Except karma requirements (which were in force due to the critical path process) did NOT prevent this particular regression, nor would a 1 week minimum in testing requirement have prevented it (the update spent 8 days in testing). That process DOES NOT WORK. It just adds extra bureaucracy and delays the fix for the regression. (But thankfully, direct stable pushes are still possible for KDE packages, which allowed us to do one to fix this regression quickly.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Once upon a time, Kevin Kofler kevin.kof...@chello.at said: Matthew Garrett wrote: snip Can we PLEASE not rehash all of this again? Thanks a lot Kevin; you showed a lot of class trying to stir up the same arguments that you stirred up before. Maybe the reason you lost votes is that a lot of people just don't agree with you; pouting about that won't help anything. -- Chris Adams cmad...@hiwaay.net 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: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 3, 2010 at 8:00 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Kevin Kofler kevin.kof...@chello.at said: Matthew Garrett wrote: snip Can we PLEASE not rehash all of this again? Generally agreed. Maybe the reason you lost votes is that a lot of people just don't agree with you Doesn't automatically mean they are right. And they aren't right if it comes to the Desktop. They just like it and don't want to change it. For whatever reason. pouting about that won't help anything. To not speak up as well not. Arguments are arguments, even the other side don't like them, doesn't make them smaller. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, May 3, 2010 at 10:00 AM, Chris Adams cmad...@hiwaay.net wrote: Thanks a lot Kevin; you showed a lot of class trying to stir up the same arguments that you stirred up before. Maybe the reason you lost votes is that a lot of people just don't agree with you; pouting about that won't help anything. There's no reason to paint this as a sour grapes issue. I'm pretty sure Kevin strongly believes that some decision-making is not in the best interest of the project... its not sour grapes to be persistent in that belief. It's difficult being cast into the role of loyal opposition (whether by choice or by calculation.) especially when you don't enjoy that role and being in that position burns you out. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, 2010-05-03 at 18:45 +0200, Kevin Kofler wrote: here will ALWAYS be a need for a way to fasttrack regression fixes! The proposals I've seen include a way to fasttrack. That is you get the required karma between the time the update was submitted to bodhi, and the time a bodhi admin starts the push. In such cases your update would go directly to stable. How is that not a fast track? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, 2010-05-03 at 18:51 +0200, Kevin Kofler wrote: Except karma requirements (which were in force due to the critical path process) did NOT prevent this particular regression, nor would a 1 week minimum in testing requirement have prevented it (the update spent 8 days in testing). That process DOES NOT WORK. It just adds extra bureaucracy and delays the fix for the regression. (But thankfully, direct stable pushes are still possible for KDE packages, which allowed us to do one to fix this regression quickly.) You are definitely missing the forest for the trees here. In the proposals I've seen, the was no mandate that an update spend a week in testing, provided it got enough karma before that. If the issue at hand is so egregious to need a push ASAP, then there should be plenty of people on hand to snag the update from koji and provide you the necessary karma nearly immediately. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
Jesse Keating wrote: The proposals I've seen include a way to fasttrack. That is you get the required karma between the time the update was submitted to bodhi, and the time a bodhi admin starts the push. In such cases your update would go directly to stable. How is that not a fast track? Because it requires getting karma. That's usually not fast at all, especially if you enforce that karma should not be given out without testing. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Mon, 2010-05-03 at 23:49 +0200, Kevin Kofler wrote: Jesse Keating wrote: The proposals I've seen include a way to fasttrack. That is you get the required karma between the time the update was submitted to bodhi, and the time a bodhi admin starts the push. In such cases your update would go directly to stable. How is that not a fast track? Because it requires getting karma. That's usually not fast at all, especially if you enforce that karma should not be given out without testing. Kevin Kofler Testing takes time, lets give up? Seriously? Pushes happen about once every 24 hours, do you really say it'll take longer than 24 hours to get a couple people to test the issue and confirm that your fix does indeed fix the issue, and doesn't seem to create any other immediately noticeable issues? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On 5/4/2010 12:57 AM, Jesse Keating wrote: Testing takes time, lets give up? Seriously? Pushes happen about once every 24 hours, do you really say it'll take longer than 24 hours to get a couple people to test the issue and confirm that your fix does indeed fix the issue, and doesn't seem to create any other immediately noticeable issues? At the risk of putting words into Kevin's mouth, I think that you just made his point. I'd be very surprised if Kevin couldn't get x number of people to say yes to a fix that he considered urgent. This might confirm that the fix had its expected consequence, but I think that he already knew that or he wouldn't be trying to push it to stable. It wouldn't say much for stability or edge cases, only a good regression suite would give confidence on that score. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, 2010-05-04 at 01:27 +0300, shmuel siegel wrote: At the risk of putting words into Kevin's mouth, I think that you just made his point. I'd be very surprised if Kevin couldn't get x number of people to say yes to a fix that he considered urgent. This might confirm that the fix had its expected consequence, but I think that he already knew that or he wouldn't be trying to push it to stable. It wouldn't say much for stability or edge cases, only a good regression suite would give confidence on that score. The point here is that Kevin isn't perfect. As such, he can make mistakes, just like all of us. By asking for a couple karma nods from different people, we increase the chance of catching some of those mistakes. Since the delay exists anyway, it doesn't seem to be that big of a deal to me to make sure a couple people test it and comment as such during that delay. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On 05/03/2010 10:30 PM, Jesse Keating wrote: The point here is that Kevin isn't perfect. As such, he can make mistakes, just like all of us. By asking for a couple karma nods from different people, we increase the chance of catching some of those mistakes. Since the delay exists anyway, it doesn't seem to be that big of a deal to me to make sure a couple people test it and comment as such during that delay. Agreed. For example we had a bug in one of the previous release were a relativity harmless fix in the maintainers eye ( which I do believe he tested locally before updating the package ) broke all non US keyboard layouts ( if I can recall correctly actually reset or set the keyboard layout setting to US or deleted the previous stored layout) luckily for us he did not act impatiently but pushed it to updates-testing were we were able to capture it before it hit mainstream. This could have proven disastrous but it did not thanx to this process. Now if maintainers wants to wield the power of pushing straight to update without having to have his update lay for few hours/day's in update-testing it is my firm opinion that he should be.. a) a upstream maintainer b) have flawless bugzilla interaction, c) have very active upstream interaction encase a) is false and d) upstream is ACTIVE. Encase of a mishap we need to be sure that the maintainer can act quickly ( from the first report in after he pushed that update ) if needed but before granting that access we seriously need to start tracking and visualize ( graph ) component action both in bugzilla and in bodhi to identify which maintainers and their components can be granted that access. You must all realize that the ratio of bureaucracy/process burden and quality of maintainers/packagers go hand in hand. The better the maintainers/packagers/components are less bureaucracy/process burden is needed. The worse it gets more bureaucracy/process burden is needed. If ye all feel that the bureaucracy/process burden is increasing that only means that the quality of maintainers and their components is going down.. ( we might be getting more components inn in less quality ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On 05/03/2010 11:12 PM, Jesse Keating wrote: On Mon, 2010-05-03 at 18:51 +0200, Kevin Kofler wrote: Except karma requirements (which were in force due to the critical path process) did NOT prevent this particular regression, nor would a 1 week minimum in testing requirement have prevented it (the update spent 8 days in testing). That process DOES NOT WORK. It just adds extra bureaucracy and delays the fix for the regression. (But thankfully, direct stable pushes are still possible for KDE packages, which allowed us to do one to fix this regression quickly.) You are definitely missing the forest for the trees here. So do you: The karma stuff will never work and if then only in corner-cases. In probably the overwhelming majority of cases, all karma does is adding to Fedora's bureaucracy, without being actually functional. In the proposals I've seen, the was no mandate that an update spend a week in testing, provided it got enough karma before that. If the issue at hand is so egregious to need a push ASAP, then there should be plenty of people on hand to snag the update from koji and provide you the necessary karma nearly immediately. You are presuming a bug * affects many people * is reproducable by many people * has user visible impacts * users are volunteering to provide feedback These presumptions are all wrong and do not apply. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, 2010-05-04 at 05:01 +0200, Ralf Corsepius wrote: You are presuming a bug * affects many people * is reproducable by many people * has user visible impacts * users are volunteering to provide feedback These presumptions are all wrong and do not apply. In many cases these do apply. I participate in cases such as this nearly every day, and it's working. We're testing fixes, rejecting bad ones, and getting the right builds into stable. The system is working, but as we all know, no system is perfect. However perfect is the enemy of good. We can't take the position of karma isn't the perfect solution to every update, therefor we should do away with testing all together. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On Tue, 2010-05-04 at 05:01 +0200, Ralf Corsepius wrote: On 05/03/2010 11:12 PM, Jesse Keating wrote: On Mon, 2010-05-03 at 18:51 +0200, Kevin Kofler wrote: Except karma requirements (which were in force due to the critical path process) did NOT prevent this particular regression, nor would a 1 week minimum in testing requirement have prevented it (the update spent 8 days in testing). That process DOES NOT WORK. It just adds extra bureaucracy and delays the fix for the regression. (But thankfully, direct stable pushes are still possible for KDE packages, which allowed us to do one to fix this regression quickly.) You are definitely missing the forest for the trees here. So do you: The karma stuff will never work and if then only in corner-cases. In probably the overwhelming majority of cases, all karma does is adding to Fedora's bureaucracy, without being actually functional. In the proposals I've seen, the was no mandate that an update spend a week in testing, provided it got enough karma before that. If the issue at hand is so egregious to need a push ASAP, then there should be plenty of people on hand to snag the update from koji and provide you the necessary karma nearly immediately. You are presuming a bug * affects many people * is reproducable by many people * has user visible impacts * users are volunteering to provide feedback So it its none of these why do you want to fast track it into stable? Leave it updates-testing for 2-3 weeks and pull it in then if nobody complains. If you can't find anyone the bug affects I don't see why its an urgent must-fix. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
On 05/04/2010 05:09 AM, Dave Airlie wrote: So it its none of these why do you want to fast track it into stable? The fact nobody has reported a bug into Fedora's bugtracking system doesn't mean a package is not bugged or doesn't suffer from defects. The prototypical situations I am facing with my packages is * upstreams releasing bug-fixes to bugs they have collected and I haven't heared nor noticed before. * individuals reporting bugs through bugzilla and me trying to find a fix ASAP. Leave it updates-testing for 2-3 weeks and pull it in then if nobody complains. That's what I have been doing and is one of the context in which I consider karma to be superflous bureaucracy. Also, when reporters are struggling with an actual bug, they typically join in bugzilla and provide feedback through it. In such cases, karma also is superflous bureaucracy. The only case I'd see some sense for karma would be feature upgrades. A case which in Fedora is supposed to happen in rawhide. If you can't find anyone the bug affects I don't see why its an urgent must-fix. c.f. above - not all bugs are highly user visible. This doesn't mean these bugs are not present in Fedora nor does this mean they do not affect Fedora users. Conversely, things like memory leaks, potential security leaks or libraries mal-processing something, often get away unnoticed and actually are much more serious than a single application dumping core immediately. Fixes to these kind of issues often are the cause for situations users typically describe as something started to work magically with nobody recalling actually having address it. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
