[oi-dev] Release engineering // planing

[Jonathan Adams]

While not a contributor of code atm :(, I suggested something a system when
OI started, which was sort of agreed to by some people at the time ...

1) stable repository, guarded rigorously by people who do not allow
anything in unless it's been signed and sealed as core and stable,
seriously if this was surrounded by the river styx and you had to pay with
your soul to cross, that'd be sensible.

2) dev/apps repository where apps that are considered not core, and mostly
stable go, and changes to core that need testing before going stable.

3) bleeding edge dev repository where apps and code that are basically
considered volatile, latest releases and all core code changes go, for
those who are happy with a suck-it-and-see approach.

this would allow risk-averse server admin to pick "stable", less
risk-averse server admin (or risk-averse laptop/desktop users) to pick
"dev", and those who like sky-diving on the way to work to pick
"unstable"/"bleeding edge" ...

I would imagine /hipster to be in the latter, and the current /dev to be in
"dev", but then, I'm an outsider.

Jon




On 10 July 2013 10:34, David Höppner <0xffea at gmail.com> wrote:

> Hi,
>
> I can speak only for myself, but I think its too early to try this. In
> my view hipster is currently
> only a developer effort. Too many core packages (automake, libtool,
> glib) still need to be updated
> to build some newer software. Even that ruby 1.8.7 update is End of
> Life now. Further many packages (desktop)
> can't be rebuild, because we have no Manifests in hipster for them yet.
>
> We should discuss the general direction of hipster (desktop,
> core package versions and updated (to build illumos)), but I think
> there are too many open problems
> to impose release quality at this stage.
>
> -- David
>
> On 10 July 2013 03:24, Erol Zavidic <erolms at gmail.com> wrote:
> > Folks,
> >
> > I just want to notice a thing or two from my side that might be relevant
> for the OI (hipster).
> >
> > What I've seen and consider really important is to implement a kind of
> release engineering. And here I do not want some complicated process with
> many approvals and stuff - rather a sleek and streamlined (hipster) release
> management.
> >
> > I've seen packages breaking builds because of incompatible versions
> (e.g. libmemcached bump made myself incompatible with php5.4, or ruby
> version breaking other stuff...).
> >
> > Is it feasible to organise a non-bureaucratic release management setting
> the priorities which packages should get updated first and then possibly
> check for defects produced by it?
> >
> > Just a thought - and willing to help with it. Let me know your thoughts.
> >
> > Cheers, Erol
> > _______________________________________________
> > oi-dev mailing list
> > oi-dev at openindiana.org
> > http://openindiana.org/mailman/listinfo/oi-dev
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20130710/09068781/attachment-0005.html>