On Fri, Dec 5, 2014 at 6:58 PM, Michel Alexandre Salim
<salimma(a)fedoraproject.org> 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?