December 13, 2012
On Thursday, 13 December 2012 at 15:44:25 UTC, Joseph Rushton Wakeling wrote:
>
> My feeling here was that as it stands Phobos is still somewhat more in flux than D itself, not so much in terms of breaking changes as in terms of new features being added.  So, I was wondering if it might be worthwhile to make new-Phobos-feature releases on a more regular basis at least in the short term while the library is still being expanded.  But I won't press for it too much.

I'll be the first to agree that Phobos should be separated from the compiler releases, but not entirely. I wish the std lib could be separated into an "essential component" and a "non-essential component" so that a partial decoupling could be achieved, that way the essential component could be directly locked into successive compiler releases, while leaving out the non-essential as a separate add-on package following it's own course of development.

But IMO we're straying off-topic because what we really need to do first, is fire up a wiki page to write down and agree on (as best as we can) what we want to achieve (a list of goals), and only after that can we continue on deciding what process will meet all of the agreed on goals.

Anyone proficient in wiki pages want to create a new page for defining the goals?

--rt
December 13, 2012
On Thu, Dec 13, 2012 at 07:26:18PM +0100, Rob T wrote: [...]
> But IMO we're straying off-topic because what we really need to do first, is fire up a wiki page to write down and agree on (as best as we can) what we want to achieve (a list of goals), and only after that can we continue on deciding what process will meet all of the agreed on goals.
> 
> Anyone proficient in wiki pages want to create a new page for defining the goals?
[...]

There's been too much talk and little action, so I've gone ahead with a stub page for this discussion:

http://wiki.dlang.org/Proposed_new_D_development_process

Please fill in the details as you understand them, so that we have something to start with.

Also, it will probably be best if we continue this discussion on the talk page, so that everything is in one place.

Since each of us may have conflicting ideas about what the final process should be, let's adopt the convention that if something on the page is not how you understand things should be, you should discuss on the talk page before making the change, so that we don't devolve into an edit war.


T

-- 
Computerese Irregular Verb Conjugation: I have preferences.  You have biases.  He/She has prejudices. -- Gene Wirchenko
December 13, 2012
On Thursday, 13 December 2012 at 18:41:47 UTC, H. S. Teoh wrote:
> On Thu, Dec 13, 2012 at 07:26:18PM +0100, Rob T wrote:
> [...]
>> But IMO we're straying off-topic because what we really need to do
>> first, is fire up a wiki page to write down and agree on (as best as
>> we can) what we want to achieve (a list of goals), and only after
>> that can we continue on deciding what process will meet all of the
>> agreed on goals.
>> 
>> Anyone proficient in wiki pages want to create a new page for
>> defining the goals?
> [...]
>
> There's been too much talk and little action, so I've gone ahead with a
> stub page for this discussion:
>
> http://wiki.dlang.org/Proposed_new_D_development_process
>
> Please fill in the details as you understand them, so that we have
> something to start with.
>
> Also, it will probably be best if we continue this discussion on the
> talk page, so that everything is in one place.
>
> Since each of us may have conflicting ideas about what the final process
> should be, let's adopt the convention that if something on the page is
> not how you understand things should be, you should discuss on the talk
> page before making the change, so that we don't devolve into an edit
> war.
>

I just started this http://wiki.dlang.org/Release_Process

Feel free to merge or whatever.
December 13, 2012
12/13/2012 12:13 AM, deadalnix пишет:
> Let me do some proposal. If people are happy with them, I can start some
> wikification.
>
> First here are the branch already existing :
>
> dev : development branch. It is used to merge new features.
> master : is the branch where the next version is stabilized (right now,
> 2.061). It receive only bug fix. eventually new features if the feature
> is of strategic importance.
> 2.60 : contains the current released version of D + bug fix.
>
> Release process :
>
> When branch 2.60 have enoug bug fixes to justify a new release, a tag is
> created (2.60.N+1). The amount and the importance of corrected bugs will
> dictate when the release is done?
>
> When master is stabilized enough, a new version of D can be released. A
> new branch s created from master, named 2.61 and a tag 2.61.0 is created :
>
> git checkout master
> git branch 2.61
> git checkout 2.61
> git tag 2.61.0
>
> Then, the dev version is merged into master and a new stabilization
> process begin :
> git checkout master
> git merge dev
>
> At some point, 2.60 will not receive any more bug fix, and will be
> considered very stable, or dead, depending on one's standard (both are
> kind of the same).
>
> I advice against maintaining a log of 2.XXX branches, as too much choice
> is as bad as no choice for the user, and it is no better for us. 2 is
> IMO the right amount.
>
> NB: I have chosen the 3 number system for branches names, this is up to
> debate, but as it is widely used in programming languages it is a good
> base. Anyway, let's not debate the name for too long, as it really don't
> matter, and concentrate on the workflow.

