On Wed, Oct 24, 2012 at 11:51 AM, Michael Stahnke
<stahnma(a)puppetlabs.com> wrote:
On Wed, Oct 24, 2012 at 9:30 AM, Greg Swift
<gregswift(a)gmail.com> wrote:
> On Tue, Oct 23, 2012 at 10:43 AM, Kevin Fenzi <kevin(a)scrye.com> wrote:
>> ...snip...
>>> NEW ---> PENDING --> TESTING --> STABLE --> OBSOLETE
>>> \--UNSTABLE--/------------/
>>>
>>> With an UNSTABLE package also being able to push into STABLE if the
>>> STABLE package is no longer considered safe to run (that unsupported,
>>> or no available patch for security issue, or whatever.. would define a
>>> list)
>>>
>>> Or the UNSTABLE package would just live in UNSTABLE unless it gets
>>> sent to OBSOLETE.
>>
>> Right. If you allow crossing the unstable/stable streams here it
>> becomes very complicated.
>>
>> This is where the start of all the work is... make git repos understand
>> an unstable, make bodhi and mash and other compose tools understand it,
>> have some way to report bugs about it (how do you set it in bugzilla?).
>>
>> Lots of complicated questions and then lots of actual work. ;)
>>
>> Even if you don't allow them to cross (ie, it's a completely seperate
>> branch), it has still a bunch of work around the tools to get them
>> working with it. Also, there will be problems where 'stable' stuff gets
>> ignored or shoved down because people are more interested in the
>> unstable part, etc.
>
> Between thinking about it more, reading the RHEL/EPEL conflict post
> again, and this post I'm inclined to go with the separate branch path.
>
>> Personally, I don't have the time or desire to do all this work. If a
>> group of folks wanted to write up a complete plan here and offer to do
>> the work, I would be happy to provide feedback and get talked into
>> helping them out, but it would have to be a pretty good plan. :)
>
> I have some cycles to work on this, but i would much rather have help,
> especially people that have more experience in these tools than I.
> This falls into the 'i either do it privately to benefit
> myself/company, or try and make it work in EPEL to benefit others that
> have expressed the need' category. Personally, I prefer to work
> upstream on it, but unless others are gonna hop on board its going to
> be much easier in the short term for me to go the private route.
>
I think users of the EL ecosystem would really like a repo with
updated software etc, but if getting EPEL off the ground is any
indication, you'll have very low participation from a development and
infrastructure side, a *lot* of infrastructure needs. It took months
(possibly years) to even find broken deps in EPEL due to lack of
time/focus from the EPEL community, and that's a pretty simple task.
Also, people who change jobs etc who were at one time very able to
help out suddenly can have a lot less time. (Ask me how I know :) )
yea... i'm well aware of that pitfall.. i've suffered from it as well
If you could get 10-12 people willing to do the infrastructure work
(like a SIG etc) it might be viable setup. Outside of that private
repos (or even public but not on Fedora properties) might be the way
to go.
So.. just spent like 30m digging through the wiki and somehow did not
stumble across the 'how to start a sig' page. anyone got a pointer?