cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <rohit.ya...@shapeblue.com>
Subject Re: rules for revolutionaries
Date Fri, 22 Aug 2014 21:31:25 GMT
Thanks for sharing Leo :)

On 22-Aug-2014, at 9:01 pm, Sebastien Goasguen <runseb@gmail.com> wrote:
>
> On Aug 22, 2014, at 5:21 AM, Leo Simons <LSimons@schubergphilis.com> wrote:
>
>> Hey folks!
>>
>> Open source means chaos.
>> Chaos is ok.
>> Community over code.
>> Consensus can and should be reached lazily.
>> Decisions should and will be made by the people who do the work.
>> Vetoes are a last resort.
>> Neither lack of consensus nor prevalence of vetoes can block progress.
>> Revolution is allowed, evolution is preferred.
>>
>> (…)
>>
>> If you were the release manager for cloudstack 4.5, and you decided to build the
release by exporting some branches to bitkeeper, doing lots of merge management in there,
and then exporting the result back out to subversion, building a release from that, and calling
a vote, no amount of process or rules could stop you.
>>
>> If you would get enough (3) binding votes, and more +1s than -1s, then that beast
you built would become cloudstack 4.5.
>>
>> Even if you weren't the nominated release manager, you could still do that. Even
if someone else _was_ nominated as release manager. Even if there’s a policy on confluence
clearly stating you should’ve done it.
>>
>> Note that it doesn’t even matter if you're not a committer. You just need the votes.
>>
>> This is, by-the-way, why active committers should want to become PMC members, to
get the binding votes aligned to who is doing the work. The ratio PMC member / committer in
this project scares me.
>>
>> (…)
>>
>> Some of the biggest releases at apache, like the 2.0 (or the 2.2) of the apache web
server, or the 4.0 (or 5.0, or 6.0) of apache tomcat, or the 2.0 of apache maven, were rather
contentiuous and rather revolutionary releases. In the linux ecosystem, ubuntu was a rather
revolutionary fork of debian. Funnily, centos is revolutionary because it _isn’t_ a fork
of RHEL. Chrome is in part a revolutionary fork of safari. HTML5 is a revolutionary fork of
HTML4, competing with XHTML. Git was a revolution against bitkeeper, which was a revolution
against centralized version control.
>>
>> Empirically, darwinistically, it has to be this way. We’re just not good enough
at software development yet to avoid revolution.
>>
>> At various points in the past, apache tried to have rules for revolutionaries, i.e.
>>   http://incubator.apache.org/learn/rules-for-revolutionaries.html
>
> good read for us all
>
>
>> to at the same time both sanction and limit the scope of revolutions. This can’t
work since, of course, revolutionaries don’t follow the rules.
>>
>> These kinds of revolutions hurt communities a lot though when they happen. So, social
pressure (not rule, not policy, just expectation from your peers) is that you do whatever
you possibly can to avoid them. I.e. you’re expected to build consensus. Are you doing everything
you can to build consensus? Good.
>>
>> What will always fail in the end is trying to block chaos, or block change, or block
the people who are doing the work from making the relevant decisions. It’s wasted energy.
>>
>> (…)
>>
>> If you’re an evolutionary, and you spot a potential revolution you don’t want,
the best strategy is to assimilate, to embrace and extend. Step up to do the work that gives
you the actual influence in how things get done. Interestingly, along the way, you’ll usually
pick up the most important bits that the revolution was about, anyway, surprising amounts
of real progress get made, and it’s a surprising amount of fun :-)
>>
>>
>> Happy hacking!
>>
>>
>> - Leo
>>
>

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

This email and any attachments to it may be confidential and are intended solely for the use
of the individual to whom it is addressed. Any views or opinions expressed are solely those
of the author and do not necessarily represent those of Shape Blue Ltd or related companies.
If you are not the intended recipient of this email, you must neither take any action based
upon its contents, nor copy or show it to anyone. Please contact the sender if you believe
you have received this email in error. Shape Blue Ltd is a company incorporated in England
& Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated
under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated
in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company
registered by The Republic of South Africa and is traded under license from Shape Blue Ltd.
ShapeBlue is a registered trademark.

Mime
View raw message