That is my major concern with it as well and is the one thing I don't like about it (I've actually written here in the past arguing against extensive cherry-picking). That's also why I wrote the feature freeze/beta window should be short.  Perhaps it's wishful thinking that it will be short in practice.  The alternative as I see it is to have every contributor know the process and know when we are in in a feature freeze/beta and know where to target their 2 pull requests. That would be ideal but as a practical matter I'm more inclined to believe assigning that job to one person who is responsible for it and knows what they should be doing and when will lead to better results.

Alternatives to this are welcome but I really feel strongly about keeping it very, very simple (especially for contributors who may or may not be privy to the current state of the release cycle).


On Mon, Jan 13, 2014 at 9:46 AM, Михаил Страшун <public@dicebot.lv> wrote:

> On Mon, Jan 13, 2014 at 5:38 PM, David Nadlinger <code@klickverbot.at>wrote:
>>
>> I suspect that liberal use of cherry-picking will make this process a bit more annoying than necessary, but it could be that the simplification of the process indeed outweighs this extra bit of effort.
>>
>
> I feel it rather unjust to put that extra effort on Andrew simply because we can't self-organize to conform existing rules but right now it just does not work :(
>
> However I think resolution of such conflicts can be made very straightforward and even made automatic via simple script (by providing list of identical commit pairs to script and making it skip one of those). Worth investigating.
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

El 09/01/14 20:33, Martin Nowak ha escrit:
> I'm working on these but would appreciate help in the form of monitoring the installer repo. http://dlang.dawg.eu/download/dmd.2.065.snapshot.1.zip

On Debian 7.3 (stable), I got:

dmd: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by dmd)

-- 
Jordi Sayol
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 01/13/2014 05:38 PM, David Nadlinger wrote:
> On Mon, Jan 13, 2014 at 7:10 AM, Brad Anderson <eco@gnuk.net> wrote:
>> http://wiki.dlang.org/Simplified_Release_Process_Proposal
> Even though I'm not sure whether this proposal is the best choice, let
> me point out that it gets one point very right, compared to the
> current state: After a release is created, the branch needs to be
> merged back into master. Otherwise, people just tracking the release
> tags (like we tend to do for the ldc druntime/Phobos repositories)
> will usually get a slew of conflicts due to commits cherry-picked onto
> the release branch or conflicting release-only changes.
I don't understand the last argument. What's your workflow for updating LDC's druntime and phobos?
How does merging back release branches help here?
>
> Doing this at the point of the release has the advantage that the
> release manager is the one who knows what went where for what reasons,
> and that they still have all the details in their working memory.
>
> I suspect that liberal use of cherry-picking will make this process a
> bit more annoying than necessary, but it could be that the
> simplification of the process indeed outweighs this extra bit of
> effort.
I think this "extra bit" of effort will make this process unsuitable.
If you cherry-pick from master onto a release branch you already have to resolve conflicts sometimes.
Now when you merge the release branch back into master the resulting merge conflict is non-trivial.
Difficult merges are usually best resolved by the people who made the code changes.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Fri, Jan 17, 2014 at 11:06 PM, Martin Nowak <code@dawg.eu> wrote:
> I don't understand the last argument. What's your workflow for updating
> LDC's druntime and phobos?
> How does merging back release branches help here?

We have druntime and Phobos as Git submodules. What we do is more or less, in Git pseudo-code:
---
cd runtime/druntime
git fetch dlang
git merge dlang/v2.064-beta1 # Release or beta tag, from the release branch.
cd ../..
git commit -am 'Updated LDC to 2.064'

# Time passes

cd runtime/druntime
git fetch dlang
git merge dlang/v2.065-beta1 # Another tag from the next release branch.
cd ../..
git commit -am 'Updated LDC to 2.065'
---

Now, if the older tag (v2.064-beta1) is not in fact an ancestor of the newer one (v2.065-beta1), we'll have to resolve all the merge conflicts ourselves again, months after the actual changes were made, and even though we probably didn't even touch the code on the LDC side.

