On Wed, Jan 29, 2014 at 4:25 AM, Karanbir Singh <kbsingh@centos.org> wrote:
On 01/28/2014 09:46 PM, Clint Savage wrote:
> With these goals in mind, we'd like to formally request an
> Interoperability Special Interest Group within the CentOS community.
> Please let us know how to further proceed.

Couple of comments here, consider the in abstract:

1) everything you mentioned here, we already do and will only increase
scope of

Yep, and that is a good thing!
 
2) with the actual instance metadata in the public ( and on github! ) -
there is very little cross-checking needed, since the result of the
scripts is what gets published anyway ( and git log will history for
anyone who cares ).
 
This sounds very open and grand. To this end, what is the harm in allowing us to improve upon what you have? Seems like a SIG that audits processes and documents things along the way could be even more valuable.


3) given the intention and direction for some of the points, duplicating
effort also means diluting the single tooling effort - then at that
point why would you not want to just contribute ( as people, not as
projects ) into the common pool anyway ? ( ie. whats the justification
for Goose to exist ? )

Let me give an actual example. Mathiew Bridon (bochecha) wrote a really cool monitoring tool called uptrack[1]. This tool resides outside of the CentOS community. The GoOSe project started to use this tool recently to monitor build status. Additional features have already been discussed and I have an intention of digging in and adding a few more. In my mind, this project could be used across both projects. I'm not sure exactly how an existing tool, uptrack, koji, mock, etc. would be considered part of the CentOS project just because they are using the tools it provides. To that end, we aren't necessarily duplicating certain efforts in writing tools that would help many EL rebuild communities.

The value of a separate rebuild is not about duplicating effort. It's more about using and improving the tools in a separate environment. I have found that as a tool grows, it needs multiple contributors from different environments to become full featured, more secure, etc. Having separate communities contributing to CentOS in the form of a SIG seems like one way to homogenize the effort, removing some of these opportunities for improving tooling and the distribution itself.
 

finally, not sure what makes this into a SIG, the content being
addressed would be all in the public on git repos, so anyone can come
along and 'help get better'.

Very true. It just seems a formalized effort would be better than no effort. Don't you agree?
 

- KB

Cheers,

herlo

1 - https://github.com/network-box/uptrack/