Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Tobias Frost]

Am 2. August 2017 23:48:15 MESZ schrieb Sean Whitton :
>Hello,
>
>Here is an updated diff for this bug, against the docbook version of
>the policy manual.
>
>I've also included a purely informative change which emphasises that
>packages that are team maintained in name only should be orphaned
>properly, with their maintainer field set to the QA team.  This is
>already current best practice, but it's worth emphasising, because one
>might fail to orphan a package on the grounds that "someone else on the
>team might fix it", which is not true of a lot of teams.
>
>This purely informative change came out of a discussion at DebCamp with
>h01ger, gregoa and David Bremner.  We are CCing -devel because we want
>to determine if there remains, in 2017, a consensus that we should not
>drop this requirement.  We think that recent objections in the bug are
>about implementation details, rather than a concern to retain humans in
>the uploaders field.
>
>diff --git a/policy.xml b/policy.xml
>index 3daa532..4731507 100644
>--- a/policy.xml
>+++ b/policy.xml
>@@ -1128,13 +1128,6 @@
> described in .
>   
>   
>-If the maintainer of the package is a team of people with a
>shared
>-email address, the Uploaders control field
>must
>-be present and must contain at least one human with their
>personal
>-email address.  See  for the
>syntax
>-of that field.
>-  
>-  
>   An orphaned package is one with no current maintainer.  Orphaned
>   packages should have their Maintainer control
> field set to Debian QA Group
>@@ -1149,6 +1142,12 @@
>   
> 
>   
>+  
>+This includes packages with a group of people or team in the
>+Maintainer control field.  They should be
>+orphaned if the team is not actively maintaining the package.
>+  
>+
> 
> 
> 
>@@ -3448,13 +3447,6 @@ endif
>Maintainer field, and multiple entries must be comma separated.
> 
> 
>-  This is normally an optional field, but if the
>-  Maintainer control field names a group of
>-  people and a shared email address, the
>-  Uploaders field must be present and must
>-  contain at least one human with their personal email
>address.
>-
>-
> The Uploaders field in debian/control can
>   be folded.
> 

Dear all,

(Please appologize the brevity, I don't have the time needed to word that
properly)

Well, I still think that not having a human explicitly named as in charge of
the package is not good and will cause more damage than it will bring
benefits.
(Disclaimer: My view is biased with my actitivies in the MIA team)

Some remarks / questions I do not see adressed:
- If you have not a name on some task human nature tends toward that nonone
feels responsible at all. Like the German (fun) expansion of TEAM: Toll, Ein
Anderer Machts (Great, someone else it taking care)
- MANY team homepages are not updated or do not even exist. I think before
droping the requirement to have human uploaders this needs to be fixed by
policy and it must be RC(?) bug if the team homepage is
outdated/absent/inaccurate. The infomation about the teams *must* be in a way
that it can be easily found/parsed.
- There is currently no way to map a person to a team or to map a team to a
list of members -- if you need accurary. This is especially true for teams
that are smaller. - - When someon is going e.g MIA, we need to know which
teams are involved to trigger them.
- Not in all teams it is working tha everyone is looking at every package.
During the lipng transistion I filed many bugs on team-managed packages which
were never answered
- We have already the problem about "partially MIA" -- people holding several
pacakgages but neglecting several of them. Currently we have no real measures
of taking care of the neglected one, MIA team wise. This will be amplified
when there is no human responsible person named.

--
tobi

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Bill Allombert]

On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote:
> Bill Allombert  writes:
> > On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
> 
> >> I've also included a purely informative change which emphasises that
> >> packages that are team maintained in name only should be orphaned
> >> properly, with their maintainer field set to the QA team.  This is
> >> already current best practice, but it's worth emphasising, because one
> >> might fail to orphan a package on the grounds that "someone else on the
> >> team might fix it", which is not true of a lot of teams.
> 
> > You are omitting the case of a team which get reduced to a single
> > member, in which case the package need not be orphaned. Yet it is
> > important the fact is mentionned in the package.
> 
> I don't think I understand the objection.  Sean's proposed wording seems
> fine for that case -- it just says that the package should be orphaned if
> the team is not maintaining it, which shouldn't depend on the size of the
> team.

The patch also remove the requirement to list individual email of the
maintainers. That is what I am objecting to.

When a team is reduced to a single individual, it is no more a team, yet
the package is still maintained and need not be orphaned.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
>...
> I've also included a purely informative change which emphasises that
> packages that are team maintained in name only should be orphaned
> properly, with their maintainer field set to the QA team.  This is
> already current best practice, but it's worth emphasising, because one
> might fail to orphan a package on the grounds that "someone else on the
> team might fix it", which is not true of a lot of teams.
>...
> @@ -1149,6 +1142,12 @@
>
>  
>
> +  
> +This includes packages with a group of people or team in the
> +Maintainer control field.  They should be
> +orphaned if the team is not actively maintaining the package.
> +  
> +
>  
>  
>  
>...

Please be more thoughtful about the consequences of such changes to policy.

This would not be "a purely informative change".

Your suggested wording has the potential to create a HUGE amount of tensions.

I could name a lot of team-maintained packages where a team member 
uploads a new upstream version every 1-2 years and noone ever bothers
to handle incoming bugs.[1]

If policy does not provide a definition of "actively maintaining",
it would be a reasonable interpretation to consider a package with
no upload or visible activity in new open bugs during the past
6 or 12 months as not actively maintained.

If policy states that such packages "should be orphaned" without 
describing a proper process, it is a valid reading that everyone can do 
this without trying to contact the team prior to orphaning the package.

And it does not even help with the problem Tobias raised:

When a maintainer retires or is declared MIA by the MIA team according 
to the MIA process, how can you *find* all teams and team-maintained 
packages where this maintainer was the only or last active team member
when there is no Uploaders: field?

This information could be moved from the Uploaders: field to
a database, but then this database has to exist and maintaining
the information there has to be mandatory when no Uploaders: field
is present.

Another option would be to keep the Uploaders: requirement,
but make it more clear that autogenerating is permitted.

The GNOME team already generates Uploaders: as the intersection
of current team members and people who did the latest 10 uploads
of a package.

cu
Adrian

[1] a few people are IMHO just bad maintainers, but in the common
case there is simply too much work for too few people in a
volunteer project and new team members are always welcome

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 11:01:24AM +0200, Bill Allombert wrote:
> On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote:
> > Bill Allombert  writes:
> > > On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
> > 
> > >> I've also included a purely informative change which emphasises that
> > >> packages that are team maintained in name only should be orphaned
> > >> properly, with their maintainer field set to the QA team.  This is
> > >> already current best practice, but it's worth emphasising, because one
> > >> might fail to orphan a package on the grounds that "someone else on the
> > >> team might fix it", which is not true of a lot of teams.
> > 
> > > You are omitting the case of a team which get reduced to a single
> > > member, in which case the package need not be orphaned. Yet it is
> > > important the fact is mentionned in the package.
> > 
> > I don't think I understand the objection.  Sean's proposed wording seems
> > fine for that case -- it just says that the package should be orphaned if
> > the team is not maintaining it, which shouldn't depend on the size of the
> > team.
> 
> The patch also remove the requirement to list individual email of the
> maintainers. That is what I am objecting to.
> 
> When a team is reduced to a single individual, it is no more a team, yet
> the package is still maintained and need not be orphaned.

Your objection does not make sense.

The change Sean is proposing is intended to make providing the 
information about team members in Uploaders: optional.

If are not objecting to removing the information about who is in a team,
you cannot suggest that anything should be done based on the no longer 
existing information about the number of team members.

