Community

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.

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