On 09/06/14 18:21, Jim Perrin wrote: > > > On 06/09/2014 10:43 AM, Ned Slider wrote: > >> >> It's nice that the board has a vision Jim, but what can grow can also >> shrink too. > > Indeed. In some areas, we already are. That's what we want to turn > around. This is the fundamental reason why we can't simply rest and keep > doing what we've been doing. Even if we're flawless in the core mission, > we'd still be ignoring emerging areas where we must grow to survive. > > > >> If we recall, it wasn't that long ago that the very continued existence >> / viability of CentOS was in question. Releases were delayed, security >> updates were slow to be released, bugs went unanswered. If community >> members questioned or asked when releases / security updates might be >> expected it was deemed as criticism and shot down in flames. > > Yep. we lost a fair number of both users and contributors. > > >> To the Project's immense credit, you guys have worked extremely hard to >> turn around that situation to the point where things now operate very >> smoothly and we almost expect updates to flow right out of the pipe >> within hours of an upstream release. To that end, the Project's future >> looks more stable (although I still know admins who were so concerned >> they switched to SL and have no intention of coming back). > > We burned bridges both on the way down, and on the way back up. This is > 100% an accurate statement. > > >> But I think there still exists a perception of mistrust / suspicion >> within the community. I think there is concern that Red Hat might wish >> to dilute the notion that CentOS == RHEL - branding. Altering / changing >> something perceptually fundamental as the release numbering simply >> reinforces this notion at a time when many users are looking for the >> board to give assurances and build trust. > > > In my view it's three separate perceptions that we have to fight. > 1. Sins of the past. We historically haven't been great at working > publicly or with community input, as you mentioned in the beginning. > > - In my eyes this amounts to broken trust, and it's difficult to fix. > This why we stood up seven.centos, and why we've tried to be as public > as possible about what we're doing around the 7 build. It's why we've > started holding our meetings in #centos-devel on irc as much as > possible. We simply won't make everyone happy, but we can certainly be > more transparent and open about how we operate. > > 2. That RH will try to force a change on us now that a significant chunk > of the board is being paid by RH. > > For the sake of argument, lets just assume the worst about RH. Bought > and paid for, we do their bidding and neuter CentOS. All that does is > ruin RH's reputation. Users move to SL or another rebuild (if they don't > jump to something else entirely) which refuses to collaborate now. > > Reality: RH wants us to be more open. RH wants us to engage more with > the community-at-large. They've given us a nice set of hardware upon > which to create a community build system so that we can do these things > without worrying that the donated machine we plopped down as the > koji-hub won't up and vanish one night when the donor reclaims it. We've > simply spotted something that will likely cause us issues as we grow, > and we want the community to help us shape how we resolve it ahead of > time so we're not stuck later. > > > 3. That we're *just* a downstream. > > Again, historical perceptions that haven't been entirely accurate. We've > been doing some of our own thing for years, with limited resources and > limited success. The centosplus kernel, our own updated php versions or > postfix-with-mysql packages, Xen4CentOS, etc. > > With dedicated time and more available resources, we're able to explore > this further (and hopefully better). We know there are integrators using > centos as a platform. We're trying to connect with them, to see if > there's value in collaboration. > > This work may or may not go back to RH, but that doesn't matter if it > helps our community. If our users want it and are willing to help make > it happen then that's what counts. > >> Maybe the board isn't feeling this? Maybe the board needs to slow down a >> little, listen to it's user base and earn it's trust? Maybe the board >> will just do as it pleases anyway? > > We are feeling it, and we are listening, but our views may not always > align. In some cases, our users are looking at their own needs, and not > at the larger distro picture. > > In other cases, we're only hearing the ones who take the time to talk to > us. So if there's a very vocal 10%... that may or may not line up with > the other 90% who remain silent wondering wtf we're thinking. > > You're correct though. We do need to continue to earn and maintain the > community's trust. It may be coming from a .mil mentality, but my > thinking has always been to earn it by action. I've said before that we > need to SHOW the community the things we've been talking about since the > RH announcement so that it's more than just words. But you bring up a > valid point in that we need to listen as well. > It's difficult to argue with you when you state your case that well, so lets move forward :-) > > To that end, help us discuss an appropriate solution for this. > > To do that I'm going to need a better understanding of the technical problem you are trying to solve. Can you spell it out for me in terms I can understand, maybe with hypothetical examples of what you envisage, because TBH I read the proposal and didn't see anything there that I felt warranted making such a perceptually important (at least to me) decision to completely change the long-established product numbering. Perhaps I can quote the original proposal and reply inline: "As we approach the release of CentOS 7, the CentOS project board has been discussing making a change to the way that we name individual CentOS Linux releases. We've always just adopted the X.y numbering, but it's clear to us that as we build up the SIG efforts, we need to find a way to allow SIGs producing variants the ability to stay in sync with their own upstream timelines, while ensuring that it's always possible to track back to the release of CentOS Linux they built or deviated from." Presumably they would always build or deviate from the latest release plus updates, as that's always going to be the only thing that is ever supported. Looking at the build dates will tell you exactly when it was built. A release date on the website/wiki next to the download link works for that. "We've been discussing a new versioning scheme in which we'd keep the major version number from upstream, and append a Year/Month value reflecting when the corresponding RHEL (or interim CentOS) release shipped. So, if RHEL 7 came out this July, the version name would be CentOS 7.1407. We also feel this better reflects to users the age of the install." Sounds like change for change sake. I don't see the technical problem you're trying to solve nor how this would solve it. "A change like this would allow CentOS to continue to deliver the core distribution (a Red Hat Enterprise Linux rebuild) while allowing ourselves the flexibility to roll in additional enhancements, such as optional repos and configuration choices included in our installer, with the goal of growing our commnuity base by delivering value to users and promoting the work of SIGs." How does changing the version specifically permit or prohibit any of this. You can roll in all of the above changes regardless of whether you call it CentOS 7.0 or CentOS 7.1407. It's just a number, albeit a very significant one. "Finally, a versioning scheme such as this would allow us to version and track builds that have in the past struggled in the x.y regime (eg. cloud images, updated at point in time against security vulns or to incorporate vendor environment changes)." Finally I see the first hint of a technical issue that might actually require a solution, but I still don't see it needing such a perceptually important change as to altering the release numbering. Could you not simply introduce some new virtual package "centos-version-snapshot-7.1407-1.el7" with whatever other virtual provides you may require that you bump each time you rebuild to achieve whatever it is you want to achieve? Heck, you could call it "centos-version-snapshot-7.140701-1.el7" and auto-rebuild it every day if you want so you really have an accurate point in time for any deviants.