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

Switch to Threaded View
Accumulo >> mail # dev >> GIT

On Tue, Jun 4, 2013 at 4:15 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
> On 6/4/13 2:34 PM, Christopher wrote:
>> Personally, I'm fine with not having a super-long running release
>> branch, but I like them for a few reasons:
> I just want to keep make note that this will affect things much more than
> previously in SVN as a merge is more than a guess at metadata.
> If you have long-lived branches, this necessitates that there are very many
> viable options in which a bug-fix can be applied (any branch at all).  Not
> keeping these around will force the developer to think about where their fix
> is supposed to go (earliest, non-EOL'ed version).

Good point.

>> I think branches should be hierarchical for subprojects and contribs,
>> as in: contrib/InstamoOrWhatever (unless there's a better way to
>> handle contribs...?)
> I believe we'll need to make separate repos for subprojects and contribs.
> This is one of the things I need to investigate how it's currently handled.
> New repos are certainly the easiest to manage.

I agree, of course, and that's the preferred option if INFRA permits
this. But this is a workable alternative if they don't.

> Point being, I do not want to preclude developers from making tags unless
> it's an ASF release as I believe this gimps Git quite a bit. IMO, for tags,
> the line should be drawn between "internal" and "external". Tags advertised
> or intended for public use should (probably) be voted on, while
> internal-only intended (doesn't preclude someone from finding and
> downloading themselves) are encouraged.

Understandable, as long as the line is drawn.

Christopher L Tubbs II