Re: Starting the derivative conversation
- To: email@example.com
- Cc: firstname.lastname@example.org
- Subject: Re: Starting the derivative conversation
- From: Martin-Eric Racine <email@example.com>
- Date: Fri, 22 Jul 2005 10:31:06 +0300 (EEST)
- Message-id: <Pine.LNX.firstname.lastname@example.org>
- In-reply-to: <1121975737.4104.19.camel@laptop1>
- References: <1121975737.4104.19.camel@laptop1>
On Thu, 21 Jul 2005, Jeff Licquia wrote:
At DebConf, several of the external derivative Debian distro vendors, as
well as several CDD representatives, got together and talked about ways
in which we could better cooperate with Debian proper. Lots of good
ideas were thrown around, but two strike me as being proper starting
I'd like to point out that I'm the one who suggested having this meeting,
upon noticing that many issues brought up by package maintainers and by
publishers of Debian derivatives were persistantly repeated in several of
Issues such as:
* receiving bug reports from derivatives the maintainer never even heard
about into the Debian BTS,
* duplicated work in separately maintaining packages with only cosmetic
differences for Debian, SkoleLinux and Ubuntu,
* open bugs that turn out to have been fixed by another derivative and the
maintainer would have appreciated receiving the patch to merge it, etc.
Upon probing some of the companies/projects involved in derivative work, I
found out that these issues were already known, but no clear solution had
achieved concensus, because nobody had dared approch other stakeholders to
gather up and discuss the issue, hence why I took the initiative.
We had a very productive meeting, whose conclusive Action Points were:
1) upload the latest version of Progeny's 'picax' CD creator to Debian.
2) submit all derivative-specific patches back to Debian, to reduce the
delta between Debian versions of the same package as much as possible and
to avoid duplicated work on issues that have already been fixed.
3) each derivative shall publish the API of their own BTS, so that all
derivatives can keep track of each other's bugfixes and more easily merge
back fixes that apply to everyone, again to avoid duplicated work.
4) join the debian-custom mailing list to discuss the establishment of a
Debian Derivatives Council, then immediately after create a separate
mailing list bearing the official name we'll select for the commitee, if
it turns out that the debian-custom list would prefer that this agenda be
5) create a page on the Debian site that describes the key differences
between the Debian "reference distro" and each derivative.
6) create a Deriver's FAQ on the Debian site that describes the CDD tool
and what steps are required to create a CDD or derivative.
7) upload debianized packages not yet in Debian.
A) should we create a common BTS that would ease the maintainer's job of
keeping track of all bugs on their package as built by every derivative?
B) should there be a "United Debian" base CD, common to all derivatives?
C) Who is allowed to use the Debian brand and how?
- Could e.g. Ubuntu sell their Ubuntu Certified Engineer training as a
simulateneous Debian Certified Engineer training? On what conditions?
- Contrast brand usage rights with the goal of giving back to Debian.