Not all of the information included (perhaps "planned to be included" at this point) in the document is likely candidate for final inclusion in the site (e.g. steps to contact INFRA, getting github mirrors, etc); however, I like writing in markdown and this gave me a template without having to do other lifting of my own.

If people want to contribute, I'm more than happy to put something up in /accumulo/contrib so that multiple people can directly add/modify information.

I finished a first draft of all but what should be done with Git during/after a release (outlining RC tags, a final tag and cleanup for the branch which started said work, with corresponding merges upstream).

Again, any and all help, preferably the form of patchs :D, is welcome, but comments on ACCUMULO-1498 are the next-best thing. I tried to leave placeholders on the site for information which needs to finalized by the devs.

On 06/04/2013 11:04 PM, Josh Elser wrote:> In an effort to track the abundance of information that we need to > define, manage, etc before making the development switch to git, I've > started a WIP document.>> http://people.apache.org/~elserj/git/git.html>> Not all of the information included (perhaps "planned to be included" > at this point) in the document is likely candidate for final inclusion > in the site (e.g. steps to contact INFRA, getting github mirrors, > etc); however, I like writing in markdown and this gave me a template > without having to do other lifting of my own.>> If people want to contribute, I'm more than happy to put something up > in /accumulo/contrib so that multiple people can directly add/modify > information.

Disclaimer, I actually got Christopher to say "it's kind of long...". Yes, this was intended. I'd rather be (painfully) explicit front and lift out a TL;DR version from the master document.

_Please_ give feedback now as to what is still unclear about after reading the document. I'd hate to have wasted all of this time writing this to just change our minds again in the near future

Also, please look for text in _emphasis_ as these are things which I do not believe were decided upon as a group. Copied here for your ease:

1. Need to ensure that deleting remote branches is not an issue. History is still intact so this should not grind against ASF policy.2. Do we have a nice write-up of the release policies?

And, the last thing:

Is everyone ok with the default branch when cloning the repository being latest unstable branch (synonymous with what "trunk" is now)? If so, is everyone ok with naming it `master`? This is what my vote is towards.

Once we get these questions answered and the process reviewed, I believe we're ready to move forward with the INFRA ticket.

- Josh

On 06/05/2013 09:58 PM, Josh Elser wrote:> For those who are interested:>> Fork of CMS site: > https://svn.apache.org/repos/asf/accumulo/site/branches/git/> Active copy: http://people.apache.org/~elserj/git/git.html> Jira issue: https://issues.apache.org/jira/browse/ACCUMULO-1498>> I finished a first draft of all but what should be done with Git > during/after a release (outlining RC tags, a final tag and cleanup for > the branch which started said work, with corresponding merges upstream).>> Again, any and all help, preferably the form of patchs :D, is welcome, > but comments on ACCUMULO-1498 are the next-best thing. I tried to > leave placeholders on the site for information which needs to > finalized by the devs.>> On 06/04/2013 11:04 PM, Josh Elser wrote:>> In an effort to track the abundance of information that we need to >> define, manage, etc before making the development switch to git, I've >> started a WIP document.>>>> http://people.apache.org/~elserj/git/git.html>>>> Not all of the information included (perhaps "planned to be included" >> at this point) in the document is likely candidate for final >> inclusion in the site (e.g. steps to contact INFRA, getting github >> mirrors, etc); however, I like writing in markdown and this gave me a >> template without having to do other lifting of my own.>>>> If people want to contribute, I'm more than happy to put something up >> in /accumulo/contrib so that multiple people can directly add/modify >> information.>

> Alright, I think I covered all of the content that's needed.>> http://people.apache.org/~**elserj/git/git.html<http://people.apache.org/~elserj/git/git.html>>> Disclaimer, I actually got Christopher to say "it's kind of long...". Yes,> this was intended. I'd rather be (painfully) explicit front and lift out a> TL;DR version from the master document.>> _Please_ give feedback now as to what is still unclear about after reading> the document. I'd hate to have wasted all of this time writing this to just> change our minds again in the near future>> Also, please look for text in _emphasis_ as these are things which I do> not believe were decided upon as a group. Copied here for your ease:>> 1. Need to ensure that deleting remote branches is not an issue. History> is still intact so this should not grind against ASF policy.> 2. Do we have a nice write-up of the release policies?>> And, the last thing:>> Is everyone ok with the default branch when cloning the repository being> latest unstable branch (synonymous with what "trunk" is now)? If so, is> everyone ok with naming it `master`? This is what my vote is towards.>> Once we get these questions answered and the process reviewed, I believe> we're ready to move forward with the INFRA ticket.>> - Josh>>> On 06/05/2013 09:58 PM, Josh Elser wrote:>>> For those who are interested:>>>> Fork of CMS site: https://svn.apache.org/repos/**>> asf/accumulo/site/branches/**git/<https://svn.apache.org/repos/asf/accumulo/site/branches/git/>>> Active copy: http://people.apache.org/~**elserj/git/git.html<http://people.apache.org/~elserj/git/git.html>>> Jira issue: https://issues.apache.org/**jira/browse/ACCUMULO-1498<https://issues.apache.org/jira/browse/ACCUMULO-1498>>>>> I finished a first draft of all but what should be done with Git>> during/after a release (outlining RC tags, a final tag and cleanup for the>> branch which started said work, with corresponding merges upstream).>>>> Again, any and all help, preferably the form of patchs :D, is welcome,>> but comments on ACCUMULO-1498 are the next-best thing. I tried to leave>> placeholders on the site for information which needs to finalized by the>> devs.>>>> On 06/04/2013 11:04 PM, Josh Elser wrote:>>>>> In an effort to track the abundance of information that we need to>>> define, manage, etc before making the development switch to git, I've>>> started a WIP document.>>>>>> http://people.apache.org/~**elserj/git/git.html<http://people.apache.org/~elserj/git/git.html>>>>>>> Not all of the information included (perhaps "planned to be included" at>>> this point) in the document is likely candidate for final inclusion in the>>> site (e.g. steps to contact INFRA, getting github mirrors, etc); however, I>>> like writing in markdown and this gave me a template without having to do>>> other lifting of my own.>>>>>> If people want to contribute, I'm more than happy to put something up in>>> /accumulo/contrib so that multiple people can directly add/modify>>> information.>>>>>>>>-- Sean

I did add the high-level release guide to that comment with a place holder for when we get the specifics also written down on the CMS.