> Cheers,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 12:30:11PM +0300, Adrian Bunk wrote:
> On Thu, Aug 03, 2017 at 11:01:24AM +0200, Bill Allombert wrote:
> > On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote:
> > > Bill Allombert  writes:
> > > > On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
> > > 
> > > >> I've also included a purely informative change which emphasises that
> > > >> packages that are team maintained in name only should be orphaned
> > > >> properly, with their maintainer field set to the QA team.  This is
> > > >> already current best practice, but it's worth emphasising, because one
> > > >> might fail to orphan a package on the grounds that "someone else on the
> > > >> team might fix it", which is not true of a lot of teams.
> > > 
> > > > You are omitting the case of a team which get reduced to a single
> > > > member, in which case the package need not be orphaned. Yet it is
> > > > important the fact is mentionned in the package.
> > > 
> > > I don't think I understand the objection.  Sean's proposed wording seems
> > > fine for that case -- it just says that the package should be orphaned if
> > > the team is not maintaining it, which shouldn't depend on the size of the
> > > team.
> > 
> > The patch also remove the requirement to list individual email of the
> > maintainers. That is what I am objecting to.
> > 
> > When a team is reduced to a single individual, it is no more a team, yet
> > the package is still maintained and need not be orphaned.
> 
> Your objection does not make sense.
> 
> The change Sean is proposing is intended to make providing the 
> information about team members in Uploaders: optional.
> 
> If are not objecting to removing the information about who is in a team,
> you cannot suggest that anything should be done based on the no longer 
> existing information about the number of team members.

Re-reading, I might understand what caused the misunderstanding:

This bug is about making providing the information about team members
in Uploaders: optional.

That's the core point discussed.

The part you were referring to is an attempt from Sean to address some 
problems caused by this change. This is not a standalone proposal.

If Uploaders: stays mandatory, we do not need new rules for orphaning 
team maintained packages that compensate for the no longer available 
information about team membership.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bits from the 10th Debian Groupware Meeting

[Rainer Dorsch]

Hi Guido,

just wondering, did you consider nextcloud as groupware?

Thanks
Rainer

Am Mittwoch, 2. August 2017, 19:44:14 CEST schrieb Guido Günther:
> Hi,
> The 10th Debian Groupware Meeting[1] was held on a weekend in April in
> the LinuxHotel, Essen, Germany[2]. We were five people altogether.
> 
> This is a short overview of what we worked on during the weekend:
> 
> * The groupware page[3] got far more than the usual update and was
>   completely reworked. It now gives a better overview about client and
>   server packages already included in Debian and prospective new
>   packages.
> 
> * Several bugs in Calypso were fixed including adding bcrypt support,
>   fixes for newer python-vobject and some patches towards python3
>   support.
> 
> * There was further work on getting zarafa-webapp initially into
>   Debian. This included adding support for different http servers.
>   A first upload is underway[4]. There was also work on updating
>   kopanocore and it's dependencies such as libvmime.
> 
> * We made the preparations for the first upload of the now renamed
>   Icedove to Thunderbird to stable / oldstable. This included fixing
>   bugs in the profile migration and preparing updates for packages that
>   still had an unversioned conflict on Thunderbird.
> 
> * Several bugs in DAViCal were fixed, reported or commented on and
>   there was some work on running tests with caldav-tester. Integration
>   with khal/vdirsyncer was also tested.
> 
> * A new upstream snapshot of Radicale was uploaded to experimental.
>   Integration with vdirsyncer was tested.
> 
> * A new upstream release of uWSGI was packaged and uploaded. Some of the
>   fixed bugs affected applications like Radiale.
> 
> Again we had a mix of first timers, Debian Maintainers, upstreams and Debian
> Developers with lots of room for discussion, barbecue and bug squashing.
> 
> Cheers,
>  -- Guido (on behalf of the Debian Groupware Meeting attendees)
> 
> [1]: https://wiki.debian.org/GroupwareMeeting2017-04-07to09
> [2]: http://www.linuxhotel.de/community.html
> [3]: https://wiki.debian.org/Groupware
> [4]: https://github.com/tijuca/zarafa-webapp


-- 
Rainer Dorsch
http://bokomoko.de/

Re: Bits from the 10th Debian Groupware Meeting

[Martin Steigerwald]

Hello Rainer.

Rainer Dorsch - 03.08.17, 13:12:
> Hi Guido,
> 
> just wondering, did you consider nextcloud as groupware?

Owncloud has been in Debian… and its past maintainers gave up on maintaining 
it. For a part of the discussion see:

Debian Bug report logs - #822681
RM: owncloud -- ROM; Unfit upstream, uninstallable
https://bugs.debian.org/822681

[Pkg-owncloud-maintainers] Removing owncloud from jessie?
https://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/2017-March/
003200.html

[Pkg-owncloud-maintainers] You want users to lose data?!?!
https://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/2016-February/002881.html


[Pkg-owncloud-maintainers] Bug#815963: Warn users about unsupported upgrade 
path
[Pkg-owncloud-maintainers] Upstream making our life more and more painful 
(Was: [owncloud-devel] Bug#815963: Warn users about unsupported upgrade path)  
https://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/2016-February/002872.html

Debian Bug report logs - #815963
Warn users about unsupported upgrade path
https://bugs.debian.org/815963

I think unless there are significant changes in how upstream handles updates… 
or… in the way how Debian handles webapps it may be difficult to find a 
maintainer for official Nextcloud Debian packages.

Thank you,
-- 
Martin

signature.asc
Description: This is a digitally signed message part.

Bug#655420: ITP: jtransforms -- A multithreaded FFT library written in pure Java

[Carnë Draug]

Package: wnpp
Followup-For: Bug #655420
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

Re: Bits from the 10th Debian Groupware Meeting

[Rainer Dorsch]

Hi Martin,

thank you for all the links.  My main question was why it is not listed at all 
in the groupware wiki, you could easily list nextcloud/owncloud in the section 
"Groupware projects not currently considered for inclusion in Debian".

I always had the impression that part of the motivation for owncloud to 
collaborate with downstream, that owncloud wanted to preserve their business 
model to sell enterprise support.

For the technical part, I am wondering if that is still a real issue. I see 
the latest version 12.0.0 was released at May 22 2017, since then there was 
not even a bugfix release. Before, I remember that I have seen much shorter 
release cycles.

So I can see multiple solutions
1) Debian includes nextcloud only in unstable and testing (probably most 
compatible with the nextcloud/owncloud business models, see also https://
help.nextcloud.com/t/will-nextcloud-be-inviting-to-distribution-packages/89/28 
)
2) If Nexcloud is interested to bring their software into the debian repo, 
they can help run their regression tests on the upgrade path implemented for 
Debian stable releases (which happens infrequently)
3) If only Debian is interested to have nextcloud, assuming that there are 
only 1-2 major nextcloud releases within a Debian release, Debian might be 
able to handle the upgrade path.

Kind regards
Rainer

Am Donnerstag, 3. August 2017, 14:07:29 CEST schrieb Martin Steigerwald:
> Hello Rainer.
> 
> Rainer Dorsch - 03.08.17, 13:12:
> > Hi Guido,
> > 
> > just wondering, did you consider nextcloud as groupware?
> 
> Owncloud has been in Debian… and its past maintainers gave up on maintaining
> it. For a part of the discussion see:
> 
> Debian Bug report logs - #822681
> RM: owncloud -- ROM; Unfit upstream, uninstallable
> https://bugs.debian.org/822681
> 
> [Pkg-owncloud-maintainers] Removing owncloud from jessie?
> https://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/2017-Marc
> h/ 003200.html
> 
> [Pkg-owncloud-maintainers] You want users to lose data?!?!
> https://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/2016-Febr
> uary/002881.html
> 
> 
> [Pkg-owncloud-maintainers] Bug#815963: Warn users about unsupported upgrade
> path
> [Pkg-owncloud-maintainers] Upstream making our life more and more painful
> (Was: [owncloud-devel] Bug#815963: Warn users about unsupported upgrade
> path)
> https://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/2016-Feb
> ruary/002872.html
> 
> Debian Bug report logs - #815963
> Warn users about unsupported upgrade path
> https://bugs.debian.org/815963
> 
> I think unless there are significant changes in how upstream handles
> updates… or… in the way how Debian handles webapps it may be difficult to
> find a maintainer for official Nextcloud Debian packages.
> 
> Thank you,


-- 
Rainer Dorsch
Beatus-Widmann-Str. 5
72138 Kirchentellinsfurt
07157-734133
email: fdb...@bokomoko.de

Bug#870625: ITP: libengine-gost-openssl1.1 -- Loadable module for openssl implementing GOST algorithms

[Wartan Hachaturow]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: libengine-gost-openssl1.1
Version: 1
Upstream Author: Many
URL: https://github.com/gost-engine/
License: OpenSSL license
Description: This package contains loadable module for openssl
 library, which implements (in software) Russian national standard
 (GOST) cryptograpy algorithms.

-- 
Regards, Wartan.