The same goes for the ldc branch on our testsuite repository, which we also reference as a submodule (https://github.com/ldc-developers/dmd-testsuite).

And even for merging the frontends itself, I've been using Git to good success for the last few releases, doing something like this:
---
cd dmd
git checkout v2.064

# Create a dummy commit with all the LDC changes to the frontend.
git checkout -b ldc
cp -a ../ldc/dmd2/* src/
git commit -am 'Merged in LDC changes.'

# Now merge the changes, which is easier due to the added context,
# compared to just using "git diff v2.064..v2.065" and applying it to LDC.
git merge v2.065
git commit -m 'Merged in new frontend.'

# Export the patch and apply it to the LDC repository, where it should
apply cleanly.
git diff HEAD^ src > ../ldc-2.064-2.065.diff
---
Exploiting the additional history information in the DMD repository makes resolving merge conflicts quite a bit easier (and Git can resolve more of them by itself), but this approach is also thwarted by diverging histories due to unmerged cherry-picks.


> I think this "extra bit" of effort will make this process unsuitable.
> If you cherry-pick from master onto a release branch you already have to
> resolve conflicts sometimes.
> Now when you merge the release branch back into master the resulting merge
> conflict is non-trivial.
> Difficult merges are usually best resolved by the people who made the code
> changes.

To get everyone to submit their pull request to the right branch by default is somewhat unrealistic, also because it is sometimes not in the submitter's responsibility to decide where a change goes (think semi-critical bug fix that might go into a point release or not). So, either we would have to tell people to redo their pull requests against the appropriate branch, which will lead to a general mess, or the onus will be on the reviewers to include the changes on the right branch (i.e. manually merging them to the release branch, the pull request will auto-close once it is merged back to master). Hm, in the last case, we'd lose auto-tester integration, so I guess that's not an option…

David

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 01/17/2014 11:40 PM, David Nadlinger wrote:
> To get everyone to submit their pull request to the right branch by
> default is somewhat unrealistic, also because it is sometimes not in
> the submitter's responsibility to decide where a change goes (think
> semi-critical bug fix that might go into a point release or not). So,
> either we would have to tell people to redo their pull requests
> against the appropriate branch, which will lead to a general mess, or
> the onus will be on the reviewers to include the changes on the right
> branch (i.e. manually merging them to the release branch, the pull
> request will auto-close once it is merged back to master). Hm, in the
> last case, we'd lose auto-tester integration, so I guess that's not an
> option…
That's the dilemma and I haven't yet heard any good solution.
But asking to reopen a pull request for a release branch seems feasible.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Fri, Jan 17, 2014 at 4:03 PM, Martin Nowak <code@dawg.eu> wrote:

> That's the dilemma and I haven't yet heard any good solution.
> But asking to reopen a pull request for a release branch seems feasible.
>
>
Perhaps just have the Release Manager request the author of a commit open a pull request targeting `release` if it has conflicts.

On 01/18/2014 01:08 AM, Brad Anderson wrote:
> Perhaps just have the Release Manager request the author of a commit open a pull request targeting `release` if it has conflicts.
Another problem is the integration with the auto-tester.
Ideally every merge would be tested.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 01/15/2014 07:54 PM, Jordi Sayol wrote:
> On Debian 7.3 (stable), I got:
>
> dmd: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by dmd)
Yikes, I start to dislike versioned symbols ;).
So the problem here is that Ubuntu 12.04 switched to glibc-2.15 (
https://launchpad.net/ubuntu/precise/amd64/libc6) while
Debian 7.3 still uses glibc-2.13 ( http://packages.debian.org/wheezy/libc6).
What do you think would be an the distribution with best compatibility?
Hopefully it comes with a readymade http://www.vagrantbox.es/. How about
Debian 6.07?

El 19/01/14 21:19, Martin Nowak ha escrit:
> On 01/15/2014 07:54 PM, Jordi Sayol wrote:
>> On Debian 7.3 (stable), I got:
>>
>> dmd: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by dmd)
> Yikes, I start to dislike versioned symbols ;).
> So the problem here is that Ubuntu 12.04 switched to glibc-2.15 ( https://launchpad.net/ubuntu/precise/amd64/libc6) while
> Debian 7.3 still uses glibc-2.13 ( http://packages.debian.org/wheezy/libc6).
> What do you think would be an the distribution with best compatibility?
> Hopefully it comes with a readymade http://www.vagrantbox.es/. How about Debian 6.07?

If correctly compiles, Debian 6.0.? should be the best option. The second one would be Debian 7.?

-- 
Jordi Sayol
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 01/20/2014 02:47 AM, Jordi Sayol wrote:
> If correctly compiles, Debian 6.0.? should be the best option. The second one would be Debian 7.?
OK, done. https://github.com/MartinNowak/installer/commit/b64ddfefd9cd6a773cb32d1cdd7acde68eb353c9

http://dlang.dawg.eu/download/dmd.v2.065-b1.zip <https://github.com/MartinNowak/installer/commit/b64ddfefd9cd6a773cb32d1cdd7acde68eb353c9> sha1 bd4ce088e9f20d04023dccdd2ec7b170e7f2cea0