On Sat, 14 Jan 2012 09:12:06 +0100, KK (Kevin) wrote: > > Even in the scenario of project-wide write-access to > > packages, there must be someone to decide when to perform an upgrade. > > Not if we make it a project-wide policy to upgrade whenever there isn't a > strong reason not to (as I've been proposing all this time) and encourage > provenpackagers (or even any packagers) to just upgrade the packages (unless > the maintainer explicitly left a note in the specfile why it shouldn't be > upgraded and the reason given actually makes sense), instead of discouraging > it as we do now. Wow, that's a bit much for wrapping it into one sentence only! There is _a package_ with _a maintainer_. Is it an arbitrary maintainer or one assigned to the package's team of maintainers, who also handle incoming bug reports? Anyway, that maintainer has looked into performing an upgrade, but has found a reason not to upgrade and leaves a note in the specfile or a separate README in git. So far, so good. That reminds me of what I've been doing for Audacious during its troublesome v2 series. That is a basic idea, not a tested bullet-proof process, however. For example, what happens if an upgrade-mad maintainer thinks the notes in the spec file no longer apply? What happens if this is not (or cannot be) discussed for various reasons with the person that added the note? A single pet-peeve bug fixed in the latest upstream release could lead to a maintainer pushing forward an upgrade without taking care of the package normally. Conflict resolvement would be necessary. I'm not convinced that would be easy. Else there would not be regular threads-of-doom on the mailing-lists either. The system would lead quickly to some people accusing others of abusing their package write-access. What happens if there is no note and someone does an upgrade, which turns out to be broken in several ways? Who decides whether to downgrade (Epoch-fun!) or whether to try to fix the problems? And if the problems affect external packages and require porting to a new API (or require heavier development even), are there volunteer maintainers to do that for packages that are not being assigned to? Why is it so difficult to say "I'm interested in many more packages, I want to contribute to those packages, and I do that either upstream or only in the Fedora packages, and in order to do so, I request pkgdb access to the packages in Fedora properly"? Then you could find out whether team-work is possible with the existing maintainers. Why must it be the opposite? Arbitrary access to packages, possibly sporadic or random upgrades (as time permits), with no one taking care of the packages normally. > With that, the policy would be: You think the software is old? You upgrade > it. Problem solved. =:-o That's all? Software is old, replace it? You must be kidding. Especially Fedora's users expect the distribution makers to offer the full show: Everything from choosing a working combination/collection of software to testing/QA, integration-work, and maintaining all this during the life-time of the distribution. If software is new but broken, users turn that against you. Even if this is Fedora and not RHEL. > real PITA to resurrect them. (If I want to pick up a package I missed in one > of the previous "retiring" announcements, I have to get it through all the > review process again just as if it had never been in Fedora!) This is almost ridiculous. The reason you've missed it could very well be that the package doesn't interest you at all and that you've not had a look at it (or its http://bugz.fedoraproject.org/NAME page) before. You haven't taken care of it in the package collection either. And if you've discovered the software just recently, would you be its only user in Fedora? Nobody else? Perhaps just a few users who run with a personal repo or a 3rd party repo on the web? Impressive. And finally, I'm almost certain FESCo could be approached with a proposal to have provenpackagers not require a re-review of previously retired packages. The reason they have been retired is very important, however. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