Re: Bits from the 10th Debian Groupware Meeting

[Guido Günther]

Hi,
On Thu, Aug 03, 2017 at 01:12:55PM +0200, Rainer Dorsch wrote:
> Hi Guido,
> 
> just wondering, did you consider nextcloud as groupware?

Yes. I had owncl...@packages.debian.org on the list of people
contacted.
 -- Guido

Re: Bits from the 10th Debian Groupware Meeting

[Adam D. Barratt]

On 2017-08-03 14:21, Rainer Dorsch wrote:

So I can see multiple solutions
1) Debian includes nextcloud only in unstable and testing (probably 
most
compatible with the nextcloud/owncloud business models, see also 
https://

help.nextcloud.com/t/will-nextcloud-be-inviting-to-distribution-packages/89/28


I have no particular comment on the remainder of the discussion, but the 
above would be "only in unstable". Packages that aren't intended to be 
part of the next stable release shouldn't be in testing.


Regards,

Adam

Re: Bits from the 10th Debian Groupware Meeting

[Christian Seiler]

Hi,

On 08/03/2017 03:21 PM, Rainer Dorsch wrote:
> thank you for all the links.  My main question was why it is not listed at 
> all 
> in the groupware wiki, you could easily list nextcloud/owncloud in the 
> section 
> "Groupware projects not currently considered for inclusion in Debian".

It's a wiki, feel free to add it. :)

> For the technical part, I am wondering if that is still a real issue. I see 
> the latest version 12.0.0 was released at May 22 2017, since then there was 
> not even a bugfix release.

In terms of Debian release cycles that is still a very short time.

And the main issue here wasn't the release frequency; the main issues
were:

 - most importantly: how to support updates from Debian release X to
   X + 1, and upstream didn't want to support that at all, because the
   amount of minor versions between two Debian releases was too much

 - also  how Debian can provide security support for the package during
   the lifetime of a Debian release (though this was never a showstopper
   in this case as far as I understand it)

And while nextcloud is a fork of owncloud, many of the people that
forked it were part of the original owncloud project.

My primary impression is that there's a mindset gap here: what I
really like about Debian stable - especially for servers - is that
the software included doesn't change except for security updates
and other serious bugs. Especially if I administer something, and
that something is not the primary thing I'm interested in in my
daily life, then I really want to be able to basically install and
forget the whole thing. And Debian provides me with that opportunity.
And Debian provides the opportunity that when I upgrade Debian once
every two or three years I can migrate my installation and only
have to test invasive changes _once_ at that point.

If I continuously update a package that is simply not the case. On
every update will I have to make sure that the new package doesn't
break anything. And that'd be fine if that specific package were
the primary thing I'm interested in, but that is not true for most
things.

So sure, someone whose job it is to run a service will not be
interested in Debian stable's packages for that service. They'll
use an own installation thereof. And that's perfectly fine. For
example, Wikipedia is not going to use Debian stable with th
MediaWiki packages from Debian on their systems - because it just
doesn't make sense to them. But a company that just wants to run
an internal Wiki for their own things might be very interested in
Debian's packages for MediaWiki because they have better things
to do than constantly administer a Wiki.

My impression with Owncloud/Nextcloud was that the developers are
not interested in the "install & forget for 2 years" use case of
their software. Which is fine, after all they're giving away their
software for free, but which also means that the fact that Fedora
and Debian dropped the packages is only a symptom of a larger
problem: I personally just can't recommend Owncloud/Nextcloud.
Because if I install that manually or via some other mechanism
upstream provides (e.g. Snap packages) I still have to deal with
the fact that every update is going to be something that might
require quite a bit of manual intervention. Again: for someone
whose job it is to administer an Owncloud/Nextcloud instance
that would be perfectly fine, but it's not something I want to
have to deal with, and my guess is that a lot of other people
don't want to have to deal with.

And I have not seen anything by the Owncloud/Nextcloud devs that
this attitude has changed. I don't begrudge them their opinions
in this problem space, but that just means that their software is
simply not for me.

> So I can see multiple solutions
> 1) Debian includes nextcloud only in unstable and testing (probably most 
> compatible with the nextcloud/owncloud business models, see also https://
> help.nextcloud.com/t/will-nextcloud-be-inviting-to-distribution-packages/89/28
>  
> )

You could have it in unstable-only, but anything in testing
targets the next stable release of Debian, and if a package is
not a candidate for a stable Debian release, it shouldn't be in
testing.

> 2) If Nexcloud is interested to bring their software into the debian repo, 
> they can help run their regression tests on the upgrade path implemented for 
> Debian stable releases (which happens infrequently)

Well, sure, if they were interested in supporting these kinds
of upgrade paths, which they strongly implied that they are
not.

Regards,
Christian

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Bill Allombert  writes:

> The patch also remove the requirement to list individual email of the
> maintainers. That is what I am objecting to.

Oh, okay, I see that, but I'm not sure why.  What is the purpose of
listing those email addresses that you want to preserve?

> When a team is reduced to a single individual, it is no more a team, yet
> the package is still maintained and need not be orphaned.

It still is a team even when it's one individual.  I don't know why you
would say that it's not.  A team can certainly contain just one person.

I'm confused about how this is at all related to listing individual email
addresses, and I don't understand why you think this would result in a
package being orphaned.

-- 
Russ Allbery (r...@debian.org)   

Re: Bits from the 10th Debian Groupware Meeting

[Jonas Smedegaard]

Quoting Rainer Dorsch (2017-08-03 09:21:37)
> thank you for all the links.  My main question was why it is not 
> listed at all in the groupware wiki, you could easily list 
> nextcloud/owncloud in the section "Groupware projects not currently 
> considered for inclusion in Debian".

The wiki page only tracks things that are, well, tracked.

Please share your ideas for packaging nextcloud at 
http://bugs.debian.org/835086 - i.e. by posting not here but to 
835...@bugs.debian.org which is read by those actively working on it, 
now or later.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Bits from the 10th Debian Groupware Meeting

[Martin Steigerwald]

Hi.

Christian Seiler - 03.08.17, 17:34:
> On 08/03/2017 03:21 PM, Rainer Dorsch wrote:
> > thank you for all the links.  My main question was why it is not listed at
> > all in the groupware wiki, you could easily list nextcloud/owncloud in
> > the section "Groupware projects not currently considered for inclusion in
> > Debian".
> It's a wiki, feel free to add it. :)
> 
> > For the technical part, I am wondering if that is still a real issue. I
> > see
> > the latest version 12.0.0 was released at May 22 2017, since then there
> > was
> > not even a bugfix release.
> 
> In terms of Debian release cycles that is still a very short time.
> 
> And the main issue here wasn't the release frequency; the main issues
> were:
> 
>  - most importantly: how to support updates from Debian release X to
>X + 1, and upstream didn't want to support that at all, because the
>amount of minor versions between two Debian releases was too much

Yes. You nicely summarized it. Seafile for example has from/to versioned update 
scripts. And an update between several releases is easy: You just run all the 
update scripts in between. Owncloud didn´t provide for this and David Prévot  
back then put a lot of work around it, only to be accused of irresponsible by 
 Jos Poortvliet.

> My primary impression is that there's a mindset gap here: what I
> really like about Debian stable - especially for servers - is that
> the software included doesn't change except for security updates
> and other serious bugs. Especially if I administer something, and
> that something is not the primary thing I'm interested in in my
> daily life, then I really want to be able to basically install and
> forget the whole thing. And Debian provides me with that opportunity.
> And Debian provides the opportunity that when I upgrade Debian once
> every two or three years I can migrate my installation and only
> have to test invasive changes _once_ at that point.

Yes, and thats a principal mind gap between many web application developers 
and Debian.

I concur with your preference here. I don´t want to upgrade to major new 
software versions all three month. Thus I plan to install Seafile instead, but 
AFAIK there are only Seafile client packages ready for Debian. I´d love to see 
official Debian packages for the server component, but currently see myself 
putting time into this.
 
> > 2) If Nexcloud is interested to bring their software into the debian repo,
> > they can help run their regression tests on the upgrade path implemented
> > for Debian stable releases (which happens infrequently)
> 
> Well, sure, if they were interested in supporting these kinds
> of upgrade paths, which they strongly implied that they are
> not.