On 6/11/13 7:16 AM, Sean Busbey wrote:> Release Guide:>> http://accumulo.apache.org/governance/releasing.html>>> On Mon, Jun 10, 2013 at 10:44 PM, Josh Elser <[EMAIL PROTECTED]> wrote:>>> Alright, I think I covered all of the content that's needed.>>>> http://people.apache.org/~**elserj/git/git.html<http://people.apache.org/~elserj/git/git.html>>>>> Disclaimer, I actually got Christopher to say "it's kind of long...". Yes,>> this was intended. I'd rather be (painfully) explicit front and lift out a>> TL;DR version from the master document.>>>> _Please_ give feedback now as to what is still unclear about after reading>> the document. I'd hate to have wasted all of this time writing this to just>> change our minds again in the near future>>>> Also, please look for text in _emphasis_ as these are things which I do>> not believe were decided upon as a group. Copied here for your ease:>>>> 1. Need to ensure that deleting remote branches is not an issue. History>> is still intact so this should not grind against ASF policy.>> 2. Do we have a nice write-up of the release policies?>>>> And, the last thing:>>>> Is everyone ok with the default branch when cloning the repository being>> latest unstable branch (synonymous with what "trunk" is now)? If so, is>> everyone ok with naming it `master`? This is what my vote is towards.>>>> Once we get these questions answered and the process reviewed, I believe>> we're ready to move forward with the INFRA ticket.>>>> - Josh>>>>>> On 06/05/2013 09:58 PM, Josh Elser wrote:>>>>> For those who are interested:>>>>>> Fork of CMS site: https://svn.apache.org/repos/**>>> asf/accumulo/site/branches/**git/<https://svn.apache.org/repos/asf/accumulo/site/branches/git/>>>> Active copy: http://people.apache.org/~**elserj/git/git.html<http://people.apache.org/~elserj/git/git.html>>>> Jira issue: https://issues.apache.org/**jira/browse/ACCUMULO-1498<https://issues.apache.org/jira/browse/ACCUMULO-1498>>>>>>> I finished a first draft of all but what should be done with Git>>> during/after a release (outlining RC tags, a final tag and cleanup for the>>> branch which started said work, with corresponding merges upstream).>>>>>> Again, any and all help, preferably the form of patchs :D, is welcome,>>> but comments on ACCUMULO-1498 are the next-best thing. I tried to leave>>> placeholders on the site for information which needs to finalized by the>>> devs.>>>>>> On 06/04/2013 11:04 PM, Josh Elser wrote:>>>>>>> In an effort to track the abundance of information that we need to>>>> define, manage, etc before making the development switch to git, I've>>>> started a WIP document.>>>>>>>> http://people.apache.org/~**elserj/git/git.html<http://people.apache.org/~elserj/git/git.html>>>>>>>>> Not all of the information included (perhaps "planned to be included" at>>>> this point) in the document is likely candidate for final inclusion in the>>>> site (e.g. steps to contact INFRA, getting github mirrors, etc); however, I>>>> like writing in markdown and this gave me a template without having to do>>>> other lifting of my own.>>>>>>>> If people want to contribute, I'm more than happy to put something up in>>>> /accumulo/contrib so that multiple people can directly add/modify>>>> information.>>>>>>>>>>>>>>

There are two active development branches - versions 1 and 2. Branch 1 usesexternal library version 7, while Branch 2 uses external library version9. It is discovered that version 7 of the external library has a bug, witha known workaround. In this case, the workaround should be applied tobranch 1, but does not need to be applied to branch 2. What is thegit-friendly way to make these changes, not merge them into the laterbranch, but still have a proper history and allow future fixes againstbranch 1 to merge cleanly?

On Tue, Jun 11, 2013 at 12:05 PM, Josh Elser <[EMAIL PROTECTED]> wrote:> The person who implements the workaround in Version1 should ensure that when> Version1 is merged into Version2, the correct code is present in Version2.

I'm not sure that's a sufficient solution, because this means that thebranch for Version2 may stick around with effectively no change fromits last tag other than history, and you can't simply update the tagto update the history, can you? Either it sticks around for a verylong time, or it goes away and eventually somebody else is going tohave to resolve that potential merge conflict when fixing the next bugthat comes around (which maybe applies to both).

> Do you think this merits a section on the document or was this a general> question?

I think it merits inclusion in the same way that the other genericscenarios I proposed should be included.

> On 6/11/13 11:44 AM, Mike Drob wrote:>>>> How do we handle the following situation:>>>> There are two active development branches - versions 1 and 2. Branch 1>> uses>> external library version 7, while Branch 2 uses external library version>> 9. It is discovered that version 7 of the external library has a bug, with>> a known workaround. In this case, the workaround should be applied to>> branch 1, but does not need to be applied to branch 2. What is the>> git-friendly way to make these changes, not merge them into the later>> branch, but still have a proper history and allow future fixes against>> branch 1 to merge cleanly?>>>> Mike

It was originally a general question, because I wasn't sure on what theproper answer.

Actually, I'm still not quite clear - should the person who did the fix forVersion1 immediately do a merge into Version2 with an empty commit so thathistory looks pretty? Or is it better to wait until the next merge and thenfix it as it happens? The first option sounds less liable to bite somebodyin the rear.

It's not an empty commit. It's just circumstantial that the changes for your commit are empty. The fact that you noted "changes X version version1 should not be applied to version2" is important and that merge tracks such information.

The same is applicable when version1 and version2 depend on two different versions of a dependency. Say your new code in version1 calls a method whose signature changed in said dependency from the version version1 depends on as opposed to the version of the dependency version2 depends on. Point being, after making the changes in version1, it is your responsibility to make sure whatever necessary variants exist in their appropriate versions.

> It's not an empty commit. It's just circumstantial that the changes for> your commit are empty. The fact that you noted "changes X version version1> should not be applied to version2" is important and that merge tracks such> information.>> The same is applicable when version1 and version2 depend on two different> versions of a dependency. Say your new code in version1 calls a method> whose signature changed in said dependency from the version version1> depends on as opposed to the version of the dependency version2 depends on.> Point being, after making the changes in version1, it is your> responsibility to make sure whatever necessary variants exist in their> appropriate versions.>>> On 06/11/2013 07:10 PM, Mike Drob wrote:>>> It was originally a general question, because I wasn't sure on what the>> proper answer.>>>> Actually, I'm still not quite clear - should the person who did the fix>> for>> Version1 immediately do a merge into Version2 with an empty commit so that>> history looks pretty? Or is it better to wait until the next merge and>> then>> fix it as it happens? The first option sounds less liable to bite somebody>> in the rear.>>>> Probably worth expounding on the example work-flow in the documentation>> though.>>>>>> On Tue, Jun 11, 2013 at 12:05 PM, Josh Elser <[EMAIL PROTECTED]>>> wrote:>>>> The person who implements the workaround in Version1 should ensure that>>> when Version1 is merged into Version2, the correct code is present in>>> Version2.>>>>>> Do you think this merits a section on the document or was this a general>>> question?>>>>>>>>> On 6/11/13 11:44 AM, Mike Drob wrote:>>>>>> How do we handle the following situation:>>>>>>>> There are two active development branches - versions 1 and 2. Branch 1>>>> uses>>>> external library version 7, while Branch 2 uses external library>>>> version>>>> 9. It is discovered that version 7 of the external library has a bug,>>>> with>>>> a known workaround. In this case, the workaround should be applied to>>>> branch 1, but does not need to be applied to branch 2. What is the>>>> git-friendly way to make these changes, not merge them into the later>>>> branch, but still have a proper history and allow future fixes against>>>> branch 1 to merge cleanly?>>>>>>>> Mike>>>>>>>> On Tue, Jun 11, 2013 at 8:55 AM, Josh Elser <[EMAIL PROTECTED]>>>>> wrote:>>>>>>>> Sean,>>>>>>>>> I was referring to Christopher's notes on the maven commands; using the>>>>> release plugin, making RCs, publishing to the ASF staging area,>>>>> promoting>>>>> to the RC if the vote passes, etc.>>>>>>>>>> http://mail-archives.apache.******org/mod_mbox/accumulo-dev/******>>>>> 201305.mbox/%**>>>>> 3CCAL5zq9bH8y0FyjXmmfXhWPj8axo******sn9dZ7%2Bu-R1DK4Y-WM1YoWg%****>>>>> 40mail.gmail.com%3E<http://**m**ail-archives.apache.org/mod_**<http://mail-archives.apache.org/mod_**>>>>>> mbox/accumulo-dev/201305.mbox/****%****3CCAL5zq9bH8y0FyjXmmfXhWPj8axo*>>>>> ***>>>>> sn9dZ7%2Bu-R1DK4Y-WM1YoWg%**40**mail.gmail.com<http://40mail.gmail.com>>>>>> %3E<http://mail-**archives.apache.org/mod_mbox/**>>>>> accumulo-dev/201305.mbox/%**3CCAL5zq9bH8y0FyjXmmfXhWPj8axo**>>>>> sn9dZ7%2Bu-R1DK4Y-WM1YoWg%**40mail.gmail.com%3E<http://mail-archives.apache.org/mod_mbox/accumulo-dev/201305.mbox/%3CCAL5zq9bH8y0FyjXmmfXhWPj8axosn9dZ7%2Bu-R1DK4Y-WM1YoWg%40mail.gmail.com%3E>>>>>> >>>>>>>>>>>>>>>> I don't believe that information is markdown-ified/CMS'ed at all.>>>>>>>>>> I did add the high-level release guide to that comment with a place>>>>> holder>>>>> for when we get the specifics also written down on the CMS.>>>>>>>>>>>>>>> On 6/11/13 7:16 AM, Sean Busbey wrote:

I don't want to go into super-specifics in the write-up, but I can probably work something into the developer section similar to your quote of ... myself... About OBE changes between versions :)

Thanks for the feedback, Mike.

On 06/11/2013 07:25 PM, Mike Drob wrote:> Great, makes sense.>>> [...]after making the changes in version1, it is your responsibility to> make sure whatever necessary variants exist in their appropriate versions.>> +1 Something like this should go into the documentation.>>> On Tue, Jun 11, 2013 at 7:18 PM, Josh Elser <[EMAIL PROTECTED]> wrote:>>> It's not an empty commit. It's just circumstantial that the changes for>> your commit are empty. The fact that you noted "changes X version version1>> should not be applied to version2" is important and that merge tracks such>> information.>>>> The same is applicable when version1 and version2 depend on two different>> versions of a dependency. Say your new code in version1 calls a method>> whose signature changed in said dependency from the version version1>> depends on as opposed to the version of the dependency version2 depends on.>> Point being, after making the changes in version1, it is your>> responsibility to make sure whatever necessary variants exist in their>> appropriate versions.>>>>>> On 06/11/2013 07:10 PM, Mike Drob wrote:>>>>> It was originally a general question, because I wasn't sure on what the>>> proper answer.>>>>>> Actually, I'm still not quite clear - should the person who did the fix>>> for>>> Version1 immediately do a merge into Version2 with an empty commit so that>>> history looks pretty? Or is it better to wait until the next merge and>>> then>>> fix it as it happens? The first option sounds less liable to bite somebody>>> in the rear.>>>>>> Probably worth expounding on the example work-flow in the documentation>>> though.>>>>>>>>> On Tue, Jun 11, 2013 at 12:05 PM, Josh Elser <[EMAIL PROTECTED]>>>> wrote:>>>>>> The person who implements the workaround in Version1 should ensure that>>>> when Version1 is merged into Version2, the correct code is present in>>>> Version2.>>>>>>>> Do you think this merits a section on the document or was this a general>>>> question?>>>>>>>>>>>> On 6/11/13 11:44 AM, Mike Drob wrote:>>>>>>>> How do we handle the following situation:>>>>> There are two active development branches - versions 1 and 2. Branch 1>>>>> uses>>>>> external library version 7, while Branch 2 uses external library>>>>> version>>>>> 9. It is discovered that version 7 of the external library has a bug,>>>>> with>>>>> a known workaround. In this case, the workaround should be applied to>>>>> branch 1, but does not need to be applied to branch 2. What is the>>>>> git-friendly way to make these changes, not merge them into the later>>>>> branch, but still have a proper history and allow future fixes against>>>>> branch 1 to merge cleanly?>>>>>>>>>> Mike>>>>>>>>>> On Tue, Jun 11, 2013 at 8:55 AM, Josh Elser <[EMAIL PROTECTED]>>>>>> wrote:>>>>>>>>>> Sean,>>>>>>>>>>> I was referring to Christopher's notes on the maven commands; using the>>>>>> release plugin, making RCs, publishing to the ASF staging area,>>>>>> promoting>>>>>> to the RC if the vote passes, etc.>>>>>>>>>>>> http://mail-archives.apache.******org/mod_mbox/accumulo-dev/******>>>>>> 201305.mbox/%**>>>>>> 3CCAL5zq9bH8y0FyjXmmfXhWPj8axo******sn9dZ7%2Bu-R1DK4Y-WM1YoWg%****>>>>>> 40mail.gmail.com%3E<http://**m**ail-archives.apache.org/mod_**<http://mail-archives.apache.org/mod_**>>>>>>> mbox/accumulo-dev/201305.mbox/****%****3CCAL5zq9bH8y0FyjXmmfXhWPj8axo*>>>>>> ***>>>>>> sn9dZ7%2Bu-R1DK4Y-WM1YoWg%**40**mail.gmail.com<http://40mail.gmail.com>>>>>>> %3E<http://mail-**archives.apache.org/mod_mbox/**>>>>>> accumulo-dev/201305.mbox/%**3CCAL5zq9bH8y0FyjXmmfXhWPj8axo**>>>>>> sn9dZ7%2Bu-R1DK4Y-WM1YoWg%**40mail.gmail.com%3E<http://mail-archives.apache.org/mod_mbox/accumulo-dev/201305.mbox/%3CCAL5zq9bH8y0FyjXmmfXhWPj8axosn9dZ7%2Bu-R1DK4Y-WM1YoWg%40mail.gmail.com%3E>

On 06/11/2013 12:26 PM, Christopher wrote:> On Tue, Jun 11, 2013 at 12:05 PM, Josh Elser<[EMAIL PROTECTED]> wrote:>> >The person who implements the workaround in Version1 should ensure that when>> >Version1 is merged into Version2, the correct code is present in Version2.> I'm not sure that's a sufficient solution, because this means that the> branch for Version2 may stick around with effectively no change from> its last tag other than history, and you can't simply update the tag> to update the history, can you? Either it sticks around for a very> long time, or it goes away and eventually somebody else is going to> have to resolve that potential merge conflict when fixing the next bug> that comes around (which maybe applies to both).>

I think I already addressed this concern with Mike later in this thread, but I'll restate for completeness:

Even if a merge from v1 to v2 is a no-op in terms of changes, the fact that a non-no-op change in v1 merits a no-op change in v2 is important, and thus this is important for the developer to record with a merge.

The lifetime of the v2 branch is then subject to the same circumstance we've talked about previously.

Re: "The lifetime of the v2 branch is then subject to the samecircumstance we've talked about previously."

Right, my only additional point was that we should be aware that itmay have a much longer lifetime, due to the fact that it doesn't makesense to re-release/re-tag it when it doesn't appear to have anychanges (but its history would show a commit from the merge, and acomplementing commit that together are effectively a no-op). Thisbranch longevity in these circumstances may not be desirable, but weshould be aware of the possibility, so that the branch doesn't getdeleted and somebody down the road is expected to resolve theconflict.

