[oi-dev] Release engineering // planing

[David Höppner]

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