On Thu, May 7, 2009 at 12:52 AM, Les Harris <lhar...@gnome.org> wrote: > On Wed, May 6, 2009 at 2:14 PM, Felipe Contreras > <felipe.contre...@gmail.com> wrote: >> Would you fight to keep alive the branch Linus just found too crappy >> and just killed it? If a commit never made it to a release and >> probably never would, is it really that important? > > It seems to me whatever Linus decided to do for the kernel is > completely orthogonal to what we, the gnome project, decide to do.
Germán argued that the commits are kept for archaeological reasons and I just showed how the linux project managed to both keep historical commits and have a clean slate. How is that not relevant? >> I guess this is like the abortion debate. When is a commit really >> alive? Does commits feel pain when they are killed before being >> pushed? > > It's probably for the best to keep technical arguments based on > technical details and not conflate the issue with highly charged and > emotional topics. > > The consensus so far seems to be that losing commits is a non-starter. > It's not clear to me what benefit dropping these ossified branches > gives us. What is the problem you're trying to solve Felipe? I've already explained that having a gazillion of branches is not clear, it creates noise. Let's take a look at these from the GTK+ repo: themes: 11 years themes-2: 11 years rendering-demo: 4 years ps-mf: 10 years master-UNNAMED-BRANCH: 10 years kris-async-branch: 3 years hp-patches: 9 years havoc-patches: 9 years gtk-printing: 3 years gtk-pango: 9 years gtk-no-flicker: 9 years gtk-new-im: 9 years gtk-multihead: 7 years gtk-hp-patches: 9 years gdk-object-with-pango: 9 years gdk-object: 3 years federico-filename-entry: 3 years cancelation-changes: 3 years AUTO_DENATTIFYING: 3 years If you move them to a historic repo, what do you loose? -- Felipe Contreras _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
