git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* [RFC] Moving main git-subtree development. to GitHub
@ 2017-08-01  2:10 David A. Greene
  2017-08-01 17:52 ` Jonathan Nieder
  2017-08-01 20:55 ` Junio C Hamano
  0 siblings, 2 replies; 3+ messages in thread
From: David A. Greene @ 2017-08-01  2:10 UTC (permalink / raw)
  To: git

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC] Moving main git-subtree development. to GitHub
  2017-08-01  2:10 [RFC] Moving main git-subtree development. to GitHub David A. Greene
@ 2017-08-01 17:52 ` Jonathan Nieder
  2017-08-01 20:55 ` Junio C Hamano
  1 sibling, 0 replies; 3+ messages in thread
From: Jonathan Nieder @ 2017-08-01 17:52 UTC (permalink / raw)
  To: David A. Greene; +Cc: git

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC] Moving main git-subtree development. to GitHub
  2017-08-01  2:10 [RFC] Moving main git-subtree development. to GitHub David A. Greene
  2017-08-01 17:52 ` Jonathan Nieder
@ 2017-08-01 20:55 ` Junio C Hamano
  1 sibling, 0 replies; 3+ messages in thread
From: Junio C Hamano @ 2017-08-01 20:55 UTC (permalink / raw)
  To: David A. Greene; +Cc: git

greened@obbligato.org (David A. Greene) writes:

> 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.
> ...
> Does this mode of operation work for the larger git community?  Are
> there suggestions of how to make this work as smoothly as possible?

As a reasonably well-known and mature project, I'd actually welcome
the idea of git-subtree graduating from my tree and standing on its
own, managed in the way its developers and users prefer using the
workflow they choose to use.

If it is a good idea to keep a copy in contrib/, that will stay to
be slightly to moderately stale depending on the phase of the
"upstream" development, by periodically accepting code dumps?  I do
not have a strong opinion on this.  It is not too much work for me
personally to do so, but

 - I think git-subtree no longer needs the "contrib/ bump" to
   sustain its userbase and community; otherwise you wouldn't be
   sending out the message I am responding to.

 - Seen from the world outside the Git world, it may be confusing if
   two different "sources" of git-subtree exist; the users and the
   distro packagers want fewer choices in things like this.

So I do not have a good answer to what should be done to the copy in
contrib/, at least not yet, but I think it is a good idea to separate
it out as its own development project with its own community.



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-08-01 20:55 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-01  2:10 [RFC] Moving main git-subtree development. to GitHub David A. Greene
2017-08-01 17:52 ` Jonathan Nieder
2017-08-01 20:55 ` Junio C Hamano

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).