Re: fast-forward only policy

[Elijah Newren <newren gmail com>]

Hi,

On Tue, May 5, 2009 at 4:24 PM, Felipe Contreras
<felipe contreras gmail com> wrote:
> On the other hand 'gnome-2-0' is not pointing to any release, there
> where commits after the last release. So my question here is: who
> would care about those commits? They were done 6 years ago and nobody
> made a tag that contains them. The arguments I've heard apply to the
> stable releases (GEDIT_2_0_5), if somebody wants to create a GNOME 2.0
> build, or make GEDIT_2_0_6 release, they'll probably go for the latest
> code that was actually released and used.

I disagree; I think they'd check out the branch and use it;
particularly since that has been the practice for a number of years
now.  But that's only one side of the issue, and the less interesting
one at that...

The reason these branches were created and kept was not merely because
subversion and cvs suck and can't reasonably delete old branches.  Due
to the various enterprise distributions, developers needed to continue
to apply patches and make other fixes to versions of the code that
were several years old and they were duplicating each others' work.
They had trouble discovering when others were doing similar backports
and where their work was.  So there was an effort to standardize old
branch names to make it easy to know where to put their fixes, and
where other developers could go to find them; these fixes were often
not straightforward backports given the divergence of the development
branch and these old versions.  (I believe it was started by an email
from Federico on desktop-devel-list, but it's been so many years that
my memory may be faulty there.) Yes, people decided that it was okay
for developers to commit their fixes without maintainer approval to
otherwise "unsupported" branches for this particular use.  Think what
you will of that solution, but if you delete these old branches you
will make finding and/or recording such fixes harder.  Those 6 patches
that are not part of any tag are evidence that the old system was
being used.  (I don't know if this is the optimal solution to the
problem, particularly given the better VCS available to us today, but
it was certainly low cost and made people happy.  I believe this email
thread is the first time in years anyone has expressed any issues with
that decision.)

Even in git.git there were maint-1.5.1, maint-1.5.4, maint-1.6.0, and
maint-1.6.1 branches, in addition to the standard pu, next, master,
and maint (check the log; you'll see the evidence these were there).
Since only Junio can push to git.git, he can create or delete branches
as he wants without affecting others; so he can (and did) delete these
branches once he knew they were no longer active.  But we have
multiple people accessing git.gnome.org, and others may be using these
old branches for years after most consider them to no longer be
'active'.  Since they were particularly there for people who were
_not_ the maintainer, the maintainer can't really know when they
aren't being used anymore.  (Maybe we could try to find out when a
particular version is no longer being used in *any* stable or
enterprise distribution?  I bet we could kill the 1.x branches, but
Solaris would probably cause us to keep all the 2.x ones around.)

Yes, I understand the desire to clean things up; it's nice to prune
stuff that's "not used" in git, especially since it is so easy to
recreate or even work without it.  However, these branches really do
have a reason and do have an important (though infrequent) use; so
unless you can come up with a convincing proposal for an alternate way
to handle these issues (and I may not be remembering all the issues
either), *and* can convince others that adopting a new mechanism and
trying to get it disseminated to everyone (which isn't easy due to
this being an infrequent use case and the fact of how few read
desktop-devel-list and even devel-announce-list) and show that it
should be less of a cost than keeping some branches around that appear
to be unused, then it's really unlikely that such a change will occur.

I think you could easily come up with such a proposal that I would not
have a problem with in my personal use (I don't like lots of branches
for the public repositories either); however, I'm not sure that others
are going to see changing a policy that will take time to communicate
to everyone is worth the cost of making things a little bit tidier for
you and me.  So I'm betting on a very uphill battle if you want to
pursue this; I certainly don't see the cost/benefit tradeoff as being
very encouraging and wouldn't put my time into it.

Anyway, I hope that at least provides some perspectives on why these
things exist and why you're seeing people oppose your proposal.


Elijah