Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes:

> Isn't everyone involved much better solved if we come up with some plan
> to split these off from git.git? I.e. I think if if git-gui, gitk and
> gitweb were proposed for inclusion in-tree today I don't think we'd
> bite, and instead point to things like [1] or [2].

It is actually the other way around.  gitk and git-gui had active
maintainers and they (not Linus nor I) wanted to have their own
release schedule and versioning; they started as eparate projects.

The arrangement was pleasant to work with while the subsystem was
actively managed.  People can send patches to it just like to other
parts of the system (and the change rarely if ever needs to touch
both core and GUI at the same time---otherwise it would be
impractical to split them out as a separate projects), reviewers
would give comments on the list, and subsystem maintainers would
pick them up just like I pick up patches to the core part.  Then
from time to time, subsystem maintainers would give me a pull
request to complete the cycle.  I do "pull -Xsubtree=git-gui/".

It breaks down when subsystem maintainers go quiet.  Even if I were
to play a patch monkey backed by volunteer reviewers, I'd still have
to pretend that these are separate projects that are occasionally
subtree merged, with my own pull requests to subsystem repositories
that may never be responded, just in case the separate subsystem
projects will become active again.

If you split git-gui off, it would just die, unless somebody steps
up and takes it over.  And if somebody steps up and takes it over,
we can keep merging from their repositories without any problem.

Reply via email to