Moblin package futures ...
Hi guys, 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. That, of course requires a little hacking work for some conflicting packages; but other than that - the main barrier I see is procedural - where should the packages go, how do we get them into factory; and how can we bring to an absolute minimum the pain for everyone. The Moblin:Factory packages break down into several pieces. * Bits already in openSUSE:Factory A. Bits that are the same + no action required. B. Bits that are different + telepathy patches + some speed optimisations * Bits that are not (yet) C. sharable bits that are not * ccss, librest, nbtk, jana ... whatever ... + some of these may be picked up as GNOME deps in future. D. non-sharable - moblin specific bits * netbook-manager-netbook * moblin-panel-* * mutter / mutter-moblin + potentially fragile, and depend on mutter version GNOME's mutter version is different - urk. + I guess we need to hack these about E. base-O/S changes + we have quite a few here - from aaa_base to Of course, it would be possible to have Moblin:Factory to be the source for openSUSE:Factory for C. and D. - with some fun around the mutter situation (I suppose). 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. Please bear in mind that '_link's essentially don't work, so I would strongly prefer a solution that is not based on them. Of course, we want to get some of the performance wins into SP1 too. 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 ? ). Anyhow - I'd love some input here and/or unstructured thoughts for synthesis. If we can't come to some conclusion by mail - there might even have to be a (dreaded) phone meeting (you have been warned). Thanks, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot -- To unsubscribe, e-mail: opensuse-goblin+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-goblin+help@opensuse.org
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
(resending my reply to opensuse-goblin, it wasn't sent with the right address) Le mardi 12 janvier 2010, à 18:05 -0600, Federico Mena Quintero a écrit :
* Push everything that we can upstream, then to 11.2, and then to SLE, *in that order*.
I generally agree, except that you want to do s/11.2/Factory/ for openSUSE. It's really too late for 11.2, now. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-goblin+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-goblin+help@opensuse.org
Le mercredi 06 janvier 2010, à 17:23 +0000, Michael Meeks a écrit :
The Moblin:Factory packages break down into several pieces.
* Bits already in openSUSE:Factory A. Bits that are the same + no action required.
Yay, easy :-)
B. Bits that are different + telepathy patches
Patches? Any reason they are not committed upstream?
+ some speed optimisations
Hrm, if the optimizations are not accepted upstream, we can do a big "%if MOBLIN_BUILD" for those patches -- quite easy.
* Bits that are not (yet) C. sharable bits that are not * ccss, librest, nbtk, jana ... whatever ... + some of these may be picked up as GNOME deps in future.
Those ones are easy, and I expect they don't need much patches? I can just take them somewhere. The question is where (see below).
D. non-sharable - moblin specific bits * netbook-manager-netbook * moblin-panel-*
Well, we still want them -- so it's a bit like C, we just need to know where to put them.
* mutter / mutter-moblin + potentially fragile, and depend on mutter version GNOME's mutter version is different - urk. + I guess we need to hack these about
The simple solution would be to have a mutter-moblin package that conflicts with mutter, but that means it won't be possible to get gnome-shell and moblin installed at the same time...
E. base-O/S changes + we have quite a few here - from aaa_base to
(I don't think I can help there?)
Of course, it would be possible to have Moblin:Factory to be the source for openSUSE:Factory for C. and D. - with some fun around the mutter situation (I suppose).
I think Moblin:Factory makes sense if its primary target is Factory. This means people will be able to submit changes, update things, etc. that might break on 11.2 or SLE11. We'll try to avoid that, but it will happen. If Moblin:Factory cannot work this way, I suggest using another project. I don't think it should be GNOME:Factory, but we can use something like GNOME:Moblin, if we want (it will just be highly confusing ;-)). (Note that some packages that were originally in C might have made their way into factory via GNOME:Apps or GNOME:Factory)
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. Please bear in mind that '_link's essentially don't work, so I would strongly prefer a solution that is not based on them. Of course, we want to get some of the performance wins into SP1 too.
(would be interesting to evaluate the new branch mechanism that is available in OBS) [...]
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 ? ).
Needing to build against SLE11 is not a big big issue -- we do that all the time for old versions of openSUSE, and it's more or less like building against 11.1 (+ some new packages).
Anyhow - I'd love some input here and/or unstructured thoughts for synthesis. If we can't come to some conclusion by mail - there might even have to be a (dreaded) phone meeting (you have been warned).
I love phone meetings! I do my best to never talk, so that's cool with me ;-) FWIW, what is really difficult for me, as of today, is that if I want to start pushing some of the bits to Factory during the next free hour I have, I can't because I have no idea what the status of the packages is, and the fact that the current base is old means, to me, that I either choose to fork stuff or I don't even care to do the work because I'm unsure it'll be accepted in M:F (no idea what are the policies there; and this is related to the fact that the target of M:F is not Factory). Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-goblin+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-goblin+help@opensuse.org
participants (3)
-
Federico Mena Quintero
-
Michael Meeks
-
Vincent Untz