Re: fast-forward only policy

[Felipe Contreras <felipe contreras gmail com>]

On Wed, May 6, 2009 at 1:00 AM, Vincent Untz <vuntz gnome org> wrote:
> Le mercredi 06 mai 2009, à 00:48 +0300, Felipe Contreras a écrit :
>> On Tue, May 5, 2009 at 11:29 PM, Robin Sonefors <ozamosi flukkost nu> wrote:
>> > On tis, 2009-05-05 at 23:10 +0300, Felipe Contreras wrote:
>> >>
>> >> Imagine someone who has been on a GNOME hiatus or is a new comer. What
>> >> would be easier to understand? '1-2' or 'stable'?
>> >
>> > If I want the sources for the gedit in Gnome 2.26, cloning gedit's
>> > repository and checking out the branch 'gnome-2-26' sounds like an
>> > easy-to-remember way to do it. If I want the sources for gedit in Gnome
>> > 2.24, I can probably deduce that 'gnome-2-24' sounds like a branch to
>> > look for.
>>
>> Right, 'gnome-2-24' does actually point to the latest release (2.24.3)
>
> No. It points to the latest code in the 2.24 branch. There might be code
> after the release. It's a branch, it's not a tag. So, maybe I don't
> understand what you're saying because I misunderstand git?

I'm talking about that specific branch in that specific repo:
gnome-2-24 -> GEDIT_2_24_3 -> 8372af3

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.

>> which is good and I think all the GNOME projects should have such
>> branches (perhaps 'gnome-2.24' instead) so it's easier to manually
>> checkout the sources you want. But that's not in the guidelines, and
>> it seems not even GTK+ is following that. I believe right now in order
>> to find out all the latest stable packages for a certain GNOME release
>> you need to use something like jhbuild.
>
> Again, it's in the guidelines. Not for GTK+ since GTK+ is an independent
> project. But it is for GNOME modules. See
> http://live.gnome.org/MaintainersCorner#branches

Ok, now I looked more closely and yeah, it's in that guideline, but
not on this one:
http://live.gnome.org/Git/Developers#head-48e4d2e1d946ed26fa5401c9b9a0c7f5152c0161

Now, let's suppose GTK+ is a truly independent project, and their
independent repo (non-gnome) is in git.gtk.org. Just like you can
create arbitrary branches in your local repo, you can do the same in
git.gnome.org.

So what I'm trying to say is: even if GTK+ is an independent project,
GNOME maintainers can still add their own branches in their own repos.
After all you are prefixing the branches with 'gnome-' so it should
not conflict with GTK+ branches. Right?

-- 
Felipe Contreras