On Fri, 18 May 2012 16:41:55 +0100
"Manuel A. Fernandez Montecelo" <manuel.montezelo@gmail.com> wrote:

> Another question, perhaps unrelated is, what happens with the bugs
> closed from egroupware or salome (removed from unstable/testing but
> still present in stable releases) when their users look for them in
> the BTS? They would be closed and archived, I suppose, and users of
> stable wouldn't be able to find them easily -- and them maybe report
> them again.

Depends on the found version of the bugs. If the bug isn't found in any
version currently in Debian, the bug needs to be closed. It could be
triaged in the previous versions, if people have the time, but that may
well have already happened or someone may have added a comment to the
bug that it affects old releases too.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Hi!

On 18.05.2012 10:50, Paul Wise wrote:


Our bug tracker contains items for packages, which do (not longer) exist. What should happen to them? I see, that it might be a good idea to keep them for the case, a package is re-introduced. But this might happen only for a few packages. Most of them got removed because newer versions were released. What about closing those reports, if an RM-request is filed?


ftpmaster already close bugs automatically when processing RM requests.


Not always. IIRC we only close bugs on removal if:

a) BTS is up and running.
b) source and binary are removed.
c) The package is removed from unstable.
d) The removed package is on sync on all arches. (Because otherwise we
won't know with which version we'd like to close the bug.)


d) also affects binNMUed packages.


Best regards,
Alexander


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FB6A0D2.6000003@schmehl.info">http://lists.debian.org/4FB6A0D2.6000003@schmehl.info

Neil Williams <codehelp@debian.org> writes:

> On Fri, 18 May 2012 14:34:40 +0100
> "Manuel A. Fernandez Montecelo" <manuel.montezelo@gmail.com> wrote:
>
>> Hi,
>>
>> 2012/5/18 Daniel Leidert <Daniel.Leidert.Spam@gmx.net>:
>> > Hi,
>> >
>> > Our bug tracker contains items for packages, which do (not longer) exist. What should happen to them? I see, that it might be a good idea to keep them for the case, a package is re-introduced. But this might happen only for a few packages. Most of them got removed because newer versions were released. What about closing those reports, if an RM-request is filed?
>> >
>> > http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=
>>
>> As others have said, I asked the question only a few weeks ago:
>>
>> http://lists.debian.org/debian-devel/2012/03/msg00946.html
>>
>> Reassigning 300 bugs from emacsX (X<23) to current emacs packages is
>> not very helpful, really. What I did is to notify the maintainers (or
>> related mailing lists) of the three biggest groups (linux, gcc, emacs)
>> to decide what to do.
>
> There's a big difference between these bugs and the rest - here there
> are clear migration paths to later packages which can be used to triage
> the bug reports in order not to lose reports. A lot of the rest *can*
> be closed without more triage work because the package was removed, not
> replaced. e.g. gcc-4.4 bugs may be applicable with gcc-4.7 and need to
> be triaged. The opensync/multisync bugs just had to be closed without
> even looking at any of them.
>
> Identifying this subset (which could be quite large) which apply only
> to packages which have no appropriate replacement packages would be a
> very useful QA step and dramatically improve the total number of bugs
> in this situation.

For packages like gcc-x.y that know that there will be a continious
progression of new sources with old sources becoming obsolete wouldn't
it make sense to declare some sort of meta-source-package for
them. Something like

Package: gcc-4.4
Version: 4.4.7-1
Meta-Source: gcc-x.y

The BTS could then not just track the binary/source package of a bug but
also the meta-source package. That way when gcc-4.4 is removed from the
archive the bugs can still be associated with the gcc-x.y meta package
and won't be completly lost. The gcc maintainers would still be
listed as repsonsible for the bug.

Similary when a source package is renamed (but the old not yet removed)
all the old bugs could be assigned "Meta-Source: <new name>" so on
removal of the old package they automatically default to the new source
name. This could be semi automatic so that new bugs against the old
packages automatically get the Meta-Source info too.

Just an idea.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87aa14k2gp.fsf@frosties.localnet">http://lists.debian.org/87aa14k2gp.fsf@frosties.localnet

On Vi, 18 mai 12, 14:34:40, Manuel A. Fernandez Montecelo wrote:
>
> So I wouldn't blindly close those bug reports, and that's why I'm
> triaging and handling them in my spare time.

Do you know how to retrieve those bugs with querybts(1) other than by
individual bug number?

Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic

On Sat, 19 May 2012, Goswin von Brederlow wrote:
> The BTS could then not just track the binary/source package of a bug
> but also the meta-source package. That way when gcc-4.4 is removed
> from the archive the bugs can still be associated with the gcc-x.y
> meta package and won't be completly lost. The gcc maintainers would
> still be listed as repsonsible for the bug.

What may be the appropriate solution is to allow for meta-source
packages to be specified at the BTS level instead. That is, I (or
someone else with an owner@ hat) can just alias source packages to
other source packages, so that they all appear to be the same source
package. [Possibly also allowing for aliased binary packages as well,
with aliases being overridden if there is a currently existing binary
or source package with that name.]

We can generate a list fairly automatically by parsing the changelog
history looking for cases where a new source package name follows a
previous source package name.


Don Armstrong

--
This can't be happening to me. I've got tenure.
-- James Hynes _Publish and Perish_

http://www.donarmstrong.com http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120519135505.GB8248@teltox.donarmstrong.com">htt p://lists.debian.org/20120519135505.GB8248@teltox.donarmstrong.com

2012/5/19 Andrei POPESCU <andreimpopescu@gmail.com>:
> On Vi, 18 mai 12, 14:34:40, Manuel A. Fernandez Montecelo wrote:
>>
>> So I wouldn't blindly close those bug reports, and that's why I'm
>> triaging and handling them in my spare time.
>
> Do you know how to retrieve those bugs with querybts(1) other than by
> individual bug number?

I don't know much about querybts, but you can ask for all [unarchived,
I think] bugs in package emacs21, for example:

$ querybts emacs21
Querying Debian BTS for reports on emacs21...
292 bug reports found:
...


bts (from devscripts) is a bit more sophisticated, but when you query :

bts select maintainer:""

it seems to return all open bugs (not only those with empty
maintainer), and if you query:

bts select maintainer:" " (blank space)

it returns an empty list.

Hopefully somebody more knowledgable than me can help you, I usually
do it with the web interface.

Cheers.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAPQ4b8kvqHK==ON-DyzZ+6gVRAYxEF4=w_VnmEhAZyzWCKu62g@mail.gmail.com" >http://lists.debian.org/CAPQ4b8kvqHK==ON-DyzZ+6gVRAYxEF4=w_VnmEhAZyzWCKu62g@mail.gmail.com

On Sb, 19 mai 12, 15:48:46, Manuel A. Fernandez Montecelo wrote:
>
> I don't know much about querybts, but you can ask for all [unarchived,
> I think] bugs in package emacs21, for example:

For that you would have to know the "package" the bug was reported
against.

> Hopefully somebody more knowledgable than me can help you, I usually
> do it with the web interface.

Yes please. At a quick look I've seen some bugs where I might be able to
help triage, but I would be much more efficient with a tool that can
query the BTS and feed an mbox to mutt.

Both querybts and bts can do that, but I haven't found a way to query
for those bugs.

Thanks,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic