Re: About the recent DD retirements

[Matthias Urlichs]

Hi,

Paul Wise:
> The difference is that your x86 laptop will get supported by the Linux
> kernel community during its lifetime but your ARM devices probably wont.
> 
which creates a lot of culture clashes, when people who come from the mobile
phone background try their hand at non-mobile devices. This creates a lot of
pain for people who need newer kernel features and suddenly discover that
they can't.

Odroid computers are a good bad example. I'm sure there are more.

> I'm not sure that is something that is fixable. It is simply more work
> to care about licenses and license compatibility, to package deps
> separately, to do security audits, to do QA on packages and code etc.
> 
The problem is that, while the cumulative work caused by your lazy
packaging often exceeds the time you'd have to do, it's distributed across
too many people for the pain to become severe enough.

I could spend a month or two, porting the Odroid hacks to a newer kernel,
but it's far easier and cheaper to just use them for whatever old jobs
they're still good for -- and buy something else to solve the needs-a-
-new-kernel problems.

Arguably, the library problem is worse: the kernel people, at least, _try_
to be as backwards compatible as possible.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150130122250.ga17...@smurf.noris.de

Re: cran2deb is back! Was: About the recent DD retirements

[Don Armstrong]

On Mon, 26 Jan 2015, Yaroslav Halchenko wrote:
> On Fri, 23 Jan 2015, Don Armstrong wrote:
> > Just to piggyback here, debian-r.debian.net has about 8.6k of these
> > packages (bioc, cran, and omegahat).
> 
> Just kudos, Dan, for reviving the deb2cran initiative!
> 
> any plans for providing builds for jessie state of affairs? ;)

I'd like to; I basically just need to sit down and upgrade sbuild and
fixup dak so that things work properly.

I'll stick it on my todo list, and hopefully get to it soonish.

-- 
Don Armstrong  http://www.donarmstrong.com

"You know," said Arthur, "it's at times like this, when I'm trapped in
a Vogon airlock with a man from Betelgeuse, and about to die from
asphyxiation in deep space that I really wish I'd listened to what my
mother told me when I was young."
"Why, what did she tell you?"
"I don't know, I didn't listen."
 –- Douglas Adams _The Hitchhikers Guide To The Galaxy_


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150126160217.gy21...@teltox.donarmstrong.com

cran2deb is back! Was: About the recent DD retirements

[Yaroslav Halchenko]

On Fri, 23 Jan 2015, Don Armstrong wrote:
> Just to piggyback here, debian-r.debian.net has about 8.6k of these
> packages (bioc, cran, and omegahat).

Just kudos, Dan, for reviving the deb2cran initiative!

any plans for providing builds for jessie state of affairs? ;)


-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150126142738.gp7...@onerussian.com

Re: About the recent DD retirements

[Thomas Hochstein]

Torsten Landschoff wrote:

> I think Debian lists are forwarded to UseNet 

Most lists are gated to linux.*, yes.

> but it is not as easy as
> years ago to get a good UseNet server.

Try
- news.individual.de
- news.eternal-september.org
or contact me at  for reading access or a feed.

Regards,
-thh


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ldp.1501260934@landroval.ancalagon.de

Re: About the recent DD retirements

[Thorsten Glaser]

Tollef Fog Heen  err.no> writes:

> This means that if you use system packages and want to have two
> applications that both want foo.jar installed, but different versions
> (since they need different APIs or different bug compatibility), we
> don't support that well.  For C libraries, there are sonames and all,

And this is why I disagree with Gunnar’s…

|programmers often prefer anyway working with either a particular
|library version they are comfortable with, or with the bleeding edge,
|or whatnot. Programmers will often look outside of the distribution,
|because they will want specific bits at different points in time.

… because if even the distribution thinks so, the attempt at
re-educating that kind of developers is lost. (Luckily, not all
think so; they see the benefit of packaging and distro-provided
security updates, and develop using packaged components only.
And *that* would be *much* easier if things were there already…
I’ve had to hand-compile stuff for mwlib (Mediawiki to PDF render
server), to run an OSM mapserver, and don’t even let me get started
about the difficulty of packaging even a small java web application
because all its dependencies are not yet packaged either.)

bye,
//mirabilos

Re: About the recent DD retirements

[Paul Wise]

On Mon, Jan 26, 2015 at 5:40 AM, Torsten Landschoff wrote:

> I am subscribed to about 10 Debian mailing lists but can hardly follow
> more than a few discussions a week. Therefore my mailbox is filled with
> unread Debian email.

I notice we have a library for automatic text summarisation in Debian.
It might be interesting to use that to determine if threads are
interesting to you before reading them.

http://libots.sourceforge.net/
https://packages.debian.org/sid/libots-dev

> My sieve filters sort every list into an extra mail folder, but it would
> be much easier to read via some NNTP interface. I do not know of any though.
> I think Debian lists are forwarded to UseNet but it is not as easy as
> years ago to get a good UseNet server.

The Debian lists are mostly on Gmane:

http://news.gmane.org/index.php?prefix=gmane.linux.debian

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6F_9GPVzh4uu=v1q5gznmao5m31ned5caj-r328v1y...@mail.gmail.com

Re: About the recent DD retirements

[Torsten Landschoff]

Hi Gunnar,

On 01/22/2015 03:35 AM, Gunnar Wolf wrote:
> First of all: Yes, this is the right forum. At least, this is *the*
> forum we currently keep an eye on and start acting on account
> retirement notices. Usually, account retirements posted here get
> processed first by keyring-maint (Jonathan McDowell, Daniel Kahn
> Gillmor and myself). We then either transfer or open a relevant
> ticket to DSA.
I think you misunderstood my question. :-) I was wondering if it is the
right forum to discuss the amount of retirements seen with the reason
being "not enough time for Debian".
Apparently debian-private was not the right forum, which is why this
ended up on -project which is fine with me.
> Second, yes, the retirement trend is public: We talked about its
> inavoidability back in DC14, and I posted several times on my blog
> about it. The last one is at:
>
>http://gwolf.org/node/4022
I did not see this before your email. Thanks for the all the details in
that blog post. I am happy that the number of retirements is not as big
as I had the impression: 34 retirements is way less than I was expecting.
> involvement, I do know many of the retirees personally. It is, as I
> have posted here, animically(?) hard to prompt so much people for
> action and get all those retirement messages. We "lost" 34 people in
> the last six months!
I would not have wanted to take up that task. Thanks for all the work!
> viewpoints. And yes, maybe (but that'd fuel a different discussion)
> Debian is less attractive in general to the young developer population
> to what it was in the past — I don't remember where I read that the
> median birth year of DDs has remained almost constant, which means
> that (yes) we might be attracting more senior developers (after all,
> Linux is no longer just a toy), but also... That we are failing to
> attract young talent.
That was my impression as well. OTOH I think that's not only for Debian
internal reasons but also because more people are just consuming
technology today, partly because it got easy to do that. There is a
swing in the other direction so, as Arduino, Rasberry Pi etc. are
showing. So I hope this also leads to more new Debian developers in the
future.
>
>>   * do you have the impression that Debian wants only contributors that
>> consistently spend many hours for Debian each month?
> I really hope not. My time allocation from Debian varies wildly, and
> it often reaches zero.
Happy to hear that I am not alone :-)
>>   * is there something that can be changed to make it less time
>> consuming to be a good citizen (like better ways to keep up with
>> relevant discussions)?
> I try to do that, at least. It's a very passive way of participating,
> but at least I "lurk" (and post very seldom) on ~10 mailing lists
> (including -devel, -project and -private) and idle on a couple of IRC
> channels. That allows me to feel the pulse of the project and catch
> many of the erupting topics.
I am subscribed to about 10 Debian mailing lists but can hardly follow
more than a few discussions a week. Therefore my mailbox is filled with
unread Debian email.
My sieve filters sort every list into an extra mail folder, but it would
be much easier to read via some NNTP interface. I do not know of any though.
I think Debian lists are forwarded to UseNet but it is not as easy as
years ago to get a good UseNet server.

Perhaps somebody has some hints where to follow discussions on Debian
lists without storing all that extra mail.
>>   * does the concept of "the package maintainer" assign too much
>> responsibility, putting too many eggs in a single basket? (Freezing
>> a package if $maintainer goes MIA, stopping other contributors from
>> moving Debian forward)?
> I think we have collectively done a great job of slowly moving over to
> shared maintenance. Again, I don't have the numbers handy, but
> remember having read it.
Where? :-)
I added myself to the LowNMU threshold list in wiki after writing the
original email. collab-maint is also a good thing.
But somehow Debian still feels like many small islands to me. Perhaps it
is just me though.
>  And yes, I do hope every DD should at some
> point have all of their packages group-maintained and sit on the
> low-NMU-threshold list.
100% agreement.

Greetings, Torsten




signature.asc
Description: OpenPGP digital signature

Re: About the recent DD retirements

[Torsten Landschoff]

On 01/22/2015 03:35 AM, Gunnar Wolf wrote:
> However, the original poster made a very
> interesting, long mail, with some questions to which the answers might
> be interesting for the general public to read. I will take the freedom
> to quote the questions along with my answers. Mr. Original Poster, if
> you care to identify yourself and forward your full message, I'll be
> happy.
It actually was not that long. Your reply was much longer and much more
enlighting. Thanks for that!
Here is the content of my original email. I'll reply to your reply in
another mail to not mix those.

Friendly, Torsten

 Forwarded Message 
Subject:Not retiring, but worried about the current trend - are we
doing something wrong?
Date:   Wed, 21 Jan 2015 23:40:49 +0100
From:   Torsten Landschoff 
To: debian-priv...@lists.debian.org



Hello everybody,

[ObPrivate: I am not sure if the amount of retirements currently going
on is public knowledge. We should not hide our problems, but I do not
want to be the one who makes this public. Also these announcements
happen here so this might be the right forum.]

whenever I get the time to read debian-private I find more of those
emails with the word "retiring" in the subject line.
Most of those emails mention the lack of time to be a "real" developer
as the reason to quit. I have to wonder if doing stuff for Debian or at
least carrying the developer/maintainer status means that you are
supposed to have copious amounts of time available for your Debian duties.

Because currently I am pretty much out of spare time that I can put into
Debian work I feel pressed to retire as well. But I think that Debian
would be better off with many helping hands just helping with a little
bit instead of loading a few maintainers with dozens of packages.

Looking back I have the impression that Debian has the tendency to suck
you in. It is quite addicting to work on stuff that many people are
using and what's more to learn so much new stuff in the process. When I
got into Debian in 1998 I spent more time on it than on my studies of
computer science which took quite a hit. Reading debian-devel almost in
full took hours away from me each and every day but I could not stop,
mostly consuming information with little output. Whenever I had
something to add to a thread I noticed that somebody else shared my
point of view and made the point I wanted to make.

Also taking over packages like ghostscript and openldap back then really
overwhelmed me because I underestimated the effort required, especially
doing stuff like fixing the OpenSSL license dilemma (I actually tried to
port OpenLDAP to GnuTLS back then, which was way over my head at the
time). I have to say that I had the most fun just doing some QA work
like triaging bugs, sending patches etc. because I was not in charge.

This mail already gets too long so I cut it short here.

The questions I want to open up with this email are:

  * do you have the impression that Debian wants only contributors that
consistently spend many hours for Debian each month?
  * is there something that can be changed to make it less time
consuming to be a good citizen (like better ways to keep up with
relevant discussions)?
  * does the concept of "the package maintainer" assign too much
responsibility, putting too many eggs in a single basket? (Freezing
a package if $maintainer goes MIA, stopping other contributors from
moving Debian forward)?


Greetings, Torsten



signature.asc
Description: OpenPGP digital signature

Re: About the recent DD retirements

[Paul Wise]

On Fri, 2015-01-23 at 10:57 +, Anthony Towns wrote:

>  - having automated scripts pull everything from CPAN (et al), package
>it as debs, and publish it

That already exists IIRC but I don't know where it is.

If you want to work on the more general problem here I'd suggest looking
at two things related to this:

GoboLinux's package manager has the concept of foreign packages and is
able to deal with them quite well. I can't find a reference for this but
there was a talk at the distros miniconf at LCA in Wellington.

DEP-11 will eventually allow us to run commands like below, allowing us
to catch up with RPM's ability to put non-RPM things in Provides.

apt-get install --perl HTML::Parser
apt-get install --binary man
apt-get install --header zlib.h
apt-get install --firmware carl9170-1
https://wiki.debian.org/DEP-11

> Isn't that statement alone a pretty clear indication that Debian's not
> addressing the packaging problems of today?

I didn't say that we aren't packaging web stuff. That is definitely
happening, countless ruby/npm/php modules have entered Debian in recent
years. The thing that isn't happening is Debian-specific policy and
standards for packaging web stuff.

> Why is that something "the GNOME folks" are doing, but "the Debian
> folks" aren't?

GNOME are interested in containers since they want "apps", where
applications come with the libraries they depend on, either via static
binaries or bundling but Debian generally considers that a bad idea.
Most of the containerisation stuff in recent years is focussed on that.

> My last phone (nexus 4) lasted a bit over two years, which is longer
> than my current laptop is going to last, I think, given they keycaps
> are starting to fall off. My tablet gets much less use, but is about
> two and a half I think.

The difference is that your x86 laptop will get supported by the Linux
kernel community during its lifetime but your ARM devices probably wont.

> In any event, cyanogenmod already demonstrates that the free software
> world can support them.

The cyanogenmod model (and Replicant) for supporting devices is one fork
of the Android version of the Linux kernel per device...

> > It is also much more work to do things the Debian way.
> In so far as that's true, it's a problem to be fixed.

I'm not sure that is something that is fixable. It is simply more work
to care about licenses and license compatibility, to package deps
separately, to do security audits, to do QA on packages and code etc.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Re: About the recent DD retirements

[Russ Allbery]

Tollef Fog Heen  writes:

> That requires tracking ABI versions.  People often don't do that.  They
> (effectively) statically link and then just test the resulting binary
> and distribute that, including all dependencies.

> There are certainly downsides to this approach, but it's what lots of
> the world seems to have fallen down on.

The primary drawback is that if there's a problem with some dependency,
you have to rebuild the world, and you have to backport the fix to the
problem to every version of the dependency you're using.  The former is a
problem for smaller sites but something large web-scale sites have
probably solved in some way.  Rebuilding the world is something that,
culturally, gets prioritized pretty highly.  But the backporting problem
is still pretty nasty.

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


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ppa3oi2y@hope.eyrie.org

Re: About the recent DD retirements

[Tollef Fog Heen]

]] Keith Packard

> Tollef Fog Heen  writes:
> 
> > This means that if you use system packages and want to have two
> > applications that both want foo.jar installed, but different versions
> > (since they need different APIs or different bug compatibility), we
> > don't support that well.  For C libraries, there are sonames and all,
> > but those largely doesn't exist for other languages and fixing that
> > would be a huge undertaking with, IMO, pretty poor prospects for
> > success.
> 
> For Java, I'm afraid I've taken to embedding the ABI version in the
> filename. The alternative is to completely disallow simultaneous
> installs of different versions, which seems worse.

That requires tracking ABI versions.  People often don't do that.  They
(effectively) statically link and then just test the resulting binary
and distribute that, including all dependencies.

There are certainly downsides to this approach, but it's what lots of
the world seems to have fallen down on.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761bvvrxx@aexonyam.err.no

Re: About the recent DD retirements

[Russ Allbery]

Tollef Fog Heen  writes:

> This also points at something not explicitly mentioned: Our support for
> multiple versions of the same package is pretty much non-existent.  (You
> can hard-code the version into the package name.  This causes NEW pain,
> this kinda breaks dependencies and doesn't map well to how at least some
> languages like Ruby handles dependencies.)

> This means that if you use system packages and want to have two
> applications that both want foo.jar installed, but different versions
> (since they need different APIs or different bug compatibility), we
> don't support that well.  For C libraries, there are sonames and all,
> but those largely doesn't exist for other languages and fixing that
> would be a huge undertaking with, IMO, pretty poor prospects for
> success.

Yeah, this is a cause of serious pain.  It's probably the number one
objection to using Debian packages to distribute software internally.
People don't like using a system that breaks down when different pieces of
software need different versions of some dependency, and this is very,
very common.  Hence the popularity of things that fix this, such as Python
virtual_env, Java's tendency to use per-application JAR trees, Ruby's
support for doing something similar, Nix, or languages like Go that do
static compiles.

You can work around this problem by using containers for everything (or,
similar but less modern, chroots), but that introduces a bunch of new
pain.

A clean way to let, e.g., Python modules at different versions co-exist
would be really nice, but it's a very hard problem.  You'd probably have
to completely redesign the way that packages are built and deployed,
similar to what Nix does.

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


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/873870oskw@hope.eyrie.org

Re: About the recent DD retirements

[Steve Langasek]

On Sat, Jan 24, 2015 at 09:59:17AM -0800, Keith Packard wrote:
> Tollef Fog Heen  writes:

> > This means that if you use system packages and want to have two
> > applications that both want foo.jar installed, but different versions
> > (since they need different APIs or different bug compatibility), we
> > don't support that well.  For C libraries, there are sonames and all,
> > but those largely doesn't exist for other languages and fixing that
> > would be a huge undertaking with, IMO, pretty poor prospects for
> > success.

> For Java, I'm afraid I've taken to embedding the ABI version in the
> filename.

AKA: ELF shared library semantics, reinvented 20 years behind schedule.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: About the recent DD retirements

[Keith Packard]

Tollef Fog Heen  writes:

> This means that if you use system packages and want to have two
> applications that both want foo.jar installed, but different versions
> (since they need different APIs or different bug compatibility), we
> don't support that well.  For C libraries, there are sonames and all,
> but those largely doesn't exist for other languages and fixing that
> would be a huge undertaking with, IMO, pretty poor prospects for
> success.

For Java, I'm afraid I've taken to embedding the ABI version in the
filename. The alternative is to completely disallow simultaneous
installs of different versions, which seems worse.

One alternative would be to store the .jar file in a per-version
directory, and then have the application's Class-Path point at the
correct directory for the desired version.

-- 
-keith


signature.asc
Description: PGP signature

Re: About the recent DD retirements

[Tollef Fog Heen]

]] Anthony Towns 

