Re: [PATCH 04/30] subtree: t7900: use consistent formatting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Luke Shumaker <lukeshu@xxxxxxxxxxx> writes:

>> If Luke is volunteering to take over its maintainership, it would be
>> appreciated by its users.  It has been in the "abandonware" status
>> for too long.
>
> I think I am volunteering.

Wonderful, and thanks.

> Elsewhere in the thread, you suggested that subtree be taken out of
> git.git, and live as a standalone project.
>
> I'm not entirely opposed to that, but
>
>  1. I'm not sure how whoever picks it up (me) establishes their
>     git-subtree as the "real" subtree (get a blessing from Avery?).

Avery is so distant a past, but a work like this series, while we
still have it in contrib/ in my tree, will help build necessary
trust in you by the Git user/developer community, and when that
happens, it would be obvious to everybody that you would be the new
owner of the tool.

And when that happens while the tool is in the contrib/ in my tree,
and you'd be an established trusted member of the development
community by then, I do not mind if you take it and maintain out of
tree, if you keep working on the tool still in contrib/, or if you
polish it to the main porcelain status and take it out of contrib/
and make it part of the git-core proper.

> On the other hand, I think that in the long-ish term git-subtree wants
> to be rewritten in a better-suited language.  My personal inclination
> would be Go, but if I ever want it to graduate to git-core, it'd have
> to be C, huh?

If somebody is willing to do a rewrite and will maintain it for a
long haul, I'd say that it would not necessarily have to be in C
especially if it is not performance sensitive.

As long as it is done in a widely available language, that is (which
used to man Perl or Python, but my persoonal preference won't carry
that much weight these days ;-)

Then folks who really want it in C can rewrite the rewrite on their
own after that.

One advantage you may have if you choose to take it out of my tree
and make it a standalone project is that you have more latitude on
the future implementation technology, but we'd need to start from
helping you earn the trust by convincing others that "subtree" would
be in good hands with your volunteering ;-)

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux