Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> [git] Documentation and Plan of Action


Copy link to this message
-
Re: [git] Documentation and Plan of Action
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
>>
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB