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

Re: Restoring the removed e16 package



The Wanderer writes ("Re: Restoring the removed e16 package"):
> On this point, I've already been advised (by Bart Martens, in
> off-list mail) that debian-mentors would probably be a more
> appropriate venue.

Fair enough.  I'll try to keep my response here to one point which I
think is probably of general interest.

> > Find someone (preferably a team) to be the maintainers, prepare a
> > suitable package, get someone to sponsor it, and reopen all the
> > bugs which were closed by the removal.
> 
> I'm a little surprised by this last point. Since I wouldn't have thought it
> would seem appropriate to add (or re-add) a known-buggy package to the
> repository,

"A suitable package" means one that is fit for release, obviously.
Assembling a team who were happy to be the maintainers would naturally
mean a team who are happy that they can fix the RC bugs.

I spoke loosely about the bugs.  I think the right procedure would be
to reopen /all/ the bugs before uploading the new package, and then
allow the changelog entry of the new package to close the ones that
had actually been fixed in the new version.

(An RC-buggy package will not end up in a Debian release provided it's
properly tagged in the BTS.  So I think in principle it can be
appropriate to upload an RC-buggy package to the archive if you have a
plan for fixing the bugs and there is some reason why it is better to
do it that way - eg, perhaps there are dependencies and working on the
whole lot in unstable is easier.)

> The only reason I can think of would be documentation - to record
> that the bug has in fact been officially fixed, rather than simply
> lost in the shuffle. Is that the only reason for that step, or is
> there more which I'm missing?

It is unlikely that the new package would fix all of the bugs in the
package.  It is mostly straightforward to automatically reopen all the
bugs which were fixed by the removal.  Closing the fixed bugs in the
changelog is easy.  The result is that the set of bugs remaining open
in the BTS is correct, and it will be easier to avoid mistakes.

Ian.


Reply to: