[RFC] Moving main git-subtree development. to GitHub

2 messages, 2 authors, 2017-08-01 · open the first message on its own page

[RFC] Moving main git-subtree development. to GitHub

From: David A. Greene <hidden>
Date: 2017-08-01 02:46:15

Hello all,

I have decided that moving git-subtree development off of the main git
mailing list is the best way to address the needs of git-subtree users
while providing the flexibility necessary to get it in shape for
eventual "official" status in the git project.

Over the last year and a half I have been working on some new features
for git-subtree, motivated by day-job requirements.  Much of that effort
has been spent hardening the new code in a real work environment, driven
by real-world needs.  I believe it is now ready for public consumption.
However, because it is a large change, it will need lots of public
exposure before it can be considered safe for general use.  Essentially,
I would like to do a "beta" release of the new code while not impacting
existing users of git-subtree in contrib.

During this time and due to work and life commitments, I have not been
able to keep up with the git mailing list as I would like.  Questions
and patches related to git-subtree have languished and I don't want to
lose that good work by our users.  Therefore, I would like to transfer
the main development activity over to GitHub.  GitHub's patch tracking,
review and feedback infrastructure works better for me that a large
mailing list with patches sent via e-mail.  It is easy to lose things in
a sea of conversations.  It's completely personal preference but I think
a switch to GitHub will also make tracking git-subtree's progress easier
for users.  Moving the main development to GitHub will also allow
git-subtree users to be more visible, ask questions and help each other
out.

Going forward, I would like to do the main feature and bug fix work on
GitHub and periodically subtree-merge to git's main repository under
contrib when the code has stabilized and we are reasonably confident
interfaces are stable.  This will allow us to experiment with new ideas
while keeping a stable codebase for end users.  I expect a lot of
re-engineering of the core bits of git-subtree to bring it into
compliance with git's coding standards, support new features and provide
a better user experience.

I believe keeping a stable git-subtree in contrib is valuable.
git-subtree and git-submodule provide alternative solutions to similar
problems, as well as each solving problems the other does not.
Anecdotally, I noticed an uptick in git-subtree user activity after the
move into contrib.  I would like to maintain that visibilty.

Does this mode of operation work for the larger git community?  Are
there suggestions of how to make this work as smoothly as possible?

Thank you for your feedback and support of git-subtree!

                          -David

Re: [RFC] Moving main git-subtree development. to GitHub

From: Jonathan Nieder <hidden>
Date: 2017-08-01 17:52:44

Hi,

David A. Greene wrote:
                                                            Essentially,
I would like to do a "beta" release of the new code while not impacting
existing users of git-subtree in contrib.
Sounds like a sensible goal.  In-tree, you can do that by saying
"please merge this branch to 'next', but I do not want it in 'master'
yet".  But doing it out-of-tree is even more straightforward, since
you have complete control of the repository people use and do not have
to wait for git to pull in your latest changes.

[...]
I believe keeping a stable git-subtree in contrib is valuable.
I am not convinced of this.  git-subtree is a well known tool, and in
its role as a separate project then I think distributors are actually
more likely to package it for easy installation by users.  The usual
benefit of contrib of providing visibility for a new project seems to
have already occurred and not be needed as much as it used to be for
this project --- by now it is a very visible project.

[...]
Does this mode of operation work for the larger git community?  Are
there suggestions of how to make this work as smoothly as possible?
That said, if we want to keep it in contrib then I think the mode of
operation you described is a good one.

Thanks for your work,
Jonathan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help