On Wed, Oct 24, 2012 at 11:51 AM, Michael Stahnke <[email protected]> wrote: > On Wed, Oct 24, 2012 at 9:30 AM, Greg Swift <[email protected]> wrote: >> On Tue, Oct 23, 2012 at 10:43 AM, Kevin Fenzi <[email protected]> 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? _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