> On Fri, Jan 23, 2015 at 11:29:19AM -0600, Gunnar Wolf wrote:
> > Anthony Towns dijo [Fri, Jan 23, 2015 at 10:57:55AM +]:
> > > (Yes, I really think Debian should have 300k+ packages, including
> > > everything in all the language archives, no matter how special purposes
> > > (compare against the chiark* packages eg).
> > My answer to this is that... A distribution should mostly cater to
> > users. That means, we should target applications, not libraries.
> 
> So I'm going to disagree with that in two ways.
> 
> First, and more trivially, is that there are plenty of applications
> people want to run, that depend on unpackaged libraries that are a
> PITA to package. Etherpad is the example I already gave. Openrocket is
> another -- it's packaged as an installer that "downloads the pre-build
> OpenRocket .jar file from the upstream site and instals it"; because
> openrocket upstream likes using cool new java libraries for features and
> java libraries are a pain to package. 

This also points at something not explicitly mentioned: Our support for
multiple versions of the same package is pretty much non-existent.  (You
can hard-code the version into the package name.  This causes NEW pain,
this kinda breaks dependencies and doesn't map well to how at least some
languages like Ruby handles dependencies.)

This means that if you use system packages and want to have two
applications that both want foo.jar installed, but different versions
(since they need different APIs or different bug compatibility), we
don't support that well.  For C libraries, there are sonames and all,
but those largely doesn't exist for other languages and fixing that
would be a huge undertaking with, IMO, pretty poor prospects for
success.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d264um6d@aexonyam.err.no

Re: About the recent DD retirements

[Don Armstrong]

On Sat, 24 Jan 2015, Anthony Towns wrote:
> Archive, mirrors, lintian, piuparts, other qa stuff, yep.

Right.

> Promotion to testing [1], maybe?

I think so; I know I personally would like to have a set of bits of R
packages which didn't change on about the schedule of a stable release.

> BTS, I somewhat don't think so?

Probably just a single pseudo-package for coordinating groups of
automatically packaged packages; if someone really wants to file more
than one or two bugs, then it's probably a sign that the package should
become a fully-supported package. [Or the person filing bugs should get
more involved and help promote it to becoming a real package.]

> NEW-esque license review seems impractical.

Yeah; for debian-r, we assume that CRAN has the license listed
correctly, and we just go from there. [Well, the awesome cran2deb stuff
does it; I just modified it and built the results.]

> Probably also wants an additional db tracking what upstream
> commit/whatever was converted to which Debian-ised version.

Right.

> [1] Oh, dude! I finally thought of a possible rename for britney:
> pro-test as in promotion to testing.

Sounds good to me.

-- 
Don Armstrong  http://www.donarmstrong.com

"You have many years to live--do things you will be proud to remember
when you are old."
 -- Shinka proverb. (John Brunner _Stand On Zanzibar_ p413)


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150124073130.gp21...@teltox.donarmstrong.com

Re: About the recent DD retirements

[Anthony Towns]

On Fri, Jan 23, 2015 at 10:03:08AM -0800, Don Armstrong wrote:
> On Fri, 23 Jan 2015, Anthony Towns wrote:
> >  CRAN has about 6k (~250 in Debian),
> Just to piggyback here, debian-r.debian.net has about 8.6k of these
> packages (bioc, cran, and omegahat).

Talk about giving 110%! [0] 

> > Yes, I really think Debian should have 300k+ packages, including
> > everything in all the language archives
> Handling this will probably require second-class packages, where we use
> automated tools to package the package, and hope for the best. In some
> ways, we're already starting to go that way,[1] but it would be nice to
> use all of Debian's infrastructure even for those second-class packages,
> too.

Archive, mirrors, lintian, piuparts, other qa stuff, yep. Promotion to
testing [1], maybe? BTS, I somewhat don't think so? NEW-esque license
review seems impractical.

Probably also wants an additional db tracking what upstream
commit/whatever was converted to which Debian-ised version.

Cheers,
aj

[0] Or more accurately 110% of 110% of 110% of 110% 

[1] Oh, dude! I finally thought of a possible rename for britney:
pro-test as in promotion to testing.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150124071757.gc17...@master.debian.org

Re: About the recent DD retirements

[Anthony Towns]

On Fri, Jan 23, 2015 at 11:29:19AM -0600, Gunnar Wolf wrote:
> Anthony Towns dijo [Fri, Jan 23, 2015 at 10:57:55AM +]:
> > (Yes, I really think Debian should have 300k+ packages, including
> > everything in all the language archives, no matter how special purposes
> > (compare against the chiark* packages eg).
> My answer to this is that... A distribution should mostly cater to
> users. That means, we should target applications, not libraries.

So I'm going to disagree with that in two ways.

First, and more trivially, is that there are plenty of applications
people want to run, that depend on unpackaged libraries that are a
PITA to package. Etherpad is the example I already gave. Openrocket is
another -- it's packaged as an installer that "downloads the pre-build
OpenRocket .jar file from the upstream site and instals it"; because
openrocket upstream likes using cool new java libraries for features and
java libraries are a pain to package. 

ie, not having those libraries easily available in Debianised form /is/
one of the things that prevents people from running apps on Debian.

Second, and more philosophically... Free software's about users not just
being passive consumers, but treating them like co-developers. From
fsf.org: "Free software developers guarantee everyone equal rights
to their programs; any user can study the source code, modify it,
and share the program." If we *really* believe that, then we shouldn't
just be about getting users some nice eary to install prepackaged apps,
we should be about getting them the tools they need to make those apps
do whatever they want, and even make apps of their own. Once upon a
time the C library, a compiler and a debugger were state of the art for
doing that; nowdays, pulling together bits of code from the hundreds of
thousands of pre-written open source modules is.

Oh, and as a bonus: third -- how much easier would packaging applications
be, if all the libraries they used (and all the libraries we currently
maintain) we're already packaged, essentially for free?

> By limiting our scope to what is actually wanted (i.e. by applications
> that have been ITPed or RFPed, 

Per the wnpp pages, there are:

 * 868 packages being worked on
 * 3434 requested packages

That's a total of 4302, compared to 21554 source packages, that's just
under 20%, so about two years worth of backlog at 10% growth in source
packages per year. ie, Debian's already not coming close to keeping up
with the "actually wanted" stuff.

(Also, note that quite a lot of those are modules from various language sites
already)

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150124064646.gb17...@master.debian.org

Re: About the recent DD retirements

[Don Armstrong]

On Fri, 23 Jan 2015, Anthony Towns wrote:
>  CRAN has about 6k (~250 in Debian),

Just to piggyback here, debian-r.debian.net has about 8.6k of these
packages (bioc, cran, and omegahat).

> Yes, I really think Debian should have 300k+ packages, including
> everything in all the language archives

Handling this will probably require second-class packages, where we use
automated tools to package the package, and hope for the best. In some
ways, we're already starting to go that way,[1] but it would be nice to
use all of Debian's infrastructure even for those second-class packages,
too.

1: I mean, I've already done this myself for parts of CRAN.
-- 
Don Armstrong  http://www.donarmstrong.com

But if, after all, we are on the wrong track, what then? Only
disappointed human hopes, nothing more. And even if we perish, what
will it matter in the endless cycles of eternity?
 -- Fridtjof Nansen _Farthest North_ p152


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150123180308.gj21...@teltox.donarmstrong.com

Re: About the recent DD retirements

[Gunnar Wolf]

Anthony Towns dijo [Fri, Jan 23, 2015 at 10:57:55AM +]:
> On Thu, Jan 22, 2015 at 07:02:51PM +0800, Paul Wise wrote:
> > On Thu, Jan 22, 2015 at 6:28 PM, Anthony Towns wrote:
> > >  - there are "archive networks" for most programming languages these days:
> > >CPAN, CRAN, Hackage, PyPI, RubyGems, NPM, CCAN, etc. Installing
> > >software from these sources is often necessary for Debian users, but
> > >doesn't mesh well with packaged software (unlss you're a DD and can
> > >package it yourself). Since it's all free software, I don't really
> > >see why Debian doesn't have a set of automatic tools to repackage
> > >all that software, so it's all just an "apt-get" away.
> > We do: dh-make-perl, npm2deb, gem2deb, stdeb, cabal-debian etc which
> > are intended to be wrapped by debdry to eliminate much of the initial
> > packaging process.
> 
> Sure, that works great if your model is "there are a few thousand pieces
> of interesting software, and a few hundred packagers, each of whom can
> maintain tens of them". But CPAN has 30k modules (~3k in Debian), CRAN
> has about 6k (~250 in Debian), Hackage has 7k (~700 packaged), PyPI has
> about 54k (2500 packaged), RubyGems has about 95k (~6000 packaged?),
> npm has about 120k (266 packaged?). [0]
> 
> There's obviously a seriously long tail of stuff that's not very
> interesting to many people in those numbers, but Debian's still at least
> an order of magnitude short of any of them.
> (...)
> In an ideal world, users would just be able to say "apt-get install
> lib-whatever-perl" and have it. At worst, they might have to modify
> their apt sources explicitly to say "yes, I know there's a lot of crap
> on CPAN that doesn't necessarily receive good security updates, I know
> what I'm doing".

We have talked about this problem since long ago. I'm presently not
involved in the (great!) pkg-perl group, but back in 2007 I wrote an
article and presented this talk at the Vienna YAPC:

   http://gwolf.org/files/integrating_perl_in_distro.pdf
   http://gwolf.org/files/integrating_perl_in_distro_-_presentation.pdf

Around that time there was talk in the pkg-perl group about packaging
*all* of the CPAN. One of the factors that made us decide against it
is that in Debian we care about quality, not just quantity. And not
all of the available Perl modules have the same maintenance level (and
Perl is quite an exemplary community WRT their quality levels). Having
all modules packaged would mean we DDs would have to answer through
the BTS for any shortcomings in the different Perl (or Ruby, or R, or
TeX, or Hackage, or Python, or Node.js, or Drupal, or Whatnot)
modules. Hardly feasible.

>  - having automated scripts pull everything from CPAN (et al), package
>it as debs, and publish it
> (...)
> But if the answer is "oh, you want to use some random nodejs package? just
> npm it into /opt. if you want there's some tools to help start you off
> in packaging it too" 
>
> (Yes, I really think Debian should have 300k+ packages, including
> everything in all the language archives, no matter how special purposes
> (compare against the chiark* packages eg).

My answer to this is that... A distribution should mostly cater to
users. That means, we should target applications, not libraries. Yes,
most of us are programmers, and we are a special kind of users — But
programmers often prefer anyway working with either a particular
library version they are comfortable with, or with the bleeding edge,
or whatnot. Programmers will often look outside of the distribution,
because they will want specific bits at different points in time.

I believe it is the programmers' products (the applications) are
closer to what we should aim to package. If an application requires a
given set of dependencies we don't have yet fulfilled, we should work
on them. And yes, that might mean tweaking it so it works with the
versions of the libraries we have on the distribution — As we need to
provide an always-coherent, always-coinstallable set of packages.

By limiting our scope to what is actually wanted (i.e. by applications
that have been ITPed or RFPed, or for the *relatively few* specific
librares deemed as worth having on their own because there's an
obvious need for them, or whatnot), we can expect to keep excelling in
overall quality. If we were to open the scope to
just-about-everything, our distribution's quality would surely drop.

> > >  - perhaps it's all been fixed since I last looked, but "web apps" still
> > >don't seem to be a "solved problem" to me. If you install, say,
> > >libreoffice, you run apt-get (or whatever), then you run libreoffice,
> > >and you're done. But if you want to install wordpress, you have a whole
> > >bunch of additional steps to go through [1].
> > We have a web app policy but it is fairly abandoned.
> 
> Isn't that statement alone a pretty clear indication that Debian's not
> addressing the packaging problems of today?

Yes. Web ap

Re: About the recent DD retirements

[Anthony Towns]

On Thu, Jan 22, 2015 at 07:02:51PM +0800, Paul Wise wrote:
> On Thu, Jan 22, 2015 at 6:28 PM, Anthony Towns wrote:
> >  - there are "archive networks" for most programming languages these days:
> >CPAN, CRAN, Hackage, PyPI, RubyGems, NPM, CCAN, etc. Installing
> >software from these sources is often necessary for Debian users, but
> >doesn't mesh well with packaged software (unlss you're a DD and can
> >package it yourself). Since it's all free software, I don't really
> >see why Debian doesn't have a set of automatic tools to repackage
> >all that software, so it's all just an "apt-get" away.
> We do: dh-make-perl, npm2deb, gem2deb, stdeb, cabal-debian etc which
> are intended to be wrapped by debdry to eliminate much of the initial
> packaging process.

Sure, that works great if your model is "there are a few thousand pieces
of interesting software, and a few hundred packagers, each of whom can
maintain tens of them". But CPAN has 30k modules (~3k in Debian), CRAN
has about 6k (~250 in Debian), Hackage has 7k (~700 packaged), PyPI has
about 54k (2500 packaged), RubyGems has about 95k (~6000 packaged?),
npm has about 120k (266 packaged?). [0]

There's obviously a seriously long tail of stuff that's not very
interesting to many people in those numbers, but Debian's still at least
an order of magnitude short of any of them.

So what's that mean if you're either developing or installing random
software?

 1) ignore anything not in Debian and be hamstrung

 2) use the language native packaging stuff

 3) invest a lot of time skilling up on the various Debian utilities