Fairly enough this was with Owncloud upstream… and more than a year ago. I 
believe many Owncloud developers moved on to Nextcloud… so I belief Nextcloud 
upstream consists of mostly the same people… I never really confirmed that 
belief, beyond anecdotical statements I read in several blog posts.

Thanks,
-- 
Martin

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Sean Whitton]

On Thu, Aug 03, 2017 at 12:06:16PM +0300, Adrian Bunk wrote:
> Please be more thoughtful about the consequences of such changes to policy.
> 
> This would not be "a purely informative change".
> 
> Your suggested wording has the potential to create a HUGE amount of tensions.

You're right.  After sending my patch I realised that it contains the
word "should", which is a magic word in policy, imposing a normative
requirement.  This was not intended.

My intended meaning: it is already best practice that *other team
members* should orphan a package if they know that no-one in the team is
actively taking care of it *according to their judgement of 'actively'*.

Would you agree that this is already established best practice?

> And it does not even help with the problem Tobias raised:
> 
> When a maintainer retires or is declared MIA by the MIA team according 
> to the MIA process, how can you *find* all teams and team-maintained 
> packages where this maintainer was the only or last active team member
> when there is no Uploaders: field?

I'll reply to this when replying to Tobias' remarks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Sean Whitton]

Hello Tobias,

Thank you for writing about this bug from the MIA team's perspective,
which is very relevant to resolving this.

On Thu, Aug 03, 2017 at 08:44:36AM +0200, Tobias Frost wrote:
> Some remarks / questions I do not see adressed:
> - If you have not a name on some task human nature tends toward that nonone
> feels responsible at all. Like the German (fun) expansion of TEAM: Toll, Ein
> Anderer Machts (Great, someone else it taking care)

In most teams, this happens anyway -- I would take this as an argument
against team maintenance more generally.

> - MANY team homepages are not updated or do not even exist. I think before
> droping the requirement to have human uploaders this needs to be fixed by
> policy and it must be RC(?) bug if the team homepage is
> outdated/absent/inaccurate. The infomation about the teams *must* be in a way
> that it can be easily found/parsed.
> - There is currently no way to map a person to a team or to map a team to a
> list of members -- if you need accurary. This is especially true for teams
> that are smaller. - - When someon is going e.g MIA, we need to know which
> teams are involved to trigger them.

For teams on alioth, would you find the list of team members on the
alioth project insufficient?

I agree this doesn't help with teams that do not use alioth but are
based around a mailing list.

As Adrian said, it's not clear what an alternative to Uploaders would
be for this purpose.  But I'm not sure that Uploaders is much use,
either, because in so many teams it's simply not kept up-to-date.

> - Not in all teams it is working tha everyone is looking at every package.
> During the lipng transistion I filed many bugs on team-managed packages which
> were never answered

Right, but having some random team members listed in Uploaders: doesn't help.

> - We have already the problem about "partially MIA" -- people holding several
> pacakgages but neglecting several of them. Currently we have no real measures
> of taking care of the neglected one, MIA team wise. This will be amplified
> when there is no human responsible person named.

Could you explain further how this would amplify the problem?  I agree
that this is a serious problem, but I don't see how this change would
amplify it.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Tobias Frost]

Am Donnerstag, den 03.08.2017, 12:44 -0400 schrieb Sean Whitton:
> Hello Tobias,
> 
> Thank you for writing about this bug from the MIA team's perspective,
> which is very relevant to resolving this.
> 
> On Thu, Aug 03, 2017 at 08:44:36AM +0200, Tobias Frost wrote:
> > Some remarks / questions I do not see adressed:
> > - If you have not a name on some task human nature tends toward
> > that nonone
> > feels responsible at all. Like the German (fun) expansion of TEAM:
> > Toll, Ein
> > Anderer Machts (Great, someone else it taking care)
> 
> In most teams, this happens anyway -- I would take this as an
> argument
> against team maintenance more generally.
> 
> > - MANY team homepages are not updated or do not even exist. I think
> > before
> > droping the requirement to have human uploaders this needs to be
> > fixed by
> > policy and it must be RC(?) bug if the team homepage is
> > outdated/absent/inaccurate. The infomation about the teams *must*
> > be in a way
> > that it can be easily found/parsed.
> > - There is currently no way to map a person to a team or to map a
> > team to a
> > list of members -- if you need accurary. This is especially true
> > for teams
> > that are smaller. - - When someon is going e.g MIA, we need to know
> > which
> > teams are involved to trigger them.
> 
> For teams on alioth, would you find the list of team members on the
> alioth project insufficient?

The lists on alioth are hardly accurate. Also, as you say:

> I agree this doesn't help with teams that do not use alioth but are
> based around a mailing list.

This and in combination that team information is not in an defined
location makes it quite hard to find useful, accurate information.
Not mentioning that there is no way to do an lookup in which teams
someone is; so there is no way to trigger them to act when e.g someone
has left the project and did not clean up after them.

Some time ago I did some spring cleaning going over DDs that have
retired but still in the Maintainer/Uploader fields: There were quite a
 lot "team maintained" packages where the team did not recognize that
the (sole) Uploader wasn't there anymore and the packages were
bitrotting. Without the Uploader field there would have been excactly
zero change to find those packages and get them back into maintainance
again. 

 
> As Adrian said, it's not clear what an alternative to Uploaders would
> be for this purpose.  But I'm not sure that Uploaders is much use,
> either, because in so many teams it's simply not kept up-to-date.

Removing the requirement won't help here either; It would just mask
this fact and makes it harder for other parties to detect this.

I think the "how can I contact somone on the team" could be fixed, like
(brainstomring) e.g by a Team-Contact field in d/control with an human
contact and formalizing requirements on a Team so that they are allowed
to drop the Uploaders -- if they fulfill this requirements. One
requirement could be e.g  that the team has a site on the Wiki and we
need some central place to record the team members and a mandatory
enrollment process (like the yearly team member ping that the perl team
does, AFAIK)

> > - Not in all teams it is working tha everyone is looking at every
> > package.
> > During the lipng transistion I filed many bugs on team-managed
> > packages which
> > were never answered
> 
> Right, but having some random team members listed in Uploaders:
> doesn't help.

This is not the point I wanted to make: In my experience if there is
NOT a name tacked to an task, the likelyhood of noone will feel
responsible and the task not done is very high. 

> > - We have already the problem about "partially MIA" -- people
> > holding several
> > pacakgages but neglecting several of them. Currently we have no
> > real measures
> > of taking care of the neglected one, MIA team wise. This will be
> > amplified
> > when there is no human responsible person named.
> 
> Could you explain further how this would amplify the problem?  I
> agree
> that this is a serious problem, but I don't see how this change would
> amplify it.

Relates to the "if there is no name attached to a task" thing explained
above. 
Also mind that we really do not have processes at hand to handle those
situations. The MIA team has already now no actual power on "partially
MIA" situations, but in the past it often helped to write a nice mail.
If I write to the anonymity of a team mailing list, I guess those mails
will be more easily ignored.

-- 
tobi 

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Jonas Smedegaard]

Quoting Russ Allbery (2017-08-03 11:41:12)
> Bill Allombert  writes:
> 
> > The patch also remove the requirement to list individual email of the
> > maintainers. That is what I am objecting to.
> 
> Oh, okay, I see that, but I'm not sure why.  What is the purpose of
> listing those email addresses that you want to preserve?
> 
> > When a team is reduced to a single individual, it is no more a team, yet
> > the package is still maintained and need not be orphaned.
> 
> It still is a team even when it's one individual.  I don't know why you
> would say that it's not.  A team can certainly contain just one person.
> 
> I'm confused about how this is at all related to listing individual email
> addresses, and I don't understand why you think this would result in a
> package being orphaned.

Do the MIA team also track MIA teams?

My concern is that packages without maintainers may go unnoticed when 
none of its previously active maintainers were tracked individually.

For such detection of abandonment we need not track _all_ active 
maintainers, but at least one - as individual.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Jonas Smedegaard  writes:

> Do the MIA team also track MIA teams?

> My concern is that packages without maintainers may go unnoticed when 
> none of its previously active maintainers were tracked individually.

> For such detection of abandonment we need not track _all_ active 
> maintainers, but at least one - as individual.

Or track MIA teams, which in a lot of ways is a much easier problem, and
seems like a worthwhile problem to solve anyway.

