Am Thu, 03 Jan 2013 10:58:46 -0800
schrieb Walter Bright <newshound2@digitalmars.com>:


> > What changes? All changes should be made in master, then applied to staging via cherry picking.
> 
> I think that's a vast assumption that there would never be changes specific to the release.

If there's a change which is 100% specific to a release it can be pushed to staging directly, but then there's no need to merge it back into master. If the change makes sense in master, push it to master then cherry pick into staging.

On 1/3/13 1:58 PM, Walter Bright wrote:
> As I suggested to Jacob, if the wiki lists git command sequences, it
> should be complete (like a script), and not full of assumptions about
> other commands that need to be inserted.

I think this is a pertinent point - the process proposed at github is incomplete and scantily motivated. Can the experts make one more pass through it?

Thanks,

Andrei

On Thursday, 3 January 2013 at 19:19:49 UTC, Andrei Alexandrescu wrote:
> On 1/3/13 1:58 PM, Walter Bright wrote:
>> As I suggested to Jacob, if the wiki lists git command sequences, it
>> should be complete (like a script), and not full of assumptions about
>> other commands that need to be inserted.
>
> I think this is a pertinent point - the process proposed at github is incomplete and scantily motivated. Can the experts make one more pass through it?
>
> Thanks,
>
> Andrei

I'm rather concerned when I see comments that suggest that the purpose of the staging branch was not understood in the slightest. There's a lot of discussion on the issue here http://forum.dlang.org/thread/ka5rv5$2k60$1@digitalmars.com

The people who are attempting to use the new process have to at least take some time to read through the process discussion threads, certainly that is not ideal, and the wiki should explain everything much better.

The reason for a less than adequate process description, is that the process was not yet fully completed and was difficult to complete without a dry run to work out the bugs and oversights etc. Instead of a dry run, we're experiencing the real thing, started in the middle of the holidays to boot.

We have to expect some problems of course!

It would be nice to contain everything under one discussion thread so that the same people who started this whole thing are more likely to notice the complaints and misunderstandings and so forth.

--rt

Couldn't we just make an auto-publishing cron-job service or so which periodically (once a day or even just after a push/merge) compiles dmd and everything, packs it and makes this archive downloadable then?

Of course this literally rolling release should be marked as unstable/nightly build. Anyway, if a halfway stable state has been reached or if the community thinks that it's enough for a version bump,
the latest build is simply tagged and marked as latest stable version.
How easy is that?

Am Thu, 03 Jan 2013 21:17:08 +0100
schrieb "Rob T" <rob@ucora.com>:

> On Thursday, 3 January 2013 at 19:19:49 UTC, Andrei Alexandrescu wrote:
> > On 1/3/13 1:58 PM, Walter Bright wrote:
> >> As I suggested to Jacob, if the wiki lists git command
> >> sequences, it
> >> should be complete (like a script), and not full of
> >> assumptions about
> >> other commands that need to be inserted.
> >
> > I think this is a pertinent point - the process proposed at github is incomplete and scantily motivated. Can the experts make one more pass through it?
> >
> > Thanks,
> >
> > Andrei
> 
> I'm rather concerned when I see comments that suggest that the purpose of the staging branch was not understood in the slightest. There's a lot of discussion on the issue here http://forum.dlang.org/thread/ka5rv5$2k60$1@digitalmars.com

Sorry, but I'm not sure if we have a consensus on some things discussed
there:
This is probably the best summary:
http://forum.dlang.org/thread/ka5rv5$2k60$1@digitalmars.com?page=16#post-woyboqigqbkqjxmshppn:40forum.dlang.org


"4. Feature can than be further refined and _integration bugs_ can be fixed by the general dev team."

What's the overhead for many small feature branches? DMD work is probably 90% small bug fixes and 10% bigger features. So most of the time there are no "integration bugs" and we just waste man power reviewing commits again and copying those into staging?


"When the "dev" branch is considered stable enough by the team (exact criteria to be defined later), the changes are merged to the _2nd level of integration_ - the "staging" branch. This allows for a wider audience to test and provide real-world feedback."

The exact criteria would be kinda important. But as we have many small bugfixes which are merged every day I don't see how the master branch would suddenly get more "stable".


What I am most concerned about are the timespans discussed:
"I propose to go for a yearly release of the
stable branches with one year support (In the beginning)."

The wiki discussion page even mentions "I don't think 4 months are a ridiculously long time for staging if the release is made every 3 years."

