On Fri, Dec 5, 2014 at 6:58 PM, Michel Alexandre Salim <salimma@xxxxxxxxxxxxxxxxx> wrote: > On 12/05/2014 01:32 AM, M. Edward (Ed) Borasky wrote: >> As a user/re-mixer, I don't like it. I'm at the point now where I need >> a rolling release. I can live with a six-month or eight-month lag >> between desktop updates, but I can't live without regular updates to R >> and R packages, PostgreSQL/PostGIS, QGIS, the Python data science >> tools, etc. And I'm running the Developer Edition of Firefox, which >> updates almost every day. >> >> There's only one major distro now with a calendar-driven release >> cadence, and quite frankly I don't know how they do it. Everyone else >> is either rolling, try for calendar but don't ship if it's fatally >> broken (Fedora and openSUSE), or ship when it's solid and stable and >> supportable (Debian and RHEL). >> >> I'm probably going to run at least one of my machines on Rawhide after >> the F21 release, but I think the "sweet spot" is what openSUSE has >> done - a stable release with a nominal eight-month cycle and a rolling >> release (Tumbleweed) layered over that. I'd like Fedora to at least >> consider something similar. >> > > Minor version updates are allowed by the update policy, and packages > like Firefox are in effect on a rolling release anyway. I believe R is > also updated quite regularly. > > http://fedoraproject.org/wiki/Updates_Policy#All_other_updates > > Do we have the manpower for a Tumbleweed-style repo that is built > against the stable release as its core? Or perhaps the present upgrade > policy is sufficient, and the lack of updates Ed cite is already a > reflection of a lack of available manpower to update the packages he > mentioned (apart from PostgreSQL, where we wouldn't want to upgrade > mid-release). PostgreSQL is a good example - 9.4 is in the release candidate stage right now and will probably be declared stable within a month. If it doesn't at least make it into updates-testing before F22, I'll be adding 9.4 from the PostgreSQL project's RPM repos or building it from source. I need a major new feature - Binary indexable JSON storage. GDAL and QGIS are other examples; I ran for a couple of months building gdal 1.11.0 from source and installing QGIS from non-Fedora repos because I needed those features and they weren't in updates-testing. If the packages are at least in Rawhide, I suppose I can download them to a local repo and use them from there. > > Ed, could you perhaps cite specific R and Python tools where you find > the current version to be insufficiently up-to-date? I'm not a Python programmer and I don't currently use the Fedora RPMs for most R packages. I have to have all the package building infrastructure anyhow, so it's easier to build them from source. I can name two instances during the F21 release cycle where I needed newer packages than what was in the F21 branch. One was nikola 7.1.0, which is a Python package, and the other was nodejs-glob, which is an npm package. In both cases I had to go upstream to get them. I assume those will make it into updates before the F22 branch ;-). > > We could perhaps create a tracker for update requests, and provide a > Bugzilla template for it linked to from the package database and from > the Fedora homepage - that way we could prioritize what packages users > really want updated. That does seem like a good way to do it. Would that also have an impact on the automation / testing queues once the source RPMs were built by a human package maintainer? -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