--Christopher L Tubbs IIhttp://gravatar.com/ctubbsiiOn Tue, Jun 11, 2013 at 8:46 PM, Josh Elser <[EMAIL PROTECTED]> wrote:> On 06/11/2013 12:26 PM, Christopher wrote:>>>> On Tue, Jun 11, 2013 at 12:05 PM, Josh Elser<[EMAIL PROTECTED]> wrote:>>>>>> >The person who implements the workaround in Version1 should ensure that>>> > when>>> >Version1 is merged into Version2, the correct code is present in>>> > Version2.>>>> I'm not sure that's a sufficient solution, because this means that the>> branch for Version2 may stick around with effectively no change from>> its last tag other than history, and you can't simply update the tag>> to update the history, can you? Either it sticks around for a very>> long time, or it goes away and eventually somebody else is going to>> have to resolve that potential merge conflict when fixing the next bug>> that comes around (which maybe applies to both).>>>> I think I already addressed this concern with Mike later in this thread, but> I'll restate for completeness:>> Even if a merge from v1 to v2 is a no-op in terms of changes, the fact that> a non-no-op change in v1 merits a no-op change in v2 is important, and thus> this is important for the developer to record with a merge.>> The lifetime of the v2 branch is then subject to the same circumstance we've> talked about previously.

On Mon, Jun 10, 2013 at 10:44 PM, Josh Elser <[EMAIL PROTECTED]> wrote:> Alright, I think I covered all of the content that's needed.>> http://people.apache.org/~elserj/git/git.html>> Disclaimer, I actually got Christopher to say "it's kind of long...". Yes,> this was intended. I'd rather be (painfully) explicit front and lift out a> TL;DR version from the master document.

I did read the whole thing. I would like to see a place for thescenarios I contributed, but other than that, I think it's asufficient plan for transition.

> _Please_ give feedback now as to what is still unclear about after reading> the document. I'd hate to have wasted all of this time writing this to just> change our minds again in the near future

One thing mentioned is the release instructions (how to create/stage arelease). I'm not sure things will work exactly the same as for svn,but I hope they'll be very close (it might require an extra 'git push'or something, after the normal steps expressed in assemble/build.sh).I'd have to do some more experimenting with git and themaven-release-plugin, after which I could write something up. I can dothis after the transition, though, and after I'm sure myself how to doit smoothly. I don't think this should be a blocker, though.

> Also, please look for text in _emphasis_ as these are things which I do not> believe were decided upon as a group. Copied here for your ease:>> 1. Need to ensure that deleting remote branches is not an issue. History is> still intact so this should not grind against ASF policy.

IMO, this is probably the most important thing remaining to find out,since the described workflow that seems to have consensus assumesthis.

> 2. Do we have a nice write-up of the release policies?>> And, the last thing:>> Is everyone ok with the default branch when cloning the repository being> latest unstable branch (synonymous with what "trunk" is now)? If so, is> everyone ok with naming it `master`? This is what my vote is towards.

+1, +1

> Once we get these questions answered and the process reviewed, I believe> we're ready to move forward with the INFRA ticket.

I just asked this question and received a response in the #infra chatroom on freenode:

(05:32:08 PM) ctubbsii: Hi, infra. The Accumulo project is discussingswitching to git, and had a question. Does git allow deleting remotebranches? (which we'd want to do in our workflow, after merging to ourmaster branch). What other permissions/restrictions are set on Apachegit repos that we should be aware of?(05:32:46 PM) KurtStam left the room (quit: Quit: KurtStam).(05:33:22 PM) ke4qqq: ctubbsii yes(05:33:59 PM) ke4qqq: ctubbsii: can't rewrite history, (e.g. no forcemerges) aside from that not much that I can think of off the top of myhead(05:34:19 PM) ctubbsii: ke4qqq: thank you very much!(05:34:59 PM) ke4qqq: np

--Christopher L Tubbs IIhttp://gravatar.com/ctubbsiiOn Wed, Jun 12, 2013 at 4:21 PM, Christopher <[EMAIL PROTECTED]> wrote:> On Mon, Jun 10, 2013 at 10:44 PM, Josh Elser <[EMAIL PROTECTED]> wrote:>> Alright, I think I covered all of the content that's needed.>>>> http://people.apache.org/~elserj/git/git.html>>>> Disclaimer, I actually got Christopher to say "it's kind of long...". Yes,>> this was intended. I'd rather be (painfully) explicit front and lift out a>> TL;DR version from the master document.>> I did read the whole thing. I would like to see a place for the> scenarios I contributed, but other than that, I think it's a> sufficient plan for transition.>>> _Please_ give feedback now as to what is still unclear about after reading>> the document. I'd hate to have wasted all of this time writing this to just>> change our minds again in the near future>> One thing mentioned is the release instructions (how to create/stage a> release). I'm not sure things will work exactly the same as for svn,> but I hope they'll be very close (it might require an extra 'git push'> or something, after the normal steps expressed in assemble/build.sh).> I'd have to do some more experimenting with git and the> maven-release-plugin, after which I could write something up. I can do> this after the transition, though, and after I'm sure myself how to do> it smoothly. I don't think this should be a blocker, though.>>> Also, please look for text in _emphasis_ as these are things which I do not>> believe were decided upon as a group. Copied here for your ease:>>>> 1. Need to ensure that deleting remote branches is not an issue. History is>> still intact so this should not grind against ASF policy.>> IMO, this is probably the most important thing remaining to find out,> since the described workflow that seems to have consensus assumes> this.>>> 2. Do we have a nice write-up of the release policies?>>>> And, the last thing:>>>> Is everyone ok with the default branch when cloning the repository being>> latest unstable branch (synonymous with what "trunk" is now)? If so, is>> everyone ok with naming it `master`? This is what my vote is towards.>> +1, +1>>> Once we get these questions answered and the process reviewed, I believe>> we're ready to move forward with the INFRA ticket.>> +1>> --> Christopher L Tubbs II> http://gravatar.com/ctubbsii

On Jun 12, 2013 4:21 PM, "Christopher" <[EMAIL PROTECTED]> wrote:>> On Mon, Jun 10, 2013 at 10:44 PM, Josh Elser <[EMAIL PROTECTED]> wrote:> > Alright, I think I covered all of the content that's needed.> >> > http://people.apache.org/~elserj/git/git.html> >> > Disclaimer, I actually got Christopher to say "it's kind of long...".Yes,> > this was intended. I'd rather be (painfully) explicit front and liftout a> > TL;DR version from the master document.>> I did read the whole thing. I would like to see a place for the> scenarios I contributed, but other than that, I think it's a> sufficient plan for transition.

Are you planning to update it yourself or would you like me to? If you'dlike me to, please refresh my mind on the specifics :)>> > _Please_ give feedback now as to what is still unclear about afterreading> > the document. I'd hate to have wasted all of this time writing this tojust> > change our minds again in the near future>> One thing mentioned is the release instructions (how to create/stage a> release). I'm not sure things will work exactly the same as for svn,> but I hope they'll be very close (it might require an extra 'git push'> or something, after the normal steps expressed in assemble/build.sh).> I'd have to do some more experimenting with git and the> maven-release-plugin, after which I could write something up. I can do> this after the transition, though, and after I'm sure myself how to do> it smoothly. I don't think this should be a blocker, though.>> > Also, please look for text in _emphasis_ as these are things which I donot> > believe were decided upon as a group. Copied here for your ease:> >> > 1. Need to ensure that deleting remote branches is not an issue.History is> > still intact so this should not grind against ASF policy.>> IMO, this is probably the most important thing remaining to find out,> since the described workflow that seems to have consensus assumes> this.

Yay for your response from #infra. Thanks for taking the time to ask. I'llremove those caveats from the doc.>> > 2. Do we have a nice write-up of the release policies?> >> > And, the last thing:> >> > Is everyone ok with the default branch when cloning the repository being> > latest unstable branch (synonymous with what "trunk" is now)? If so, is> > everyone ok with naming it `master`? This is what my vote is towards.>> +1, +1

I'll update this section of the doc tonight.>> > Once we get these questions answered and the process reviewed, I believe> > we're ready to move forward with the INFRA ticket.>> +1

Does anyone feel we need to call a vote on this plan? I feel lazy consensusis good enough given our previous poll on wanting to move to git in thefirst place.>> --> Christopher L Tubbs II> http://gravatar.com/ctubbsii

> On Jun 12, 2013 4:21 PM, "Christopher" <[EMAIL PROTECTED]> wrote:> >> > On Mon, Jun 10, 2013 at 10:44 PM, Josh Elser <[EMAIL PROTECTED]>> wrote:> > > Alright, I think I covered all of the content that's needed.> > >> > > http://people.apache.org/~elserj/git/git.html> > >> > > Disclaimer, I actually got Christopher to say "it's kind of long...".> Yes,> > > this was intended. I'd rather be (painfully) explicit front and lift> out a> > > TL;DR version from the master document.> >> > I did read the whole thing. I would like to see a place for the> > scenarios I contributed, but other than that, I think it's a> > sufficient plan for transition.>> Are you planning to update it yourself or would you like me to? If you'd> like me to, please refresh my mind on the specifics :)> >> > > _Please_ give feedback now as to what is still unclear about after> reading> > > the document. I'd hate to have wasted all of this time writing this to> just> > > change our minds again in the near future> >> > One thing mentioned is the release instructions (how to create/stage a> > release). I'm not sure things will work exactly the same as for svn,> > but I hope they'll be very close (it might require an extra 'git push'> > or something, after the normal steps expressed in assemble/build.sh).> > I'd have to do some more experimenting with git and the> > maven-release-plugin, after which I could write something up. I can do> > this after the transition, though, and after I'm sure myself how to do> > it smoothly. I don't think this should be a blocker, though.> >> > > Also, please look for text in _emphasis_ as these are things which I do> not> > > believe were decided upon as a group. Copied here for your ease:> > >> > > 1. Need to ensure that deleting remote branches is not an issue.> History is> > > still intact so this should not grind against ASF policy.> >> > IMO, this is probably the most important thing remaining to find out,> > since the described workflow that seems to have consensus assumes> > this.>> Yay for your response from #infra. Thanks for taking the time to ask. I'll> remove those caveats from the doc.> >> > > 2. Do we have a nice write-up of the release policies?> > >> > > And, the last thing:> > >> > > Is everyone ok with the default branch when cloning the repository> being> > > latest unstable branch (synonymous with what "trunk" is now)? If so, is> > > everyone ok with naming it `master`? This is what my vote is towards.> >> > +1, +1>> I'll update this section of the doc tonight.> >> > > Once we get these questions answered and the process reviewed, I> believe> > > we're ready to move forward with the INFRA ticket.> >> > +1>> Does anyone feel we need to call a vote on this plan? I feel lazy consensus> is good enough given our previous poll on wanting to move to git in the> first place.> >> > --> > Christopher L Tubbs II> > http://gravatar.com/ctubbsii>

On Wed, Jun 12, 2013 at 6:15 PM, Josh Elser <[EMAIL PROTECTED]> wrote:> On Jun 12, 2013 4:21 PM, "Christopher" <[EMAIL PROTECTED]> wrote:>> On Mon, Jun 10, 2013 at 10:44 PM, Josh Elser <[EMAIL PROTECTED]> wrote:[snip]>> I did read the whole thing. I would like to see a place for the>> scenarios I contributed, but other than that, I think it's a>> sufficient plan for transition.>> Are you planning to update it yourself or would you like me to? If you'd> like me to, please refresh my mind on the specifics :)

I'd prefer you do it, just so a second pair of eyes can take a lookand verify that the scenarios I describe match what you've alreadydocumented. Keep in mind that the example scenarios might grow (suchas the scenario Mike Drob described above, and I'm sure there will bemore we'll encounter and want to document as we make mistakes)... Idon't know if that warrants a separate page, or just a dedicatedsection for "scenarios".

[snip]> Does anyone feel we need to call a vote on this plan? I feel lazy consensus> is good enough given our previous poll on wanting to move to git in the> first place.

Lazy consensus is probably sufficient, but if it helps, I say, +1 onmoving forward with tickets.

Josh, Chris, Mike, thanks for hashing this out. The document is long, but Ibelieve it contains the appreciate level of detail so as to eliminatemany ambiguities/questions as to how things are done.

I have a couple questions. From the docs:

" Whatever the actual case is, the developer who made the first set ofchanges (you) is the one responsible for performing the merge through therest of the active versions. Even when the merge may results in azero-length change in content, this is incredibly important to record asyou are the one who knows that this zero-length change in content iscorrect!"

Sorry for the newb question, but how does one actually create zero lengthcommit?

Also, I have encountered cases where a merge has pulled in changes fromprevious branches that were unrelated to the particular changes I am tryingto merge upwards. I suspect this has something to do with the fact thatsomeone else has done something wrong (eg: neglected to merge theirchange). What is the appropriate approach to resolving this issue?

On 06/12/2013 09:05 PM, Drew Farris wrote:> Josh, Chris, Mike, thanks for hashing this out. The document is long, but I> believe it contains the appreciate level of detail so as to eliminate> many ambiguities/questions as to how things are done.>> I have a couple questions. From the docs:>> " Whatever the actual case is, the developer who made the first set of> changes (you) is the one responsible for performing the merge through the> rest of the active versions. Even when the merge may results in a> zero-length change in content, this is incredibly important to record as> you are the one who knows that this zero-length change in content is> correct!">> Sorry for the newb question, but how does one actually create zero length> commit?Take the loggers for example. In 1.4, we have local disk loggers, and in 1.5, HDFS loggers. Hypothetically, say there is additional work on the internal Logger interface that is only required on local disk loggers and not HDFS loggers, let's call this method "foo()" on Logger.

In your fix against 1.4.4-SNAPSHOT, you change some stuff with Logger, in which you need to call Logger.foo(). You complete the changes and 1.4.4-SNAPSHOT works. When you go to merge to 1.5, hypothetically, say your change in 1.4.4-SNAPSHOT which required a call to Logger.foo() is no longer required because it's natively handled by the HDFS Logger implementation.

This is a (contrived) example of how a change in a lower version may be OBE in more recent versions. Does that make sense?

> Also, I have encountered cases where a merge has pulled in changes from> previous branches that were unrelated to the particular changes I am trying> to merge upwards. I suspect this has something to do with the fact that> someone else has done something wrong (eg: neglected to merge their> change). What is the appropriate approach to resolving this issue?Yes, this, ideally, should never happen. It is always possible that you get merge conflicts in the target version due to changes upstream (1.5.1-SNAPSHOT) that were not applied downstream (1.4.4-SNAPSHOT). The dev merging their changes should alleviate most of this; however, it is not foolproof. In this case, it would be on you to resolve the conflict as even though it was not your changes alone that created the conflict your changes were the most recent. It would also be reasonable to expect the other dev to also help you with the conflict :)>> Drew>

