On Wed, 2010-01-06 at 17:23 +0000, Michael Meeks wrote:
Soo - we have a lot of changes in Moblin:Factory, and the way they pile up rather concern me; in particular, I really want to see our work getting into openSUSE - it sucks to see Fedora beat us there.
I have been updating the packages in Moblin:Cleanup (which started as an all-links clone of Moblin:Factory) so that it is based on openSUSE:11.2 instead of various versions. The end result is that Moblin:Cleanup will be based upon a clean GNOME 2.28 and an updated low-level stack. The idea is to finish Moblin:Cleanup and then replace Moblin:Factory with its contents. Aaron is updating the Mono stack, I believe. I'm dealing with the GNOME packages. You can see this ongoing work here: http://en.opensuse.org/Moblin/Rebase_to_openSUSE_11.2 Scroll down to the section titled "Packages modified to link from openSUSE:11.2" to see what I have so far. That section contains detailed comments on which patches need to be put in openSUSE:11.2, which ones need to be sent upstream, and which ones still need rebasing because I didn't do them yet. You can assume that everything marked for inclusion in 11.2 should also go into SLE11 SP1. One recurring problem in Suse is this: 1. Someone makes a patch for SLE. 2. The patch gets released as an online update for SLE. 3. The patch author gets too busy and forgets to put the patch in openSUSE, or doesn't feel like going through the onerous "patchinfo" maintenance process. 4. The patch author may forget to send the patch upstream. The result is that SLE gets fixes regularly, but not all of those fixes get upstreamed or put into openSUSE. With Moblin, we have an additional layer of complication. The one cardinal rule to reduce duplicated work is: WORK AS CLOSE TO UPSTREAM AS POSSIBLE. In our context, this means: 1. If you are writing something for Moblin, write it for GNOME at large instead. Develop upstream. 2. Backport to openSUSE. 3. Backport to SLE if applicable. Doing it the other way around, like we have been doing so far, involves a lot of work to move the code "into the future". If you do it in the way I mentioned, your work from upstream will eventually reach our distro, no matter what. If we do things the other way around, there comes the time to bite the bullet (like right now) and forward-port and rebase everything. This is a huge pain in the ass, duplicated work, and patches *will* get lost. So, right now it is time to bite the bullet and do the following: * Annotate all the patches we have with the patch tags. * Build a tool that will tell us which patches are not tagged, which ones need to be upstreamed, etc. Vincent and Aaron have code for this. * Rebase everything. * Push everything that we can upstream, then to 11.2, and then to SLE, *in that order*.
Pieces in 'B' could be made as (some sort of?) build conditional patches in G:F (and G:Apps ?) - how would that work obs wise ? is that even a good idea.
I'm all for build conditionals. Having identical packages except for two or three patches that are carried around for all versions (the "enable gnome-settings-daemon in Moblin" patch comes to mind) is a waste of resources; build-time conditionals can handle this much more nicely, and we get fewer duplicated packages.
Please bear in mind that '_link's essentially don't work, so I would strongly prefer a solution that is not based on them.
We absolutely need git repositories based on the git.gnome.org ones, with the Moblin patches in them. This is easy to do.
For E. of course - there is some degree of teeth pulling required left and right, which there is little appetite for I suspect; most likely we should adopt a lifeboat model for the base-system: torpedo it all, and transfer whatever floats to upstart [ assuming there is no mental copyright assignment policy on it ].
One of the problems with slaving M:F to openSUSE - is that we have a different, more rapid development schedule, and of course we badly need to build against a SLE11 base as well as 11.2 - which may require some accommodation ( is this best achieved with .spec file conditionals ? ).
I think you need to reframe "slaving M:F to openSUSE" as "let's base M:F on a known-to-be-eventually-stable distro instead of reinventing our own distro" :) SLE is another beast. You *can* assume that it will be more stable than the version of openSUSE that it is based upon, but less stable than any newer version of openSUSE. SLE really needs to be the place where you backport things, not the place where you develop things and then rebase them forward. Federico -- To unsubscribe, e-mail: opensuse-goblin+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-goblin+help@opensuse.org