[oi-dev] Release engineering // planing

[Alasdair Lumsden]

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 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>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> 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
> 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

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/771f249e/attachment-0005.html>