accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: [git] Documentation and Plan of Action
Date Thu, 13 Jun 2013 23:52:06 GMT
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 <> wrote:
>> On Wed, Jun 12, 2013 at 11:23 PM, Josh Elser <> 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 so it's easily organized in
>> my mailbox.
>> --
>> Christopher L Tubbs II

View raw message