[CentOS-devel] Release file versioning, sunk costs and community involvement

Tue Jun 24 14:34:15 UTC 2014
R P Herrold <herrold at owlriver.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I have stayed still on the topic of release naming, as I had 
little new to offer.  TL;DR: my opinion is that Smooge 
probably has it right suggesting most recently a NEVR of:
	Name:	centos-release
	Epoch:	nil
	Version: 7.0_201407
	Release: 0.201407

And I see Johnny responding to a question about trust 
from 'Toracat', and "Ned Slider" [each long time community 
participants], suggest:

> I finally get the opportunity to actually work on the 
> project full time to make it better and somehow I am 
> purposely recommending something that would somehow sabotage 
> it? How does that make any sense at all?

While 'absence of evidence is not evidence of absence' of 
ulterior motives, I have the strong impression that 'behind 
the scenes', Johnny has been carrying the water and keeping 
the buildsystem running, as he has since the start of the 6 
series for CentOS.  

Part of that buildsystem is the ability to key off of a 
release file, which then cascades down into the 'dist' tag, 
and more.  He seems to be an honorable man. Indeed, so are 
they all, all honorable men, absent indicia to the contrary.

BUT notwithstanding the RHT takeover, their number is still 
few -- I see very few public external 'community' members 
commits.  About three outside people and that is it, in one 
sample

The three external non-source code branches which have 
activity at the centos 'git' site are:
	https://git.centos.org/tree/sig-cloud-instance!build-instance.git
	https://git.centos.org/tree/sig-core!bld-seven.git
	https://git.centos.org/tree/sig-core!livemedia.git

and they may be viewed without pulling the git contents at:
	https://git.centos.org/summary/sig-cloud-instance!build-instance.git
	https://git.centos.org/summary/sig-core!livemedia.git
	https://git.centos.org/summary/sig-cloud-instance!build-instance.git

I see overnight commits on:
 create mode 120000 mock/c7-updates-i386.cfg                              
 create mode 100644 mock/c7-updates-i686.cfg                              
 create mode 120000 mock/c7-updates-noarch.cfg                            
 create mode 100644 mock/c7-updates-x86_64.cfg    

=============

We have been told that the buildsystem runs off mock configs, 
and I have absolutely no reason to doubt it

If a person wants a centos release file of a given form OTHER 
than a Version of:
	Major.Minor.`date +%y%m`

My example above would be:
	Major.Minor_`date +%Y%m`

... it is easy enough to edit the driver sources file for 
'centos-release', and the corresponding mock config files via 
something like:

	find . -type f -a -exec sed -i \
	-e "@Major.Minor.`date +%y%m`@Major.Minor_`date +%Y%m`@g" {} \;

and submit a diff from the community

=============

Until then, there is a 'sunk cost' and the inertia of not 
touching running code [1].  Time for some community coders to 
step up and put meat on the bones of the words of alternative 
forms, or let it be

fwiw, I really dislike the use of '.' as the second 
separatorin Version, and simply changing to '_' and adopting a 
4 digit YYYY would go a LONG way to dis-ambiguate possible 
interpretations, and aid communication to PHB's who dont want 
to know all the 'inside baseball' bike-shedding, which that 
thread represents

Just some thoughts

- -- Russ herrold

ps: nice link, Lamar.  As a child in Montana, I was tasked 
with driving cows and their stupid heifers around the pasture 
and back to the barn, from time to time.  The heifers, like 
those in Hosea, were amazingly stupid but creative (they could 
slip outside of the fences).  I encountered once, and learned 
from that, to watch to avoid later contact with the 'presents' 
left by the cows in the fields

[1] http://www.lifehack.org/articles/communication/how-the-sunk-cost-fallacy-makes-you-act-stupid.html

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlOpjG0ACgkQMRh1QZtklkRxrQCgxujq72syLiU5GTBEVZ45TibO
7dcAniwvubq4L4X3sjy+e0I/msNDCRFU
=Lh5j
-----END PGP SIGNATURE-----