Re: on mass bug reassigning
Luk Claes wrote:
> Raphael Geissert wrote:
>
>> I currently don't have enough time to write a script that gathers the
>> versions information from the origin package to use when MBR. But here is
>> what I believe needs to be done:
>>
>> * Encourage package maintainers to keep the old changelog around (e.g.
>> php5's changelog include php4's changelog). So the BTS knows about old
>> package versions
>
> This is not practical for packages that are uploaded next to eachother
> and where one is dropped. Including a very long changelog is also not
> practical...
In case of php5, the maintainers at that moment took the php4 packaging and
based the php5 packaging on it. Newer changelog entries are not included in
php5's, for practical reasons.
But now that I think about it, maybe the BTS could detect different source
package names in debian/changelog, and if a package with that given name is
also in the archive, grab its versions for the 'new' package. And if
the 'old' package(s) are no longer known to be in the archive, display
their bugs together with the ones filed against the 'new' package.
That sounds more reasonable IMHO.
>
>> * Write a script that gathers the versions not/affecting a given bug,
>> and
>> generates the appropriate reassigning bug (in the form of "reassign nnnn
>> package version", or if more than one affected version: "reassign nnnn
>> package \n found nnnn version ...").
>
> What's wrong with the assumption that all versions are affected if no
> versioning information is known?
That when there are many bug reports it clutters the page and you may
accidentally not notice one. Same applies when you want to prepare an
upload for s-p-u fixing important bugs only relevant to stable.
And going over every bug report to see the versions the BTS used to know
about is just impractical and a waste of time, don't you agree? :)
>
>> * Reach a concensus on whether maintainers should be contacted before
>> MBR
>> (waiting a specific number of days for their reply before going ahead),
>> or not.
>
> I think the best scenario would be that the maintainers reassign and
> close the bugs themselves before needing to contact them.
Of course, but it also depends on the amount of bug reports, the amount of
time required for checking every report, replying, reassigning, forwarding,
checking status at upstream, and so on. One may not notice the progress if
only a couple of bugs are handled every week or so.
> Even if they
> didn't do it themselves up to the point of decision to contact them I
> think it's best to inform them about the bug triage and give them some
> time to do it themselves as they should know the best what the status of
> the bugs is.
Which is more or less what I was suggesting :)
>
> Cheers
>
> Luk
Cheers,
--
Atomo64 - Raphael
Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
Reply to: