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

Re: Maintaining packages properly

On Fri, 20 Mar 2009, Raphael Hertzog wrote:

[ Moving to -project ]

context: someone proposed a scoring system like this:
x (= 10?) Important bugs are RC critical
y (= 25?) Normal bugs are RC critical

Well, this someone was me and the "context" is a bit short compared
to my original suggestion which was:

  just a raw thought which popped up in my mind:  Don't we have a second class
  repository?  We have unstable and packages with RC bugs stay there (or will
  be banned to this place if RM decides).  I know that unstable is not something
  you are allowed to break - but effectively there just are broken packages.
  We might just find a better definition what means "broken".  So why not just
  define a scoring system like

    x (= 10?) Important bugs for one package are RC critical
    y (= 25?) Normal bugs are RC critical

  or something like this.  May be we have to adjust the scoring system. And yes,
  I know that some very basic tools will be quickly RC critical if you blindly
  apply this rule.  But perhaps this suggestion might be taken with a grain of
  salt for packages in optional and extra or something like this.  At least this
  would increase the motivation of maintainers to care for their bugs.

  It's all about "make sure your package has no RC critical problems" and
  we could just enhance the definition of RC critical.

Take the dpkg package, it currently has 396 bugs open and 13 marked
important among them (and 176 normal). We had more than 500 bugs 2 years
ago and it has been a _lot_ of work to get to this state.

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

Just to addjust the context a bit ...

Kind regards



Reply to: