View mode: basic / threaded / horizontal-split · Log in · Help
January 04, 2013
Re: github release procedure
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 !
January 04, 2013
Re: github release procedure
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
January 04, 2013
Re: github release procedure
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
January 05, 2013
Re: github release procedure
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.
January 05, 2013
Re: github release procedure
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
January 05, 2013
Re: github release procedure
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
January 05, 2013
Re: github release procedure
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.
January 05, 2013
Re: github release procedure
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.
January 05, 2013
Re: github release procedure
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
January 05, 2013
Re: github release procedure
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.
3 4 5 6 7 8
Top | Discussion index | About this forum | D home