On Sat, 2011-10-15 at 21:52 +0100, Jon Tibble wrote: > Hi all, > > We currently have a bit of a mess with lots of wants and issues > conflicting with the result that things just get held up. I'm going to > outline where I think we are, where we want to be and then propose > taking on a half way house so others can concentrate on getting us there. > > Current status... > We currently have oi_151a in /dev based on the old consolidations with > their variety of build systems all tied together after build with > distro-import that sorts it all out. > We then have oi-build based on the SFW replacement userland that is > currently just that plus a few added extras. Built packages from here > get pushed to /experimental. > Currently there are conflicts about a stable release because people want > to fix stuff but don't want to use the old build system so we're torn > between wanting to only patch one thing at a time and make sure stuff is > tested with wanting to do those fixes in a build system that is a > complete melting pot of large changes with very little test coverage. > > Where we want to be... > In the ideal OI world we just want the illumos and oi-build hg repos so > small fixes are easy to apply and large changes can be worked out in > testing repos with the same build framework as the repo they're being > tested to go in to. > Ideally something along the following lines (which I hope shouldn't > surprise anyone who's been in a dev meeting): > /stable - The destination where only releases and security/stability > fixes get pushed to. > /dev - This should take snapshots from /experimental and stabilise them > for a release to /stable. > /experimental - This is the melting pot with the latest and greatest > where the big collisions can be worked out if necessary. > If people want something between /stable and /dev for a release > candidate scenario that may make sense and has been discussed but I > don't remember us reaching a conclusion.
I'd like to rewind to the question about the place of experimental because I don't think we've got our heads around it. I'm not sure I've got my head around it, but each time I've tried to lay this out, we seem to end up talking about what results we want without fully disposing of the practical issues that have in fact cropped up. Here's how I'd summarise it: richlowe asked us not to deploy Mercurial 1.8.4, and we said we'd do that. Nevertheless, 1.8.4 is in experimental, and the arrangement at the moment is that developers working with oi-build must use experimental. It matters not that it hasn't been introduced to dev per se: the disruption happens as soon as it is introduced to experimental, where experimental the environment used to prepare further changes for submission to experimental. experimental is meant to allow people who want to contribute to have changes accepted immediately, but using it for development means that initial acceptance means developer acceptance. Changes that are disruptive to development aren't segregated because nothing's in place to decide what bits of experimental should be tagged together and form a coherent build. (With 151 we had that handed to us to a significant extent.) The way our trade-off looks is that we reduced the burden for acceptance by effectively shifting the burden of integrating it to the development community generally. Particularly if there are a significant number of disruptive changes pending, this can make it very hard for development to progress, but even if there's just one doozy, how would we deal? As it is, I think we're not managing to do so by working on an ad hoc basis. Please understand: I'll probably be happier to be convinced that these are not in fact the droids I'm looking for. Thanks in any case to Meths for writing all this up. Cheers, Bayard
signature.asc
Description: This is a digitally signed message part
_______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
