I don't think this needs an explicit exception. Its the same that we do for kernels (no longer supported upstream, bugfixes hard to backport, hardware enablement).

So unless we need to update llvm and thus have abi / api problems (in that case asking for an exception would be in order IMO) and need to update other packages it should be fine.

There no broken API/ABI

The fact that a depending package requires a rebuild indicates there was an ABI change.
Surely libxatracker.so.1 -> libxatracker.so.2 is an ABI change, isn't it?
I welcome the new mesa, but let's be clear about this.

Replying to [comment:2 michich]:

There no broken API/ABI

The fact that a depending package requires a rebuild indicates there was an ABI change.
Surely libxatracker.so.1 -> libxatracker.so.2 is an ABI change, isn't it?
I welcome the new mesa, but let's be clear about this.
whoops ;) IIRC there only xorg-x11-drv-vmware, which was rebuilt by Dave.

Replying to [comment:1 drago01]:

I don't think this needs an explicit exception. Its the same that we do for kernels (no longer supported upstream, bugfixes hard to backport, hardware enablement).

So unless we need to update llvm and thus have abi / api problems (in that case asking for an exception would be in order IMO) and need to update other packages it should be fine.
Could you update wiki page with this note ?

I could be wrong but I believe the kernel was granted an ongoing exception to the general update policy. So the kernel is not a good example to follow unless we are willing to generalize that in the policy.

(FWIW, I tend to agree with michich's view on this specific update).

Replying to [comment:7 toshio]:

I could be wrong but I believe the kernel was granted an ongoing exception to the general update policy. So the kernel is not a good example to follow unless we are willing to generalize that in the policy.

Well it is because it is pretty much the same / a similar case.

I'm going to miss the FESCo meeting. Voting here.

I don't want to establish a precedent here, but given the extraordinary nature of F20 (lengthened cycle due to Fedora.next efforts), I'm inclined to give a +1 to this mesa update.

FYI, the update including mesa-10.0.x was recently autokarma'd and is queue'd for stable updates:
https://admin.fedoraproject.org/updates/FEDORA-2014-3719

If fesco wants to have to grant an explicit exception here, you either need to do it quickly or someone ought to disable autokarma for the aforementioned update.

+1 to mesa update. I'm okay with it establishing a general precedent as well.

The precedent being: We don't require maintainers to backport fixes. Maintainers are allowed to update to newer versions to get fixes if they take precautions to fix dependent packages within Fedora for the update.

+1 here as well. It's already pushing to stable today, so the point is kind of moot. We should ask folks to not use autokarma on any update that is waiting for fesco approval on the updates policy.

I'm +1 in general, but as per the policy for critical path packages (which this is), it should have had 14 days in updates-testing. See http://fedoraproject.org/wiki/Updates_Policy#Updates_to_.27critical_path.27_packages

I don't think we should roll back the clock on this one, but we should either revisit the policy or enforce it in the future.

Replying to [comment:11 toshio]:

+1 to mesa update. I'm okay with it establishing a general precedent as well.

The precedent being: We don't require maintainers to backport fixes.

We already don't require that. (Well, we kind of do if the upstreams tend to break the ABI. That's putting the pain to those upstreams and packages and removing it from the users, which is the right decision IMHO.)

Maintainers are allowed to update to newer versions to get fixes if they take precautions to fix dependent packages within Fedora for the update.

I'm strongly against implying that it is OK to break ABI as long as in-distribution users are handled. This does nothing for third-party or user's personal applications, and the purpose of a general-purpose OS (as opposed to a limited appliance) is to run applications.

It seems that libxatracker is specifically intended for one user, so it would warrant an exception - but it ''is'' an exception in an ''exceptional'' case.

It's been pointed out that I misread the policy (missed that the previous point ends in OR), so my complaint shuold be disregarded. :)