Re: Debconf QA BOF summary / handling of orphaned packages

[Stefano Zacchiroli]

On Fri, Aug 21, 2009 at 11:08:56AM +0200, Lucas Nussbaum wrote:
  That was not the counter-argument back then [1], it might be a new /
  different counter-argument.
 Actually, it kind-of was, see the subthread that starts here:
 http://lists.debian.org/debian-qa/2007/08/msg00076.html

I'm offline right now and I cannot check, but I'm happy in trusting
your words. Probably, my memories were biased.

 I'm not sure I understand what you want to do. You want to import all
 orphaned packages into $VCS, so that it is easier for people to work on
 them. But then, you want to allow people to upload orphaned packages
 without using $VCS, which would lead to a very confusing situation.

Actually, I was just arguing that having packages in $VCS does not
necessarily make harder to do QA uploads, because you are not forced
to use / know $VCS; this is no difference with non-QA uploads.

On the contrary, I agree now that if they are not in $VCS yet, forcing
a check in to $VCS to do the QA upload is an additional burden that
should be avoided.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Debconf QA BOF summary / handling of orphaned packages

[Stefano Zacchiroli]

On Fri, Aug 21, 2009 at 11:09:39AM +0200, Lucas Nussbaum wrote:
  Just to clarify, I meant moving collab-maint/foo.git to e.g.
  collab-maint/orphaned/foo.git to make it obvious to folks browsing the
  repository that it's orphaned, while retaining the history. Not
  suggesting to put everything under $VCS. Sorry for the bad phrasing.
 Do people actually browse the repository like that? I never do that.

Me neither and I concur that probably nobody does that.
Also, re-thinking at the issue, moving the Git repos around that way,
would make git pull on old checkouts fail rather gratuitously.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Debconf QA BOF summary / handling of orphaned packages

[Lucas Nussbaum]

On 05/08/09 at 14:16 +0200, Cyril Brulebois wrote:
 Lucas Nussbaum lu...@lucas-nussbaum.net (05/08/2009):
  Actually, the counter-argument is that we don't want to make it
  *harder* to do a QA upload. Currently, it's apt-get source ; make
  change ; dput. If we used a VCS, we would have to create: - a process
  to auto-import orphaned packages into the VCS - procedures to commit
  changes to VCS before doing QA uploads
  
  I don't have numbers about that, but a fair share of QA uploads are done
  by one- or two-timers, even a majority of uploads is done by QA folks.
  We don't want to make it harder for those one-timers to improve the
  status of orphaned packages.
 
 Just to clarify, I meant moving collab-maint/foo.git to e.g.
 collab-maint/orphaned/foo.git to make it obvious to folks browsing the
 repository that it's orphaned, while retaining the history. Not
 suggesting to put everything under $VCS. Sorry for the bad phrasing.

Do people actually browse the repository like that? I never do that.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Lucas Nussbaum]

On 05/08/09 at 14:41 +0200, Stefano Zacchiroli wrote:
 On Wed, Aug 05, 2009 at 08:27:22AM +0200, Lucas Nussbaum wrote:
  Actually, the counter-argument is that we don't want to make it
  *harder* to do a QA upload.
 
 That was not the counter-argument back then [1], it might be a new /
 different counter-argument.
 
 [1] http://lists.debian.org/debian-qa/2007/08/msg00073.html

Actually, it kind-of was, see the subthread that starts here:
http://lists.debian.org/debian-qa/2007/08/msg00076.html

  Currently, it's apt-get source ; make change ;
  dput. If we used a VCS, we would have to create:
  - a process to auto-import orphaned packages into the VCS
  - procedures to commit changes to VCS before doing QA uploads
  
  I don't have numbers about that, but a fair share of QA uploads are done
  by one- or two-timers, even a majority of uploads is done by QA folks.
  We don't want to make it harder for those one-timers to improve the
  status of orphaned packages.
 
 Frankly, I don't buy this. Nowadays everybody should be able to work
 with common $VCS. But even when this is not the case, $VCSs are always
 unofficial wrt the archive: it is not *mandatory* to use them, even
 for normal (non-QA) NMUs.
 
 So even checking in orphaned packages in $VCS does not make it harder
 to do a QA upload. If you want to use it: fine, otherwise you can
 always upload the old way.

I'm not sure I understand what you want to do. You want to import all
orphaned packages into $VCS, so that it is easier for people to work on
them. But then, you want to allow people to upload orphaned packages
without using $VCS, which would lead to a very confusing situation.

