hi
One key aspect to the proper functioning of our SIGs is the ability for people to reach out in user, contributor and advisor roles ( each of those is key, in decreasing levels of impact ). However, the way we are setting up right now is still very much driven by the idea of packagers and rpms in repos.
For example, $project working off their github repo - delivering sources for a centos userbase should also have some level of influence over what goes in and out of the repos and how the repos are lined up ; just like any other SIG might. And components in a SIG should be able to impact components in other SIG resources.
A more specific example locally within the ecosystem might be that Cloud SIG should have some expectation around what the VirtSIG is doing and the StorageSIG is doing without needing to be co-authors on packages.
The same would be true for EPEL and other external repos that we might want to rope into a common pool at some point. Folks doing the consumption part of the components should have the ability to assert influence and impact on the providers backing the content.
I have some ideas on how we can make this happen, but nothing that is simple nor straightforward in a complete cycle. The biggest challenge is in mindset down the contributor path.
Maybe as a first step, we should consider having a common criteria on what is considered stable and what is considered releasable - without removing the ability for the SIG's and their hosted projects to still deliver a user story they want ( and ideally, in line with their ultimate upstream desires ).
Thoughts ?
On Wed, Feb 4, 2015 at 8:01 PM, Karanbir Singh mail-lists@karan.org wrote:
One key aspect to the proper functioning of our SIGs is the ability for people to reach out in user, contributor and advisor roles ( each of those is key, in decreasing levels of impact ). However, the way we are setting up right now is still very much driven by the idea of packagers and rpms in repos.
For example, $project working off their github repo - delivering sources for a centos userbase should also have some level of influence over what goes in and out of the repos and how the repos are lined up ; just like any other SIG might. And components in a SIG should be able to impact components in other SIG resources.
A more specific example locally within the ecosystem might be that Cloud SIG should have some expectation around what the VirtSIG is doing and the StorageSIG is doing without needing to be co-authors on packages.
The same would be true for EPEL and other external repos that we might want to rope into a common pool at some point. Folks doing the consumption part of the components should have the ability to assert influence and impact on the providers backing the content.
I have some ideas on how we can make this happen, but nothing that is simple nor straightforward in a complete cycle. The biggest challenge is in mindset down the contributor path.
Maybe as a first step, we should consider having a common criteria on what is considered stable and what is considered releasable - without removing the ability for the SIG's and their hosted projects to still deliver a user story they want ( and ideally, in line with their ultimate upstream desires ).
Hi,
With my user cap on I can say that the simpler it is for the user the better. So ideally there would be no need for any specific centos-release-sig rpms. I know this might be one step to far, but from a user perspective one centos-release-sig rpm that points to a coordinate stable release of all the output of the SIG's would be the perfect scenario. This should be the thing that we aim for.
I know that for some SIG's this would not be possible, so there will always be exceptions. So they have their own separate release file and all this is well documented. But we should still aim for the one big coordinated release. This of course requires that each SIG also a stable repo/release as an intermediate.
Kind regards, Tim
-
Karanbir Singh -
Tim Verhoeven