[CentOS-devel] CentOS 7 and release numbering

Fri Jun 20 12:34:27 UTC 2014
Ned Slider <ned at unixmail.co.uk>

On 20/06/14 11:35, Karanbir Singh wrote:
> Hi,
>
> On 06/18/2014 06:02 PM, Akemi Yagi wrote:
>> With the release of CentOS 7 just around the corner, have the board
>> members made a decision?
>
> No we havent, its something we've been iterating over but there is no
> decision made at this point.
>
>> We have seen an overwhelming number of responses from the community
>> members. Many of them are long time contributors who do not mind
>> "having late-night
>> coffee-fueled work sessions after the family's gone to bed".
>>
>> Now the world is watching (between the FIFA games) how the board would
>> handle the situation in which their idea/plan does not get support
>> from the community.
>
> So, personally - I think the community feedback was great, how badly we
> communcated the idea was apareny and clear for everyone to see. And I
> personally feel that a large chunk of the response was down to fear of
> change in areas that we had never even imaged were going to change.
>
> I'm also assuming that my last email to this thread cleared all the
> technical issues that people had brought up, if there are still some
> outstanding now is a great time for people to raise those.
>

No, not really. I've yet to see any technical issue described that this 
proposed change would fix, that couldn't be fixed just as easily outside 
of the release numbering name space.

> So what it really boils down to is communication, and not technical
> reasons as to why there is resistance to this change. And if we are able
> to find a clear / clean way to communicate the relationship - something
> that the community at large agree's to, then we have a plan going forward.
>

Well yes, it is a communication issue really. The board expressed a 
desire to change the release numbering system and the community 
categorically rejected that proposal. The communication issue seems to 
be that the board still aren't listening to the community but continue 
trying to persuade the community that this is a good idea.

> I seem to be saying this a lot, but getting better at what we do should
> never really be optional - and I definitely feel that the numbering
> change allows us to do just that. We just need to find a way to to
> communicate and overcome the emotional resitance to change. CentOS Linux
> is going to always retain RHEL mapping for 1:1 rebuild, as a best effort
> - and now more open and more visible than before. Now, reparse the
> thread with that statement in mind and you will find that the biggest
> resistance goes away completely.
>

Ford make cars, not push bikes. Ford decide it would be a good idea to 
make slimmer thinner cars for narrower streets despite the fact that 
their core market has nice wide roads. Then ford decide to make a 3 
wheeled car, as the forth wheel really is unnecessary and thus just 
wasteful. In the interests of environmental improvements Ford decide it 
would be good to do away with the engine, as it's only a source of 
pollution and not environmentally friendly. Finally Ford decide that 
losing the third wheel will make the vehicle lighter and easier to 
peddle. Ford now make bicycles. I now drive a German car because all I 
really wanted was a car, not a bicycle.

Trust is something you have to earn, over time. Once the community has 
seen, over time, that there is no intention of changing the Core disto 
then you will have earned that trust. Coming out of the gates in the 
first few months with proposals to change such fundamentally important 
aspects of a distro's identity as the release numbering scheme, 
especially when it so directly corresponds to the upstream numbering 
does nothing to establish / earn trust. Stating nothing is going to 
change whilst changing fundamentally important things the community has 
strongly rejected breaks what little trust you have.

So I guess at this point the community, having expressed it's opinion, 
is waiting to see what decision the board makes and will judge accordingly.