I don't feel like dropping the Uploaders field for team-maintained
packages if the team so chooses will make MIA tracking substantially
harder, or will make orphaned package tracking substantially harder.

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Tobias Frost  writes:

> Some time ago I did some spring cleaning going over DDs that have
> retired but still in the Maintainer/Uploader fields: There were quite a
> lot "team maintained" packages where the team did not recognize that the
> (sole) Uploader wasn't there anymore and the packages were
> bitrotting. Without the Uploader field there would have been excactly
> zero change to find those packages and get them back into maintainance
> again.

I'm dubious about this assertion and would like to dig into it a bit more.

The way we hopefully would find bitrotting packages is that they are,
well, bitrotting.  This is based on lack of uploads, open bugs, old Policy
versions, incomplete transitions, and in serious cases, missing from
stable releases.  While we can *also* find bitrotting packages via the MIA
process, it shouldn't be our primary or even a major way of finding them
since it's entirely possible for someone to be quite active in Debian
while still neglecting some of their packages.

Keeping around uploader information that we know gets constantly out of
date and is kind of irritating to maintain, plus results in noise for team
members that they don't want, just so that we can detect packages that
aren't being worked on feels like putting the cart before the horse.  It's
pretty obvious *from the package* if a package isn't being worked on.  And
detection based on uploaders isn't even accurate: there are teams that use
semi-automated tools and sprints and mass uploads to maintain tons of
packages, and listing themselves as Uploaders on everything they touch is
just extra work and doesn't carry any useful meaning.

Currently, when the MIA team finds someone who is no longer active, teams
have to go do a bunch of work to strip their name out of uploader fields.
That work doesn't really make Debian any better; it's just bookkeeping.
When the team has other ways of knowing the health of their packages, I'd
like to let them not do this bookkeeping.

> I think the "how can I contact somone on the team" could be fixed, like
> (brainstomring) e.g by a Team-Contact field in d/control with an human
> contact and formalizing requirements on a Team so that they are allowed
> to drop the Uploaders -- if they fulfill this requirements.

We already have a way of contacting the team: the address in the
Maintainer field.  I feel like we're inventing extra complexity without a
good motivating reason for it.  If no one replies to mail to that address,
I'm dubious you're going to get much more of an (actually useful) reply to
mailing individuals either.

> One requirement could be e.g that the team has a site on the Wiki and we
> need some central place to record the team members and a mandatory
> enrollment process (like the yearly team member ping that the perl team
> does, AFAIK)

This feels like way more bureaucratic structure than Debian needs.  What
specific problem in Debian are you trying to solve with this sort of
formal org chart maintenance?  I think this is quickly going to get out of
date, and it's not particularly compatible with structures like the Perl
team, which has tons of members doing varying amounts of work based on
their available time and energy and knowledge.

> This is not the point I wanted to make: In my experience if there is NOT
> a name tacked to an task, the likelyhood of noone will feel responsible
> and the task not done is very high.

And yet I can name counter-examples, such as the Perl team who maintain
hundreds of packages as a team effort and do not look out for *only* the
packages they personally care about.

Packaging teams that aren't doing a great job of maintaining their
packages will continue to not do a great job of maintaining their packages
whether or not they're listed as uploaders.  We already have other tools
for finding packages that aren't well-maintained.  I can see the argument
for keeping uploaders if it gave people some motivation to work on those
packages, but in practice (and I say this as someone who has been a member
of a ton of packaging teams), the uploaders changes quickly become just a
minor bit of bureaucratic housekeeping that I do once and then never look
at again, and I stopped looking at my package list on qa.debian.org
because it became useless due to all the team noise.  So I don't think
this is achieving what you intend to achieve.

> Also mind that we really do not have processes at hand to handle those
> situations. The MIA team has already now no actual power on "partially
> MIA" situations, but in the past it often helped to write a nice mail.
> If I write to the anonymity of a team mailing list, I guess those mails
> will be more easily ignored.

I agree that this is a problem, but this is a problem regardless, and we
will need to address this regardless.  I don't think it's closely related.

(I am entirely in favor of giving the MIA team more actual power.)

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Christian Seiler]

On 08/03/2017 08:58 PM, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> 
>> Do the MIA team also track MIA teams?
> 
>> My concern is that packages without maintainers may go unnoticed when 
>> none of its previously active maintainers were tracked individually.
> 
>> For such detection of abandonment we need not track _all_ active 
>> maintainers, but at least one - as individual.
> 
> Or track MIA teams, which in a lot of ways is a much easier problem, and
> seems like a worthwhile problem to solve anyway.
> 
> I don't feel like dropping the Uploaders field for team-maintained
> packages if the team so chooses will make MIA tracking substantially
> harder, or will make orphaned package tracking substantially harder.

I wonder whether we are framing this in the right way anyway. There
are two orthogonal questions in my mind:

 - is a specific person MIA?

 - is a package still maintained?

