View mode: basic / threaded / horizontal-split · Log in · Help
December 19, 2012
Re: Next focus: PROCESS
On 12/19/12 1:45 PM, H. S. Teoh wrote:
> On Fri, Dec 14, 2012 at 10:16:45AM -0500, Andrei Alexandrescu wrote:
>> On 12/14/12 10:02 AM, H. S. Teoh wrote:
>>> A number of us have put up a draft of a proposed release process on
>>> the wiki, based on some of the things discussed in this thread.
>>>
>>> 	http://wiki.dlang.org/Release_Process
>>
>> Seen it, will give a thorough read today. Thanks!
> [...]
>
> Just to follow up, any comments on what's there currently?
>
> I fear that some of us on this thread may be over-engineering the whole
> thing without input from the core devs who will actually be implementing
> this process.

I was hoping for more consensus to build in this thread. Right now it 
seems there's still quite a bit of controversy about what the best way 
to go is.

Andrei
December 19, 2012
Re: Next focus: PROCESS
On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei 
Alexandrescu wrote:
>
> I was hoping for more consensus to build in this thread. Right 
> now it seems there's still quite a bit of controversy about 
> what the best way to go is.
>
> Andrei

We need to list out all the main points of contention and pick 
away at them until there's none left

I suspect that some of it may be more of a misunderstanding than 
real contention, but no doubt a few key points are in contention.

In terms of "core devs", I know about Walter and Andrei, so who 
else is there that has yet to give us any input?

--rt
December 19, 2012
Re: Next focus: PROCESS
On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei 
Alexandrescu wrote:
> I was hoping for more consensus to build in this thread. Right 
> now it seems there's still quite a bit of controversy about 
> what the best way to go is.
>

I'm afraid a lot of discussions we see right now are plain 
useless because overengineered. This shouldn't prevent us from 
switching some more basics things, like the git workflow and see 
how it work.

This process need some actual practical use for the reflection to 
go forward, as it has gone way too far in the stratosphere.
December 19, 2012
Re: Next focus: PROCESS
On Wednesday, 19 December 2012 at 19:26:48 UTC, deadalnix wrote:
> On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei 
> Alexandrescu wrote:
>> I was hoping for more consensus to build in this thread. Right 
>> now it seems there's still quite a bit of controversy about 
>> what the best way to go is.
>>
>
> I'm afraid a lot of discussions we see right now are plain 
> useless because overengineered. This shouldn't prevent us from 
> switching some more basics things, like the git workflow and 
> see how it work.
>
> This process need some actual practical use for the reflection 
> to go forward, as it has gone way too far in the stratosphere.

Yes, overengineering is pointless, and doing something basic is 
better than doing nothing at all, and knowing what will work and 
what won't and what the challenges are means that we have to try 
something out or we'll never learn anything.

There are some main points that I think everyone agrees with that 
could be implemented immediately.

Do we all agree that MASTER becomes the "Dev" branch?

Do we all agree that we need a "testing" (aka staging) branch?

Do we all agree that we need a "stable" branch?

--rt
December 19, 2012
Re: Next focus: PROCESS
On Wed, Dec 19, 2012 at 02:01:57PM -0500, Andrei Alexandrescu wrote:
> On 12/19/12 1:45 PM, H. S. Teoh wrote:
> >On Fri, Dec 14, 2012 at 10:16:45AM -0500, Andrei Alexandrescu wrote:
> >>On 12/14/12 10:02 AM, H. S. Teoh wrote:
> >>>A number of us have put up a draft of a proposed release process on
> >>>the wiki, based on some of the things discussed in this thread.
> >>>
> >>>	http://wiki.dlang.org/Release_Process
> >>
> >>Seen it, will give a thorough read today. Thanks!
> >[...]
> >
> >Just to follow up, any comments on what's there currently?
> >
> >I fear that some of us on this thread may be over-engineering the
> >whole thing without input from the core devs who will actually be
> >implementing this process.
> 
> I was hoping for more consensus to build in this thread. Right now
> it seems there's still quite a bit of controversy about what the
> best way to go is.
[...]

I think we need more input from the core devs before any further
discussions make sense. Like deadalnix said, we've gone way overboard
with the over-engineering; can we at least get the core devs to evaluate
the most basic tenets of the proposal first?

Others can correct me if I'm wrong, but the main points as I understand
them are:

- Continue using master for development, as before.

- New features will be developed in their own dedicated branches
 (branched from master), NOT on master directly. When the new feature
 is deemed ready, by some criterion to be decided on, then it's merged
 into master.

- At some point in the process, perhaps after a release is made from
 staging (see below), the new changes in master are folded into the
 staging branch (we can argue about the exact name of this later).

- The intent of staging is to test new features and possibly breaking
 changes by a wider audience before the official release. It is to be
 used by people who want bleeding-edge features and can live with
 existing code breaking once in a while.

- Staging only receives bugfixes and no new features until it's deemed
 release-ready. It may receive breaking changes if a particular feature
 is deemed unsuitable in its present form and needs to be revised.
 (Said changes are also applied to master, of course.) This is where
 new features are refined from their initial design to their final
 form.

- Once staging is release-ready, a release branch is made from staging,
 then the latest stuff from master is folded into staging.

- A release branch is used for applying critical bugfixes and
 showstopper fixes after a release is made. It does not receive
 low-priority bug fixes, and certainly no new features and no breaking
 changes.

I deliberately left out things like version numbering and timelines,
etc., as those are just bikeshedding. The exact criteria under which
master is folded into staging, and staging is deemed release-ready, are
intentionally left vague. We need the core devs to evaluate whether
these high-level steps in the process are actually workable first,
before we even think about timelines, version numberings, and
merging/branching criteria.


T