So far me likes.
>
> On Wednesday, 12 December 2012 at 16:14:44 UTC, Andrei Alexandrescu wrote:
>> Beyond that we need to have a wiki page with workflows:
>>
>> "To initiate a new feature"
>>
>
> A new feature is developed in its own branch. The reference is the dev
> branch. In git it goes as follow :
>
> git checkout dev
> git branch featureName
>
> Development of the feature.
>
> You can work on many feature at the same time; each one in its own
> branch. You initiate them the same way and switch from one another with
> git checkout.
>
> Before submitting a feature, it has to be reabsed as follow :
>
> git checkout featureName
> git rebase dev
>

Just make sure your local dev is always in sync with upstream!

Or rather add an 'upstream' remote as github.com/D-Programming-Language/phobos.git (dmd, druntime etc.) and always do:

git pull --rebase upstream dev
git push --force origin featureName

before submitting pull via github.

> When the feature is ready to inclusion into dev, the dev can make a pull
> request.
>
>> "To initiate a bug fix"
>>
>
> The same as for new feature, except that you start from the branch the
> bug is in. If the bug is in several branches, then the most stable one
> is choosen, as i is usually easier to bubble up the bugfix from a stable
> branch to dev than the other way around.
>
>> "To initiate a library addition without formal review"
>>
>> "To initiate a library addition with formal review"
>>
>> ...
>>
>
> I don't really know what to do here. I guess bug fixes on the library
> can be done the same way, but something specific probably have to be
> done with new modules.
>
>> All of these should be subsections in the documentation.
>>
>> "If your branch has conflicts"
>>
>
> If your branch has conflict, it is up to you to resolve them. The
> conflict will most likely occurs when rebasing. In such case, git status
> will inform you on which files are impacted. Edit the file to resolve
> the conflict and do git add file, then git rebase --continue .
>
> If you don't want to resolve the conflict now, you can abort the rebase
> by doing git rebase --abort
>
>> "If your branch became really messed up"
>>
>
> Well this one is difficult, because it is unclear what is wrong, so
> unclear ho to solve it.

I find it to be 'git reset' to some early point, stash changes, fast forward from the upstream version to the head of current branch and stash pop your local changes.

But it really depends on symptoms and what the end result should be discard changes?, save changes elsewhere but restore to something stable? which branch is messed up? It's an infinite list of questions.

> Is that good ?

I think it's good.

But personally I'd expect:

* master to be what you define as dev, because e.g. GitHub puts master as default target branch when making pull requests. Yeah, I know it's their quirk that it's easy to miss. Still leaving less burden to check the branch label for both reviewers and pull authors is a net gain.

