On Wed, Jan 29, 2014 at 4:39 AM, Karanbir Singh mail-lists@karan.orgwrote:
On 01/29/2014 06:08 AM, Clint Savage wrote:
I don't think the intent here is to rebuild the rebuilt code. It is to rebuild the upstream source in a similar way to the CentOS process. It might mean the source is distributed differently than its current state, but it should still be distributed.
pointing to the redhat shipped faq: git.centos.org -> canonical source of public source release. There will be no ftp.redhat.com in the coming weeks/months; the first people will see source would be as a downstream of centos.
hence my question on why you want to work away from this process and limit yourself by design, rather than work within and for the process.
Yes, I realized this was going to change. My question is really where is the code for all of the packages going to live? I know that the processes at GoOSe depend currently on SRPMS, will those be going away? If so, how will these packages look? I'd love to help suggest how this might look, but to date, I've seen no discussion about it. Though I haven't read everything that has come by in the centos-devel list.
So you ask why work 'away' from this process. I don't think we want to be separate, we want to be heavily involved in discussions and improving CentOS as much as anything else.
The SIGs rely on a process managed by CentOS. Having that process reviewed and improved by an outside entity would seem like an ideal way to audit code, improve processes and be as open as possible. These things seem like benefits. I'm not sure why you would not want to have this in place.
vendorisation and commercialisation within silo's - isnt that what we are trying to get away from ? so why go down the route of encouraging it by creating the -arguabally- whacked idea that communities are not just people working towards a goal ? Johnny mentioned it in his post as well, using different words, but let me re-iterate that ; given that we all might want to work towards the same goal, why not be a part of that process. I still dont see any value in people spending time on a process that effectively aims to find syntax errors in bash scripts. hopefully, there wont be any - since those bash scripts contribute to the code that gets shipped out.
Look it at another, more tangiable way: why fork a test harness when the harness and payload are easily contributed into, open ended.
Forking is important. If I don't fork your code, you don't get contributions back from me. How else would you propose we do this?
Agreed. And I'm excited to see it. As I said to Jim above, we are excited to help in any way we can and would love to continue this discussion toward something that benefits both the CentOS community and ours.
Then step up, be a part of the process. help remove the US v/s THEM arguements. Surely being in a place where you can submit patches and fix issues > standing on the sidelines putting red cross's in the gutter column of git blames.
I acknowledge that I am widely trivialising the effort you propose, but I do so in order to highlight the fact that you dont need to do this as an outside entity or a SIG - just work with the scope of baseline content.
KB, I appreciate your candor and I look forward to being a part of the process. The value of this is having an entity that is not just part of CentOS, but also has an outsiders view. We are stepping up as you say, we want to help. We've suggested several areas where CentOS and other EL rebuild communities, including ours could work together within your SIG definition to make things better for all.
-- Karanbir Singh
Cheers,
herlo