On Thursday, January 03, 2013 21:42:37 Johannes Pfau wrote:
> What I am most concerned about are the timespans discussed:
> "I propose to go for a yearly release of the
> stable branches with one year support (In the beginning)."
> 
> The wiki discussion page even mentions "I don't think 4 months are a ridiculously long time for staging if the release is made every 3 years."

That makes it sound like they want the current stuff to be marked as staging and then have some other release that sits around for a very long time being treated as somehow more stable than the staging branch. In general, there's nothing about bug fixing which is stable, and separating out bug fixes between a more stable branch and a less stable one doesn't make all that much sense. Separating out new features and not putting them in the "stable" branch makes sense, but that really doesn't make sense for bugs.

Also, the name "staging" implies that it's purely for preparing a release, in which case keeping it around makes _no_ sense. Not to mention, as already mentioned, it would make more sense to simply create a new branch for each release to begin with than have a staging branch if that's what it's for. And if that's not what it's for, then it's a horrible name.

- Jonathan M Davis

On Thu, Jan 03, 2013 at 09:17:08PM +0100, Rob T wrote:
> On Thursday, 3 January 2013 at 19:19:49 UTC, Andrei Alexandrescu wrote:
> >On 1/3/13 1:58 PM, Walter Bright wrote:
> >>As I suggested to Jacob, if the wiki lists git command sequences, it should be complete (like a script), and not full of assumptions about other commands that need to be inserted.
> >
> >I think this is a pertinent point - the process proposed at github is incomplete and scantily motivated. Can the experts make one more pass through it?
[...]
> I'm rather concerned when I see comments that suggest that the purpose of the staging branch was not understood in the slightest. There's a lot of discussion on the issue here http://forum.dlang.org/thread/ka5rv5$2k60$1@digitalmars.com

In my mind, 'staging' is just a placeholder name for the place where we can freeze new features and stabilize them before a release. The actual mechanics of doing this is independent of the concept itself.

We could either:

(1) Have an actual branch called 'staging', where changes made to master since the last merge are merged in immediately after release, and when things have sufficiently stabilized, we tag/branch that particular commit as release 2.X.Y;

(2) Or, we can follow Walter's suggestion of branching master into 2.X.Y after a release and just tag it as a release when it's sufficiently stable. In this case, the latest 2.X.Y branch acts as 'staging'.

Part of the draw of (1) is that betatesters and adventurous people have a fixed place to go to, to get the latest and greatest features, but without the instability of master.

I think (2) is more commonly what is actually done by software companies and projects. In this case, 'staging' isn't so much as an actual physical branch, as the general concept of having a branch (2.X.Y, which changes per release) to stabilize things for a release, while development on master continues unhindered.

The Linux kernel also uses a similar kind of process: X.Y.Z is a development release (can be thought of as 'master') when Y is odd, and a stable release (can be thought of as 'staging' or Walter's release branches) when Y is even.

Basically, the idea is that master should be able to receive the latest and greatest features, completely unhindered, while stabilizing the code for a release is done in a separate branch which doesn't receive new features, but only bugfixes, prior to an actual release.


> The people who are attempting to use the new process have to at least take some time to read through the process discussion threads, certainly that is not ideal, and the wiki should explain everything much better.
[...]

I confess to having contributed some poorly-written material on the wiki page. Please feel free to revise it.


T

-- 
The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5

On 1/3/13 3:17 PM, Rob T wrote:
> On Thursday, 3 January 2013 at 19:19:49 UTC, Andrei Alexandrescu wrote:
>> On 1/3/13 1:58 PM, Walter Bright wrote:
>>> As I suggested to Jacob, if the wiki lists git command sequences, it
>>> should be complete (like a script), and not full of assumptions about
>>> other commands that need to be inserted.
>>
>> I think this is a pertinent point - the process proposed at github is
>> incomplete and scantily motivated. Can the experts make one more pass
>> through it?
>>
>> Thanks,
>>
>> Andrei
>
> I'm rather concerned when I see comments that suggest that the purpose
> of the staging branch was not understood in the slightest. There's a lot
> of discussion on the issue here
> http://forum.dlang.org/thread/ka5rv5$2k60$1@digitalmars.com
>
> The people who are attempting to use the new process have to at least
> take some time to read through the process discussion threads, certainly
> that is not ideal, and the wiki should explain everything much better.

That is correct. The discussion was the crucible and the wiki page should be the result of what boiled down into it. There continues to be a bit a debate on the exact details of the procedure to be followed, which has naturally led to a scant wiki page.

That all is natural and expected - no need for it to cause concern.

> The reason for a less than adequate process description, is that the
> process was not yet fully completed and was difficult to complete
> without a dry run to work out the bugs and oversights etc. Instead of a
> dry run, we're experiencing the real thing, started in the middle of the
> holidays to boot.
>
> We have to expect some problems of course!

There we go :o).

