On Fri, 2011-07-01 at 11:26 -0700, ext Andy Ross wrote: > 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 have you looked at my proposal at http://wiki.meego.com/Release_Infrastructure/devroot i think it should tackle some of things you already mentioned -- Ramez Hanna <ramez.ha...@nokia.com>
_______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
