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