Re: fast-forward only policy



On Thu, May 7, 2009 at 6:16 AM, Elijah Newren <newren gmail com> wrote:
> Hi,
>
> On Wed, May 6, 2009 at 3:52 PM, Felipe Contreras
> <felipe contreras gmail com> wrote:
>> On Wed, May 6, 2009 at 6:44 AM, Elijah Newren <newren gmail com> wrote:
>>> 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...
>>
>> *sigh*
>>
>> Do this command:
>> $git checkout GEDIT_2_0_5
>>
>> Then do 'git branch'. What do you see? "(no branch)" Of course,
>> completely unintuitive, how contributors are expected to create a
>> 2.0.6 release under such hard conditions!
>>
>> Well, now do this command:
>> $git checkout origin/gnome-2-0
>>
>> What does 'git branch' show this time? "(no branch)" Ah, much better!
>> Now contributors will be on their element.
>>
>> Creating a local branch is a step that you need to do on both cases,
>> there's no difference whatsoever.
>
> That's kind of orthogonal to the point I was making and responding to.
>  I was responding to your two comments, "who would care about those
> commits" and "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."  Using the GEDIT_2_0_5 tag vs. the
> origin/gnome-2-0 branch give you different answers, since the branch
> may have advanced past the tag; so there's a decision to be made.  You
> have consistently claimed that those commits on the branch were
> useless and no one would even look at them, and I was pointing out
> historical precedent that was in conflict with this assumption of
> yours.

Ok I thought when you said "that has been the practice for a number of
years now" you were trying to argue against checking out tags on the
basis of unfamiliarity. If you agree that checking out a tag or a
branch is exactly the same on terms of difficulty then we are on the
same page.

Such branches were distributions just push the stuff sounds a lot like
the 'pu' branch in git. The fact that they are proposed updates
doesn't mean they'll get in. Someone would need to make a review of
the patches before making the release and drop the ones not
acceptable.

I don't see how GNOME people can be comfortable making a release out
of patches nobody has reviewed, but that's for another thread.

>> I express concern because when you use git properly branches are a
>> central part of development (unlike other SCMs) therefore you *see*
>> these branches all the time, which is annoying.
>
> I agree.
>
>> I understand the need for such branches like 'gnome-2-20'. It's
>> unlikely, but some one might make a release out of that. But
>> 'gnome-2-0'?
>
> Maybe I missed your switch, but I thought you had been advocating
> 'master' and 'devel' and getting rid of 'gnome-2-x' branches until
> today.  So I was responding to that.

I'm still advocating 'master' and 'stable', but also gnome-2.x.y (on
*all* the projects). If the branch is active I say it should stay, if
it's not, I say it should go.

To be more clear, I think bot the gedit and gnome repos should have
gnome-2.26 branches, but not gedit-1.4 or gtk-2.16.

> I agree it'd be nice to move known-to-be-unused branches to some
> archival or legacy area (refs/archive/*, refs/legacy/*?).  You just
> have to be reasonably certain they are really unused (no enterprise
> distro could possibly be using them anymore, etc.).  I'm guessing
> there's very few gnome-2-x branches that are ready for archiving by
> now.

Perhaps it's true that gnome-2.x branches are still not ready to be
archived, but there are many other branches.

>> Do you seriously think because git.git is maintained by Junio nobody
>> else has a clone of that repo? Of course not! Every git developer had
>> a clone, and they all saw the maint branches. Some might have have
>> work on top of those branches.
>>
>> Why didn't the world fell to pieces when Junio removed those branches?
>> git is *distributed* if you have local main-1.6.0 branch with 4
>> commits and Junio removes the branch what happens? Nothing, you only
>> see that "origin/main-1.6.0" was removed, big deal. Your local
>> main-1.6.0 remains intact.
>
> I must have done a really poor job communicating; sorry about that.
> You had been advocating only having 'master' and 'stable' branches.  I
> was pointing out that even git.git went further than that and had the
> equivalent of stable-x.y branches, and that I thought we would need
> those too.  I figured you'd say, "yes, but they have since been
> deleted in git.git", and so I proceeded to point out why I think gnome
> is different and would need to keep several of those stable-x.y
> branches around for a long time and not delete them.

I'm advocating branches that are actually used: active, moving.

The fact that Junio is the only maintainer of git makes no difference
whatsoever. The difference is your historical maintenance policy since
apparently dropping certain branches will affect some people.

>> Yes, but what about branches like CORBA_ENABLED, GEDIT_VIEW, GNOME_MDI.
>
> Oh, I'm a big fan of archiving old branches like these; that sounds
> great.  I just think the gnome-2-x branches will need to be around
> longer (e.g. rhel4 is still supported and ships with gnome 2.8), but
> it sounds like you're now in agreement with that.

The fact that rhel4 is shipping gnome 2.8 doesn't necessarily mean
they use the gnome-2-8 branch. But let's suppose they do, then yes,
gnome-2-8 branch should be kept.

But 1.x branches can probably be dropped, and a simple announcement
would do: we are going to drop 1.x branches, if you are still using
these branches, please shout.

> I hope this email is a bit clearer than my last; sorry about that.

Yes, thanks.

-- 
Felipe Contreras


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]