I don't think that our current workflow for QA uploads is suboptimal,
but I have not done many QA uploads. Maybe the best thing to do would be
to ask people who do a lot of QA uploads, and see if using a VCS would
help them?
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Sandro Tosi]

On Fri, Aug 21, 2009 at 11:08, Lucas Nussbaumlu...@lucas-nussbaum.net wrote:
 I don't think that our current workflow for QA uploads is suboptimal,
 but I have not done many QA uploads. Maybe the best thing to do would be
 to ask people who do a lot of QA uploads, and see if using a VCS would
 help them?

I did some qa uploads (so if that doesn't qualify as 'a lot', simply
ignore this email).

I don't think importing all (or a part) orphaned packages in a
(public) VCS is anything near helpful. Which one to choose, for
example? one may like A and dislike B, while another may love C, quite
like B and dislike A, and another one prefers B over anything else; or
any other possible combinations.

I think that the best workflow for a QA upload is: take the canonical
source package (hence from the debian archive), do the needed changes,
upload. Simple, fast, no additional layers not strictly needed (that
could scare potential contributors): as it should be for a *temporary*
maintainership of a package.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Marco Rodrigues]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Sandro Tosi wrote:
 On Fri, Aug 21, 2009 at 11:08, Lucas Nussbaumlu...@lucas-nussbaum.net wrote:
 I don't think that our current workflow for QA uploads is suboptimal,
 but I have not done many QA uploads. Maybe the best thing to do would be
 to ask people who do a lot of QA uploads, and see if using a VCS would
 help them?
 
 I did some qa uploads (so if that doesn't qualify as 'a lot', simply
 ignore this email).
 
 I don't think importing all (or a part) orphaned packages in a
 (public) VCS is anything near helpful. Which one to choose, for
 example? one may like A and dislike B, while another may love C, quite
 like B and dislike A, and another one prefers B over anything else; or
 any other possible combinations.
 
 I think that the best workflow for a QA upload is: take the canonical
 source package (hence from the debian archive), do the needed changes,
 upload. Simple, fast, no additional layers not strictly needed (that
 could scare potential contributors): as it should be for a *temporary*
 maintainership of a package.

In the upload part, I just use mentors for that. I don't need to VCS for nothing
in these cases. I think to import debian/ to VCS is only a time and server 
wasting.

- --
Marco Rodrigues

http://Marco.Tondela.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKjwf7AAoJENDqNB6bSPIzM98P/jksg1pUq+7RjwsfLmDlK/Th
r252UZzdfgVRXo9AVN0aLSSYyQA/SYWFjxOuYGKzEXdrm7LYbUSsJ48qQps3RBzf
43PmCCz/qn70bWm7MABLjcdlsRXInexJRrMHliaqlEs3EgnmdsjfX+ZqD1xdEk91
HOqlfYg9tjo2YunHcgJuv7IengrlOerKjBZFPeJ4enZaTJZgSnwRiycGwI6Csrql
lJ2Ru1onuCduTBa6llBv4tdxtnJnBdaOsvEi2xlf9jft3ZVTwmNEhYPtcF+CclfA
b72/XXD0rAhJ+wcmhVeYcPk31V9JQsFnw+OEQxiN2Lk1Oy0X6sqmegYM+riEQTcr
NSuxvJge1AkTklCWxVOZNDOcyc1BIxbKp6FVpzVXT1FPHftRK51fkx+rnJtt3e/I
If0jdl2n4e3wqqGqnmORunDjsIQJnE20ZP7aN6mSWiyV0urRExVAipllHaW4G5xv
VmSvDOlzPqt9m5QXsl1ixdbgkBL0u6Hw8LnjhGf7wMC31ktZZYLLZ0eh5zq+36Fd
1TSgJ3NgySsmvwE0q863vCLievEQSN8kf0P2+E4st5sn5rx3rqZf91EoHRgdHvnp
Twvwg94YuWhQcS7G6tpR5R7u6bvhd5xwSlifKq4Dq0x2driszWTOQL7VqlWNNLAl
WM9pWBWNYS5AWz6RBppH
=2tk5
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Cyril Brulebois]

Lucas Nussbaum lu...@lucas-nussbaum.net (05/08/2009):
 Actually, the counter-argument is that we don't want to make it
 *harder* to do a QA upload. Currently, it's apt-get source ; make
 change ; dput. If we used a VCS, we would have to create: - a process
 to auto-import orphaned packages into the VCS - procedures to commit
 changes to VCS before doing QA uploads
 
 I don't have numbers about that, but a fair share of QA uploads are done
 by one- or two-timers, even a majority of uploads is done by QA folks.
 We don't want to make it harder for those one-timers to improve the
 status of orphaned packages.

Just to clarify, I meant moving collab-maint/foo.git to e.g.
collab-maint/orphaned/foo.git to make it obvious to folks browsing the
repository that it's orphaned, while retaining the history. Not
suggesting to put everything under $VCS. Sorry for the bad phrasing.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Debconf QA BOF summary / handling of orphaned packages

[Stefano Zacchiroli]

On Wed, Aug 05, 2009 at 08:27:22AM +0200, Lucas Nussbaum wrote:
 Actually, the counter-argument is that we don't want to make it
 *harder* to do a QA upload.

That was not the counter-argument back then [1], it might be a new /
different counter-argument.

[1] http://lists.debian.org/debian-qa/2007/08/msg00073.html

 Currently, it's apt-get source ; make change ;
 dput. If we used a VCS, we would have to create:
 - a process to auto-import orphaned packages into the VCS
 - procedures to commit changes to VCS before doing QA uploads
 
 I don't have numbers about that, but a fair share of QA uploads are done
 by one- or two-timers, even a majority of uploads is done by QA folks.
 We don't want to make it harder for those one-timers to improve the
 status of orphaned packages.

Frankly, I don't buy this. Nowadays everybody should be able to work
with common $VCS. But even when this is not the case, $VCSs are always
unofficial wrt the archive: it is not *mandatory* to use them, even
for normal (non-QA) NMUs.

So even checking in orphaned packages in $VCS does not make it harder
to do a QA upload. If you want to use it: fine, otherwise you can
always upload the old way.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Debconf QA BOF summary / handling of orphaned packages

[Thomas Viehmann]

Lucas Nussbaum wrote:

The reason why I think that moving some of the orphaned packages to
experimental is a good idea, is because often, you run into packages
that are still useful to a small number of users, have no alternative,
still basically work, but have been orphaned for 2 years with nobody
willing to maintain them. In that case, we should not release with such
packages, but it should still be available (though unsupported) to the
users.
What is experimental about these packages? Experimental has a purpose. 
It is not keeping unsupported packages around.


The packages are still on archive.d.o if they ever made a release (and 
soon more finely grained on snapshots). The typical package did not get 
nontrivial updates in a release cycle before it was removed, so the 
version on archive.d.o will be just as good as the version you want to 
stuff into experimental.


If the users who still derive benefit from the package do not want to 
maintain it, tough luck. Free software works relies on people helping out.
I cannot see how turning experimental maintained packages that can use 
a test drive before general consumption into pile of broken, obsolete 
packages nobody ever wants to see again is something that benefits 
Debian at large. In addition, I cannot see how users without means to 
obtain the package from archive.d.o or some snapshot repository can 
responsibly be pointed at experimental as a source of packages.
The same people who do not help out maintaining would also be less 
likely to file bugs. Leaving experimental essentially as a dump where 
packages rot without ever seeing any attention. Eventually experimental 
will become as useless as sourceforge as a source of working software. 
Improving Debian? Only if your only measure is number of packages, 
probably. Other than that? No.


Please do not turn Debian into Pile of Packages as opposed to 
operating system more than it already is.


Kind regards

T.

P.S.: Of course, a lot time might be freed if Debian QA didn't 
effectively maintain half of the non-orphaned packages as well when it 
comes to fixing bugs. But as things are like they are

--
Thomas Viehmann, http://thomas.viehmann.net/


--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Raphael Hertzog]

Hi Thomas,

I love the work you do for Debian but I hate the positions you are
taking since you left the project. I have the feeling that you have an
extremist point of view and that you are not willing to try to understand
the other side of the discussion.

On Sun, 02 Aug 2009, Thomas Viehmann wrote:
 Lucas Nussbaum wrote:
 The reason why I think that moving some of the orphaned packages to
 experimental is a good idea, is because often, you run into packages
 that are still useful to a small number of users, have no alternative,
 still basically work, but have been orphaned for 2 years with nobody
 willing to maintain them. In that case, we should not release with such
 packages, but it should still be available (though unsupported) to the
 users.
 What is experimental about these packages? Experimental has a
 purpose. It is not keeping unsupported packages around.

What's experimental in packages put in experimental just because testing
is frozen?

The naming of the repository is not the only thing that should be 
taken into account...

Experimental is:
- auto-built
- still part of debian (packages there show up in the PTS for instance)
- mirrored
- packages can still be updated by DD
- not supported by the security team

So a package that has been orphaned for some months already but that is
still working could be moved to it in the hope that someone will come and
maintain it. Once a package is removed of Debian, it's not here anymore and
we're not looking for anyone to adopt it.

So this solution is a nice intermediary solution between continue to
maintain the package in sid by the QA team and remove the package
completely.

And I see no point in trying to convince us not to do this for some
packages where this makes sense (because we don't want to remove
it as it still has a high-popcon).

 I cannot see how turning experimental maintained packages that can
 use a test drive before general consumption into pile of broken,
 obsolete packages nobody ever wants to see again is something that
 benefits Debian at large.

Not all orphaned packages are broken and obsolete. So just stop asserting
this as a general rule.

 where packages rot without ever seeing any attention. Eventually
 experimental will become as useless as sourceforge as a source of
 working software. Improving Debian? Only if your only measure is
 number of packages, probably. Other than that? No.

The packages in experimental would still follow the same process... if
they ever start accumulating RC bugs or are there for too long, they will
be removed. The point is to stop keeping orphaned packages for too long in
testing/sid...

Because by keeping them in testing/sid, you make it harder to remove them
later as other packages might start depending on them and we make it
harder to keep testing/sid RC bug free since we have more packages that
must be taken care of by the QA team.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Thomas Viehmann]

Hi.

Raphael Hertzog wrote:

I love the work you do for Debian but I hate the positions you are
taking since you left the project. I have the feeling that you have an
extremist point of view and that you are not willing to try to understand
the other side of the discussion.


 And I see no point in trying to convince us not to do this for some
 packages where this makes sense (because we don't want to remove
 it as it still has a high-popcon).

Thanks for clarifying that.

Kind regards

T.
--
Thomas Viehmann, http://thomas.viehmann.net/


--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Cyril Brulebois]

Lucas Nussbaum lu...@lucas-nussbaum.net (31/07/2009):
 On 30/07/09 at 17:16 +0200, Sven Hoexter wrote:
  IMHO it would be nice to aim at a release without oraphaned packages.
 
 That's totally unrealistic.

Indeed. Quick examples which may come to mind:
 - xulrunner and all gecko-based pakages.
 - webkit and all depending packages.

Ha!

(Looks like people got interested lately, but you get the idea.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Debconf QA BOF summary / handling of orphaned packages

[Cyril Brulebois]

Thomas Viehmann t...@beamnet.de (02/08/2009):
 The packages are still on archive.d.o if they ever made a release (and
 soon more finely grained on snapshots). The typical package did not
 get nontrivial updates in a release cycle before it was removed, so
 the version on archive.d.o will be just as good as the version you
 want to stuff into experimental.

I can think of three packages (maintained until now by Pabs and myself)
that may deserve being kept somewhere as they currently are, so that
people can still jump in and not start again from scratch. I believe the
current packages could be better than the last released ones (read: the
ones one could find on archive.debian.org). I guess that having that
kind of packages still available on snapshot.debian.org might be a bit
more useful than only archive.debian.org; but well, VCSes might still be
alive for some time, and that might be enough. Not everyone's using
VCSes anyway.

Speaking of which it might be nice to have some area in collab-maint's
VCSes where to put orphaned (and even removed) packages, so that it's
cleared they're kind-of-dropped.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Debconf QA BOF summary / handling of orphaned packages

[Stefano Zacchiroli]

On Sun, Aug 02, 2009 at 02:58:27PM +0200, Cyril Brulebois wrote:
 Speaking of which it might be nice to have some area in
 collab-maint's VCSes where to put orphaned (and even removed)
 packages, so that it's cleared they're kind-of-dropped.

This seems to be a recurring proposal. I raised it 1 year ago (IIRC,
sorry I'm too lazy right now to look the reference) and Raphael
Hertzog pointed out to me that way before he advanced the same
proposal.

The counter-argument I received 1 year ago is that we do not want to
make any easier to maintain orphaned packages, e.g., via QA
uploads. While I somehow understand that point of view, I still
consider the proposal a good idea, mainly because it technically
facilitates resurrecting the packages for the future maintainer.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Debconf QA BOF summary / handling of orphaned packages

[Manoj Srivastava]

On Sun, Aug 02 2009, Raphael Hertzog wrote:

 I love the work you do for Debian but I hate the positions you are
 taking since you left the project. I have the feeling that you have an
 extremist point of view and that you are not willing to try to understand
 the other side of the discussion.

This is an argument against the man (ad hominem), and should not
 be acceptable on a public mailing list.  Such content, if it at all has
 to be expressed, should be done in private, and thus improve the
 overall atmosphere on public mailing lists.

manoj
-- 
Sigmund Freud is alleged to have said that in the last analysis the
entire field of psychology may reduce to biological electrochemistry.
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Cyril Brulebois]

Stefano Zacchiroli z...@debian.org (02/08/2009):
 This seems to be a recurring proposal. I raised it 1 year ago (IIRC,
 sorry I'm too lazy right now to look the reference) and Raphael
 Hertzog pointed out to me that way before he advanced the same
 proposal.

Sorry for that, missed it/them.

 The counter-argument I received 1 year ago is that we do not want to
 make any easier to maintain orphaned packages, e.g., via QA uploads.
 While I somehow understand that point of view, I still consider the
 proposal a good idea, mainly because it technically facilitates
 resurrecting the packages for the future maintainer.

Well, orphaning something because one is running out of time, and
because some packages need a lot of attention is I guess a valid
situation (hint: see the blender thread on dd@). I would personally hate
that someone has to start the packaging and the patching from scratch.

Anyway, it's probably too hot a topic for me. I guess I'll just shut up.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Debconf QA BOF summary / handling of orphaned packages

[Paul Wise]

On Wed, Jul 29, 2009 at 12:53 PM, Lucas
Nussbaumlu...@lucas-nussbaum.net wrote:

 Removal of orphaned packages
 
 The audience clearly want orphaned packages to be removed. I'm not quite
 sure it's reasonable to do that. However, clearly, there's no opposition
 to this idea. When snapshots.debian.org will be fully fonctional, a web
 interface will allow users to fetch and install removed packages.

I forgot to mention it during the discussion, but s.d.o isn't an
optimal solution due to library ABI bumps and so on. I think a proper
solution is something like unsupported.debian.net or
debian-unsupported.org, documented here (but not yet worked on):

http://wiki.debian.org/MergeDerivedDistributions#DebianUnsupported

This is similar to the below idea:

 Move of orphaned packages to another place
 ==
 Another possible solution would be to move orphaned packages to another
 section/archive area (i.e something sitting next to unstable or
 experimental), or just to experimental.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Lucas Nussbaum]

On 30/07/09 at 17:16 +0200, Sven Hoexter wrote:
 On Thu, Jul 30, 2009 at 01:47:23PM +0200, Thomas Viehmann wrote:
 
 Hi,
 
  Experimental is a development resource and not a dump for packages that  
  should not be in unstable/testing. Abusing it sounds like a bad idea, so  
  IMO think the current regime with a tad (but not overly) more aggressive  
  removal once orphaned packages are more easily accessible seems like a  
  good idea.
 
 ACK. It feels wrong to have in exeprimental a mix of orphaned packages and
 stuff under strong developement.
 
 IMHO it would be nice to aim at a release without oraphaned packages.

That's totally unrealistic.

 Though with the discussion of a freeze in Dec. this might be ambious.
 One has to see where it produces complains from other devs and users
 when orphaned packages start to be missing on a larger scale.
 
 Would it make sense to create a list of orphaned packages and start
 with blocking them from entering testing (e.g. add a bug of RC priority)
 and subsequently remove them, including reverse deps, from testing?
 Or has someone already made such lists and played with something like this?

There's no complete list like you describe, since it's A LOT of work to
analyze each orphaned package. (I'd like to encourage you to start
working on analyzing some orphaned packages -- the full list doesn't
need to be done by the same person).

The reason why I think that moving some of the orphaned packages to
experimental is a good idea, is because often, you run into packages
that are still useful to a small number of users, have no alternative,
still basically work, but have been orphaned for 2 years with nobody
willing to maintain them. In that case, we should not release with such
packages, but it should still be available (though unsupported) to the
users.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Lucas Nussbaum]

(Replying to the various comments in a single mail)
On 29/07/09 at 12:15 +0100, Marco Rodrigues wrote:
  - move packages to experimental
 
 I vote for this option. If a package doesn't have an active
 maintainer, it should belong to experimental suite and add some note
 at PTS explaning what to do in this case.

Something that was not very clear in my mail is that the plan is to have
all the options. For each orphaned package, we can either decide:
- to remove it from debian
- to move it to experimental, if it's still marginally useful
- to keep it in unstable/testing

 Another thing, is provide by default in apt package the experimental
 suite, without the need of manual user configuration, so he can do $
 apt-get -t experimental install package easily.

experimental isn't that hard to add to one's sources.list. We will just
need to check that it's properly documented.

On 29/07/09 at 14:51 +0200, Sandro Tosi wrote:
 What about only remove them from testing?

