[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Maintaining packages properly

On Mon, 23 Mar 2009, Otavio Salvador wrote:

When issuing the mail which I declared as "raw thought" I was aware that
the rule would not work for dpkg and that's why I added some additional
tules to the scoring system which should have made clear that dpkg does
not fall under this suggestion.

Furthermore the thread was about first and second class (or however you
might call this) packages and my concern was about finding a way to work
with "potential second class" packages.  I was explicitely not talking
about dpkg in this sense - but you are right dpkg definitely needs more

There're many bugs that fit in this group. Kernel, Parted, Dpkg, APT and
so on.

I agree with Raphael, this kind of things just doesn't work.

But you ignore the main point of my mail: I was talking about packages
with lower priority.  I'm aware that it at some point makes no sense
to blindly tag the packages you mentioned above as RC and I did not
intended this.  IMHO the problem why these packages habe so many bugs
that a newcomer has nearly no way to decide where to start.  Seeing a
list of > 100 outstanding bugs (324 bugs against dpkg for instance) is
just not inviting for anybody who has not dealt with this issue before.
I have no real solution for this problem - but please do not blame me
about this - nobody else seems to have one.

But does this mean we could not set some preasure on lower priority
packages which just collect a lot of bugs?

There was also a verification of my proposal to not automatically file
a RC bug which fits some bug measures but enable users manually filing
an RC bug if some criterions which should be defined are fullfilled.
This enables to give further reasons and does not need any technical
changes in our infrastructure.

Kind regards



Reply to: