On Wednesday, October 5, 2011 17:48:55 Sven Burmeister wrote: > > regressions where: master, stable branch, ..? > > Since distros only ship released versions I guess that would be branch.
ok; realize that most regressions occur in master, and that master becomes the next release, so a number of regressions may occur between, e.g. 4.7.2 and 4.8.0. which means master, or when it is branched for feature freeze, becomes probably the most important source of regressions. > > 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 this is how someone would notice them .. now how is that verified, communicated and recorded in a process going from identification to fixed. > > 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. i didn't say new features, but changes in existing ones. > Nitpicking > about the details does not make sense, I would like to rely on the common > sense within the community. relying on that is what got us to where we are now. ergo why i ask these questions :) > 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. that will cover 95% of situations; it's the other 5% that give us problems (today and under the scenario you are describing) and which ruin things. we need to get that closer to 99%, and that can come through definition. > > 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? yes, there is. you noted a few yourself (crashes, data loss bugs...), but there are also realities like "we're releasing Plasma Active One this weekend; i won't be working on anything else in Plasma until that's done." regressions are important .. but i will not make commitments i can not keep, so giving a deadline in advance isn't going to happen. if we said "we won't make a new minor release until all regressions of a certain level are fixed", that would work. but it would mean dropping a time-based release cycle. > > 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. hopefully regression counts are low; they can be pretty high in master, however, and can build up over time. they also need to be prioritized so that they can be weighted next to crashes and other severe issues. > But even if, it should be trivial to prioritise. And if this is the epitome of the problem! "well, we need to do this difficult thing that requires coordination and defintion, but i'm sure we can just wing it and figure it out as we go." this is lazy and doomed to failure. either someone takes this on and does a proper, thorough job of it, or don't bother as we already have a mess that sprouted from such an approach. we don't need a new one. > the dev team does not know how to prioritise their bugs I can do that. without an agreement on how priotization works, this will lead to disagreement or the dev team must becoming *your* dev team which just does what you say. good luck on that. > In general regressions must have the highest priority after crashes and data > loss bugs simply because they break something that did work before. according to who's definition of "break"? again, a clear definition of what makes a regression is needed here. (which is not merely a change in behaviour, even though that might make something that was once possible no longer possible) > 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. you've picked a trivial example with no variability in reproduction. which makes the example uninteresting and unhelpful. a more realistic case is a situation where feature X does not work properly in some way (small or large deviance from before) but only for some people and not others who are running various builds on top of various OSes. that's the reality we deal with and why it gets difficult to manage. > 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. in the simple case, yes. > 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 in the simple case, yes. often enough a regression caused by a commit is actually the exposition of a bug / misfeature elsewhere. this "the world is simple" thinking fails to address all the time we have issues with bug reporting: it isn't when the bug is simple and straight forward, it's when it is untriaged, untested, unobvious and/or the people involved are being unsocial. > Martin regressions mostly appear because devs do not test minor releases > well enough but are working on the next major release's code base. well, no, it's because we don't have a traditional Q/A staff .. those who do, could and should be our Q/A team do not have the tools too communicate effectively, accurately and in a timely manner to the dev teams. which is to say: processes around bugs.kde.org are non-existent and/or broken. that's the issue. not devs doing more testing or thinking that regressions can be solved simply if someone on the internet somewhere happens to notice it quickly enough. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
