[CentOS-devel] CentOS 7 and release numbering

Philip Mather

phil at philipmather.me.uk
Sat Jun 21 11:14:15 UTC 2014


Wading in late as usual. :^)

Message: 28
> Date: Fri, 20 Jun 2014 11:35:08 +0100
> From: Karanbir Singh <mail-lists at karan.org>
> Subject: Re: [CentOS-devel] CentOS 7 and release numbering
>
...
> 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.
>

Not really, I think the idea was communicated fine but the motivations and
the absolute technical requirements for deviating from upstream's format at
the Core level rather than at the SIG level were never nailed down? It's
because of the cloud images and the fact that a CVE fix isn't recorded into
an release string?

"
> 2) A clear example of what the datestamp tries to workaround is yesterdays
> docker updates ( and the AMI and GCE images etc ) that were done to CVE
fix
> openssl content. These are not marked as a point at all, just a
centos-6-x86_64-
> 20140609 ( and in most cases, the link that people hit is for
centos-6-x86_64,
> which points at the latest images ); this is becoming more of an issue as
the
> cloud side of things grows, even within CentOS we've seen a massive
increase in
> uptake on that side and I am sure everyone sees that.
"

...surely cloud images should be a product of the Cloud SIG and as to how
those final releases or images (in their specific scenario) are named is
entirely up to them? A SIG could eschew numbering all together in it's
final product and, as was suggested earlier, perhaps even go for a release
entitled CentOS: Constipated Chihuahua?

  People missing CVEs, other important updates or not bothering to update
at all and then expecting support/help is just par for the course. No
project such as a CentOS is out to educate people at such a fundamental
level, you just have to politely point them in the right direction and hope
they find the right page. We've all been there, seen that and "Stupid is as
Stupid does" at the end of the day.

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.


> How can we make it even more aparent as to what we are trying to do ?
>

Given the code changes are apparently trivial to less than trivial, this is
being done simply to obviate a direct link between RHEL 7.x and CentOS 7.x
by calling it CentOS 7.YYMM, hence allowing CentOS to do other things
without the baggage of being too closely coupled and the expectations that
would bring from some users?


> I will aim to deliver two sets of tree's today to buildlogs.centos.org,
> one that targets a 7.0 release tag and another one that does 7.1406,
> lets see if we can find, in using the 7.1406 metrics on what breaks and
> how. We can then work backwards to fix the issues, and move the
> conversation forward.
>

Might be able to do some testing with that next week.

-- 
Regards,
   Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140621/a5d8759e/attachment-0003.html>


More information about the CentOS-devel mailing list