On 01/13/2012 10:51 PM, Michael Schwendt wrote:
On Fri, 13 Jan 2012 21:03:09 +0100, KK (Kevin) wrote:
When we're in danger of losing so many packages, it's a sign that our
processes are broken:
That's a dubious conclusion.
I concur with Kevin.
* The whole concept of packages being "owned", and by one person at that, is
broken.
No, it isn't.
To me, it's obvious, this concept doesn't work well anymore.
Even in the scenario of project-wide write-access to packages,
there must be someone to decide when to perform an upgrade.
... but this someone doesn't have to be an individual nor does it have
to be the package maintainer. It can be a group, it can be an expert or
a group of experts etc.
The "1 package:1 owner" model works in commercial environments, where
"supposed to be skilled professionals" are supposed to be in _charge_ of
"customer care". It doesn't work well in an environment run by
volunteers, who often are laymen, work in their spare time and can not
be forced to anything.
Fedora as a whole should feel responsible for those packages, commit
access should be open to ALL packagers (not just provenpackagers) as in the
good old Extras, and there should be experienced packagers actually stepping
in to rebuild packages with broken dependencies, fix FTBFS issues etc. (I
used to do that, but I had to mostly give up because nobody else would help
(Alex Lancaster used to help fixing broken dependencies, but mostly doesn't
anymore)
Well, I also did several times, but often found me stuck in bureaucracy
and often got stuck in a web of bugs elsewhere - in short, not a pretty
tedious experience.
Any package which is removed from Fedora is a package our users will no
longer be able to use. Removing a package should only be a last resort if it
cannot be made to work at all.
No. We need _more_ packagers, even if that means, many more _newbie
packagers_.
Do you realize that such "demands for more people" often are symptoms of
a failing system?
The common alternatives are to "improve efficency" and to "improve
productivity" using those resources you have available. Approaches into
this direction would be "teaming up", "less burecracy" and a "less
volatile basis" to work with.
Ralf
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
