John Keeping <[email protected]> writes:
> And it is now probably too late for that to make Git 2.0,...
Anything with end-user visible changes in the core part that is not
a fix to a regression introduced between v1.9.0..master is too late
for the upcoming release. We are way past -rc1.
>> So I think these are the two options:
>>
>> 1) Include git-remote-hg/bzr to the core and distribute them by
>> default (as is the current intention)
>>
>> 2) Remove git-remote-hg/bzr entirely from the Git tree. And do the
>> same for other tools: git-p4, git-svn, git-cvs*. Given the huge
>> amount of people using Subversion, we might want to defer that one
>> for later, but eventually do it.
Isn't there a middle ground? The option 1.5 may be like this:
- Eject tools in contrib/ that would benefit the users better if
they were outside my tree. There are a few points to consider
when judging "benefit better if outside":
* Their release cycle requirements are better met outside my tree
(the "remote-hg depends not just on Git but Hg internal" issue
we have discussed).
* They are actively maintained. The overall Git maintainer would
merely be being a bottleneck than being a helpful editor with
respect to these tools if we keep them in my tree, and we
expect that the tool maintainer would do a much better job
without me.
- Keep tools that are not actively maintained but still used by the
users widely in my tree, but when their external dependencies
become baggage to Git as a whole, demote them to contrib/ and
stop installing them by default.
- I would not mind having install.contrib-frotz target in the
top-level Makefile for each of the remaining contrib/frotz
hierarchies for those users and distro packagers who know their
platform meets the dependency requirements.
> I'm not sure it needs to
> wait for a major Git release since most of the impact is on package
> maintainers and not end users.
Removal of features is a big deal, I would think, though.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
