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.
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.
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.