[oi-dev] Release engineering // planing

[alp at sfedu.ru]

Hello.
Just several thoughts.
1) I look at /hipster as on FreeBSD-current - there should be no 
specific  "RE", but rather internal settlement (e.g. if you know that 
your changes can break something notify all beforehand, ask feedback and 
see if anyone cares).

BTW, can someone look through 
https://github.com/pyhalov/oi-userland/compare/php54-modules ? :)

2) Another question is real RE - i.e. migrating some stuff to /dev (and 
possibly one day to /stable ...).
3) One more problem is packages which influence build in a specific way 
- e.g., requires other packages to be rebuilt. It would be nice to catch 
(using current dependencies machinery or introducing something like 
"BUILD_DEPENDS/INSTALL_DEPENDS" in userland building scripts).


Erol Zavidic писал 10.07.2013 05:24:
> 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