QA process was Re: RPM submission procedure

Karl DeBisschop kdebisschop at alert.infoplease.com
Fri Jan 9 21:32:49 UTC 2004


On Fri, 2004-01-09 at 16:13, Alan Cox wrote:
> On Fri, Jan 09, 2004 at 02:20:16PM -0500, Karl DeBisschop wrote:
> > Somehow it seems to me contrary to the idea that Fedora stresses
> > upstream bugfixes.
> 
> Do you want 35 rival competing updated copies of perl that all
> conflict ?

Not at all. In fact I don't really see how you read that from what I
wrote, so I must be missing something or I must not have been clear.

What I'm suggesting is that if every distro has entirely separate specs,
you are tending torward these sorts of conflicts. But if the distros are
less insistent that a spec is for their distro alone, then we have less
tendency to diverge.

> > Do other people see this tension?
> 
> Not really. Firstly you should be working with the package maintainer,
> and secondly if you can't work with them then Fedora has another category
> to deal with stuff that might cause conflicts, and lets people be aware
> that they may get them.

Generally, it's hard as a developer to get feedback from packagers. They
tend to do what they want and never feed it back to the developer in my
experience.

And even if you do, it's not tenable to ask a developer to coordinate
independently with packagers from all the distros out there. So what I'm
suggesting is that if the distros work from the idea of a reference spec
that is somewhat distro agnostic, then the delevopr coordinates with the
.deb packaging community, the rpm packaging community, and the ports
community. That way, as packagers contribute thier feedback to the
devlopers, it's more focused on what make the application better.

If packagers from different distros eschew that tpe of cooperation, then
the developer either sees silence or a "do things my way because that's
our policy" from 20 different camps pulling the project in all different
ways.

-- 
Karl DeBisschop <kdebisschop at alert.infoplease.com>
Pearson Education/Information Please





More information about the fedora-devel-list mailing list