I'm generally against the idea of having packages in unstable that are
not meant to be included in stable releases. This adds a lot of noise to
various QA reports, and also requires a way to keep them out of testing
(release team hint that would have to be updated when a QA upload is
made, or RC bug).

 about that, I though to re-implement this [1] experiment as a UDD CGI.
 
 [1] http://people.debian.org/~morph/qa_packages_analyze.html
 
 This allows to split the orphaned lists in subset allowing to select
 packages you (or your team) care them most (for example, take all the
 perl libs).

Nice! We should look into integrating this into bapase[2] somehow.
[2] http://udd.debian.org/cgi-bin/bapase.cgi

On 29/07/09 at 18:34 +0200, Stefano Zacchiroli wrote:
 On Wed, Jul 29, 2009 at 12:53:54PM +0200, Lucas Nussbaum wrote:
  - add a note on the PTS explaining how to install packages from
snapshots.d.o
 snip
  - add a note on the PTS for experimental-only packages to explain
  how to
install them.
 
 Just a comment: the PTS is not meant to be user-oriented (heck I
 cannot even contain package descriptions at the moment, since we don't
 have source package description!). I'm of course fine to add info
 about that in those pages, but they will be more like this package is
 only available from BLA than add this stanza to sources.list to get
 it.
 
 The latter kind of user information should better be pushed to some
 package manager.

Sure, we should just try to find a way to provide the needed information
without cluttering the PTS with user-oriented info. For example, we
could add a link to a wiki page that would explain the procedure.

On 29/07/09 at 15:41 +0200, Bas Zoetekouw wrote:
 Correction; the was (apparently) no opposition to this
 _from_the_people_present_.  I have in the past strongly opposed this,
 and I still do.  IMO, there is no compelling reason to remove packages
 that work fine, have no (RC) bugs, and is actually being used (as
 shown by popcon.
 
 So, please do not remove packages simply because they are orphaned.

You are very welcomed to adopt and maintain all the packages that are
currently orphaned. However, as you might discover if you investigate
the list of orphaned packages, many of them don't match one of your 3
criterias. The goal is not to just remove all orphaned packages from
Debian. Our first priority continues to be our users, and packages that
are reasonably useful at least a bit maintained upstream won't be
removed (but maybe moved to experimental).
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Thomas Viehmann]

Lucas Nussbaum wrote:

(Replying to the various comments in a single mail)
On 29/07/09 at 12:15 +0100, Marco Rodrigues wrote:

- move packages to experimental

I vote for this option. If a package doesn't have an active
maintainer, it should belong to experimental suite and add some note
at PTS explaning what to do in this case.


Something that was not very clear in my mail is that the plan is to have
all the options. For each orphaned package, we can either decide:
- to remove it from debian
- to move it to experimental, if it's still marginally useful

 - to keep it in unstable/testing

Experimental is a development resource and not a dump for packages that 
should not be in unstable/testing. Abusing it sounds like a bad idea, so 
IMO think the current regime with a tad (but not overly) more aggressive 
removal once orphaned packages are more easily accessible seems like a 
good idea.


Personally, I think that old removing packages from Debian is a good 
idea. Everyone seems to be keen on removing cruft from her and his own 
computers, I don't really see that keeping cruft around in the archive 
is a necessarily beneficial when the it is already a huge problem to 
find the right package for a given job because the archive is as big as 
it is.
Just like a newspaper chooses the stories it carries, it is Debian's 
task to offer a good *selection* of packages to its users.
It would seem that even if they are not terminally broken, orphaned 
packages usually show more age, quirks, and lack of features compared to 
their currently maintained counterparts.


That said, I'm all for meritocracy, so maybe Barry and Chris should have 
the most say when they do the most QA uploads. (Hi Bas.)


Cheers

T.
--
Thomas Viehmann, http://thomas.viehmann.net/


--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Sven Hoexter]

On Thu, Jul 30, 2009 at 01:47:23PM +0200, Thomas Viehmann wrote:

Hi,

 Experimental is a development resource and not a dump for packages that  
 should not be in unstable/testing. Abusing it sounds like a bad idea, so  
 IMO think the current regime with a tad (but not overly) more aggressive  
 removal once orphaned packages are more easily accessible seems like a  
 good idea.

ACK. It feels wrong to have in exeprimental a mix of orphaned packages and
stuff under strong developement.


IMHO it would be nice to aim at a release without oraphaned packages.
Though with the discussion of a freeze in Dec. this might be ambious.
One has to see where it produces complains from other devs and users
when orphaned packages start to be missing on a larger scale.

