On Wed, May 6, 2009 at 1:53 AM, Vincent Untz <vu...@gnome.org> wrote: > Le mercredi 06 mai 2009, à 01:24 +0300, Felipe Contreras a écrit : >> On Wed, May 6, 2009 at 1:00 AM, Vincent Untz <vu...@gnome.org> wrote: >> > 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. > > Some distributions might have shipped those patches. The fact that they > are in the vcs made it easy to share with other distributions who might > have needed it. Even if there was no release with those changes.
Debian patches are debian patches, they control them, and they make debian releases. If GNOME decides to remove those commits the distributions will not loose their patches. > Or maybe the maintainer really intended to do a release and found out it > wasn't really needed in the end. That's a very unlikely situation, it make no sense that everybody suffers (having gazillions of branches) just because of that. If you really want to be safe you can create legacy (hidden) repos in the case someone might need those commits. They will not waste any space because git uses hard links when you clone locally. Then you can delete all the legacy branches in the public (visible) repos while still be confident no commit will be lost. > [...] > >> 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? > > I guess I'm lost here, since this seems to be another topic (or maybe > you're getting back to the original topic in the thread). Sure, > maintainers are free to push any branches they want. There's nothing wrong with adding gnome-major-minor branches on "independent" projects on the git.gnome.org repos. Maybe this would help. Let's say we have git.maemo.org where we have a GTK+ repo, we don't have any changes on top of that (hypothetical), but we want some branches to keep track of our releases, so we add a 'maemo-2.0' branch that essentially points to 'gnome-2-24'. Should GNOME care what branches are in git.maemo.org that are not in git.gnome.org? No. It's DSCM, the owner of the repo can do whatever they want, so GNOME can add any 'gnome-' branches they want to git.gnome.org because GNOME owns those repos. -- Felipe Contreras _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list