On Wed, Oct 24, 2012 at 9:30 AM, Greg Swift <gregsw...@gmail.com> wrote: > On Tue, Oct 23, 2012 at 10:43 AM, Kevin Fenzi <ke...@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 :) ) 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. > -greg > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list _______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