and package it yourself (including repackaging every update)

 4) invest even more time so that your packages can be included in Debian

It takes a couple of minutes to download something using pip or
npm; how long does it take to get a python or nodejs Debianized and
installable? (eg: learning that npm2deb exists, how to use it, what else
you have to do to have a package, building the package, and getting apt
access to the package -- which in turn presumably includes setting up
and distributing an archive key)

In an ideal world, users would just be able to say "apt-get install
lib-whatever-perl" and have it. At worst, they might have to modify
their apt sources explicitly to say "yes, I know there's a lot of crap
on CPAN that doesn't necessarily receive good security updates, I know
what I'm doing".

There's two ways that could be achieved:

 - having automated scripts pull everything from CPAN (et al), package
   it as debs, and publish it

 - having about 14,000 new DDs each individally maintaining 10-20
   library packages

But if the answer is "oh, you want to use some random nodejs package? just
npm it into /opt. if you want there's some tools to help start you off
in packaging it too" 

(Yes, I really think Debian should have 300k+ packages, including
everything in all the language archives, no matter how special purposes
(compare against the chiark* packages eg). By my count, jessie's at
20,700 source packages in main, which is about an 11% per annum growth
rate since lenny, and indeed since sarge in 2005 [1]. If we'd stayed at
about a 35% pa growth rate since woody then we'd be at around 200k source
packages now, which I think would be the right order of magnitude for
everything that's actually buildable in CPAN, and PyPI and so on being
just an apt-get away.)

