<div dir="ltr">Hi All,<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div style>Hipster is an experimental development branch for making rapid progress. If you break something, you can fix it after, no big deal.</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>And on an unrelated note, someone motivated enough should do something about <a href="http://www.openindiana.org">www.openindiana.org</a> - it's ugly and out of date :-)</div><div style>
<br></div><div style>Regards,</div><div style><br></div><div style>Alasdair</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 11, 2013 at 3:19 PM, Ken Gunderson <span dir="ltr"><<a href="mailto:kgunders@teamcool.net" target="_blank">kgunders@teamcool.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At Thu, 11 Jul 2013 01:12:50 +0200,<br>
<div class="im">Adam Števko wrote:<br>
><br>
> Hi Erol,<br>
><br>
> On Jul 10, 2013, at 11:50 PM, Erol Zavidic <<a href="mailto:erolms@gmail.com">erolms@gmail.com</a>> wrote:<br>
><br>
>     Good evening folks,<br>
><br>
>     thanks for your feedbacks so far, here's the summary clustered in some way:<br>
><br>
>     1.0 - Release Engineering:<br>
>     1.1    - should not be bureaucratic, i.e. rather an internal agreement (Alex)<br>
><br>
> I support this type for now.<br>
><br>
>     1.2    - the process of pushing updates to /dev or /stable repos is undefined<br>
>     (Alex)<br>
><br>
>     1.3    - safeguarding /stable repo (Jon)<br>
>     1.4    - streamline code review and integration process LGTMs (Adam)<br>
>     1.5    - build of many desktop packages impossible due to missing Manifests<br>
>     (David)<br>
>     1.6    - creation of development, release and stable branches within hipster<br>
>     repository (Erol)<br>
<br>
</div>I don't code and been away from OI for a while visiting other<br>
interesting lands.  It's good to see OI getting some traction.  I have<br>
used platforms developed on the release, stable, and testing model for<br>
many years, e.g. FreeBSD.  It worked.  But I question whether this may<br>
have become rather outdated with the advancement of more modern, agile<br>
like models.  For example, on the desktop I have been using Archlinux,<br>
wh/uses a rolling release model, and it has been working out quite<br>
nicely.  This model eliminates the extra manpower required to maintain<br>
separate branches.  Of course not many that I know of are using Arch<br>
server side and I think a /stable branch may be beneficial and<br>
justifiable on OI.  OTOH, OI was intended as continuation of OS, so<br>
maybe desktop is it's niches, especially in light of SmartOS and<br>
OmniOS offerings for server side use.  What compelling features does<br>
OI offer to compete with these?  Hence, maybe best not to and focus on<br>
desktop niche.  Maybe not...<br>
<br>
In any case, I have been doing some "DevOps" Engineering as of late<br>
and moving more towards a rolling release model would facilitate<br>
"Continuous Delivery" <<a href="http://continuousdelivery.com/" target="_blank">http://continuousdelivery.com/</a>>.  Frequent<br>
smaller changes make breakages easier to track than "vetting" big<br>
releases and keep things fresher on the desktop.<br>
<br>
Just a few thoughts.  We now return you to your regularly scheduled<br>
programming...<br>
<br>
Peace-- Ken<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
oi-dev mailing list<br>
<a href="mailto:oi-dev@openindiana.org">oi-dev@openindiana.org</a><br>
<a href="http://openindiana.org/mailman/listinfo/oi-dev" target="_blank">http://openindiana.org/mailman/listinfo/oi-dev</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Alasdair Lumsden<br><br>
<a href="http://www.everycity.co.uk" target="_blank">http://www.everycity.co.uk</a><br><br>EveryCity Managed Hosting<br>Studio 18 Bluelion Place<br>237 Long Lane, London, SE1 4PU<br><br>general: 020 7183 2800<br>support: 020 7183 2801<br>
email: <a href="mailto:al@everycity.co.uk" target="_blank">al@everycity.co.uk</a><br><br>Every City Limited<br>Registered in England and Wales, No. 5689474 Registered Office: Roper<br>Yard, Roper Road, Canterbury, CT2 7EX
</div>