On 07/01/2011 10:59 AM, Kok, Auke-jan H wrote:
I think Ryan is spot on. Until you get out of the hack-n-slash phase, your main development model should just be git, and ignore downstream.
Yeah, but I'm with Shane on this. There's a big gap right now between "I have a sandbox build with a fix and a patch" and "I have a working package in OBS". And that gap is filled with traps, all of which involve round trips to a known-finicky web app: + Have to remember the spectacle syntax again. + Patch collides with others: have to muck with ordering and respin. + Oops, forgot to update changes file (or just typo the date, builds kick back if the dates aren't monotonic) + Oops, built in a Trunk project branch when I should have branched MeeGo:1.2:oss. + It's built, but won't install cleanly from the resulting repo because the OBS build numbers are lower than the real version (quick hack is to update a file a dozen times here), and it's something like qt or libmeegotouch with frightening interpackage dependencies. + Get everything ready, and just to annoy you OBS asks for a *third* commit message (one in the patch, one in the .changes file, and a third for the SR). Look up the bug number one last time... Add to that the fact that OBS projects are sometimes heavily patched, and there's no straightforward path to turn an OBS project into a buildable sandbox tree. The adaptation kernels and qt are really bad in this respect. You can't meaningfully work with upstream code at all for some things. And on top of it all, setting up OBS itself is really non-trivial. I think something like this tool would be very useful, honestly, though I think it's likely to be a ton of work to maintain. Andy _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
