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. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc