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

Bug#736715: marked as done (DDPO shouldn't list packages under their maintainer in stable)

Your message dated Tue, 8 Jan 2019 15:22:14 +0100
with message-id <20190108142214.GA25001@msg.df7cb.de>
and subject line Re: Bug#736715: PTS shouldn't list packages under their maintainer in stable
has caused the Debian Bug report #736715,
regarding DDPO shouldn't list packages under their maintainer in stable
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
736715: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736715
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: qa.debian.org
Severity: normal

It is confusing that pages like
  http://qa.debian.org/developer.php?login=packages@qa.debian.org
list whoever maintained packages also under whoever is listed in
the maintainer field in stable - that person might have given up
maintainership of the package many years ago (or here in the case
of packages@qa.debian.org, it is no longer of any interest for QA
since it does now have a maintainer).

As an example, when looking for where a QA upload might make sense
for reducing differences with Ubuntu, I am not interested in seeing
the wmii package listed - that package is no longer maintained by QA.

I'd expect the maintainer in unstable to be the one and only being
responsible for all versions of the package.

When there are different maintainers in unstable and experimental,
I see the point of listing a package under both since it is not
trivial to see which maintainer information is more recent, and that
would usually anyway be resolved soon with a new upload.

Additional information from the discussion on #debian-qa :

12:33 < noshadow> looks like developer.php gets the information from database 
                  files, so it looks more like a show or not show and no easy 
                  graying out those where one is only maintainer in stable.
12:46 < noshadow> reading the source it looks like something in oldstable 
                  should not show up. And if the examples I tried were correct 
                  it indeed does not show up. So from the code it looks like it 
                  was an explicit decision to have stable packages show up 
                  there (but oldstable not).
12:49 < noshadow> stable stable-proposed-updates testing 
                  testing-proposed-updates experimental and unstable are taken 
                  for maintainer information while 
                  oldstable{,/updates,-proposed-update} stable-updates 
                  stable/updates testing/updates are not.
12:51 < noshadow> svn.debian.org/svn/qa/trunk  date/ddpo/extract_archive.pl 
                  line 139 the ', 1' part
12:52 < bunk> noshadow: IMHO unstable (and perhaps experimental) are the only 
              suites that make sense for checking maintainer information
12:54 < noshadow> bunk: I guess the interesting part in suggesting the change 
                  is finding out what else used that maintainer information 
                  from archive.db

--- End Message ---
--- Begin Message --- 
Re: Adrian Bunk 2014-01-26 <20140126111623.26517.17762.reportbug@localhost>
> Package: qa.debian.org
> Severity: normal
> 
> It is confusing that pages like
>   http://qa.debian.org/developer.php?login=packages@qa.debian.org
> list whoever maintained packages also under whoever is listed in
> the maintainer field in stable - that person might have given up
> maintainership of the package many years ago (or here in the case
> of packages@qa.debian.org, it is no longer of any interest for QA
> since it does now have a maintainer).
[...]
> I'd expect the maintainer in unstable to be the one and only being
> responsible for all versions of the package.

The logic has been improved recently. Now it lists all packages in
unstable and experimental, plus all (old*)stable packages that have
been removed (but might still be RC-buggy in stable). Packages that
have switched maintainers between stable and unstable are no longer
listed.

Christoph

--- End Message ---
Reply to: