greened@xxxxxxxxxxxxx (David A. Greene) writes:
> Just to clarify, what is the expectation of things in contrib?
> Basically the same as other code?
That heavily depends on your exit strategy.
The contrib/ area was created back when Git was still young and we
felt that it would be beneficial for building the community if
contributions to non-core part were also included, encouraging
developers whose strength are not necessarily in the core part to
participate in various design-level discussions to grow the
community faster. Back then, we felt that an obscure standalone
project outside Git that would help the Git-life of users have a
much better chance of surviving (and eventually be polished) if we
had them bundled, even if the code quality and stability were
sub-par.
Those young days are long gone. A standalone tool that aims to help
users' Git-life would not just survive but flourish with much more
certainty, as long as the tool is good. We have enough Git users to
rely on words-of-mouth these days to ensure their success.
That is why I am very hesitant to add new things to contrib/ these
days. It is very welcome thought that you are working on improving
subtree, and eventually moving it out of contrib/. From the point
of view of the project, either moving up (to be part of the git core
proper) or moving out (to become an independent project) is far more
preferreable than the status quo so far that was staying in contrib/
(without seeing much changes and slowly but steadily bitrotting).
If the aspiration is to move up to exit, then the quality and
stability expectation is basically the same as stuff in core, and we
need to strive to keep it stable and high quality.
On the other hand, if it is exiting by moving out, then Git-core
developers wouldn't have much say in how you would run your project.
There are obvious pros-and-cons from various points of view when
choosing between moving up and moving out:
* If the integration between "git subtree" and the rest of the
system is loose (in other words, if your improved version of "git
subtree" taken from Git 2.8 is dropped into an even newer version
of Git 2.13, or an older version like Git 2.4 for that matter, is
it expected to work, given the promise of interface stability git
core gives you?), there is not much technical reason why it must
stay in core. Of course, your improvements may need to take
advantage of improvements on the core side and your new "git
subtree" may start to require at least Git 2.8, or you may even
send patches to the core side to extend and enhance the services
you use from the core side, but as long as that happens only
occasionally and the dependency does not require lock-step
upgrade, we can still call such an integration "loose" and moving
out will still be a viable possibility.
* If there are many existing users who expect their Git to come
with "git subtree", unbundling may inconvenience them unless we
work closely with Distros, from which most of these users get
their Git.
* If you expect the pace of improvement would be far faster than
the release schedule of git core (usually a cycle lasts for 8 to
12 weeks), moving out would give users a shorter turnaround for
getting new and improved "git subtree".
* It may even turn out that the users are a lot more tolerant for
instability (e.g. removal of rarely used features) in "git
subtree" than they require the git core proper to be stable, in
which case moving up (rather than moving out) to apply the same
stability requirement to "git subtree" as the rest of the system
would be undesirable.
* Moving up and staying in has a big social implication. It gives
the version that comes with git core an appearance of being
authoritative, even when other people fork the project.
- This discourages incompatible forks (e.g. when one such fork
finds the need to improve the "metadata" left by merge
operation and used by split, the resulting repository managed
by it may no longer usable by other variants of "git subtree",
and if there is one in-tree "authoritative" one that is
maintained, such a fork will not get wide adoption without
taking compatibility issues into account).
- On the other hand, if the "authoritative" one moves too slowly,
that may hinder progress. An exit by "moving out" to become
one of the projects that help people's Git-life would result in
two or more honestly competing forks of "git subtree", which
might give users a better end-result after a few years, even
though the users who happened to have picked the losing side
during these few years may end up having to rewrite the
history.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html