Comments on: Upstream GNOME as a product http://blog.fishsoup.net/2007/09/27/upstream-gnome-as-a-product/ Owen Taylor on Coding, Food, etc. Sat, 14 Nov 2009 17:46:51 +0000 http://wordpress.com/ hourly 1 By: GNOME Summit, day 1 « fishsoup http://blog.fishsoup.net/2007/09/27/upstream-gnome-as-a-product/#comment-38 GNOME Summit, day 1 « fishsoup Sun, 07 Oct 2007 00:19:19 +0000 http://blog.fishsoup.net/2007/09/27/upstream-gnome-as-a-product/#comment-38 [...] fishsoup Owen Taylor on Coding, Food, etc. « Upstream GNOME as a product [...] [...] fishsoup Owen Taylor on Coding, Food, etc. « Upstream GNOME as a product [...]

]]> By: Emanuele Aina http://blog.fishsoup.net/2007/09/27/upstream-gnome-as-a-product/#comment-30 Emanuele Aina Mon, 01 Oct 2007 10:07:21 +0000 http://blog.fishsoup.net/2007/09/27/upstream-gnome-as-a-product/#comment-30 For someone that is implementing a feature that require more than six months and that needs to be stabilized before inclusion in the main branch, distributed SCMs are really handy as they make repeated merges from upstream really simple. When the feature branch is ready can be pulled in the main branch by the maintainer even without requiring commit access for the developer. A developer needs only to change jhbuild to point to his feature branches, merging upstream changes in those. This way a developer is effectively forking GNOME without letting its fork diverge from upstream. When he has finished he can show a working system without requiring any authorization and with the full history of his changes. The maintainers involved need only to review those changes when pulling from the developer's branches. It's not my intention to start a flame, though. ;) For someone that is implementing a feature that require more than six months and that needs to be stabilized before inclusion in the main branch, distributed SCMs are really handy as they make repeated merges from upstream really simple.

When the feature branch is ready can be pulled in the main branch by the maintainer even without requiring commit access for the developer.

A developer needs only to change jhbuild to point to his feature branches, merging upstream changes in those.

This way a developer is effectively forking GNOME without letting its fork diverge from upstream.

When he has finished he can show a working system without requiring any authorization and with the full history of his changes.

The maintainers involved need only to review those changes when pulling from the developer’s branches.

It’s not my intention to start a flame, though. ;)

]]> By: liberforce http://blog.fishsoup.net/2007/09/27/upstream-gnome-as-a-product/#comment-29 liberforce Mon, 01 Oct 2007 07:42:38 +0000 http://blog.fishsoup.net/2007/09/27/upstream-gnome-as-a-product/#comment-29 You should consider having some machines of the Build Brigade building GNOME ( http://build.gnome.org, or http://jhbuild.bxlug.be ) on several distros so other people can just download some binary tarballs for their distro, built on machines of the GNOME project. Compilation is a power consuming activity, and having too much people making this choice when it's not necessary is IMHO overkill. You should consider having some machines of the Build Brigade building GNOME ( http://build.gnome.org, or http://jhbuild.bxlug.be ) on several distros so other people can just download some binary tarballs for their distro, built on machines of the GNOME project.

Compilation is a power consuming activity, and having too much people making this choice when it’s not necessary is IMHO overkill.

]]> By: Elijah’s Blog » Blog Archive » Proposed passing of the baton http://blog.fishsoup.net/2007/09/27/upstream-gnome-as-a-product/#comment-26 Elijah’s Blog » Blog Archive » Proposed passing of the baton Sat, 29 Sep 2007 18:06:48 +0000 http://blog.fishsoup.net/2007/09/27/upstream-gnome-as-a-product/#comment-26 [...] [1] I particularly like and agree with Owen’s suggestion to create standard jhbuild configurations. [...] [...] [1] I particularly like and agree with Owen’s suggestion to create standard jhbuild configurations. [...]

]]> By: FelipeC http://blog.fishsoup.net/2007/09/27/upstream-gnome-as-a-product/#comment-25 FelipeC Fri, 28 Sep 2007 20:54:37 +0000 http://blog.fishsoup.net/2007/09/27/upstream-gnome-as-a-product/#comment-25 I agree completely. I'm a Fedora 7 user. GNOME 2.20 has been released and I want to try it but there are few options. My laptop is not that powerful so the compilation will take a lot of time, and I definitely don't want to compile stuff I already have. So yes, jhbuild should be smart enough to know what stuff is _really_ needed for the build. GNOME 2.20 probably won't get into Fedora 7, upgrades always have issues, so the recommended way for F7 users is to install Fedora 8 from scratch. BTW. easing the compilation process improves the chances of hooking new contributors. I agree completely.

I’m a Fedora 7 user. GNOME 2.20 has been released and I want to try it but there are few options. My laptop is not that powerful so the compilation will take a lot of time, and I definitely don’t want to compile stuff I already have. So yes, jhbuild should be smart enough to know what stuff is _really_ needed for the build.

GNOME 2.20 probably won’t get into Fedora 7, upgrades always have issues, so the recommended way for F7 users is to install Fedora 8 from scratch.

BTW. easing the compilation process improves the chances of hooking new contributors.

]]> By: troll http://blog.fishsoup.net/2007/09/27/upstream-gnome-as-a-product/#comment-24 troll Fri, 28 Sep 2007 20:19:33 +0000 http://blog.fishsoup.net/2007/09/27/upstream-gnome-as-a-product/#comment-24 If you cared of the product, you would - Decide what newer language support (C#, python, ..) and make it CORE feature, and get rid of the rest - Make a legacy sweep renewing the components that have got the least attention (ie. icon selector) - Form good strategic leadership context (not democracy) for taking a genuine direction with the development If you cared of the product, you would
- Decide what newer language support (C#, python, ..) and make it CORE feature, and get rid of the rest
- Make a legacy sweep renewing the components that have got the least attention (ie. icon selector)
- Form good strategic leadership context (not democracy) for taking a genuine direction with the development

]]>