* And what you describe as master (it's a snapshot or a pre-release to me) to be named e.g. staging.

And we can as well drop the dead branch 'dev' then.
-- 
Dmitry Olshansky
December 13, 2012
On Thursday, 13 December 2012 at 20:04:50 UTC, Dmitry Olshansky wrote:
> I think it's good.
>
> But personally I'd expect:
>
> * master to be what you define as dev, because e.g. GitHub puts master as default target branch when making pull requests. Yeah, I know it's their quirk that it's easy to miss. Still leaving less burden to check the branch label for both reviewers and pull authors is a net gain.
>
> * And what you describe as master (it's a snapshot or a pre-release to me) to be named e.g. staging.
>
> And we can as well drop the dead branch 'dev' then.

That sound also like a good plan to me.
December 13, 2012
On Thursday, 13 December 2012 at 18:41:47 UTC, H. S. Teoh wrote:
> Since each of us may have conflicting ideas about what the final process
> should be, let's adopt the convention that if something on the page is
> not how you understand things should be, you should discuss on the talk
> page before making the change, so that we don't devolve into an edit
> war.
>
>
> T

I was wondering how we'll resolve conflicts, because not everyone will agree on everything thats for certain. We don't really have a voting system in place, and there's no "benevolent dictator" heading the project unless Andrei has appointed himself for resolving conflicts, but he's not really participating much at this point. We're kinda leaderless and left with no mechanism for making the inevitable hard decisions that we'll have to make if this effort is to move ahead.

Any ideas?

--rt
December 13, 2012
On Thu, Dec 13, 2012 at 10:36:17PM +0100, Rob T wrote:
> On Thursday, 13 December 2012 at 18:41:47 UTC, H. S. Teoh wrote:
> >Since each of us may have conflicting ideas about what the final process should be, let's adopt the convention that if something on the page is not how you understand things should be, you should discuss on the talk page before making the change, so that we don't devolve into an edit war.
[...]
> I was wondering how we'll resolve conflicts, because not everyone will agree on everything thats for certain. We don't really have a voting system in place, and there's no "benevolent dictator" heading the project unless Andrei has appointed himself for resolving conflicts, but he's not really participating much at this point.  We're kinda leaderless and left with no mechanism for making the inevitable hard decisions that we'll have to make if this effort is to move ahead.
> 
> Any ideas?
[...]

I don't have a good answer to this, but maybe we could use Wikipedia's method of garnering consensus before a major change is made? I don't know how well it will work, given our relatively small numbers, though.

It would be nice if Andrei could step in and head up this process. But then again, he's a busy man and only does D on his limited free time, so it may be just a matter of waiting for a bit for him to pipe up.


T

-- 
Mediocrity has been pushed to extremes.
December 13, 2012
On Thursday, 13 December 2012 at 20:48:30 UTC, deadalnix wrote:
> On Thursday, 13 December 2012 at 20:04:50 UTC, Dmitry Olshansky wrote:
>> I think it's good.
>>
>> But personally I'd expect:
>>
>> * master to be what you define as dev, because e.g. GitHub puts master as default target branch when making pull requests. Yeah, I know it's their quirk that it's easy to miss. Still leaving less burden to check the branch label for both reviewers and pull authors is a net gain.
>>
>> * And what you describe as master (it's a snapshot or a pre-release to me) to be named e.g. staging.
>>
>> And we can as well drop the dead branch 'dev' then.
>
> That sound also like a good plan to me.

Updated to follow the idea, plus added bunch of process description. Feel free to comment in order to refine this.

http://wiki.dlang.org/Release_Process
December 14, 2012
On Fri, Dec 14, 2012 at 12:34:13AM +0100, deadalnix wrote:
> On Thursday, 13 December 2012 at 20:48:30 UTC, deadalnix wrote:
[...]
> Updated to follow the idea, plus added bunch of process description. Feel free to comment in order to refine this.
> 
> http://wiki.dlang.org/Release_Process

I've rearranged the page a bit and added more higher-level discussion. Please feel free to edit/correct any mistakes I may have had.


T

-- 
MSDOS = MicroSoft's Denial Of Service
December 14, 2012
On 2012-12-11 00:41, Andrei Alexandrescu wrote:
> Hello all,
>
>
> Walter and I have had a long discussion following his trip to Australia.
> Following the current sprint for Win64 (which we all, I think, agree was
> long overdue and had to be done), the main area we need to work on (as
> I'm sure many would agree) is improving our process, in particular the
> approach to releasing the compiler and standard library.
>
> Walter has delegated me to lead this effort, and agreed to obey with
> whatever process comes forward as long as it's reasonably clear and simple.
>
> In turn, I'll be collecting thoughts and opinions in this thread,
> distilled from previous discussions. We should develop a few simple git
> scripts (such as git-start-new-feature or git-start-bugfix etc)
> supported by an equally simple piece of documentation describing how to
> start a new release, fix a bug, experiment with a new feature, and such.
>
> (One piece that has been brought forward is
> http://nvie.com/posts/a-successful-git-branching-model/ - something to
> keep in mind.)

Don't know if this has already been said but there already exists a git command for this workflow:

https://github.com/nvie/gitflow

It's available in MacPorts so I should assume it's available in most Linux package mangers as well.

-- 
/Jacob Carlborg