[oi-dev] Release engineering // planing

[Ken Gunderson]

At Thu, 11 Jul 2013 01:12:50 +0200,
Adam Števko wrote:
> 
> Hi Erol,
> 
> On Jul 10, 2013, at 11:50 PM, Erol Zavidic <erolms at gmail.com> wrote:
> 
>     Good evening folks,
>    
>     thanks for your feedbacks so far, here's the summary clustered in some way:
>    
>     1.0 - Release Engineering:
>     1.1    - should not be bureaucratic, i.e. rather an internal agreement (Alex)
> 
> I support this type for now.
> 
>     1.2    - the process of pushing updates to /dev or /stable repos is undefined
>     (Alex)
> 
>     1.3    - safeguarding /stable repo (Jon)
>     1.4    - streamline code review and integration process LGTMs (Adam)
>     1.5    - build of many desktop packages impossible due to missing Manifests
>     (David)
>     1.6    - creation of development, release and stable branches within hipster
>     repository (Erol)

I don't code and been away from OI for a while visiting other
interesting lands.  It's good to see OI getting some traction.  I have
used platforms developed on the release, stable, and testing model for
many years, e.g. FreeBSD.  It worked.  But I question whether this may
have become rather outdated with the advancement of more modern, agile
like models.  For example, on the desktop I have been using Archlinux,
wh/uses a rolling release model, and it has been working out quite
nicely.  This model eliminates the extra manpower required to maintain
separate branches.  Of course not many that I know of are using Arch
server side and I think a /stable branch may be beneficial and
justifiable on OI.  OTOH, OI was intended as continuation of OS, so
maybe desktop is it's niches, especially in light of SmartOS and
OmniOS offerings for server side use.  What compelling features does
OI offer to compete with these?  Hence, maybe best not to and focus on
desktop niche.  Maybe not...

In any case, I have been doing some "DevOps" Engineering as of late
and moving more towards a rolling release model would facilitate
"Continuous Delivery" <http://continuousdelivery.com/>.  Frequent
smaller changes make breakages easier to track than "vetting" big
releases and keep things fresher on the desktop.

Just a few thoughts.  We now return you to your regularly scheduled
programming...

Peace-- Ken