Would it make sense to create a list of orphaned packages and start
with blocking them from entering testing (e.g. add a bug of RC priority)
and subsequently remove them, including reverse deps, from testing?
Or has someone already made such lists and played with something like this?

Sven
-- 
If God passed a mic to me to speak
I'd say stay in bed, world
Sleep in peace
   [The Cardigans - 03:45: No sleep]


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Marco Rodrigues]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Lucas Nussbaum wrote:
 Hi,
 
 Here is some notes (from memory) about the QA BOF, and the actions that
 we are likely to take during the next weeks/months.

I saw the discussion from home and it was very interesting. Thank you

 As usual, the most (only?) discussed topic was the handling of orphaned
 packages. Several ideas were discussed.
 
 Removal of orphaned packages
 
 The audience clearly want orphaned packages to be removed. I'm not quite
 sure it's reasonable to do that. However, clearly, there's no opposition
 to this idea. When snapshots.debian.org will be fully fonctional, a web
 interface will allow users to fetch and install removed packages.
 
 TODO:
 - wait for snapshots.d.o to be fully functional (weeks, not months)
 - add a note on the PTS explaining how to install packages from
   snapshots.d.o
 - remove packages

 Move of orphaned packages to another place
 ==
 Another possible solution would be to move orphaned packages to another
 section/archive area (i.e something sitting next to unstable or
 experimental), or just to experimental.
 
 This would provide a intermediate solution between keep the package in
 testing/unstable and remove the package.
 
 However, it doesn't sound easy to create another release, so the easy
 solution is to just use experimental for that.
 
 While it is technically possible for ftpmaster to move packages between
 suites, it is better to do source-ful QA uploads to experimental, and to
 file RM requests from unstable at the same time, so that process is
 documented in the changelog and the RM bug report.
 
 TODO:
 - add a note on the PTS for experimental-only packages to explain how to
   install them.
 - move packages to experimental

I vote for this option. If a package doesn't have an active maintainer, it 
should belong to
experimental suite and add some note at PTS explaning what to do in this case.

When someone adopt the package, he upload the package to unstable and the dak 
semi-automatically
script remove it from experimental, and all the process begins again.

if ($maintainer==QA)
show_link_with_howto_to_install_experimental_packages

Another thing, is provide by default in apt package the experimental suite, 
without the need
of manual user configuration, so he can do $ apt-get -t experimental install 
package easily.

I think the policy about removing packages from QA need to be changed too, so 
we know when we should
ask for a package removal, else the archive will be full of garbage.

 Raise the awareness about orphaned packages
 ===
 For developers:
 ---
 The idea of a cron script in devscripts was proposed again, and didn't
 receive much opposition. Of course it adds to the daily batch of mails
 that admins have to read, so we have to make sure that it is written in
 a useful way.
 
 TODO:
 - write the script (heavily based on wnpp-alert), and integrate it in
   devscripts
 
 For users:
 --
 liw worked on Computer Janitor[1,2], which seems to be a GUI for
 debfoster/deborphan. It could be an interesting addition to add support
 for listing orphaned packages in such a tool.
 
 [1] http://packages.ubuntu.com/jaunty/computer-janitor
 [2] 
 http://beginlinux.wordpress.com/2009/05/14/ubuntu-9-04-cleanup-with-computer-janitor/
 
 
 It is important to note that Joerg Jaspert read and ACKed this with his
 ftpmaster hat.

Nice.

- --
Marco Rodrigues

http://Marco.Tondela.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKcC9GAAoJENDqNB6bSPIzYGkQAI+LKFst4O9fcbjeu1s+7qtd
/GbXL++9hMdsmWLDtqIxaYOf0l8omfG3eZ1bbVdvvLWs2/YiOJqSAOQNnl0k5wlb
s+EXN70YnycQeBJ+EJU2PdMSgm0pJni3ax9HlQCE2DKunnydCizPDuUcXG5qtTv6
u8vP19NMbd+8LJi9g2AZeE15fWn+WkUjVbiosGN0Gzo9U+oM//tqVIRFfBoeCgc3
X0mPjKlbTOOf3+s5jYpSrky6KgPlpYutf7RozQI9mC8enxWJ0wLwdI1Ed56/E8I+
OrTsmeUJcpk5wvMS9COq1PJ5KL1Y2aEtcHRU7qpV6UHHefa7Y4d43ya4wvTzIdQK
PLwzfTLe6kQgAKxay6uLgLKHoKPuh9t2Jgt4Ni/NoCYtHsd/3GHW9IIiRXaOqh8q
8VMGLoNX6UArg/WAk9MPkGXB0dh24cYJyS00TUzS4MHyIbGzxpoAZMfQGH75+IL7
mathr9zj1JY2XLZdNTlIbQV6V/oEqmzjbA/XJvIaa0v+lzFjvGOnhoOl4s82kEmm
LF3Z40jBjDfvItn4Ce6vAS36Jg60tfkHeT/bQ1VSkJTS972iZRFgTFKn448WYNJw
YWBxnfYpf2c/TBXe5PFg6N0JKgYp8bzm06GubrBLLfknwk4FYjg6qLu+8mVvtsGY
emUWWEXj2YdmLYSRbXXc
=R/JM
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Sandro Tosi]

