[oi-dev] Release engineering // planing

[hugo at myhomeemail.co.uk]

Strongly agree on all notes Alisdair has made.

Furthermore, if people are using OI in production, they should have their own
suitable testing procedures in place to avoid the majority of (if not all)
upsets.

Regards


> On 11 July 2013 at 17:53 Alasdair Lumsden <alasdairrr at gmail.com> wrote:
> 
>  Hi All,
> 
>  Back in the days of oi-build, we tried to have a process, and enforce
> quality, and it just resulted in super slow progress followed by near-death.
> Andrzej didn't contribute at all as he didn't like the bureaucracy, he just
> wants to hack-and-go.
> 
>  So after all that, I basically think Andrzej is completely right with his
> current approach - breaking things should be allowed. You can't make an
> omelette quickly and easily without breaking a few eggs.
> 
>  Hipster is an experimental development branch for making rapid progress. If
> you break something, you can fix it after, no big deal.
> 
>  I do think that /dev should get moved to /release, and /hipster should go to
> /dev. Not many know about hipster beyond the oi-dev list. It would show people
> in the outside world that progress is being made on OI.
> 
>  And on an unrelated note, someone motivated enough should do something
> about<http://www.openindiana.org> - it's ugly and out of date :-)
> 
>  Regards,
> 
>  Alasdair
> 
> 
> 
>  On Thu, Jul 11, 2013 at 3:19 PM, Ken Gunderson <kgunders at teamcool.net
> <mailto:kgunders at teamcool.net> > wrote:
>    > > 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
> >    > <mailto: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
> > 
> >    _______________________________________________
> >    oi-dev mailing list
> >    oi-dev at openindiana.org <mailto:oi-dev at openindiana.org>
> >    <http://openindiana.org/mailman/listinfo/oi-dev>
> >  > 
> 
> 
>  --
>  Alasdair Lumsden
> 
>  <http://www.everycity.co.uk>
> 
> 
>  EveryCity Managed Hosting
>  Studio 18 Bluelion Place
>  237 Long Lane, London, SE1 4PU
> 
>  general: 020 7183 2800
>  support: 020 7183 2801
>  email: al at everycity.co.uk <mailto:al at everycity.co.uk>
> 
>  Every City Limited
>  Registered in England and Wales, No. 5689474 Registered Office: Roper
>  Yard, Roper Road, Canterbury, CT2 7EX
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20130711/d48f347d/attachment-0005.html>