-- 
All problems are easy in retrospect.
December 19, 2012
Re: Next focus: PROCESS
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
> On Wednesday, 19 December 2012 at 19:26:48 UTC, deadalnix wrote:
>> On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei 
>> Alexandrescu wrote:
>>> I was hoping for more consensus to build in this thread. 
>>> Right now it seems there's still quite a bit of controversy 
>>> about what the best way to go is.
>>>
>>
>> I'm afraid a lot of discussions we see right now are plain 
>> useless because overengineered. This shouldn't prevent us from 
>> switching some more basics things, like the git workflow and 
>> see how it work.
>>
>> This process need some actual practical use for the reflection 
>> to go forward, as it has gone way too far in the stratosphere.
>
> Yes, overengineering is pointless, and doing something basic is 
> better than doing nothing at all, and knowing what will work 
> and what won't and what the challenges are means that we have 
> to try something out or we'll never learn anything.
>
> There are some main points that I think everyone agrees with 
> that could be implemented immediately.
>
> Do we all agree that MASTER becomes the "Dev" branch?
>

Yes

> Do we all agree that we need a "testing" (aka staging) branch?
>

Yes

> Do we all agree that we need a "stable" branch?
>

No. Stable isn't a boolean criteria. You'll find different degree 
of stability going from not so stable (dev version) to very 
stable (dead project).

The wiki already mention a process with a branch per version of 
the software.
December 19, 2012
Re: Next focus: PROCESS
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix wrote:
> On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
>
>> Do we all agree that we need a "stable" branch?
>>
>
> No. Stable isn't a boolean criteria. You'll find different 
> degree of stability going from not so stable (dev version) to 
> very stable (dead project).
>
> The wiki already mention a process with a branch per version of 
> the software.

Let's generalize this point for the sake of reaching consensus - 
we need _at least one_ "stable" branch which is separate from 
"staging". We are still conflicted as to what should be the 
maximum amount. For the record, I'm with the camp advocating at 
most a fixed amount countable on one hand. That's an O(1) with a 
very small constant as opposed to the O(n) suggestion by Andrei. 
I hope Andrei appreciates the order of efficiency here.
December 19, 2012
Re: Next focus: PROCESS
On 12/19/12 4:23 PM, foobar wrote:
> On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix wrote:
>> On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
>>
>>> Do we all agree that we need a "stable" branch?
>>>
>>
>> No. Stable isn't a boolean criteria. You'll find different degree of
>> stability going from not so stable (dev version) to very stable (dead
>> project).
>>
>> The wiki already mention a process with a branch per version of the
>> software.
>
> Let's generalize this point for the sake of reaching consensus - we need
> _at least one_ "stable" branch which is separate from "staging". We are
> still conflicted as to what should be the maximum amount. For the
> record, I'm with the camp advocating at most a fixed amount countable on
> one hand. That's an O(1) with a very small constant as opposed to the
> O(n) suggestion by Andrei. I hope Andrei appreciates the order of
> efficiency here.

I agree with one "stable" branch.

Andrei
December 19, 2012
Re: Next focus: PROCESS
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei 
Alexandrescu wrote:
> On 12/19/12 4:23 PM, foobar wrote:
>> On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix 
>> wrote:
>>> On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
>>>
>>>> Do we all agree that we need a "stable" branch?
>>>>
>>>
>>> No. Stable isn't a boolean criteria. You'll find different 
>>> degree of
>>> stability going from not so stable (dev version) to very 
>>> stable (dead
>>> project).
>>>
>>> The wiki already mention a process with a branch per version 
>>> of the
>>> software.
>>
>> Let's generalize this point for the sake of reaching consensus 
>> - we need
>> _at least one_ "stable" branch which is separate from 
>> "staging". We are
>> still conflicted as to what should be the maximum amount. For 
>> the
>> record, I'm with the camp advocating at most a fixed amount 
>> countable on
>> one hand. That's an O(1) with a very small constant as opposed 
>> to the
>> O(n) suggestion by Andrei. I hope Andrei appreciates the order 
>> of
>> efficiency here.
>
> I agree with one "stable" branch.
>

This does conflict with the requirement you gave before about 
being able to support anything, as previous stable version cannot 
be revised.

Or does stable here mean supported ? (which means we still have 
branch per version, but only one version is supported)
December 19, 2012
Re: Next focus: PROCESS
On 12/19/12 4:40 PM, deadalnix wrote:
> On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei Alexandrescu wrote:
>> On 12/19/12 4:23 PM, foobar wrote:
>>> On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix wrote:
>>>> On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
>>>>
>>>>> Do we all agree that we need a "stable" branch?
>>>>>
>>>>
>>>> No. Stable isn't a boolean criteria. You'll find different degree of
>>>> stability going from not so stable (dev version) to very stable (dead
>>>> project).
>>>>
>>>> The wiki already mention a process with a branch per version of the
>>>> software.
>>>
>>> Let's generalize this point for the sake of reaching consensus - we need
>>> _at least one_ "stable" branch which is separate from "staging". We are
>>> still conflicted as to what should be the maximum amount. For the
>>> record, I'm with the camp advocating at most a fixed amount countable on
>>> one hand. That's an O(1) with a very small constant as opposed to the
>>> O(n) suggestion by Andrei. I hope Andrei appreciates the order of
>>> efficiency here.
>>
>> I agree with one "stable" branch.
>>
>
> This does conflict with the requirement you gave before about being able
> to support anything, as previous stable version cannot be revised.
>
> Or does stable here mean supported ? (which means we still have branch
> per version, but only one version is supported)

Walter needs to chime in about that. One possibility is to continue 
using tags for marking releases, and then branch for the few important 
releases that we want to patch.


Andrei
10 11 12 13 14 15 16 17
Top | Discussion index | About this forum | D home