> It would be nice to contain everything under one discussion thread so
> that the same people who started this whole thing are more likely to
> notice the complaints and misunderstandings and so forth.

It's funny - that was my exact intent when I started the thread "Next focus: PROCESS"!


Andrei

On Thursday, 3 January 2013 at 22:16:07 UTC, Andrei Alexandrescu wrote:
> It's funny - that was my exact intent when I started the thread "Next focus: PROCESS"!
>
>
> Andrei

I know that was your intent and we tried hard to stay focused in that thread, and it was working reasonably well, but now we have another thread to deal with that is disconnected from the first thread, resulting in people repeating themselves all over again. I know it was rejected a thousand times before, but solving the disconnection problem was one reason for asking to move the forum into a web based version that could be managed (ie this type of forum cannot be managed at all it seems). The other alternative was to discuss everything in the wiki page, but people found that to be not so good as can be seen by looking at the wiki as well as the comments concerning its use for that purpose.

It would be nice to have a better solution for the community to perform cooperative problem solving than what we have now, which also leads on to resolving other problems such as the endless repeating disconnected discussions on other subjects of importance. I don't want to stray off topic, so just keep in mind that there may be a more significant issue that should be resolved immediately after we get past the current one.

--rt

On Thursday, 3 January 2013 at 20:42:39 UTC, Johannes Pfau wrote:
> Am Thu, 03 Jan 2013 21:17:08 +0100
> schrieb "Rob T" <rob@ucora.com>:
>
>> On Thursday, 3 January 2013 at 19:19:49 UTC, Andrei Alexandrescu wrote:
>> > On 1/3/13 1:58 PM, Walter Bright wrote:
>> >> As I suggested to Jacob, if the wiki lists git command sequences, it
>> >> should be complete (like a script), and not full of assumptions about
>> >> other commands that need to be inserted.
>> >
>> > I think this is a pertinent point - the process proposed at github is incomplete and scantily motivated. Can the experts make one more pass through it?
>> >
>> > Thanks,
>> >
>> > Andrei
>> 
>> I'm rather concerned when I see comments that suggest that the purpose of the staging branch was not understood in the slightest. There's a lot of discussion on the issue here http://forum.dlang.org/thread/ka5rv5$2k60$1@digitalmars.com
>
> Sorry, but I'm not sure if we have a consensus on some things discussed
> there:
> This is probably the best summary:
> http://forum.dlang.org/thread/ka5rv5$2k60$1@digitalmars.com?page=16#post-woyboqigqbkqjxmshppn:40forum.dlang.org
>
>
> "4. Feature can than be further refined and _integration bugs_ can
> be fixed by the general dev team."
>
> What's the overhead for many small feature branches? DMD work is
> probably 90% small bug fixes and 10% bigger features. So most of the
> time there are no "integration bugs" and we just waste man power
> reviewing commits again and copying those into staging?
>
>
> "When the "dev" branch is considered stable enough by the team
> (exact criteria to be defined later), the changes are merged to
> the _2nd level of integration_ - the "staging" branch. This
> allows for a wider audience to test and provide real-world
> feedback."
>
> The exact criteria would be kinda important. But as we have many small
> bugfixes which are merged every day I don't see how the master branch
> would suddenly get more "stable".
>
>
> What I am most concerned about are the timespans discussed:
> "I propose to go for a yearly release of the
> stable branches with one year support (In the beginning)."
>
> The wiki discussion page even mentions "I don't think 4 months are a
> ridiculously long time for staging if the release is made every 3
> years."

Let's clarify a bunch of things here:
1. There is no overhead with maintaining many feature brunches.
2. Feature branches can be safely removed after their contents have been merged. This is useful for avoiding clutter.
3. There is no need to re-review the _same_ code on each branch it is merged to. That's just plain stupid.
4. Chery picking is a HORRIBLE idea for managing releases and should only be used on development. Chery-picking COPIES commits and thus loses the connections in the history graph.
5. There is no problem developing bug_fixes on separate topic branches.
6. There is no problem merging back to master.
7. Let me say this again. Merges are cheap and easy in git. So are re-merges. Avoiding merges is an artifact of client-server designs such as SVN and is NOT compatible with Git's conceptual model.

I suggest to read about how git works and how best to utilize its features, and NOT apply common wisdom from CVS/SVN/RCS which are based on a _completely different_ conceptual model.