On 2013-01-05 12:26, Jacob Carlborg wrote:
> 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.
>

should _not_.

-- 
/Jacob Carlborg

On Sat, Jan 05, 2013 at 11:42:23AM +0100, Johannes Pfau wrote:
> 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.

I like the new page!!

One question, though: in the git workflow section, it says that a non-regression bugfix should go directly into staging, but there's no mention of merging it back to master. Is this deliberate? It seems to me to be kinda important that we merge all fixes back to master so that bugs don't get "unfixed". Or am I missing something here?


T

-- 
Why waste time learning, when ignorance is instantaneous? -- Hobbes, from Calvin & Hobbes

Am Sat, 5 Jan 2013 10:21:30 -0800
schrieb "H. S. Teoh" <hsteoh@quickfur.ath.cx>:

> 
> One question, though: in the git workflow section, it says that a non-regression bugfix should go directly into staging, but there's no mention of merging it back to master. Is this deliberate? It seems to me to be kinda important that we merge all fixes back to master so that bugs don't get "unfixed". Or am I missing something here?
> 

It's mentioned in the official branches section and in the summary "Regression fixes and bug fixes will be merged from staging into master." and "Merge staging branch into master regularly", but it should be added to the workflow as well.

I don't think it's urgent to immediately merge it into master though and bugs can't really get 'unfixed' anyway: Releases are made from staging so the fix will be part of releases either way. It's enough to sporadically merge staging to master so that the feature branches and master also get the bug fixes.

One quick note, is that we may want to change the title and description, since I think we're taking about a "Development and Release Process" rather than only a "Release Process".

The new wiki, and even the process page should be linked in on the main page to make it easy for the devs to get access to it.

--rt

Am Sun, 06 Jan 2013 00:18:16 +0100
schrieb "Rob T" <rob@ucora.com>:

> One quick note, is that we may want to change the title and description,

Done.
http://wiki.dlang.org/Development_and_Release_Process

I also verified and corrected the git commands. They should now all work as expected and can be used like a script.

Do you agree with the process as described on that page now? Would be great to also get some feedback from other contributors of the original wiki page.

I wonder whether a section should be added to the wiki explaining the transition from current workflow to the new workflow. For the first release we should do an additional merge from master into staging in ~4weeks as otherwise there won't be any new features in 2.062.

And I'd recommend merging staging into master, then deleting staging and creating it again as we don't know whether staging already has cherry picked commits etc?

If we want to maintain the current release we might have to use cherry-picking this one time as I think there are already regression fixes only pushed to master / staging which should be in the version branch.

On Thursday, 3 January 2013 at 17:56:05 UTC, Johannes Pfau wrote:
> What changes? All changes should be made in master, then applied to
> staging via cherry picking. So there should never be changes in staging
> that are not in master so there's nothing that could be overwritten?

I strongly disagree here. We want pull requests to be made against the oldest supported/relevant branch. This could be merged to both staging and master (which can simply be done by merging staging into master) there is no need to complicate things with cherry picking.

As for history, I think that clearly shows what the history is, staging gets fixes and master gets staging that is what we want.

On Friday, 4 January 2013 at 20:10:33 UTC, Rob T wrote:
> If you look at the download page, the .0 is missing on some of the packages, but shows up as a -0 on some of the others, and that is simply confusing and totally unnecessary. If it is necessary for some reason, then it needs to be explained.

The -0 is a packaging version, if you repackage 2.63 (fixing dependencies) then the package is 2.63-1.

Am Wed, 09 Jan 2013 18:37:15 +0100
schrieb "Jesse Phillips" <Jessekphillips+D@gmail.com>:

> On Thursday, 3 January 2013 at 17:56:05 UTC, Johannes Pfau wrote:
> > What changes? All changes should be made in master, then
> > applied to
> > staging via cherry picking. So there should never be changes in
> > staging
> > that are not in master so there's nothing that could be
> > overwritten?
> 
> I strongly disagree here. We want pull requests to be made against the oldest supported/relevant branch. This could be merged to both staging and master (which can simply be done by merging staging into master) there is no need to complicate things with cherry picking.
> 
> As for history, I think that clearly shows what the history is, staging gets fixes and master gets staging that is what we want.

You replied to one of my oldest posts in this discussion ;-)

I didn't understand the staging concept when I wrote that - I think I've understood most of it now, though. I think the old release process wiki page wasn't clear enough.

I've updated the http://wiki.dlang.org/Development_and_Release_Process page last week (I even added a "do not cherry pick from one official branch into another" rule), so you won't have to convince me ;-)

Do you think the wiki page is good / correct? I've verified that all git commands work, so if everyone agrees with the workflow (should be the same as on the old page) we can probably start a new thread and ask for comments from the core devs.

On Wed, Jan 09, 2013 at 09:40:59PM +0100, Johannes Pfau wrote: [...]
> I've updated the http://wiki.dlang.org/Development_and_Release_Process page last week (I even added a "do not cherry pick from one official branch into another" rule), so you won't have to convince me ;-)
> 
> Do you think the wiki page is good / correct? I've verified that all git commands work, so if everyone agrees with the workflow (should be the same as on the old page) we can probably start a new thread and ask for comments from the core devs.

The earlier we can get input from the core devs, the better. Otherwise we're just building castles in the air.


T

-- 
It only takes one twig to burn down a forest.