<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 29, 2014 at 4:25 AM, Karanbir Singh <span dir="ltr"><<a href="mailto:kbsingh@centos.org" target="_blank">kbsingh@centos.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On 01/28/2014 09:46 PM, Clint Savage wrote:<br>
> With these goals in mind, we'd like to formally request an<br>
> Interoperability Special Interest Group within the CentOS community.<br>
> Please let us know how to further proceed.<br>
<br>
</div>Couple of comments here, consider the in abstract:<br>
<br>
1) everything you mentioned here, we already do and will only increase<br>
scope of<br></blockquote><div><br></div><div>Yep, and that is a good thing!<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2) with the actual instance metadata in the public ( and on github! ) -<br>
there is very little cross-checking needed, since the result of the<br>
scripts is what gets published anyway ( and git log will history for<br>
anyone who cares ).<br></blockquote><div> </div><div>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. <br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
3) given the intention and direction for some of the points, duplicating<br>
effort also means diluting the single tooling effort - then at that<br>
point why would you not want to just contribute ( as people, not as<br>
projects ) into the common pool anyway ? ( ie. whats the justification<br>
for Goose to exist ? )<br></blockquote><div><br></div><div>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.<br>
<br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
finally, not sure what makes this into a SIG, the content being<br>
addressed would be all in the public on git repos, so anyone can come<br>
along and 'help get better'.<br></blockquote><div><br></div><div>Very true. It just seems a formalized effort would be better than no effort. Don't you agree?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
- KB<br></blockquote><div><br></div><div>Cheers,<br><br></div><div>herlo<br><br>1 - <a href="https://github.com/network-box/uptrack/">https://github.com/network-box/uptrack/</a><br></div></div></div></div>