Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo, mail # dev - [git] Documentation and Plan of Action


+
Josh Elser 2013-06-05, 03:04
+
Josh Elser 2013-06-06, 01:58
+
Josh Elser 2013-06-11, 02:44
+
Sean Busbey 2013-06-11, 11:16
+
Josh Elser 2013-06-11, 12:55
+
Mike Drob 2013-06-11, 15:44
+
Josh Elser 2013-06-11, 16:05
+
Christopher 2013-06-11, 16:26
+
Josh Elser 2013-06-12, 00:46
+
Christopher 2013-06-12, 19:49
+
David Medinets 2013-06-13, 02:45
+
Christopher 2013-06-13, 04:21
+
Josh Elser 2013-06-13, 02:59
+
Mike Drob 2013-06-11, 23:10
+
Josh Elser 2013-06-11, 23:18
+
Mike Drob 2013-06-11, 23:25
+
Josh Elser 2013-06-11, 23:39
+
Christopher 2013-06-12, 20:21
+
Josh Elser 2013-06-12, 22:15
+
Christopher 2013-06-12, 23:09
+
Drew Farris 2013-06-13, 01:05
+
Josh Elser 2013-06-13, 01:16
+
David Medinets 2013-06-13, 02:48
+
Josh Elser 2013-06-13, 02:52
+
Drew Farris 2013-06-13, 01:38
+
Josh Elser 2013-06-13, 02:00
+
Josh Elser 2013-06-13, 03:23
+
Christopher 2013-06-13, 05:16
+
John Vines 2013-06-13, 17:36
+
Christopher 2013-06-13, 17:49
+
John Vines 2013-06-13, 17:55
+
Corey Nolet 2013-06-13, 20:26
+
Josh Elser 2013-06-13, 23:54
Copy link to this message
-
Re: [git] Documentation and Plan of Action
Josh Elser 2013-06-13, 23:52
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
>>
>
+
Eric Newton 2013-06-12, 22:52
+
Christopher 2013-06-12, 21:35