On Fri, Jan 04, 2013 at 08:15:34AM -0800, Jonathan M Davis wrote:
> On Friday, January 04, 2013 15:20:02 Johannes Pfau wrote:
> > And most important: Were the main developers part of that discussion / have they agreed? While I agree LTS would be nice it needs someone to do it. You also have to consider the available man power.
> 
> For the most part, I don't think that they were. I think that Andrei was really the only one of us involved at all, though I'd have to look at the thread again to be sure.
[...]

We solicited for core dev involvement in that thread, but AFAIK, there was only limited participation. It felt like we were just talking about castles in the air, because the people who would actually be implementing the process didn't say very much at all. So I wasn't at all surprised at the misunderstandings in this thread.

Still, I think we're finally converging on the same page here, so that's a good thing.


T

-- 
Amateurs built the Ark; professionals built the Titanic.

On Fri, Jan 04, 2013 at 08:18:52AM -0800, Jonathan M Davis wrote:
> On Friday, January 04, 2013 15:26:20 deadalnix wrote:
[...]
> > Let's get a very practical case here. 2.061 have been released, and Kenji already fixed a bug in it (unreachable statement issue).
> > 
> > Some people (including me, but I'm not the only one) would be interested by a new revision of dmd with that fix.
> > 
> > It is why the proposal include branches as 2.N and revision as 2.N.M . So the same version of D, with bugfixes can be published.
> > 
> > The branch has a 2.N form, the tag has a 2.N.M form.
> 
> And why would that particular bug get a release as opposed to another?

It doesn't. It just gets merged in to the 2.N branch post-release, and once enough fixes have accumulated, we make a 2.N.M release.


> Why wouldit be special? Or are you proposing that we do a 2.N.M release for every bug fix? That seems insane.

Some bugs are important enough to push out to the release branch, e.g. regressions or blocker bugs. Nobody is suggesting we make a new release for *every* bugfix pushed to the release branch -- that *would* be insane. The release manager, whoever that person is, makes the judgment call on when a release branch has enough bugfixes to warrant another 2.N.M release. That can be just a single bug, if it's a critical blocker bug, or it can be 20 bugs, if none of them are too important, but, taken together, constitute a significant improvement over the original release.


> Why wouldn't you just use master if you want the latest?

Because master potentially has breaking changes that one may not want to deal with. E.g. property enforcement, or breaking syntax changes, etc.. Enterprises who adopt D will want to stay with a stable release that won't randomly break code all over the place just because a particular bugfix was needed. That's why it's important to push regressions and blockers to release branches, without the new features in master.


T

-- 
Doubt is a self-fulfilling prophecy.

On Friday, January 04, 2013 08:23:58 H. S. Teoh wrote:
> On Fri, Jan 04, 2013 at 08:15:34AM -0800, Jonathan M Davis wrote:
> > On Friday, January 04, 2013 15:20:02 Johannes Pfau wrote:
> > > And most important: Were the main developers part of that discussion / have they agreed? While I agree LTS would be nice it needs someone to do it. You also have to consider the available man power.
> > 
> > For the most part, I don't think that they were. I think that Andrei was really the only one of us involved at all, though I'd have to look at the thread again to be sure.
> 
> [...]
> 
> We solicited for core dev involvement in that thread, but AFAIK, there was only limited participation. It felt like we were just talking about castles in the air, because the people who would actually be implementing the process didn't say very much at all. So I wasn't at all surprised at the misunderstandings in this thread.
> 
> Still, I think we're finally converging on the same page here, so that's a good thing.

The thread was way too big, and I had too little time to get into that conversation, which is why I wasn't involved.

- Jonathan M Davis

Am Fri, 4 Jan 2013 07:46:55 -0800
schrieb "H. S. Teoh" <hsteoh@quickfur.ath.cx>:

> 
> I like what you did with the page. I think it makes it a lot clearer. I read through "Release Schedule" and "Branching model", and I think it pretty much captures what I described as approach (2).
> 
Yes. The original workflow described in the wiki should be very similar, except that I removed staging.

> If this approach is more suitable for the core devs, then I think we should go with it.

I also created a version with staging: http://wiki.dlang.org/User:Jpf/Release_Process_Staging

It occurred to me that there is one detil where staging is really useful: If we have bugfix pull requests which target a version branch which is stabilizing (e.g 2.062) that's fine. But if those aren't merged when 2.062 is released, all open pull requests will still target 2.062 but they should target 2.063 instead. So we have to cycle through all pull requests and ask the contributors to retarget 2.063.

With staging bug fixes can just always target staging and this is not an issue.


I think in the end the core devs should choose. But it seems like an extra staging is more difficult to understand but can avoid some additional work in long term.

> Whether or not one is a git expert ought not matter, if we define the process sufficiently clearly that one can simply look up the wiki page and type in the commands as-is, like a script, as Walter puts it. The important point is to agree on a single implementation of the process, and supply complete and unambiguous series of git commands to carry out the process.
I agree. I try to do that on the wiki page, but I can't guarantee that it's complete.

Am Fri, 4 Jan 2013 08:20:00 -0800
schrieb "H. S. Teoh" <hsteoh@quickfur.ath.cx>:

> 
> I'm not sure, but in my experience at my day jobs, any bugfix that *can* be applied to master (i.e., the code hasn't diverged so much that the fix doesn't apply anymore), *should* be. For this reason, it's best to always base bugfixes on master, unless the code has diverged so much the fix only applies to a particular release branch. Otherwise you end up with the problem somebody mentioned, that the bug is fixed in a previous release, but is "unfixed" in a later release because we neglected to merge the fix into master.

But if you base bug fixes on master you have to merge master into the release branch to get the bug fixes. But master may contain newly added features which you don't want in the release branch.

The more I think about it, staging really seems to be useful to avoid some corner cases.

Am Fri, 4 Jan 2013 08:31:57 -0800
schrieb "H. S. Teoh" <hsteoh@quickfur.ath.cx>:

> On Fri, Jan 04, 2013 at 08:18:52AM -0800, Jonathan M Davis wrote:
> > On Friday, January 04, 2013 15:26:20 deadalnix wrote:
> > > It is why the proposal include branches as 2.N and revision as 2.N.M . So the same version of D, with bugfixes can be published.
> > > 
> > > The branch has a 2.N form, the tag has a 2.N.M form.
> > 
> > And why would that particular bug get a release as opposed to another?

I would propose to only merge regression fixes into minor releases. At least for dmd every bug fix also has potential to break user code. I think if 2.061 compiled some code, 2.061.1 should as well and the only way to ensure that is by only merging regression fixes (regressions which started to occur in 2.061).

The decision what fixed bug / regression justifies an immediate release is up to the release manager. But to make things simple we can just have a fixed schedule for less urgent fixes: release a update every x weeks.

Am Fri, 04 Jan 2013 08:35:17 -0800
schrieb Jonathan M Davis <jmdavisProg@gmx.com>:

> The thread was way too big, and I had too little time to get into that conversation, which is why I wasn't involved.
> 
> - Jonathan M Davis

I've restructured the wiki page here: http://wiki.dlang.org/User:Jpf/Release_Process_Staging

Do you think that's clearer?

(To my understanding it's the same process as proposed on the
"official" wiki page)

On Friday, 4 January 2013 at 16:19:45 UTC, Jonathan M Davis wrote:
> And why would that particular bug get a release as opposed to another? Why
> wouldit be special? Or are you proposing that we do a 2.N.M release for every
> bug fix? That seems insane. Why wouldn't you just use master if you want the
> latest?
>

That is not latest, that is bug fixes. That is the whole point of changing process : being able to publish bug fixes without new features, so users don't need to wait mounth to get their bug fixed and get bunch of unrelated stuff with the fix that may introduce bugs as well.

I took this precise example, but I'm not suggesting that a revision is made for EVERY bug fix. Only for severe bugs (regressions, corrupted codegen, . . .) or when the quantity is judged enough.

On Friday, 4 January 2013 at 17:26:02 UTC, Johannes Pfau wrote:
> Am Fri, 04 Jan 2013 08:35:17 -0800
> schrieb Jonathan M Davis <jmdavisProg@gmx.com>:
>
>> The thread was way too big, and I had too little time to get into
>> that conversation, which is why I wasn't involved.
>> 
>> - Jonathan M Davis
>
> I've restructured the wiki page here:
> http://wiki.dlang.org/User:Jpf/Release_Process_Staging
>
> Do you think that's clearer?
>

This is very good, however, some thing are still unclear.

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 don't think separating those 2 type of bugs is really beneficial and I would keep only the process for regression fixes.

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.

Finally, it is weird that we have v2.062 -> v2.062.1 . I'd prefers v2.062.0 for the first one.

I like very much the ASCII art on top, which make thing really clear. Overall, it is better that the actual version on the wiki.

On Fri, Jan 04, 2013 at 07:35:17PM +0100, deadalnix wrote:
> On Friday, 4 January 2013 at 17:26:02 UTC, Johannes Pfau wrote:
[...]
> >I've restructured the wiki page here: http://wiki.dlang.org/User:Jpf/Release_Process_Staging
> >
> >Do you think that's clearer?
[...]
> I like very much the ASCII art on top, which make thing really clear. Overall, it is better that the actual version on the wiki.

I think we should replace the actual version with this one. No point working on it as a user page when it's what's going to be implemented anyway. Wiki history will let us go back to review the old version if necessary.


T

-- 
Life is too short to run proprietary software. -- Bdale Garbee