On Friday, 4 January 2013 at 21:02:45 UTC, deadalnix wrote:
> I don't think anybody really care if this start with 0 or 1. What is weird is that you'll find 2 numbers versions and 3 numbers one, which is confusing (and I never saw that in any software).

Looking at several software and what they do, it seems that starting with 0 and with 1 are both fairly common.

WE ARE DEV, WE START COUNTING AT 0 !

On Friday, 4 January 2013 at 21:05:42 UTC, deadalnix wrote:
> On Friday, 4 January 2013 at 21:02:45 UTC, deadalnix wrote:
>> I don't think anybody really care if this start with 0 or 1. What is weird is that you'll find 2 numbers versions and 3 numbers one, which is confusing (and I never saw that in any software).
>
> Looking at several software and what they do, it seems that starting with 0 and with 1 are both fairly common.
>
> WE ARE DEV, WE START COUNTING AT 0 !

Even better is to also identify in the version sequence, what is a beta release and what is not.

AFAIAC the current 2.061 release is in a beta stage because it is not yet "stable". The question though, is what does "stable" mean?

For a definition, I propose something like:

All known critical bugs have been resolved, and a certain percentage [to be determined] of all known non-critical bugs have been resolved, or some function thereof. We can settle on something I'm sure, but right now we have no definition of what stable means, so that's perhaps one reason why new releases are more buggy than I would expect them to be. But what does that mean? It means that I would *not* use the new release for anything that mattered in a production environment, not until it stabilized to a much higher standard than it currently is at.

--rt

On Friday, 4 January 2013 at 20:41:47 UTC, Dmitry Olshansky wrote:
>
> Staging branch was there, so did the betas.
> What could have helped is announcing beta at D.announce instead of separate list. Plus at holidays there was not much of beta test coverage.

Yes, being the first pass through with an incomplete and poorly understood process didn't help, along with the timing, so the result is what the process produced in its current form.

We're definitely making progress however, and hopefully the criticisms are taken constructively as they should be. We just want to see things improve, that's all.

One improvement for next pass through, is to release installable snapshots of the next beta directly on the download page (with appropriate labeling) so that it is trivially easy for end users to download and install the latest beta for testing.

Also, as I mentioned in my previous post, we ought to define what "stable" means so that we have a much better way to judge if the current beta is ready for release or not. As it sits, we have no definition, so it's not surprising that some people thought the current version was ready, while others are not so sure of that.

--rt

On Fri, Jan 04, 2013 at 11:54:32PM +0100, Rob T wrote: [...]
> Even better is to also identify in the version sequence, what is a beta release and what is not.
> 
> AFAIAC the current 2.061 release is in a beta stage because it is not yet "stable". The question though, is what does "stable" mean?
> 
> For a definition, I propose something like:
> 
> All known critical bugs have been resolved, and a certain percentage [to be determined] of all known non-critical bugs have been resolved, or some function thereof. We can settle on something I'm sure, but right now we have no definition of what stable means, so that's perhaps one reason why new releases are more buggy than I would expect them to be. But what does that mean? It means that I would *not* use the new release for anything that mattered in a production environment, not until it stabilized to a much higher standard than it currently is at.
[...]

The problem is, what constitutes "stable" is a judgment call, because which bugs are critical (or, in this case, release-critical) are also a judgment call.

So we would need a delegated Release Manager who decides when a particular release branch is ready to be released, and who holds high standards of what constitutes "release-ready".

Or have some kind of voting system such that some fixed percentage of the top-voted bugs must be fixed before something can be released.  The bug tracker already has a voting system, but (1) people don't pay attention to it, so the number of votes a bug gets doesn't seem to correlate with its likelihood of getting fixed; and (2) the number of votes you can cast is arbitrarily limited to 10, which discourages people from using the system.


T

-- 
Don't get stuck in a closet---wear yourself out.

On Sat, Jan 05, 2013 at 12:02:39AM +0100, Rob T wrote: [...]
> We're definitely making progress however, and hopefully the criticisms are taken constructively as they should be. We just want to see things improve, that's all.
> 
> One improvement for next pass through, is to release installable snapshots of the next beta directly on the download page (with appropriate labeling) so that it is trivially easy for end users to download and install the latest beta for testing.
[...]

+1. More beta test coverage can only be a good thing.


T

-- 
Life is complex. It consists of real and imaginary parts. -- YHL

