Improving coordination / support for upstreams
It is very gratifying to me (an active DD from 1995-1998) to see that
Debian is doing a much better job supporting its developers than in
the past. I want to thank Margarita Manterola, Maximiliano Curia,
Valessio Brito, and Raphael Geissert for their "Debian Appreciation
Day". I want to thank yarik for noting at DebConf10 the reportbug
option --kudos (thanks to Tom Allison and Chris Lawrence for making it
happen). Cool. It is also gratifying to see that Debian is working
better with its derivatives too. We are doing great at building the
fabric of our ecosystem!
Although there is much more work to be done to support our own community
and that of our users (including derivatives), I think we also need to
work more diligently at building better interfaces with our upstreams.
Michael Banck (effectively) raised this issue in the Debian Science
track at DebConf10. Michael Hanke and Yaroslav O. Halchenko
(yarik) discussed some of the relevant issues in their presentations
at DebConf. Indeed I felt this thread everywhere at DebConf10,
but usually "below the surface".
Here are some concrete ideas that might positively improve our
coordination with upstreams:
- Build a "portal" where upstreams (and others) can come to better
understand what Debian does with its software.
o Perhaps this could be part of packages.d.o (a link for upstreams,
maybe) although the material at packages.qa.d.o might be even more
relevant for upstream. But to accommodate upstreams who may not
know much about Debian, I think we need better text to explain the
data available at those resources.
o Suggested content for the "portal"
* Statement of thanks for producing DFSG-free software so that we can
redistribute it in Debian and our derivatives
* Statement of compliance that all software distributed with Debian is
subject to extensive QA to ensure that it meets with Policy,
FHS, Release Goals, etc. (what else?)
* An explanation and link to our UpstreamGuide
* An explanation and links to Debian Policy, FHS, Release Goals, etc.
* Information about contacting packagers & the security team
* Information about the architectures to which we port and distribute
* Information about the number and locations of our ftp mirrors
* Information about any other Debian resources relating to their
software such as an Alioth project, etc.
* Number of derivative distributions (Ubuntu, Xandros, MEPSIS, etc.)
that also include the software
* Include appropriate UDD data
* Include appropriate DEHS (Debian External Health Status) data
* For software in main, a statement of DFSG-freeness (and some
explanation as to what this means)
- Add a reportbug --kudos-upstream facilitity to send kudos upstream
* This will require a standard metadata a field for contacting upstream
which DEP-5 seems to address with its Upstream-Contact field.
- Extend thank.debian.net to send kudos upstream as well.
- E-mail upstream after each major release of Debian apprising them of
the release and the location of the portal page where they can find out
more about how Debian is re-distributing their software. We could
note that they may find this data useful in grant applications,
budget requests, and for career development support materials.
* This could be an automated process for all packages.
- Document the portal page within Debian to assist DDs, DMs and others
in extending kudos as well as bug reports, patches, and other
How/Where would we build such a portal?
Any other ideas for impoving upstream coordination?
------ Appendix ------
o Inform upstream about services Debian provides so they better
understand how their software is being redistributed/integrated
* This could help them "flesh out" grant applications, career
development documents such as their CV (curriculum vitae) and
resume, reports to other sponsors, etc. By providing basic data
such as to how many architectures we port their software and
give them some insights about how widespread and useable we make
their software (popcon, lists of ftp mirrors, etc.). By providing
statements of compliance with our standards, licensing, etc, we can
assure upstream of the quality of our re-distribution of their work.
* Advocacy for Debian packaging standards. We can inform them of our
standards and lobby that they adopt our standards to improve their
software and to help simplify our job of debianizing their software.
* Advocacy for Debian. At minimum they will be informed about
what we do, but they might also list us on their home page,
in papers, on grant applications, etc.
* Advocacy for DFSG free: we can applaud them for using a DFSG free
license and explain that that was critical for Debian being able to
provide all these services for their software. This could help us in
our efforts to advocate for free licenses.
o Improve coordination with upstream
* Having an interaction with upstream that isn't just another bug
report or strange request to accommodate Debian's (weird-to-them)
* Provide more helpful ways to inform upstream about the Debian
way of packaging software. Indeed, upstream often makes
our lives difficult by mixing binaries with source code,
bad version handling, bad licenses, hardcoded paths,
and other issues that inspired the wiki page to provide
an UpstreamGuide to facilitate getting software packaged.
* Apprise them of our QA practices and the benefits they receive
5. Filesystem Hierarchy Standard http://www.pathname.com/fhs/
11. Debian Enhancement Proposals #5 http://dep.debian.net/deps/dep5/
We are on a spaceship; a beautiful one. It took billions of years to develop.
We're not going to get another. Now, how do we make this spaceship work?
-- Buckminster Fuller
CJ Fearnley | Explorer in Universe
cjf@CJFearnley.com | "Dare to be Naive" -- Bucky Fuller
http://www.CJFearnley.com | http://blog.remoteresponder.net/