> >  - perhaps it's all been fixed since I last looked, but "web apps" still
> >don't seem to be a "solved problem" to me. If you install, say,
> >libreoffice, you run apt-get (or whatever), then you run libreoffice,
> >and you're done. But if you want to install wordpress, you have a whole
> >bunch of additional steps to go through [1].
> We have a web app policy but it is fairly abandoned.

Isn't that statement alone a pretty clear indication that Debian's not
addressing the packaging problems of today?

> There are some external projects in this space, like sandstorm and juju.

(And that one too... Also, unless I'm mistaken neither are packaged
in Debian; apparently juju got dropped over a year and a half ago,
bug#716754)

> The wordpress wiki page seems to miss the wp-setup script that is in
> the package now.

The manpage says "For now, it's mainly for the package's internal usage
though."

> >  - application isolation is a popular issue now, often solved by blatting
> >whole OS images around (VMs, docker, ...). That brings up a whole host
> >of packaging issues (how do you create the image, how do you keep it up
> >to date, how do you distribute the image)
> systemd has some great isolation features that use the same Linux
> kernel APIs as docker/etc.
> 
> The GNOME folks are working on application isolation for the desktop:
> 
> http://blogs.gnome.org/mclasen/2015/01/21/sandboxed-applications-for-gnome/

Why is that something "the GNOME folks" are doing, but "the Debian
folks" aren't?

If Debian's just about packagin

Re: About the recent DD retirements

[Enrico Zini]

On Wed, Jan 21, 2015 at 06:46:16PM -0800, Russ Allbery wrote:

> about it).  But there are still a lot of hard and interesting problems,
> which are worth working on.  So, one, we need to figure out how to make
> those problems apparent and provide people leverage to work on them.  But
> we should also consider that the project has a lot of appeal for people

I volunteer one such problems: packaging collections of packages.

simple-cdd is a tool that tries to make it easy to create subsets of
Debian: you give it a debian version to build from (wheezy, jessie..), a
list of packages, some debconf preseedings, and you get an ISO image.

To do that it coordinates reprepro, debian-cd and a bunch of other
utilities. I've recently been porting simple-cdd to python, and in the
process I refactored it so that it contains more internal documentation.
The list of relevant environment variables to control the process is
quite daunting: 
http://anonscm.debian.org/cgit/collab-maint/simple-cdd.git/tree/build-simple-cdd?h=topython#n277

There's nontrivial work to be done there, and the result means making it
easy to build package collections to support all sorts of interesting
deployment and distribution workflows, with d-i images, live images,
preinstalled tarballs, docker contains or what have you.

And then it gets deployed and it's a standard Debian, well known, with
clean upgrade paths and security support.


Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: Digital signature

Re: About the recent DD retirements

[Paul Wise]

On Thu, Jan 22, 2015 at 6:28 PM, Anthony Towns wrote:

>  - there are "archive networks" for most programming languages these days:
>CPAN, CRAN, Hackage, PyPI, RubyGems, NPM, CCAN, etc. Installing
>software from these sources is often necessary for Debian users, but
>doesn't mesh well with packaged software (unlss you're a DD and can
>package it yourself). Since it's all free software, I don't really
>see why Debian doesn't have a set of automatic tools to repackage
>all that software, so it's all just an "apt-get" away.

We do: dh-make-perl, npm2deb, gem2deb, stdeb, cabal-debian etc which
are intended to be wrapped by debdry to eliminate much of the initial
packaging process.

>  - perhaps it's all been fixed since I last looked, but "web apps" still
>don't seem to be a "solved problem" to me. If you install, say,
>libreoffice, you run apt-get (or whatever), then you run libreoffice,
>and you're done. But if you want to install wordpress, you have a whole
>bunch of additional steps to go through [1].

We have a web app policy but it is fairly abandoned.

The wordpress wiki page seems to miss the wp-setup script that is in
the package now.

There are some external projects in this space, like sandstorm and juju.

>  - application isolation is a popular issue now, often solved by blatting
>whole OS images around (VMs, docker, ...). That brings up a whole host
>of packaging issues (how do you create the image, how do you keep it up
>to date, how do you distribute the image)

systemd has some great isolation features that use the same Linux
kernel APIs as docker/etc.

The GNOME folks are working on application isolation for the desktop:

http://blogs.gnome.org/mclasen/2015/01/21/sandboxed-applications-for-gnome/

> And, of course, I run Linux systems that aren't Debian these days --
> I have both a phone and a tablet.

The lifecycle for these sort of devices is too short for the Free
Software world to realistically support them in a sane way before they
become obsolete. There are also few people with the time, skills and
motivation to do so. Even the ancient N900 still doesn't have full
support in mainline Linux yet. I think the best we can do here is the
chroot on Android tools.

http://elinux.org/N900
https://wiki.debian.org/Mobile
https://wiki.debian.org/ChrootOnAndroid

There is also a lot of software from the Android ecosystem that would
be interesting to have ported to Debian, all of f-droid for example.

https://f-droid.org/

> Why aren't those people doing things in Debian? I claim two reasons:
> 1) because they can make (more/any) money doing it elsewhere; and 2)
> because Debian folks are more interested in the solved problems of the
> 90s than the problems of today.

It is also much more work to do things the Debian way.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6gnksloaldhubtbzhcy-osj+oyko54ynl_k0n_c9ow...@mail.gmail.com

Re: About the recent DD retirements

[Anthony Towns]

On Wed, Jan 21, 2015 at 06:46:16PM -0800, Russ Allbery wrote:
> Gunnar Wolf  writes:
> > ... And yes, maybe Debian is less attractive in general ...
> One side effect of this is that packaging feels like a solved problem.

If so (and assuming that's all Debian's about), then that'd be a good
reason to consider Debian a mature project and the only thing that's
really needed is enough people to keep the lights on.

I think that's a meritorious [0] argument.

Personally, I'd argue the other side though. Packaging works fine within
Debian -- which is certainly an improvement on how things were in the
90s (or even ten yars ago); but there are a bunch of unsolved problems
in the area. For instance:

 - there are "archive networks" for most programming languages these days:
   CPAN, CRAN, Hackage, PyPI, RubyGems, NPM, CCAN, etc. Installing
   software from these sources is often necessary for Debian users, but
   doesn't mesh well with packaged software (unlss you're a DD and can
   package it yourself). Since it's all free software, I don't really
   see why Debian doesn't have a set of automatic tools to repackage
   all that software, so it's all just an "apt-get" away.

 - perhaps it's all been fixed since I last looked, but "web apps" still
   don't seem to be a "solved problem" to me. If you install, say,
   libreoffice, you run apt-get (or whatever), then you run libreoffice,
   and you're done. But if you want to install wordpress, you have a whole
   bunch of additional steps to go through [1].

 - application isolation is a popular issue now, often solved by blatting
   whole OS images around (VMs, docker, ...). That brings up a whole host
   of packaging issues (how do you create the image, how do you keep it up
   to date, how do you distribute the image)

Other folks are answering those questions -- eg in order to run my own
instance of etherpad [2], I found that it needs some nodejs modules that
aren't packaged, so rather than jump through the hoops to Debianise it,
I created a docker instance for it, and followed the upstream instructions
to install it, and put a port redirect in place via systemd. Of course,
that system is out of date (because I forget to login to run apt-get on
it, and who knows what the npm packages are up to).

And, of course, I run Linux systems that aren't Debian these days --
I have both a phone and a tablet. In some sense you could say they're
kind-of open hardware running free software, but both running my own
software on them or rebuilding what's already on there aren't things I
can actually do. That's not because they're .apk's rather than .deb's,
but more because (as far as I've looked anyway) the android ecosystem 
doesn't have the same build-package-distribute infrastructure that distros
like Debian and Fedora have built and now take for granted.

Oh, for heaven's sake, how could I almost forget to mention the
reproducible builds effort? I don't know how the laws of reality changed
to make that possible let alone feasible, but wow. And that /is/ even
being addressed in Debian [3].

> But some of it is also inevitable.  A lot of smart, talented people want
> to work on really hard problems that are currently major pain points,
> since that's where they can have the most leverage.  Packaging just
> *isn't* that any more, ...

So I'd say there are plenty of major pain points in this space that are
hard and interesting and attract smart, talented people. Heck, Docker
got a $.4B valuation [4] a few months ago just a few months ago.

Why aren't those people doing things in Debian? I claim two reasons:
1) because they can make (more/any) money doing it elsewhere; and 2)
because Debian folks are more interested in the solved problems of the
90s than the problems of today.

Cheers,
aj

[0] *Not* meretricious as I was about to write. Thankyou dict.

[1] https://wiki.debian.org/WordPress#Basic_Installation_guide_for_Wheezy

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576998

[3] https://people.debian.org/~lunar/blog/posts/eighty_percent/
(This should totally be posted to d-d-a)

[4] 
http://www.bloomberg.com/news/2014-09-16/docker-said-to-be-valued-at-400-million-in-funding-round.html


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150122102845.ga18...@master.debian.org

Re: About the recent DD retirements

[Paul Wise]

On Thu, Jan 22, 2015 at 10:46 AM, Russ Allbery wrote:

> cp and ls just work, which is great, but it also means they've
> never felt any particular desire to work on them.

That reminds me of this recent talk about trends in copyleft:

https://www.youtube.com/watch?v=-ItFjEG3LaA

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6En9=ruxyKOM_WATv4Zm9dqKy_CJLmD=aumx0zbl-h...@mail.gmail.com

Re: About the recent DD retirements

[Russ Allbery]

Gunnar Wolf  writes:

> And... Sure, Debian's attractiveness has also morphed. Those of us who
> joined a long time ago (I'm "younger" than you on the project, only
> since 2003, but it's still a very long time) have changed our life
> circumstances, possibly our interests, maybe even our ideological
> viewpoints. And yes, maybe (but that'd fuel a different discussion)
> Debian is less attractive in general to the young developer population
> to what it was in the past — I don't remember where I read that the
> median birth year of DDs has remained almost constant, which means that
> (yes) we might be attracting more senior developers (after all, Linux is
> no longer just a toy), but also... That we are failing to attract young
> talent.

Partly this is because we've been so successful.

Back when I started working on this stuff in the mid 1990s, packaging and
distributing software was a hard problem.  The existing solutions were
rather dubious, portability to the various UNIXes was quite challenging,
and we all didn't really know what we were doing.

This situation has improved *radically*, largely (although not
exclusively) due to Debian.  The world is now full of high-quality
packaged software, and even the relatively crappy packaged software or
half-assed packages (fpm with no attempt at metadata, for instance) are
better than the state of the art was in the 1990s.

One side effect of this is that packaging feels like a solved problem.
That doesn't mean people aren't willing to work on it, but it isn't the
cutting edge of what we used to call sysadmining and what's now called
SRE.  In talking to professional colleagues about this, most of them are
not particularly interested in packaging, not because they think it's
unimportant, but for the same reason why they aren't interested in
coreutils.  cp and ls just work, which is great, but it also means they've
never felt any particular desire to work on them.

Addresssing this problem is tricky, since it's a *good* thing that we've
solved a problem reasonably well and packaging is no longer what's
actively painful for people (and thus motivating them to do something
about it).  But there are still a lot of hard and interesting problems,
which are worth working on.  So, one, we need to figure out how to make
those problems apparent and provide people leverage to work on them.  But
we should also consider that the project has a lot of appeal for people
who *aren't* interested in being on the cutting edge of something, and who
find maintaining their corner of a well-established infrastructure rather
attractive.  Which requires a different kind of recruiting.

But some of it is also inevitable.  A lot of smart, talented people want
to work on really hard problems that are currently major pain points,
since that's where they can have the most leverage.  Packaging just
*isn't* that any more, so it's to be expected that a lot of those people
are off working on something else that is: crypto, or social networks that
aren't driven by advertising and surveillance, or container deployment, or
trying to build a programming language that can finally replace C as a
safer language for writing our core infrastructure, to list a few obvious
examples.

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


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oaprpm6f@hope.eyrie.org

About the recent DD retirements

[Gunnar Wolf]

Hello world,

There is a thread that started today in debian-private. Don't worry,
it's not an earth-shattering thread, nor is it complaining about huge
masses of retiring DDs. However... Yes, in the last few months we have
got used to seeing many more retirement messages than what we used to
in that mailing list.

The rules of engagement dictate that I shall not disclose here
anything but my own message. However, the original poster made a very
interesting, long mail, with some questions to which the answers might
be interesting for the general public to read. I will take the freedom
to quote the questions along with my answers. Mr. Original Poster, if
you care to identify yourself and forward your full message, I'll be
happy.



First of all: Yes, this is the right forum. At least, this is *the*
forum we currently keep an eye on and start acting on account
retirement notices. Usually, account retirements posted here get
processed first by keyring-maint (Jonathan McDowell, Daniel Kahn
Gillmor and myself). We then either transfer or open a relevant
ticket to DSA.

Second, yes, the retirement trend is public: We talked about its
inavoidability back in DC14, and I posted several times on my blog
about it. The last one is at:

   http://gwolf.org/node/4022

So, we are not posting "Mr. Foobar, maintainer of packages foo and
quux, has retired", but we do have:

   The graph above shows the sharp change between tags 2014.12.31 and
   2015.01.01. But my definition of success is that we managed to get
   the number down to just 252+35=287 from what we had back in August,
   when we did our DebConf presentation and started the aggressive
   push: 490 DD keys and 49 DM keys. Since then, 34 DDs requested
   their retirement, becoming emeritus, and practically all of the
   rest managed to get their key transition done!

And, of course, you do have a public Git repository detailing the
changes:

   https://anonscm.debian.org/gitweb/?p=keyring/keyring.git

So, yes, it is public with quite full detail. And yes, we knew quite
well us retiring 1024D keys would bring a load of retirements. And to
some degree, it is a *good* thing. Yes, being a socially-active DD for
long, and having been a DebConf organizer for most of my Debian
involvement, I do know many of the retirees personally. It is, as I
have posted here, animically(?) hard to prompt so much people for
action and get all those retirement messages. We "lost" 34 people in
the last six months!

But then again, by far most of the retirees state the fact they are
leaving just acknowledges they had already left long ago. Which is
also sad — But it is, after all, just a fact of life in a
volunteer-run project.

And yes, we have at least a lesser size distortion on the project. We
have many more orphaned packages — Some months ago they were as orphan
as they are today, but we weren't paying enough attention.¹

And... Sure, Debian's attractiveness has also morphed. Those of us who
joined a long time ago (I'm "younger" than you on the project, only
since 2003, but it's still a very long time) have changed our life
circumstances, possibly our interests, maybe even our ideological
viewpoints. And yes, maybe (but that'd fuel a different discussion)
Debian is less attractive in general to the young developer population
to what it was in the past — I don't remember where I read that the
median birth year of DDs has remained almost constant, which means
that (yes) we might be attracting more senior developers (after all,
Linux is no longer just a toy), but also... That we are failing to
attract young talent.

¹ *Please* do not read this as an attack on MIA-team work. They do
  very hard, heuristic-based work. It will never precisely match
  reality, though, IMO.

> The questions I want to open up with this email are:

OK, you make specific questions. I skipped most of your mail's
content with my rant, but lets go to this point!

>   * do you have the impression that Debian wants only contributors that
> consistently spend many hours for Debian each month?

I really hope not. My time allocation from Debian varies wildly, and
it often reaches zero.

>   * is there something that can be changed to make it less time
> consuming to be a good citizen (like better ways to keep up with
> relevant discussions)?

I try to do that, at least. It's a very passive way of participating,
but at least I "lurk" (and post very seldom) on ~10 mailing lists
(including -devel, -project and -private) and idle on a couple of IRC
channels. That allows me to feel the pulse of the project and catch
many of the erupting topics.

>   * does the concept of "the package maintainer" assign too much
> responsibility, putting too many eggs in a single basket? (Freezing
> a package if $maintainer goes MIA, stopping other contributors from
> moving Debian forward)?

I think we have collectively done a great job of slowly moving over