[oi-dev] Stable and some processes going forward

[Bayard G. Bell]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20111016/817b6cce/attachment-0005.bin>