CentOS Interoperability SIG

[Clint Savage]

Hi all,

After lots of discussions and many edits, I think we've finally come to a good draft SIG proposal. I'd like to have a discussion over the next few days of anything anyone doesn't like. If there something to add, remove, reword, now is the time!

https://github.com/gooseproject/main/wiki/Interoperability-SIG

I'd like to submit this proposal to the CentOS community by Tuesday, January 28 at 12:00pm MST (UTC-7).

Please feel free to comment in reply to this thread.

Cheers,

herlo

[Derek Carter]

On 2014-01-25, 1658, Clint Savage wrote:
> Hi all,
>
> After lots of discussions and many edits, I think we've finally come to
> a good draft SIG proposal. I'd like to have a discussion over the next
> few days of anything anyone doesn't like. If there something to add,
> remove, reword, now is the time!
>
> https://github.com/gooseproject/main/wiki/Interoperability-SIG
>
> I'd like to submit this proposal to the CentOS community by Tuesday,
> January 28 at 12:00pm MST (UTC-7).
>

shipit!

--
Derek

--
Derek

[Ivan Makfinsky]

+1

[Nick Bebout]

+1

nb

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "GoOSe-Linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to goose-linux...@googlegroups.com.
To post to this group, send email to goose...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Clint Savage]

One of the major values of the EL rebuild ecosystem is the ability to interoperate, or the ability to fork from the upstream. This provides purpose in many ways, choice being the most heralded. Since the CentOS community has teamed up with Red Hat to allow for Special Interest Groups to join them, it seems that there might be a bit less of an ecosystem available. The goal of the Interoperability SIG is to ensure that the ability to fork and rebuild still exist.

Our communities already exist outside of the CentOS community purview. They are currently the GoOSe Project[1] and the Ascendos Project[2]. This shared community will serve as a "reference implementation", yet will still be operated and marketed as a product and community separate from CentOS. Consider it something of CentOS "embassy" of sorts.

It would seem that this SIG could be construed as contrary to the goals of the CentOS project. However, we believe there is value added to the CentOS project. We are interested in improving the CentOS community in at least a few ways.

* Providing feedback and collaboration on common issues. Including, but not limited to, reporting bugs, providing patches, discussing packaging techniques, rebuilding variants, QA, ISO building, etc.

* Collaboration on documentation of the rebuild process, rebranding of documentation, providing new documentation, etc.

* Build or maintain tools to ease rebranding of upstream packages as to ease adoption by companies who build upon and release software based on CentOS.

* Providing tools to help monitor statuses of builds, repositories, releases, etc. Whether they be part of the CentOS community or otherwise.

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.

Cheers,

Clint Savage

Lead Developer, GoOSe project

1 - http://gooseproject.org (#gooseproject on irc.freenode.net)

2 - http://ascendos.org (#ascendos on irc.freenode.net)

[Clint Savage]

On Wed, Jan 29, 2014 at 4:25 AM, Karanbir Singh <kbs...@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/