On Wed, Jun 12, 2013 at 9:16 PM, Josh Elser <[EMAIL PROTECTED]> wrote:>> In your fix against 1.4.4-SNAPSHOT, you change some stuff with Logger, in> which you need to call Logger.foo(). You complete the changes and> 1.4.4-SNAPSHOT works. When you go to merge to 1.5, hypothetically, say your> change in 1.4.4-SNAPSHOT which required a call to Logger.foo() is no longer> required because it's natively handled by the HDFS Logger implementation.

So, after I do the merge of my change from 1.4.4-SNAPSHOT into 1.5, doI have a modified Logger in 1.5 that calls Logger.foo()? Does thatmean that I need to add another commit to 1.5 that reverts thatchange?

On 06/12/2013 09:38 PM, Drew Farris wrote:> On Wed, Jun 12, 2013 at 9:16 PM, Josh Elser <[EMAIL PROTECTED]> wrote:>> In your fix against 1.4.4-SNAPSHOT, you change some stuff with Logger, in>> which you need to call Logger.foo(). You complete the changes and>> 1.4.4-SNAPSHOT works. When you go to merge to 1.5, hypothetically, say your>> change in 1.4.4-SNAPSHOT which required a call to Logger.foo() is no longer>> required because it's natively handled by the HDFS Logger implementation.> So, after I do the merge of my change from 1.4.4-SNAPSHOT into 1.5, do> I have a modified Logger in 1.5 that calls Logger.foo()? Does that> mean that I need to add another commit to 1.5 that reverts that> change?Right, you should notice that with a compilation error though. Stopping git before it completes the merge (--no-commit) is best here as you can include these changes in the merge itself rather than having to make yet another commit.

It troubles me that we are referring to the master branch as unstable.While we are not following the dictums of Agile methodology it is clear tome that the master branch should always be potentially releasable. It isnot a dumping ground for untested features or half-complete code.

If something is incomplete, leave it in a branch. If you want tocollaborate, create a github project and form a team. Only when the code isfully baked, merge it into the master.

The SHA1 value of a change tracks it across all branches. No need toperform no-op merges. Simply check the branch history to see it containsthe SHA1 hash you're interested in.

Why would you apply a change specifically for 1.4.4 to 1.5 code? The changesimply does not apply.On Wed, Jun 12, 2013 at 9:16 PM, Josh Elser <[EMAIL PROTECTED]> wrote:

> On 06/12/2013 09:05 PM, Drew Farris wrote:>>> Josh, Chris, Mike, thanks for hashing this out. The document is long, but>> I>> believe it contains the appreciate level of detail so as to eliminate>> many ambiguities/questions as to how things are done.>>>> I have a couple questions. From the docs:>>>> " Whatever the actual case is, the developer who made the first set of>> changes (you) is the one responsible for performing the merge through the>> rest of the active versions. Even when the merge may results in a>> zero-length change in content, this is incredibly important to record as>> you are the one who knows that this zero-length change in content is>> correct!">>>> Sorry for the newb question, but how does one actually create zero length>> commit?>>> Take the loggers for example. In 1.4, we have local disk loggers, and in> 1.5, HDFS loggers. Hypothetically, say there is additional work on the> internal Logger interface that is only required on local disk loggers and> not HDFS loggers, let's call this method "foo()" on Logger.>> In your fix against 1.4.4-SNAPSHOT, you change some stuff with Logger, in> which you need to call Logger.foo(). You complete the changes and> 1.4.4-SNAPSHOT works. When you go to merge to 1.5, hypothetically, say your> change in 1.4.4-SNAPSHOT which required a call to Logger.foo() is no longer> required because it's natively handled by the HDFS Logger implementation.>> This is a (contrived) example of how a change in a lower version may be> OBE in more recent versions. Does that make sense?>>> Also, I have encountered cases where a merge has pulled in changes from>> previous branches that were unrelated to the particular changes I am>> trying>> to merge upwards. I suspect this has something to do with the fact that>> someone else has done something wrong (eg: neglected to merge their>> change). What is the appropriate approach to resolving this issue?>>> Yes, this, ideally, should never happen. It is always possible that you> get merge conflicts in the target version due to changes upstream> (1.5.1-SNAPSHOT) that were not applied downstream (1.4.4-SNAPSHOT). The dev> merging their changes should alleviate most of this; however, it is not> foolproof. In this case, it would be on you to resolve the conflict as even> though it was not your changes alone that created the conflict your changes> were the most recent. It would also be reasonable to expect the other dev> to also help you with the conflict :)>>>>> Drew>>>>>

The point is that any developer, at any point in time (sans mid-merge of another developer), should be able to cleanly merge from 1.x->1.y. This is the same policy as we follow with SVN currently

`cd accumulo-1.y``svn merge -r 1:HEAD 1.x .`

Sometimes there are funny things that happen with drastically different new features/implementations, but this is expected with an active project over time.

On 06/12/2013 10:48 PM, David Medinets wrote:> Why would you apply a change specifically for 1.4.4 to 1.5 code? The change> simply does not apply.>>> On Wed, Jun 12, 2013 at 9:16 PM, Josh Elser <[EMAIL PROTECTED]> wrote:>>> On 06/12/2013 09:05 PM, Drew Farris wrote:>>>>> Josh, Chris, Mike, thanks for hashing this out. The document is long, but>>> I>>> believe it contains the appreciate level of detail so as to eliminate>>> many ambiguities/questions as to how things are done.>>>>>> I have a couple questions. From the docs:>>>>>> " Whatever the actual case is, the developer who made the first set of>>> changes (you) is the one responsible for performing the merge through the>>> rest of the active versions. Even when the merge may results in a>>> zero-length change in content, this is incredibly important to record as>>> you are the one who knows that this zero-length change in content is>>> correct!">>>>>> Sorry for the newb question, but how does one actually create zero length>>> commit?>>>>> Take the loggers for example. In 1.4, we have local disk loggers, and in>> 1.5, HDFS loggers. Hypothetically, say there is additional work on the>> internal Logger interface that is only required on local disk loggers and>> not HDFS loggers, let's call this method "foo()" on Logger.>>>> In your fix against 1.4.4-SNAPSHOT, you change some stuff with Logger, in>> which you need to call Logger.foo(). You complete the changes and>> 1.4.4-SNAPSHOT works. When you go to merge to 1.5, hypothetically, say your>> change in 1.4.4-SNAPSHOT which required a call to Logger.foo() is no longer>> required because it's natively handled by the HDFS Logger implementation.>>>> This is a (contrived) example of how a change in a lower version may be>> OBE in more recent versions. Does that make sense?>>>>>> Also, I have encountered cases where a merge has pulled in changes from>>> previous branches that were unrelated to the particular changes I am>>> trying>>> to merge upwards. I suspect this has something to do with the fact that>>> someone else has done something wrong (eg: neglected to merge their>>> change). What is the appropriate approach to resolving this issue?>>>>> Yes, this, ideally, should never happen. It is always possible that you>> get merge conflicts in the target version due to changes upstream>> (1.5.1-SNAPSHOT) that were not applied downstream (1.4.4-SNAPSHOT). The dev>> merging their changes should alleviate most of this; however, it is not>> foolproof. In this case, it would be on you to resolve the conflict as even>> though it was not your changes alone that created the conflict your changes>> were the most recent. It would also be reasonable to expect the other dev>> to also help you with the conflict :)>>>>> Drew>>>>>>

