"Tick-tock" release cadence?

[M. Edward (Ed) Borasky]

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