I'm just entered the world of Fedora packagers and I see a few points
that can be optimized in my opinion.
1. I saw a package that need to be upgraded. I opened a bug in bugzilla,
after some time whit no response from the maintainer I asked in pkgdb
permissions for that package: I'm still waiting, after two weeks, that
the maintainer gives me such permissions. So why I can take an orphaned
package with automatic procedure and I cannot apply as co-maintainer in
the same manner?
2. In review requests I see some of them are requests for existent
packages that should be renamed. Why bothering reviewers (that are not
so much, I think, looking at the long list of reviews pending) with this
extra-work only to rename an existing package?
In my opinion these two points can be modified to have less bureaucracy
and to make things working a bit faster.
Il 14/01/2012 13:03, Michael Schwendt ha scritto:
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
