llvm dev - Jun 2016 - [cfe-dev] [lldb-dev] GitHub anyone?

On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev
wrote:
> My only hesitation with this is that this requires use of cherry-pick,
> which is not idea.  The way most git repositories work is to put
> everything that should go into a release branch in the release branch
> *first* and then merge the release branch to master, ensuring that
> everything going out in a release will make it into the next release.
> This is how the gitflow workflow works, for example.
The model of "commit to oldest first" is IMO one of the most stupid
concepts I have ever seen in git "workflows". It is contrary to the
way
software development works and essentially just a bad workaround for
broken cherry picks. I've seen more than one project starting to use
this model due to advocacy after deciding to use git, stumble around
with it for a release or two and then going back to a normal release
management approach. Even the argument you have presented here does not
make sense to me. Just because a change has been committed to a release
branch, doesn't mean it won't get replaced later.

Joerg

+1 to that. I would strongly suggest that we continue to commit to master
first, like we've always done in llvm.

On Jun 6, 2016 11:44 AM, "Joerg Sonnenberger via cfe-dev" <
cfe-dev at lists.llvm.org> wrote:
> On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote:
> > My only hesitation with this is that this requires use of cherry-pick,
> > which is not idea.  The way most git repositories work is to put
> > everything that should go into a release branch in the release branch
> > *first* and then merge the release branch to master, ensuring that
> > everything going out in a release will make it into the next release.
> > This is how the gitflow workflow works, for example.
>
> The model of "commit to oldest first" is IMO one of the most
stupid
> concepts I have ever seen in git "workflows". It is contrary to
the way
> software development works and essentially just a bad workaround for
> broken cherry picks. I've seen more than one project starting to use
> this model due to advocacy after deciding to use git, stumble around
> with it for a release or two and then going back to a normal release
> management approach. Even the argument you have presented here does not
> make sense to me. Just because a change has been committed to a release
> branch, doesn't mean it won't get replaced later.
>
> Joerg
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160606/04dd20c6/attachment.html>

I'd suggest a workflow like the following:

- developer commits locally to a feature/bug dev branch. You can commit
work in progress, experiments, have bad commit messages etc

- developer commits locally to a feature/bug release branch. Tidy up into a
small number of logical commits, nice messages etc. I'd suggest it's
good
to have at least two commits: 1) a commit adding a test that fails, and is
marked as expected to fail, demonstrating the bug or lack of feature. 2) a
commit that fixes the bug or adds the feature, and marks the test as
expected to pass.

- developer rebases to master and tests

- developer pushes their feature/bug release branch to their github fork of
llvm, issues a pull request

- the appropriate maintainer (or or automatic system) causes build and
tests to be run on the proposed bug fix.

- if the tests work, then do a "git merge --no-ff" to master

There's room to discuss the last part. That gives a master history with
exactly one commit per feature or bug fix. The details of how it was done
are on a different branch that merges back.

You might prefer merge --ff-only. This means that the merge can only happen
if the new feature has been rebased to the head of master. The commits in
the new feature each become a commit in master. In this case you should
make very sure that every commit works -- which is defined as no crashes;
tests expected to work, work; tests expected to fail, fail.


On Mon, Jun 6, 2016 at 8:07 PM, James Y Knight via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> +1 to that. I would strongly suggest that we continue to commit to master
> first, like we've always done in llvm.
>
> On Jun 6, 2016 11:44 AM, "Joerg Sonnenberger via cfe-dev" <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote:
>> > My only hesitation with this is that this requires use of
cherry-pick,
>> > which is not idea.  The way most git repositories work is to put
>> > everything that should go into a release branch in the release
branch
>> > *first* and then merge the release branch to master, ensuring that
>> > everything going out in a release will make it into the next
release.
>> > This is how the gitflow workflow works, for example.
>>
>> The model of "commit to oldest first" is IMO one of the most
stupid
>> concepts I have ever seen in git "workflows". It is contrary
to the way
>> software development works and essentially just a bad workaround for
>> broken cherry picks. I've seen more than one project starting to
use
>> this model due to advocacy after deciding to use git, stumble around
>> with it for a release or two and then going back to a normal release
>> management approach. Even the argument you have presented here does not
>> make sense to me. Just because a change has been committed to a release
>> branch, doesn't mean it won't get replaced later.
>>
>> Joerg
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160606/62599d58/attachment.html>

On Jun 6, 2016, at 10:07 AM, James Y Knight via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
> +1 to that. I would strongly suggest that we continue to commit to master
first, like we've always done in llvm.
> 
More generally, I suggest that we keep a discussion about moving hosting and
svn->git to *just* those topics.  Any changes of workflow should be deferred
until after and if these changes happen.

-Chris

> 
> On Jun 6, 2016 11:44 AM, "Joerg Sonnenberger via cfe-dev"
<cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>
wrote:
> On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote:
> > My only hesitation with this is that this requires use of cherry-pick,
> > which is not idea.  The way most git repositories work is to put
> > everything that should go into a release branch in the release branch
> > *first* and then merge the release branch to master, ensuring that
> > everything going out in a release will make it into the next release.
> > This is how the gitflow workflow works, for example.
> 
> The model of "commit to oldest first" is IMO one of the most
stupid
> concepts I have ever seen in git "workflows". It is contrary to
the way
> software development works and essentially just a bad workaround for
> broken cherry picks. I've seen more than one project starting to use
> this model due to advocacy after deciding to use git, stumble around
> with it for a release or two and then going back to a normal release
> management approach. Even the argument you have presented here does not
> make sense to me. Just because a change has been committed to a release
> branch, doesn't mean it won't get replaced later.
> 
> Joerg
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160607/797dfbbd/attachment.html>