Am Mittwoch, 5. Oktober 2011, 11:35:41 schrieb Aaron J. Seigo: > On Tuesday, October 4, 2011 21:46:53 Sven Burmeister wrote: > > Since we have to start somewhere, as a plasma dev, how do you feel about > > prioritising regressions as soon as they are reported and fixing them > > ASAP, i.e. before the next minor release at latest? > > regressions where: master, stable branch, ..?
Since distros only ship released versions I guess that would be branch. > how would they be identified? (e.g.: who would identify them, how would they > be tagged, etc..) Users and developers who either build branch or users and developers who use packages with daily/weekly snapshots of the code branch for the latest major release which still gets minor releases, i.e. currently KDE SC 4.7.x. OBS can do automatic checkouts and package building for example. This would even save some time for the release team since they only have to pick the last tarballs and can be sure they build or to put it the other way around, build issues appear as they are introduced. > what is the definition of a regression? (i've had, on more than one > occassion, a change in a feature described as a "regression" by a person > who wanted it the old way.) Within minor releases there are/should be no feature changes. Nitpicking about the details does not make sense, I would like to rely on the common sense within the community. There might be situations where a change in functionality happens – most often though it's pretty obvious that something does not work the way it should and did before. > with reasonable answers/definitions to the above, i can only say that > regressions could be prioritized. > > there is no way, with a non-stable work force as in an open source project > and the amount of work that we need to do elsewhere, commit to "by next > minor release". Is there more important work than fixing a regression? Maybe crashes and data losses but otherwise I'd assume that it's: first fix what you (not you but dev x) broke and continue afterwards. > in times past (and recent), our team has been quite capable of pounding out > the bug fixes when the issues are well triaged and prioritized. so i don't > think the issue is finding commitment from us for follow through, the issue > is getting to a data set from which we can apply our commitment. I'm not sure how many regressions creep in with a minor release but I'd hope it's <5 across the whole minor release hence priority settings among these is not necessary. But even if, it should be trivial to prioritise. And if the dev team does not know how to prioritise their bugs I can do that. In general regressions must have the highest priority after crashes and data loss bugs simply because they break something that did work before. About triaging, I'm not sure what you mean. If x+1 user can reproduce that button y does not work anymore but did before that should suffice since if he'd know the cause/code he could fix it himself. After all it's a regression and not a "normal" bug. Devs should be thankful to get a report about a regression ASAP since that minimises the number of commits to check. Ideally the commit which causes it is known but in that seldom case no dev is needed anyway since once can simply revert it and notify whoever committed the cause for the regression that he needs to fix his code. AFAIU Martin regressions mostly appear because devs do not test minor releases well enough but are working on the next major release's code base. Sven >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