On Saturday, 5 January 2013 at 01:00:28 UTC, H. S. Teoh wrote:
>
> The problem is, what constitutes "stable" is a judgment call, because
> which bugs are critical (or, in this case, release-critical) are also a
> judgment call.
>
> So we would need a delegated Release Manager who decides when a
> particular release branch is ready to be released, and who holds high
> standards of what constitutes "release-ready".
>
> [...]

Good points.

As it stands right now, someone *has* to make a decision when to release, so we in effect have a "Release Manager" already, although who is making the decision and how the decision is being made is not clear at all. Personally, I would not want to be in that position because I would have nothing to guide me when deciding to make a release (or not), and if I made a mistake and released too soon or too late, then all the abuse for the mistake will be directed at me personally. I'd much rather have angry people place blame on a less than adequate process instead.

Processes are much easier to improve on and no one but the process itself is too blame when a process fails to deliver.

The point is, any definitions we come up with will be better than absolutely no definitions at all. For example the process as it is being defined, is making a positive impact even in its embryonic state. It allows us to look back at past less-than-perfect results, and move ahead with further incremental improvements. No one is to blame for the results, so we focus on the process improvements instead of pointing fingers at people.

--rt

Am Fri, 04 Jan 2013 21:01:41 +0100
schrieb "Rob T" <rob@ucora.com>:

> On Friday, 4 January 2013 at 17:11:54 UTC, Johannes Pfau wrote:
> > The more I think about it, staging really seems to be useful to
> > avoid
> > some corner cases.
> 
> I haven't had time to study the newly proposed process in enough detail to properly comment, but it always seemed to me that you cannot get away without a staging branch. You can try very hard to do without, but it means something else will suffer for the lack of it, so it seems you are coming to the same conclusion which is good (unless I'm wrong).

Yep. As we have lost most attention in this thread(most people have probably set "ignore this thread") we should check if we all agree on the process as outlined on the updated wiki page (I've updated the original page now) and improve it, if necessary, do some proof reading / spell checking and then open a new thread, asking for comments from the main devs.

Am Fri, 04 Jan 2013 19:35:17 +0100
schrieb "deadalnix" <deadalnix@gmail.com>:


> 
> First, regression fix don't make any sense to me. You suggest to fix bug in master and fix regression in older branches. This should be the opposite IMO.
> 
> A regression is something that used to work, but don't work anymore. So Correcting them in older version seems kind of contradictory, especially when other bugs aren't.

I added a "Definitions" section to explain what's meant by regression in that context. I also added a rationale, but already explained it well. This was written assuming dmd though, were bugfixes can easily cause regressions. For phobos/druntime we could use less strict rules, I added a not about that on the wiki.

Now why we fix regressions in the release branches:
Let's say we have dmd 2.061, 2.062, 2.062.1. A regression was
introduced in 2.062 and my code that compiled fine in 2.061 doesn't work
in 2.062 anymore. But then the regression fix is pushed to the 2.062
release branch, a minor release is made and 2.062.1 successfully
compiles that code again.

If the regression already occured in 2.061 should it be fixed in 2.062? This is a different question, but that situation can't happen as long as we only support 1 release and only fix newly introduced regressions.

> Secondly, in every git commands block you have all the commands to set-up the repository. I think this belong to its own paragraph or even its own page. Then I'd replace them with git remote update in git command block.

Yep, will fix that.

On 2013-01-04 21:11, Jonathan M Davis wrote:

> That's what the beta is for, which we did. Clearly, not enough people tried it
> out, or those regressions would have been caught. Creating a separate branch
> would not fix that.

It fixes other problems, like merging a pull request that should have been merge just because someone has missed a beta was out.

-- 
/Jacob Carlborg

Am Sat, 5 Jan 2013 11:51:43 +0100
schrieb Johannes Pfau <nospam@example.com>:

> Am Fri, 04 Jan 2013 19:35:17 +0100
> schrieb "deadalnix" <deadalnix@gmail.com>:
> > Secondly, in every git commands block you have all the commands to set-up the repository. I think this belong to its own paragraph or even its own page. Then I'd replace them with git remote update in git command block.
> 
> Yep, will fix that.
> 
http://wiki.dlang.org/Release_Process

Fixed, there's a "Local repository setup" section now. The instructions should be useable like a script now, although it would be good if someone proof-read them.

BTW: especially http://wiki.dlang.org/Release_Process#Local_repository_setup should be proof-read. I'm not sure if it's the best solution, but I wanted something which works fine if the staging branch already exists on origin(new forks) and if it doesn't already exist.