On 06/12/2013 10:45 PM, David Medinets wrote:> It troubles me that we are referring to the master branch as unstable.> While we are not following the dictums of Agile methodology it is clear to> me that the master branch should always be potentially releasable. It is> not a dumping ground for untested features or half-complete code.This is a matter of opinion on what the contents of master should be. The (public) opinion up until this point has been to just keep master unstable. TBH, I could go either way.> If something is incomplete, leave it in a branch. If you want to> collaborate, create a github project and form a team. Only when the code is> fully baked, merge it into the master.>> The SHA1 value of a change tracks it across all branches. No need to> perform no-op merges. Simply check the branch history to see it contains> the SHA1 hash you're interested in.That... isn't really how Git is meant to work. The parent of a commit is important and uniquely identifies a commit. In other words, the tree in which a commit falls identifies the changes which that commit introduces. Things break down when you try to circumvent this. See also my other comment about how we currently perform SVN merges (`cd accumulo-1.y && svn merge -r 1:HEAD 1.x .`)> I found the 'git show-graph' alias at> http://gitready.com/intermediate/2009/01/26/text-based-graph.html to be> helpful. Simply 'git show-graph | grep <sha1>' to easily find out if one> change is included in a branch.See also, `git branch --contains SHA1`> If managing the releases inside one git repository seems prone to> complications, create a separate repository for each release. After all,> post-release there really should be only bug fixes.>Forcing separate repositories for each release sounds like a terrible idea. You'd be segmenting every single Accumulo release into its own series of disjoint changes. 1.4.3 would have no common parent to 1.4.2, which would have no common parent to 1.4.1. This would destroy the linear progress that, over time, any actively developed software project takes.

On 06/12/2013 07:09 PM, Christopher wrote:>>>> I did read the whole thing. I would like to see a place for the>>> scenarios I contributed, but other than that, I think it's a>>> sufficient plan for transition.>> Are you planning to update it yourself or would you like me to? If you'd>> like me to, please refresh my mind on the specifics :)> Specifically, the scenarios in the suggestions file I attached to ACCUMULO-1498:> https://issues.apache.org/jira/secure/attachment/12586445/ctubbsii-git-suggestions.v1.txt>> I'd prefer you do it, just so a second pair of eyes can take a look> and verify that the scenarios I describe match what you've already> documented. Keep in mind that the example scenarios might grow (such> as the scenario Mike Drob described above, and I'm sure there will be> more we'll encounter and want to document as we make mistakes)... I> don't know if that warrants a separate page, or just a dedicated> section for "scenarios".>Added the first two situations to the bottom in a new header "Examples". Added the third to the feature-branches discussion under implementation>developers. I did change a few things from your txt file; please verify.

Also tweaked an example to document usage of things like `git merge --squash` and `git merge --no-commit`, re: Drew's comments.

Two last things I noticed in this go-around:

1. Link to Christopher's Maven instructions. Not critical -- we don't them in CMS now anyways, so nothing gained, nothing lost.

On Wed, Jun 12, 2013 at 10:45 PM, David Medinets<[EMAIL PROTECTED]> wrote:> It troubles me that we are referring to the master branch as unstable.> While we are not following the dictums of Agile methodology it is clear to> me that the master branch should always be potentially releasable. It is> not a dumping ground for untested features or half-complete code.

I think the master should be generally stable, in the "nightly build"sense. I thought that's why we discussed feature branches. I thinkperhaps we're confusing "latest" and "subject to change prior torelease" with "unstable". This may be a question of semantics. What dowe mean if we say "unstable"? If we're defining it as "latest", "notrelease-quality tested", or "subject to change before a release", Ithink it's fine to call it "unstable". If we mean "partially completedfeatures that are not remotely ready to be tested for a release", Ithink we definitely don't want that kind of "unstable" in master.

[snip]> The SHA1 value of a change tracks it across all branches. No need to> perform no-op merges. Simply check the branch history to see it contains> the SHA1 hash you're interested in.[snip]

I think it's still useful to merge forward (even if it's an effective"no-op"), for two reasons:1) It keeps the history between older supported versions and newerversions linear, which makes it easier to merge non-"no-op" fixesacross supported versions.2) It's still useful to record that a bug has been at least consideredand resolved in a newer branch, even if nothing needs to be done.Simply requiring that the merge process be performed as a part of theworkflow helps prevent bug regression.

On Wed, Jun 12, 2013 at 11:23 PM, Josh Elser <[EMAIL PROTECTED]> wrote:> On 06/12/2013 07:09 PM, Christopher wrote:[snip]> Added the first two situations to the bottom in a new header "Examples".> Added the third to the feature-branches discussion under> implementation>developers. I did change a few things from your txt file;> please verify.>> Also tweaked an example to document usage of things like `git merge> --squash` and `git merge --no-commit`, re: Drew's comments.

Looks good to me.

[snip]> 2. Subject of notification emails. See[snip]

I like their suggestion:git commit [%(repo_name)s]: %(shash)s - %(subject)s

However, I don't care that much, as long as it's the only thing thatever sends to [EMAIL PROTECTED] so it's easily organized inmy mailbox.

Secondly, I like what is enumerated in the document. I would like to seethe clarification on the empty merges forward in it for the sake of newpeople. Additionally, in the tl;dr version it would be awesome to haveexamples of it in command form as a quick ref (as I'm still not that greatwith git vs. svn).

Thirdly, +1 Eric's suggestion to get the ticket in ASAP because we don'tknow what the turn around time is. There was a large consensus on this oneon the meeting last week.

+1 renaming trunk to master

The "unstable" discussion of master/trunk should go into another thread ifit's going to be debated. Nothing is changing in the behavior of thetrunk/master because of the switch to git. If there are issues with the waywe handle master, it shouldn't be buried in another discussion thread. It'snothing but disruptive to the current discussion at hand.

I'm happy with the email subject. I'm assuming we're sticking with allcommits reffing a ticket? Or at least all commits to the main branch(es).

Lastly, can you provide some sort of date notation to the document. I justread it now, but it seems that it's gone through a few revisions, based onthe commentary in this thread. If I'm wrong, please ignore. Otherwise, canyou just add the date you modified (even better, by section :D). ThanksAnd again, thanks again Josh for spearheading thing.

On Thu, Jun 13, 2013 at 1:36 PM, John Vines <[EMAIL PROTECTED]> wrote:> Finally read through all of this.> First of all, great work Josh.

+42

[snip]> I'm happy with the email subject. I'm assuming we're sticking with all> commits reffing a ticket? Or at least all commits to the main branch(es).[snip]

If you're going to squash them, it would just be the squashed commitwhere this would be needed, I would think.

This also raises an interesting question: how does the JIRAintegration work for git? Would it just add comments corresponding tocommits pushed to master? Or would it track all commits pushed to anybranch? If it tracks all commits pushed to any branch, you may want toreference the JIRA issue in every commit... unless you don't want/needthat much verbosity on the ticket. Then, I suppose you could just doone reference when you merge/squash.

In my git work, there's git integration and we ref tickets in commits. Juststarting with ticket-number and then I can do #comment to add comments, aswell as #resolve to automatically resolve the issue, etc. But I think thatlatter one isn't as important since it sounds like there will be a lot ofmerging going onOn Thu, Jun 13, 2013 at 1:49 PM, Christopher <[EMAIL PROTECTED]> wrote:

> On Thu, Jun 13, 2013 at 1:36 PM, John Vines <[EMAIL PROTECTED]> wrote:> > Finally read through all of this.> > First of all, great work Josh.>> +42>> [snip]> > I'm happy with the email subject. I'm assuming we're sticking with all> > commits reffing a ticket? Or at least all commits to the main branch(es).> [snip]>> If you're going to squash them, it would just be the squashed commit> where this would be needed, I would think.>> This also raises an interesting question: how does the JIRA> integration work for git? Would it just add comments corresponding to> commits pushed to master? Or would it track all commits pushed to any> branch? If it tracks all commits pushed to any branch, you may want to> reference the JIRA issue in every commit... unless you don't want/need> that much verbosity on the ticket. Then, I suppose you could just do> one reference when you merge/squash.>> --> Christopher L Tubbs II> http://gravatar.com/ctubbsii>

I finally got a chance to read this as well. Thanks again Josh forwriting/maintaining this!

For the contributor workflow, I've always tried to avoid using "commit -a"but instead use "git status" and separately stage files for commit with"git add <directory> or <file>". I've seen people commit strange things byaccident and not notice until its too late. It's also easy to unstage itemsbefore the commit is made so I may just be being picky.

In reference to the master being "stable". I've often seen projects use a"master" and "next" branches where master is considered stable and "next"is the unstable next-gen development branch. I've also seen groups do theopposite and use "stable" and "master" where master is the unstablenext-gen development branch. As Chris pointed out, it seems like a semanticargument and I'm partial to either one.

To John's point, I assumed since we were using the jira git plugin thatwe'd be able to mark the ticket in the commit but it would be nice to notethis in the workflow somewhere.

> In my git work, there's git integration and we ref tickets in commits. Just> starting with ticket-number and then I can do #comment to add comments, as> well as #resolve to automatically resolve the issue, etc. But I think that> latter one isn't as important since it sounds like there will be a lot of> merging going on>>> On Thu, Jun 13, 2013 at 1:49 PM, Christopher <[EMAIL PROTECTED]> wrote:>> > On Thu, Jun 13, 2013 at 1:36 PM, John Vines <[EMAIL PROTECTED]> wrote:> > > Finally read through all of this.> > > First of all, great work Josh.> >> > +42> >> > [snip]> > > I'm happy with the email subject. I'm assuming we're sticking with all> > > commits reffing a ticket? Or at least all commits to the main> branch(es).> > [snip]> >> > If you're going to squash them, it would just be the squashed commit> > where this would be needed, I would think.> >> > This also raises an interesting question: how does the JIRA> > integration work for git? Would it just add comments corresponding to> > commits pushed to master? Or would it track all commits pushed to any> > branch? If it tracks all commits pushed to any branch, you may want to> > reference the JIRA issue in every commit... unless you don't want/need> > that much verbosity on the ticket. Then, I suppose you could just do> > one reference when you merge/squash.> >> > --> > Christopher L Tubbs II> > http://gravatar.com/ctubbsii> >>

On 06/13/2013 01:36 PM, John Vines wrote:> Finally read through all of this.> First of all, great work Josh.>> Secondly, I like what is enumerated in the document. I would like to see> the clarification on the empty merges forward in it for the sake of new> people. Additionally, in the tl;dr version it would be awesome to have> examples of it in command form as a quick ref (as I'm still not that great> with git vs. svn).

Honestly, I think this entire subject has really blown up, especially given that it's the same exact policy we had previously (see emails re: to David last night). See the section "Changes which affect multiple versions (a.k.a. merging)". I'll add a tl;dr to the top of that section which re-iterates "the developer is responsible for merging all of his/her changes" to be super-explicit.

>> Thirdly, +1 Eric's suggestion to get the ticket in ASAP because we don't> know what the turn around time is. There was a large consensus on this one> on the meeting last week.>> +1 renaming trunk to master>> The "unstable" discussion of master/trunk should go into another thread if> it's going to be debated. Nothing is changing in the behavior of the> trunk/master because of the switch to git. If there are issues with the way> we handle master, it shouldn't be buried in another discussion thread. It's> nothing but disruptive to the current discussion at hand.>> I'm happy with the email subject. I'm assuming we're sticking with all> commits reffing a ticket? Or at least all commits to the main branch(es).

Commit messages: yes, I see no reason to change that. Branches, yeah, perhaps stuff "beneath" `<apache_id>/` is sufficient to not have tickets, but the "upstream" branches definitely need them. I think we can revisit this again if people want.

> Lastly, can you provide some sort of date notation to the document. I just> read it now, but it seems that it's gone through a few revisions, based on> the commentary in this thread. If I'm wrong, please ignore. Otherwise, can> you just add the date you modified (even better, by section :D). Thanks

Date.. other than the last revision on the SVN CMS? I suppose I could add a last-modified bit to the top of the page if that's deemed desirable.

>> And again, thanks again Josh for spearheading thing.>> John>>>>> On Thu, Jun 13, 2013 at 1:16 AM, Christopher <[EMAIL PROTECTED]> wrote:>>> On Wed, Jun 12, 2013 at 11:23 PM, Josh Elser <[EMAIL PROTECTED]> wrote:>>> On 06/12/2013 07:09 PM, Christopher wrote:>> [snip]>>> Added the first two situations to the bottom in a new header "Examples".>>> Added the third to the feature-branches discussion under>>> implementation>developers. I did change a few things from your txt file;>>> please verify.>>>>>> Also tweaked an example to document usage of things like `git merge>>> --squash` and `git merge --no-commit`, re: Drew's comments.>>>> Looks good to me.>>>> [snip]>>> 2. Subject of notification emails. See>> [snip]>>>> I like their suggestion:>> git commit [%(repo_name)s]: %(shash)s - %(subject)s>>>> However, I don't care that much, as long as it's the only thing that>> ever sends to [EMAIL PROTECTED] so it's easily organized in>> my mailbox.>>>> -->> Christopher L Tubbs II>> http://gravatar.com/ctubbsii>>>

On 06/13/2013 01:49 PM, Christopher wrote:> On Thu, Jun 13, 2013 at 1:36 PM, John Vines <[EMAIL PROTECTED]> wrote:>> Finally read through all of this.>> First of all, great work Josh.>> +42>> [snip]>> I'm happy with the email subject. I'm assuming we're sticking with all>> commits reffing a ticket? Or at least all commits to the main branch(es).> [snip]>> If you're going to squash them, it would just be the squashed commit> where this would be needed, I would think.>> This also raises an interesting question: how does the JIRA> integration work for git? Would it just add comments corresponding to> commits pushed to master? Or would it track all commits pushed to any> branch? If it tracks all commits pushed to any branch, you may want to> reference the JIRA issue in every commit... unless you don't want/need> that much verbosity on the ticket. Then, I suppose you could just do> one reference when you merge/squash.

Good question. I would guess notifications are done via git-push (thus, any branch would trigger the email. Not sure about jira integration, but I would guess the same is true?