On Fri, Jul 1, 2011 at 11:26 AM, Andy Ross <[email protected]> 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.
you don't have to use spectacle. > + Patch collides with others: have to muck with ordering and respin. this is what devel projects are for: a sandbox where you're reasonably protected from changes in certain areas. all my devel projects build against MeeGo-1.2, Trunk, and Trunk:Testing. If Trunk and Trunk:Testing cause me to frown and spend too much time fixing up stuff, I just work against MeeGo-1.2 for a while. Or even MeeGo-1.1. > + Oops, forgot to update changes file (or just typo the date, builds > kick back if the dates aren't monotonic) irrelevant if you work in a devel project: You can violate all merge rules until you actually submit to Trunk:Testing. But at that point, you better fix your bad hack-n-slash packaging ;) > + Oops, built in a Trunk project branch when I should have branched > MeeGo:1.2:oss. see above. > + 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. Seems like a legitimate concern where OBS needs to be fixed. Please file a bugreport? > + 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... If you have a proper .changes file, you can leave this entirely empty. So, should not be an issue. > 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. Blame the kernel/Qt maintainer, not OBS? Performance is an issue, obviously, this probably needs to be a bugzilla. > 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. setting up OBS or osc? I just set up osc at home last week in 3 minutes on a totally unsupported distro (not even a .deb/.rpm distro) and I was able to checkin/build everything. Setting up OBS is something we have a team of people for to do this for projects. And, it's not easy, and we should see if we can improve it somehow. That does not warrant an OBS fork imo... Auke _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
