On Wed, Jan 29, 2014 at 4:39 AM, Karanbir Singh <mail-lists at karan.org>wrote: > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140129/34c02607/attachment-0007.html>