| 1 |
On Sun, 2014-01-26 at 16:35 -0500, Rich Freeman wrote: |
| 2 |
> On Sun, Jan 26, 2014 at 1:56 PM, Peter Stuge <peter@×××××.se> wrote: |
| 3 |
> > |
| 4 |
> > I don't think that's "completely optional" though, it sounds like a |
| 5 |
> > one-way function. If have ever stabilized a package once then must |
| 6 |
> > ensure a stable package forever. |
| 7 |
> > |
| 8 |
> > I think arbitrarily removing stable versions should also be an option, |
| 9 |
> > and I think package managers would be able to deal with that without |
| 10 |
> > much extra effort? |
| 11 |
> |
| 12 |
> Well, I think we certainly should be able to de-stabilize packages. |
| 13 |
> I've seen this happen in the past, especially when the need to not be |
| 14 |
> stable is inherent in the package itself (such as game clients that |
| 15 |
> need to be synchronized with servers - only one version will ever work |
| 16 |
> at any time buggy or not). |
| 17 |
> |
| 18 |
> Ideally this should really be the result of communication between the |
| 19 |
> maintainer and arch team. What we definitely don't want is a package |
| 20 |
> that gets stabilized, and then six months later the whole package is |
| 21 |
> back at ~arch, and then six months later there is a stable version |
| 22 |
> again, and so on. That just isn't, well, stable. |
| 23 |
> |
| 24 |
> However, if an arch team is feeling overwhelmed I'd strongly encourage |
| 25 |
> them to put out a bulletin telling maintainers to stop STABLEREQs for |
| 26 |
> non-system packages, or whatever other guidance they want to issue. |
| 27 |
> It has been pointed out that on these archs system packages often |
| 28 |
> don't work, so having those be stable at least lets them target |
| 29 |
> versions they want to fix up and lets users get a bootable system |
| 30 |
> without too much fuss. Falling back to a defensible position and all |
| 31 |
> that... |
| 32 |
> |
| 33 |
|
| 34 |
It's not necessarily the STABLEREQs stopping, some of the issues are (at |
| 35 |
least on some arches!) that some of the unstable software doesn't quite |
| 36 |
work properly anymore, and we are failing at communicating. And in |
| 37 |
those cases, we on the arch teams should definitely be pointing this |
| 38 |
out, and filing bugs so that the issues can be sorted. |
| 39 |
|
| 40 |
> But, nobody needs anybody's permission to do any of this. Ideally the |
| 41 |
> arch team should take the leadership to establish a policy on their |
| 42 |
> arch which is maintainable. If they don't do that, well, then |
| 43 |
> maintainers complain and we get threads like this one. The arch team |
| 44 |
> has the greatest interest in having the arch work - I'd strongly |
| 45 |
> support them in creating any policy for their arch that they can |
| 46 |
> follow-through on. |
| 47 |
> |
| 48 |
> Rich |
| 49 |
> |
Archives