Hi all,

On Wed, Jul 29, 2009 at 12:53, Lucas Nussbaumlu...@lucas-nussbaum.net wrote:
 Hi,

 Here is some notes (from memory) about the QA BOF, and the actions that
 we are likely to take during the next weeks/months.

I wasn't there (eheh, you should know it ;) ) and I didn't look at the
video, so my comments could have been already raised, sorry for the
noise in that case.

 Removal of orphaned packages
 
 The audience clearly want orphaned packages to be removed. I'm not quite
 sure it's reasonable to do that. However, clearly, there's no opposition
 to this idea. When snapshots.debian.org will be fully fonctional, a web
 interface will allow users to fetch and install removed packages.

What about only remove them from testing?

- no need to do a QA upload to move to experimental (consider all
those O package that didn't receive yet a QA upload) or ftp-master
team involved (that would reduce a bit their workload, already
overloaded)
- easy of access for developers, or all those others that uses
unstable as suite, to orphaned packages, to work on them (their would
be a 'apt-get source' away)
- if your package is bind to an orphaned one to transit to testing,
you're force to adopt it or find a way to properly maintain it (it
sounds a bit hard, but that will converge to have a set of packages in
testing properly maintained without relay on orphaned pkgs)
- less work, since just a testing hint is needed, probably it can also
be automated (if we want to)

 Raise the awareness about orphaned packages
 ===
 For developers:
 ---
 The idea of a cron script in devscripts was proposed again, and didn't
 receive much opposition. Of course it adds to the daily batch of mails
 that admins have to read, so we have to make sure that it is written in
 a useful way.

about that, I though to re-implement this [1] experiment as a UDD CGI.

[1] http://people.debian.org/~morph/qa_packages_analyze.html

This allows to split the orphaned lists in subset allowing to select
packages you (or your team) care them most (for example, take all the
perl libs).

If you think it worths, I'll work on it, but nothing before ~3 weeks.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Lars Wirzenius]

ke, 2009-07-29 kello 12:53 +0200, Lucas Nussbaum kirjoitti:
 liw worked on Computer Janitor[1,2], which seems to be a GUI for
 debfoster/deborphan. It could be an interesting addition to add support
 for listing orphaned packages in such a tool.

CJ actually has nothing to do with debfoster/deborphan. It is a more
general tool for finding cruft in a system (it has nothing to do with
the cruft package either, though). There is a command line interface. It
already finds orphaned packages.



-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Bas Zoetekouw]

Hi Lucas!

You wrote:

 The audience clearly want orphaned packages to be removed. I'm not quite
 sure it's reasonable to do that. However, clearly, there's no opposition
 to this idea. When snapshots.debian.org will be fully fonctional, a web
 interface will allow users to fetch and install removed packages.

Correction; the was (apparently) no opposition to this
_from_the_people_present_.  I have in the past strongly opposed this,
and I still do.  IMO, there is no compelling reason to remove packages
that work fine, have no (RC) bugs, and is actually being used (as shown
by popcon.

So, please do not remove packages simply because they are orphaned.


Kind regards,
Bas.


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debconf QA BOF summary / handling of orphaned packages

[Stefano Zacchiroli]

On Wed, Jul 29, 2009 at 12:53:54PM +0200, Lucas Nussbaum wrote:
 - add a note on the PTS explaining how to install packages from
   snapshots.d.o
snip
 - add a note on the PTS for experimental-only packages to explain how to
   install them.

Just a comment: the PTS is not meant to be user-oriented (heck I
cannot even contain package descriptions at the moment, since we don't
have source package description!). I'm of course fine to add info
about that in those pages, but they will be more like this package is
only available from BLA than add this stanza to sources.list to get
it.

The latter kind of user information should better be pushed to some
package manager.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature