www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What is the Go/NoGo gauge for releases?

reply "Andrew Edwards" <ridimz yahoo.com> writes:
Moved from D.announce for further discussion by request:

On Saturday, 12 July 2014 at 00:13:47 UTC, David Nadlinger wrote:

 For convenience, the list of unresolved issues marked as 
 regressions: 
 https://issues.dlang.org/buglist.cgi?bug_severity=regression&resolution=---

 Seems like there is still quite a way to go until we can 
 release RC1.

 David


David, I'm sure you are aware that list will never be empty. The
last release lasted from mid November to 24 February and that
list was never empty once during that entire time. The only way
we will empty that list is to prevent people from submitting new
regressions during a review.

When I checked the list yesterday the count was at 9: right now
it is at 12. And at least on of those items on the list has been
there since 2011.

The reality is that zero emphasis is place on regressions unless
it's time for a release, and even then, only a few people pay
attention to them. Everyone else just continue on in their happy
world doing "what's important to them".  You you cannot ask that
anyone work on anything because if it's not important in their
minds, they will not do it. They'd much rather sit around and
biker about how you did it incorrectly. Which, in my opinion, is
a huge wast of time and resource.

So I have some questions: What is the magic number that will
trigger the release? What happens if we never reach that number?
Do we just continue waiting for it or do we make a decision at
some point that it's time? If so, how long do we wait? Is there
one person who makes the decision, or is it decision automatic?
If there is a person, who is it?
Jul 12 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 7/12/2014 8:35 PM, Andrew Edwards wrote:

 Moved from D.announce for further discussion by request:

 On Saturday, 12 July 2014 at 00:13:47 UTC, David Nadlinger wrote:

 For convenience, the list of unresolved issues marked as regressions:
 https://issues.dlang.org/buglist.cgi?bug_severity=regression&resolution=---


 Seems like there is still quite a way to go until we can release RC1.

 David




[...]

 So I have some questions: What is the magic number that will
 trigger the release? What happens if we never reach that number?
 Do we just continue waiting for it or do we make a decision at
 some point that it's time? If so, how long do we wait? Is there
 one person who makes the decision, or is it decision automatic?
 If there is a person, who is it?


My understanding (I could be wrong) is the general rule of thumb has 
been "No *new* regressions compared to the previous release".
Jul 12 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 13 July 2014 at 01:49:16 UTC, Nick Sabalausky wrote:

 So I have some questions: What is the magic number that will
 trigger the release? What happens if we never reach that 
 number?
 Do we just continue waiting for it or do we make a decision at
 some point that it's time? If so, how long do we wait? Is there
 one person who makes the decision, or is it decision automatic?
 If there is a person, who is it?


 My understanding (I could be wrong) is the general rule of 
 thumb has been "No *new* regressions compared to the previous 
 release".


Yup, this is the case. And it is more important than conforming 
to any specific release date.
Jul 13 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 7/13/14, 7:39 PM, Dicebot wrote:

 On Sunday, 13 July 2014 at 01:49:16 UTC, Nick Sabalausky wrote:

 So I have some questions: What is the magic number that will
 trigger the release? What happens if we never reach that number?
 Do we just continue waiting for it or do we make a decision at
 some point that it's time? If so, how long do we wait? Is there
 one person who makes the decision, or is it decision automatic?
 If there is a person, who is it?


 My understanding (I could be wrong) is the general rule of thumb has
 been "No *new* regressions compared to the previous release".


 Yup, this is the case. And it is more important than conforming to any
 specific release date.



Meaning, we do not release if there is any open regressions with 
exception of issues 12242 and 6329, the only two that existed prior to 
or at the time of the last release. Got it.
Jul 13 2014
parent Jerry <jlquinn optonline.net> writes:
Andrew Edwards <ridimz yahoo.com> writes:


 On 7/13/14, 7:39 PM, Dicebot wrote:

 On Sunday, 13 July 2014 at 01:49:16 UTC, Nick Sabalausky wrote:

 So I have some questions: What is the magic number that will
 trigger the release? What happens if we never reach that number?
 Do we just continue waiting for it or do we make a decision at
 some point that it's time? If so, how long do we wait? Is there
 one person who makes the decision, or is it decision automatic?
 If there is a person, who is it?


 My understanding (I could be wrong) is the general rule of thumb has
 been "No *new* regressions compared to the previous release".


 Yup, this is the case. And it is more important than conforming to any
 specific release date.



 Meaning, we do not release if there is any open regressions with exception of
 issues 12242 and 6329, the only two that existed prior to or at the time of
 the last release. Got it.


At the moment the regression count is relatively small.  If it gets
larger, adopting the GCC approach might make sense.  The policy there is
that they create a release branch when there are no P1 (highest
severity) regressions.  Other regressions can exist if they are deemed
non-critical, but hopefully still fixing them.
Jul 15 2014
prev sibling next sibling parent reply Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
While Nick and Dicebot have covered some of this already, there's a whole lot
of problematic 
statements here that need to be addressed.

On 7/12/14, 5:35 PM, Andrew Edwards via Digitalmars-d wrote:

 Moved from D.announce for further discussion by request:

 On Saturday, 12 July 2014 at 00:13:47 UTC, David Nadlinger wrote:

 For convenience, the list of unresolved issues marked as regressions:
 https://issues.dlang.org/buglist.cgi?bug_severity=regression&resolution=---

 Seems like there is still quite a way to go until we can release RC1.

 David


 David, I'm sure you are aware that list will never be empty.


Never?  Awfully defeatist.  There was a point where it was down to just the one
from 2011.  And 
we've had releases where the no new known regressions policy has been true. 
That rule should remain 
in effect.


 The
 last release lasted from mid November to 24 February and that
 list was never empty once during that entire time. The only way
 we will empty that list is to prevent people from submitting new
 regressions during a review.

 When I checked the list yesterday the count was at 9: right now
 it is at 12. And at least one of those items on the list has been
 there since 2011.


Prevent people from filing bugs?  Not on my watch.  Also, entirely false.  The
way to get that list 
to zero is to actually fix bugs, which is happening, quite nicely.  In the last
week, 19 regressions 
have been filed, 12 of which are already fixed and several others have pulls
open awaiting review 
and merge.  This is entirely expected for the beginning of a beta period.  I'd
be surprised if there 
_weren't_ a bunch of regressions filed.


 The reality is that zero emphasis is place on regressions unless
 it's time for a release, and even then, only a few people pay
 attention to them. Everyone else just continue on in their happy
 world doing "what's important to them".  You you cannot ask that
 anyone work on anything because if it's not important in their
 minds, they will not do it. They'd much rather sit around and
 biker about how you did it incorrectly. Which, in my opinion, is
 a huge wast of time and resource.


Zero is full of hyperbole.  There's several people that do a very good job of
fixing regressions as 
they occur and are reported.  Could there be more emphasis from more people? 
Certainly.

You can't ask?  Bzzzt.  You can and most certainly should ask.  Change of
emphasis during a release 
process is appropriate and a little reminder can help quite a bit.  Are there
kibitzers that play 
arm chair quarterback?  Of course, but that shouldn't stop us from doing what
we believe to be the 
right thing.  The woe is me attitude is ridiculous and certainly not helpful.


 So I have some questions: What is the magic number that will
 trigger the release? What happens if we never reach that number?
 Do we just continue waiting for it or do we make a decision at
 some point that it's time? If so, how long do we wait? Is there
 one person who makes the decision, or is it decision automatic?
 If there is a person, who is it?


As Nick and Dicebot have said already, but worth repeating, I agree that the
policy is no known 
regressions since the last release.  Time is by far a secondary factor.  What
happens as time passes 
is that frustration rises and the people that care about getting the release
out refine their focus 
on getting those bugs fixed.  To date, that's definitely fallen on a tiny
number of people, which is 
unfortunate, but it _does_ happen.

That said, no known regressions by itself is also not the only criteria. 
Should we happen to wind 
up with no known regressions today, we still shouldn't be releasing 2.066 as
not enough time has 
passed for enough people to download and test to get any new bugs filed.

My 2 cents,
Brad
Jul 13 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 7/14/14, 7:11 AM, Brad Roberts via Digitalmars-d wrote:

 On 7/12/14, 5:35 PM, Andrew Edwards via Digitalmars-d wrote:

 David, I'm sure you are aware that list will never be empty.


 Never?  Awfully defeatist.  There was a point where it was down to just
 the one from 2011.  And we've had releases where the no new known
 regressions policy has been true.  That rule should remain in effect.


Defeatist? Hmmmm... You can call me what you want. I'm neither offended 
nor does my point of view change because of it.


 You can't ask?  Bzzzt.  You can and most certainly should ask.  Change
 of emphasis during a release process is appropriate and a little
 reminder can help quite a bit.  Are there kibitzers that play arm chair
 quarterback?  Of course, but that shouldn't stop us from doing what we
 believe to be the right thing.  The woe is me attitude is ridiculous and
 certainly not helpful.


I'd just like to draw your attention to your response to item (d) at:

	http://forum.dlang.org/post/52D07805.9090502 gmail.com
Jul 13 2014
parent Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 7/13/14, 4:09 PM, Andrew Edwards via Digitalmars-d wrote:

 On 7/14/14, 7:11 AM, Brad Roberts via Digitalmars-d wrote:

 On 7/12/14, 5:35 PM, Andrew Edwards via Digitalmars-d wrote:

 David, I'm sure you are aware that list will never be empty.


 Never?  Awfully defeatist.  There was a point where it was down to just
 the one from 2011.  And we've had releases where the no new known
 regressions policy has been true.  That rule should remain in effect.


 Defeatist? Hmmmm... You can call me what you want. I'm neither offended nor
does my point of view
 change because of it.


Please don't take what I said as intent to offend.  It's not.


 You can't ask?  Bzzzt.  You can and most certainly should ask.  Change
 of emphasis during a release process is appropriate and a little
 reminder can help quite a bit.  Are there kibitzers that play arm chair
 quarterback?  Of course, but that shouldn't stop us from doing what we
 believe to be the right thing.  The woe is me attitude is ridiculous and
 certainly not helpful.


 I'd just like to draw your attention to your response to item (d) at:

      http://forum.dlang.org/post/52D07805.9090502 gmail.com


My line in that thread:

   > ideally, but volunteers spend time where they wish.

That line and the above quote are not contradictory.  People are going to do as
they wish, but some 
of our all volunteer staff has actually _asked_ to be given direction.  And
some will take it as a 
nudge in the right direction regardless.
Jul 13 2014
prev sibling parent "Martin Krejcirik" <mk-junk i-line.cz> writes:
What is essential, is to keep fixing bugs _after_ the release, 
i.e. do point releases. It's shame we don't have one for 2.065 
already. Part of the problem is tracking which bugs are actually 
affecting a release branch. Another is a need to backport later 
discovered bugs.
IMHO all regressions affecting release branch (after the .0 
release) should require pull request on release branch.
Jul 13 2014