There is not necessarily a direct relation between both questions.
Take for example a person who someone in this thread called
"partially MIA" (I don't like that term btw.): they still actively
maintain a bunch of packages, but have dropped the ball on another
package.

On the other hand you could have a package that has
Maintainer: some team and Uploaders: some person, where "some
person" is actually MIA, but the rest of the team is still actively
maintaining the package.

The main problem I see with Uploaders: is that it's often not really
up to date. So I do think that it might be a good idea to track the
people who are responsible for a package outside of the package
itself in some kind of central database that is not tied to package
uploads. This could also make it easy to query that database. On the
other hand I would not want to maintain a team membership list for
this purpose, but track by package, because while there are small
teams where everyone is responsible for every single package, there
are also larger teams where not everyone cares about every single
package that the team maintains. So I don't think the Uploaders:
field in a package is useless, I just think the current way of
storing that information is not the best way to do so. But until
such a central database is ready for usage, I don't think it would
be wise to drop Uploaders: at the moment, because otherwise that
information can't be tracked at all.

To help with the question of whether a package is still being
actively maintained, let me frame it in this way: I think it is
not completely unreasonable to say that _most_ packages will be
updated at least once every 12 months in sid or experimental. (The
precise number is subject to bikeshedding.) Of course that's not
true for every package, there are some packages which don't require
updates that often. So what one could do is the following: a
package is considered to be actively maintained if a maintainer (or
team) upload has happened in the last 12 months. (NMUs don't count.)
If that is not the case, after 12 months an email is automatically
sent to the maintainer/uploaders to ask whether they are still
actively maintaining the package. They then have 3 months to respond
by either uploading a new version to sid or experimental, or
replying to that email that "yes, the package is still being
actively maintained, there was just no reason to update it recently".
Then there could be a clear way of determining what packages are
candidates for orphanning (while the email + reply logic should be
automatic, the orphanning should only be done after a human looks
that over). Obviously the precise amount of time can be bikeshedded,
but I do believe that the general concept is something sensible.
Becuase if one is indeed actively maintaining a package, then they
should be able to reply to an email every year or so. (Especially
if just doing "reply" + "send" is sufficient, like with mailing
list confirmations.)

Just to throw some ideas out there.

Regards,
Christian

Re: User-installable Debian packages?

[Florian Weimer]

* Steffen Möller:

> The HPC community does not want to need root privileges to get their
> software installed/used on the HPC setup. This excludes regular
> Debian packages, traditional containers like Docker and chroot
> environments.

So they would rather give the user full file system access on an
unprotected host, with a shared /tmp and /proc, limited control over
resource utilization, at least a few SUID programs, and the ability to
become root once you have obtained the password from someone?

Under the alternative model, users do not get any access whatsoever to
the actual host, are always confined to containers, and do not have
root rights in the container, either.  True, the container setup
requires elevated privileges, but this is tightly controlled by the
container management engine.  It's not something the user would run
after logging into the host over SSH.

For shared computing resources, the container model seems vastly
superior to user-based separation.  I'd be concerned about the
overhead, but I really don't understand the objection that this
requires root privileges when those privileges can be tightly
controlled.

(I'm not saying that Docker, OpenShift & Co. are suitable for HPC
environments.  They probably are not, but Linux namespaces & cgroups
seem quite appropriate for such environments.)

MBF for deprecating Python2 usage

[Matthias Klose]

While at DebCamp, Stefano Rivera and I sat down to analyze what needs to be done
to deprecate Python2 usage within the distribution.  It might not be possible to
drop Python2 for the next release, but there are still too many issues with
packages.  For now we identified some categories which need fixing. These are
documented at https://wiki.debian.org/Sprints/2017/Python3Montreal, resulting in
more than 3000 bug reports.  That's a high number, on the other hand we won't
make much progress if the issues are not named.  My intent is to bring that up
in the Python BoF next week at DebConf and then filing these bug reports with
the user tags mentiond on the wiki page.

Matthias

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

On Thu, 03 Aug 2017 12:11:07 -0700, Russ Allbery wrote:

> Tobias Frost  writes:
> > Some time ago I did some spring cleaning going over DDs that have
> > retired but still in the Maintainer/Uploader fields: There were quite a
> > lot "team maintained" packages where the team did not recognize that the
> > (sole) Uploader wasn't there anymore and the packages were
> > bitrotting. Without the Uploader field there would have been excactly
> > zero change to find those packages and get them back into maintainance
> > again.
> I'm dubious about this assertion and would like to dig into it a bit more.

[…]

Thanks for putting my thoughts (again!) into better words than I ever
could!
 
> (I am entirely in favor of giving the MIA team more actual power.)

(Me too. And, tangential to this discussion but still: maybe also to
packaging teams, like for salvaging un(der)-maintained packages.)


Cheers,
gregor 

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

On Thu, 03 Aug 2017 21:25:32 +0200, Christian Seiler wrote:

Thanks for your long and elaborate email.
Unfortunately I find myself disagreeing with your two main points:

> I wonder whether we are framing this in the right way anyway. There
> are two orthogonal questions in my mind:
>  - is a specific person MIA?
>  - is a package still maintained?

Ack, separating these questions makes sense to me.
 
> On the other hand you could have a package that has
> Maintainer: some team and Uploaders: some person, where "some
> person" is actually MIA, but the rest of the team is still actively
> maintaining the package.

Right, I think that's the situation that the proponents of this
change have in mind.
 
> The main problem I see with Uploaders: is that it's often not really
> up to date. So I do think that it might be a good idea to track the
> people who are responsible for a package outside of the package
> itself in some kind of central database that is not tied to package
> uploads. […] So I don't think the Uploaders:
> field in a package is useless, I just think the current way of
> storing that information is not the best way to do so. But until
> such a central database is ready for usage, I don't think it would
> be wise to drop Uploaders: at the moment, because otherwise that
> information can't be tracked at all.

Here I disagree: This database would just shift the outdated
information to another place; and more generally: I fail to see which
problem it solves.

I guess this is the general difference in perception we have in this
discussion: Some people start from the idea of "responsibility of a
human for a team package" while others are happy and have good
experiences in teams where all (or enough) members take
responsibility for the team packages and feel that a "dedicated human
responsible" doesn't make sense in their workflow.

What I don't understand in the point of view of the "keep Uploaders"
proponents: What does this information, whether correct or not,
actually give others? Are they going to email or phone these persons
privately when emails to the BTS or the maintainer/team list are
ignored? And what happens if they ignore these communications as
well?
 
> To help with the question of whether a package is still being
> actively maintained, let me frame it in this way: I think it is
> not completely unreasonable to say that _most_ packages will be
> updated at least once every 12 months in sid or experimental. (The
> precise number is subject to bikeshedding.) Of course that's not
> true for every package, there are some packages which don't require
> updates that often. So what one could do is the following: a
> package is considered to be actively maintained if a maintainer (or
> team) upload has happened in the last 12 months. (NMUs don't count.)
> If that is not the case, after 12 months an email is automatically
> sent to the maintainer/uploaders to ask whether they are still
> actively maintaining the package. 

I'm sorry but this feels like loads of paperwork for active teams
with tons of package which might not need an upload each $months.

I mean, in the worst case we could script the replies to the pings but
I'd rather not go there :)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Holger Levsen]

On Thu, Aug 03, 2017 at 06:04:17PM -0400, gregor herrmann wrote:
> On Thu, 03 Aug 2017 12:11:07 -0700, Russ Allbery wrote:
> […]
> Thanks for putting my thoughts (again!) into better words than I ever
> could!

+1
  
> > (I am entirely in favor of giving the MIA team more actual power.)
> (Me too. And, tangential to this discussion but still: maybe also to
> packaging teams, like for salvaging un(der)-maintained packages.)

agreed as well.

Then, Tobias has a point, knowing which team members uploaded a package is
useful. So I have a simple proposal to achieve that: make tracker.d.o
show the last 10 uploaders for a given package (based on UDD), just like it
parses the Uploaders: field from the packages now.

And probably some pages where all uploading team members of given teams are
shown.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Clint Adams]

On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> What I don't understand in the point of view of the "keep Uploaders"
> proponents: What does this information, whether correct or not,
> actually give others? Are they going to email or phone these persons
> privately when emails to the BTS or the maintainer/team list are
> ignored? And what happens if they ignore these communications as
> well?

I agree.  This information is useless, and even if it's not, the source
package is entirely the wrong place for it.  Let's get rid of the
Uploaders field entirely.

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 12:36:04PM -0400, Sean Whitton wrote:
> On Thu, Aug 03, 2017 at 12:06:16PM +0300, Adrian Bunk wrote:
> > Please be more thoughtful about the consequences of such changes to policy.
> > 
> > This would not be "a purely informative change".
> > 
> > Your suggested wording has the potential to create a HUGE amount of 
> > tensions.
> 
> You're right.  After sending my patch I realised that it contains the
> word "should", which is a magic word in policy, imposing a normative
> requirement.  This was not intended.
> 
> My intended meaning: it is already best practice that *other team
> members* should orphan a package if they know that no-one in the team is
> actively taking care of it *according to their judgement of 'actively'*.
> 
> Would you agree that this is already established best practice?
>...

That completely misses the problem.

If the team has remaining members, and one of these members knows that 
no-one in the team is actively taking care of a package, then what
happens afterwards is obvious.

Finding unmaintained packages is the hard part.

In a bigger team maintaining 500 packages it is a non-trivial amount of 
extra work searching for packages no-one inside the team is actively 
taking care of.

In a small team with 2 members maintaining 1 package, what you write 
obviously cannot work when the last team member becomes MIA.

With Uploaders you are able to see when all uploaders are retired/MIA,
either inside the team or from outside when the team has no active 
members left.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Clint Adams  writes:
> On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:

>> What I don't understand in the point of view of the "keep Uploaders"
>> proponents: What does this information, whether correct or not,
>> actually give others? Are they going to email or phone these persons
>> privately when emails to the BTS or the maintainer/team list are
>> ignored? And what happens if they ignore these communications as well?

> I agree.  This information is useless, and even if it's not, the source
> package is entirely the wrong place for it.  Let's get rid of the
> Uploaders field entirely.

I think we'd need to allow Maintainer to contain multiple people if we did
that, since there are packages that are really maintained by two or three
specific people who do not have a separate team contact address.

(I agree it's rare and usually there's a single maintainer who is whoever
was last added to Uploaders and everyone else is inactive.  But real
maintenance by a couple of people who haven't created a team mailing list
does happen!)

Or, I suppose, provide some super-easy way to create small mailing lists.

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
>...
> What I don't understand in the point of view of the "keep Uploaders"
> proponents: What does this information, whether correct or not,
> actually give others? Are they going to email or phone these persons
> privately when emails to the BTS or the maintainer/team list are
> ignored? And what happens if they ignore these communications as
> well?
>...

https://bugs.debian.org/cgi-bin/pkgreport.cgi?bug-rev=on;include=severity:minor;include=tags:pending;maint=pkg-perl-maintain...@lists.alioth.debian.org#_2_5_5

These "Updating the  Uploaders list" bugs.

When the MIA team has determined that a person is MIA,[1]
it can send bugs informing all packages where that person
is listed in Uploaders that the person is no longer active.

For small teams (e.g. 2 people in a team maintaining 1 package)
this is also a way for seeing when 0 team members are left who
are still active in Debian.

> Cheers,
> gregor

cu
Adrian

[1] or retired, all this is about what happens after it has been
determined that a person is no longer active in Debian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

On Fri, 04 Aug 2017 02:16:03 +0300, Adrian Bunk wrote:

> On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> > What I don't understand in the point of view of the "keep Uploaders"
> > proponents: What does this information, whether correct or not,
> > actually give others? Are they going to email or phone these persons
> > privately when emails to the BTS or the maintainer/team list are
> > ignored? And what happens if they ignore these communications as
> > well?
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?bug-rev=on;include=severity:minor;include=tags:pending;maint=pkg-perl-maintain...@lists.alioth.debian.org#_2_5_5
> 
> These "Updating the  Uploaders list" bugs.
> 
> When the MIA team has determined that a person is MIA,[1]
> it can send bugs informing all packages where that person
> is listed in Uploaders that the person is no longer active.

Ok, that's a good example:

So, when we (pkg-perl) get such a list of bug reports (or, which is
less work, a single mail from the MIA team about XY being inactive)
what happens is that
- we probably know that already (but it's still good to have the
  offical confirmation)
- we remove them from Uploaders in git
- nothing else changes: the package will be uploaded when there's any
  reason for it (new release, bugfix) as before when XY was still
  mentioned in Uploaders

Dropping the Uploaders field would mean that we save the work (which
can be quite tedious when we have to add the right bug numbers to the
right packages' changelog entry) without any other changes to the
maintenance of the package.


Cheers,
gregor 

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Adrian Bunk  writes:

> Regressing on being able to orphan all packages of a known-MIA/retired
> maintainer would be very bad.

I agree, but that's not directly relevant here, since we're talking about
team-maintained packages.  The whole *point* of team maintenance is that
there's no reason to orphan a package just because one team member went
away.  If that weren't the case, the package is, *by definition*, not
team-maintained (or the team itself is MIA, which is a different issue as
discussed below).

>> Currently, when the MIA team finds someone who is no longer active,
>> teams have to go do a bunch of work to strip their name out of uploader
>> fields.  That work doesn't really make Debian any better; it's just
>> bookkeeping.  When the team has other ways of knowing the health of
>> their packages, I'd like to let them not do this bookkeeping.

> You are assuming that the team notices without the current notifications
> from the MIA team that a team member is no longer active in Debian.

I'm really not.  I'm pointing out that for a lot of teams, that literally
*does not matter at all*.  Absolutely nothing changes about the
maintenance status of many team-maintained packages if the person who last
worked on that package disappears.

Teams often don't notice that someone is MIA because *it doesn't matter*
for their workflow; they're happy to have people come and go.

> You are assuming that the team has a non-zero number of active members
> left after a member becomes MIA.

No, I'm not -- as I pointed out in a separate message, this is a problem
worth solving, but this is an MIA team problem that I think is best
tackled from that angle.  If all of a team's packages are bitrotting, then
the team's packages should be orphaned just like we do with an MIA single
maintainer.

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 12:11:07PM -0700, Russ Allbery wrote:
> Tobias Frost  writes:
> 
> > Some time ago I did some spring cleaning going over DDs that have
> > retired but still in the Maintainer/Uploader fields: There were quite a
> > lot "team maintained" packages where the team did not recognize that the
> > (sole) Uploader wasn't there anymore and the packages were
> > bitrotting. Without the Uploader field there would have been excactly
> > zero change to find those packages and get them back into maintainance
> > again.
> 
> I'm dubious about this assertion and would like to dig into it a bit more.
> 
> The way we hopefully would find bitrotting packages is that they are,
> well, bitrotting.  This is based on lack of uploads, open bugs, old Policy
> versions, incomplete transitions, and in serious cases, missing from
> stable releases.  While we can *also* find bitrotting packages via the MIA
> process, it shouldn't be our primary or even a major way of finding them
> since it's entirely possible for someone to be quite active in Debian
> while still neglecting some of their packages.
>...

Regressing on being able to orphan all packages of a known-MIA/retired
maintainer would be very bad.

Think of it as a 3 step process:
1. a bitrotting package indicates a potentially MIA maintainer
2. the maintainer agrees to orphaning all packages, or after several 
   failed contact attempts the MIA team declares that the maintainer is MIA
3. for every package where the maintainer is in Maintainer or Uploaders
   the MIA team either orphans the package, or informs team or 
   co-maintainers through an "Updating the  Uploaders list" bug.

Just by going through bugs, I compiled during the past 10 months a list 
of currently 250 (sic) names of people listed in Maintainer or Uploaders
of packages in unstable where I suspect the person might be MIA.

Automating this part would not be a problem, the intersection of
"in Maintainer or Uploaders of a package in unstable" and
"no email to a Debian list or the BTS in the past 12 months"
should give approximately a superset of my list.

Step 2 is actually a lot of work.

The part where removing the Uploaders: requirement could cause 
regressions is step 3.

Give for a person a complete list of all packages where this person was 
active" - if we regress on this, it means that packages will continue to
bitrot in cases where they can currently be orphaned.

> Currently, when the MIA team finds someone who is no longer active, teams
> have to go do a bunch of work to strip their name out of uploader fields.
> That work doesn't really make Debian any better; it's just bookkeeping.
> When the team has other ways of knowing the health of their packages, I'd
> like to let them not do this bookkeeping.
>...

You are assuming that the team notices without the current notifications 
from the MIA team that a team member is no longer active in Debian.

You are assuming that the team has a non-zero number of active members 
left after a member becomes MIA.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Work-needing packages report for Aug 4, 2017

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1110 (new: 0)
Total number of packages offered up for adoption: 167 (new: 2)
Total number of packages requested help for: 46 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



No new packages have been orphaned, but a total of 1110 packages are
orphaned.  See http://www.debian.org/devel/wnpp/orphaned
for a complete list.



The following packages have been given up for adoption:

   localepurge (#870145), offered 4 days ago
 Description: reclaim disk space by removing unneeded localizations
 Installations reported by Popcon: 3248
 Bug Report URL: http://bugs.debian.org/870145

   xabacus (#870519), offered yesterday
 Description: simulation of the ancient calculator (plain X version)
 Installations reported by Popcon: 177
 Bug Report URL: http://bugs.debian.org/870519

165 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   autopkgtest (#846328), requested 246 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker openstack-pkg-tools
 Installations reported by Popcon: 890
 Bug Report URL: http://bugs.debian.org/846328

   balsa (#642906), requested 2139 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 714
 Bug Report URL: http://bugs.debian.org/642906

   busybox (#854181), requested 180 days ago
 Description: Tiny utilities for small and embedded systems
 Reverse Depends: bootcd busybox-syslogd dropbear-initramfs
   live-boot-initramfs-tools open-infrastructure-system-boot udhcpc
   udhcpd wicd-daemon zfs-initramfs
 Installations reported by Popcon: 193702
 Bug Report URL: http://bugs.debian.org/854181

   cargo (#860116), requested 114 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo
 Installations reported by Popcon: 463
 Bug Report URL: http://bugs.debian.org/860116

   cups (#532097), requested 2980 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups boomaga chromium
   cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client (66 more omitted)
 Installations reported by Popcon: 175687
 Bug Report URL: http://bugs.debian.org/532097

   cyrus-sasl2 (#799864), requested 680 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli
   autofs-ldap cairo-dock-mail-plug-in claws-mail
   claws-mail-acpi-notifier claws-mail-address-keeper
   claws-mail-archiver-plugin (127 more omitted)
 Installations reported by Popcon: 195089
 Bug Report URL: http://bugs.debian.org/799864

   dee (#831388), requested 384 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg
   libdee-dev zeitgeist-core
 Installations reported by Popcon: 62326
 Bug Report URL: http://bugs.debian.org/831388

   developers-reference (#759995), requested 1069 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 15367
 Bug Report URL: http://bugs.debian.org/759995

   devscripts (#800413), requested 674 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   bzr-builddeb customdeb debci debian-builder debmake debpear (24 more
   omitted)
 Installations reported by Popcon: 12985
 Bug Report URL: http://bugs.debian.org/800413

   ejabberd (#767874), requested 1004 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-contrib ejabberd-mod-cron
   ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml
   ejabberd-mod-message-log ejabberd-mod-muc-log-http
   ejabberd-mod-post-log ejabberd-mod-pottymouth ejabberd-mod-rest (4
   more omitted)
 Installations reported by Popcon: 631
 Bug Report URL: http://bugs.debian.org/767874

   fbcat (#565156), requested 2759 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 189
 Bug Report URL: http://bugs.debian.org/565156

   fgetty (#823061), requested 460 days ago
 Description: console-only getty & login (issue with

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 08:16:30PM -0400, gregor herrmann wrote:
> On Fri, 04 Aug 2017 02:16:03 +0300, Adrian Bunk wrote:
> 
> > On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> > > What I don't understand in the point of view of the "keep Uploaders"
> > > proponents: What does this information, whether correct or not,
> > > actually give others? Are they going to email or phone these persons
> > > privately when emails to the BTS or the maintainer/team list are
> > > ignored? And what happens if they ignore these communications as
> > > well?
> > 
> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?bug-rev=on;include=severity:minor;include=tags:pending;maint=pkg-perl-maintain...@lists.alioth.debian.org#_2_5_5
> > 
> > These "Updating the  Uploaders list" bugs.
> > 
> > When the MIA team has determined that a person is MIA,[1]
> > it can send bugs informing all packages where that person
> > is listed in Uploaders that the person is no longer active.
> 
> Ok, that's a good example:
> 
> So, when we (pkg-perl) get such a list of bug reports (or, which is
> less work, a single mail from the MIA team about XY being inactive)
> what happens is that
> - we probably know that already (but it's still good to have the
>   offical confirmation)
> - we remove them from Uploaders in git
> - nothing else changes: the package will be uploaded when there's any
>   reason for it (new release, bugfix) as before when XY was still
>   mentioned in Uploaders
> 
> Dropping the Uploaders field would mean that we save the work (which
> can be quite tedious when we have to add the right bug numbers to the
> right packages' changelog entry) without any other changes to the
> maintenance of the package.

But then the information who is currently part of pkg-perl is needed in
machine-readable form and displayed by tools like DDPO and tracker for:
1. being able to inform a team that a member is MIA and inform the team, and
2. being able to detect when the last team member is MIA

Policy equally applies to packages where point 2 is far more likely to 
happen than for pkg-perl.

Autogenerating Uploaders like GNOME does [1] would be an alternative
approach.

> Cheers,
> gregor 

cu
Adrian

[1] https://sources.debian.net/src/gnome-pkg-tools/0.19.9/1/rules/uploaders.mk/

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: MBF for deprecating Python2 usage

[barry]

On Aug 3, 2017, at 17:57, Matthias Klose  wrote:
> 
> While at DebCamp, Stefano Rivera and I sat down to analyze what needs to be 
> done
> to deprecate Python2 usage within the distribution.  It might not be possible 
> to
> drop Python2 for the next release, but there are still too many issues with
> packages.  For now we identified some categories which need fixing. These are
> documented at https://wiki.debian.org/Sprints/2017/Python3Montreal, resulting 
> in
> more than 3000 bug reports.  That's a high number, on the other hand we won't
> make much progress if the issues are not named.  My intent is to bring that up
> in the Python BoF next week at DebConf and then filing these bug reports with
> the user tags mentiond on the wiki page.

Great to hear that you guys talked about it.

Just a quick note that PEP 394 discussions have revived, lead by the Fedora 
folks.  Please do check out the new thread, especially if you have opinions 
about what /usr/bin/python should do once Python 2.7 is EOL.

https://mail.python.org/pipermail/linux-sig/2017-August/thread.html

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 05:41:00PM -0700, Russ Allbery wrote:
> Adrian Bunk  writes:
> 
> > Regressing on being able to orphan all packages of a known-MIA/retired
> > maintainer would be very bad.
> 
> I agree, but that's not directly relevant here, since we're talking about
> team-maintained packages.  The whole *point* of team maintenance is that
> there's no reason to orphan a package just because one team member went
> away.  If that weren't the case, the package is, *by definition*, not
> team-maintained (or the team itself is MIA, which is a different issue as
> discussed below).

Your definition is completely detached from the reality in Debian.

Many (likely the majority) of teams in Debian have not more
than 1 active member.

> >> Currently, when the MIA team finds someone who is no longer active,
> >> teams have to go do a bunch of work to strip their name out of uploader
> >> fields.  That work doesn't really make Debian any better; it's just
> >> bookkeeping.  When the team has other ways of knowing the health of
> >> their packages, I'd like to let them not do this bookkeeping.
> 
> > You are assuming that the team notices without the current notifications
> > from the MIA team that a team member is no longer active in Debian.
> 
> I'm really not.  I'm pointing out that for a lot of teams, that literally
> *does not matter at all*.  Absolutely nothing changes about the
> maintenance status of many team-maintained packages if the person who last
> worked on that package disappears.
> 
> Teams often don't notice that someone is MIA because *it doesn't matter*
> for their workflow; they're happy to have people come and go.

When all members of a team are confirmed to be MIA/retired,
this should result in an orphaning of all packages maintained
by the team.

> > You are assuming that the team has a non-zero number of active members
> > left after a member becomes MIA.
>
> No, I'm not -- as I pointed out in a separate message, this is a problem
> worth solving, but this is an MIA team problem that I think is best
> tackled from that angle.  If all of a team's packages are bitrotting, then
> the team's packages should be orphaned just like we do with an MIA single
> maintainer.

This would create both longer bitrot for packages and more work for
an already overworked team.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Adrian Bunk  writes:
> On Thu, Aug 03, 2017 at 05:41:00PM -0700, Russ Allbery wrote:
>> Adrian Bunk  writes:

>>> Regressing on being able to orphan all packages of a known-MIA/retired
>>> maintainer would be very bad.

>> I agree, but that's not directly relevant here, since we're talking
>> about team-maintained packages.  The whole *point* of team maintenance
>> is that there's no reason to orphan a package just because one team
>> member went away.  If that weren't the case, the package is, *by
>> definition*, not team-maintained (or the team itself is MIA, which is a
>> different issue as discussed below).

> Your definition is completely detached from the reality in Debian.

> Many (likely the majority) of teams in Debian have not more than 1
> active member.

Then when that one member disappears, that team becomes MIA, which is
something that would need to be detected by an MIA process for teams,
which I agree should exist, but which I think is detectable via other
mechanisms than Uploaders.  One approach as Holger points out: look for
packages where all the recent uploads have been by the MIA member, which
doesn't require the Uploaders field at all.

I stand by my statement that as long as the team *does* have more than one
member, not having to change anything abot package maintenance when one
team member disappears is kind of the whole point of having team
maintenance.  If the team is not providing that, it feels like there's not
much point in having a team, although I guess it could be aspirational.

> When all members of a team are confirmed to be MIA/retired, this should
> result in an orphaning of all packages maintained by the team.

One of the whole points of this discussion is that this "members of a
team" concept is not well-defined in Debian and is probably not something
that we *can* make well-defined in Debian.  Or, more to the point, *want*
to make well-defined.

>> No, I'm not -- as I pointed out in a separate message, this is a
>> problem worth solving, but this is an MIA team problem that I think is
>> best tackled from that angle.  If all of a team's packages are
>> bitrotting, then the team's packages should be orphaned just like we do
>> with an MIA single maintainer.

> This would create both longer bitrot for packages and more work for
> an already overworked team.

Why?  I don't see how this follows; in fact, I believe the exact opposite.
The current work that the MIA team does to track down Uploaders that
mention MIA people on team-maintained packages and file a bunch of bugs to
have them removed is work that they *don't* have to do in this model.
Instead, just treat the team like another maintainer and look at whether
that maintainer's packages are being maintained and whether that team is
active and orphan packages if they aren't.

-- 
Russ Allbery (r...@debian.org)   

Bug#870687: ITP: rss-bridge -- generate ATOM feeds for websites that don't have them

[Johannes Schauer]

Package: wnpp
Severity: wishlist
Owner: Johannes Schauer 

* Package name: rss-bridge
  Version : 2017-08-03
  Upstream Author : sebsauvage 
Mitsukarenai 
Pierre Mazière 
logmanoriginal 
* URL : https://github.com/RSS-Bridge/rss-bridge
* License : public domain
  Programming Lang: PHP
  Description : generate ATOM feeds for websites that don't have them

Generates ATOM feeds for facebook, twitter, youtube, flickr, google,
instagram, pinterest and more than 130 other web services which do not
provide ATOM or RSS feeds themselves. The software acts as a proxy
between the web service and an RSS reader software. It scrapes the
provided HTML to extract the necessary information. To prevent banning,
the results are cached.