On Tue, 1 Apr 2008, Holger Levsen wrote:
Yep, no problem about this. That's why I wrote that we are tolerant
to use the list for this.
I think there is a difference between being tolerant about stuff which doesnt
belong here, and accepting stuff because it belongs here. (continued below..)
Yes - it is. :)
Let me give you two (contradicting) answers to that:
To be exact these are no answers but questions and I see no reasons
why questions could contradict. So I'm answering them...
1. Haven't we met? :-D
Yes, we had several times in the past. Once I was even wearing your
name tag (HEL airport).
2. What is the meaning you once gave to CDD, where is it documented?
Easy: Try the first Google hit "Custom Debian Distributions". If in
doubt follow the link I gave in one of these mails in this thread I have
given. There were several active discussion on this mailing list in
the past - feel free to search the archive.
And, isnt it possible that this meaning changes over time?
Yes. It is perfectly possible. But this should not happen silently
to avoid confusion. It makes no sense if people use terms with different
meanings. That's why I talked about "tolerance" to give room for
a change. Once this might turn out as a positive thing we should
agree together for a change.
Also I dont think there is agreement, where a CDD is or should be.
Well, there is a definition. It makes no sense to not agree to
a definition. If somebody thinks that the defiinition is missing
to fullfill the job to describe some part of the reality than we
should work out a better definition.
Some say, a
CDD must be 100% within Debian, others say, it's enough if this is the (not
yet achieved) aim.
Well, this is a pragmatic approach, isn't it.
Others even say, a CDD is any distribution based on Debian.
If they says so, they just did not read (or understood) the definition.
I'm in the second camp. To me, a (official) CDD is a distribution, which aims
to be 100% within Debian, whether this goal is achieved or not.
I would put you into the "pragmatic" group of people anyway. ;-)
Also, I personally see this list as a list for discussions about CDD
development and about the tools useful for this. And as that I dont tolerate
discussions about (for example) using simple-cdd to build whatever non-CDD
someone has in mind, but I think this _exactly_ one of the things this list
is for.
OK. What would be your conclusion to do?
Maybe it would be wise to introduce a new term, for Debian based
distributions, which are not CDDs according to our definition. That would
prevent us from using "(official) CDDs" and unoffical ones. So I suggest DBD
(Debian Based Distributions) for those :-) What do you think?
I think we should find a new name for what is currently called CDD and
it desperately needs the term "internal" in the name. Anything else is
missinterpreted because I learned in the past that people refuse to
read definitions and the term CDD is simply missleading. When I had
my talk about Debian-Science at Chemnitzer LinuxTage two people asked
myself after the talk why I try to build just another Debian derivative.
I've talked about the fact that Debian-Science is internal several times,
I even argued to other people who wanted to know the difference to
other scientific distributions that we have a major advantage: We are
plugged into the huge Debian distribution and thus are on the sholders
of a giant. Despite this I was asked about why we try to work on
something else than Debian. So I have drawn two consequences:
1. The idea to be internal must be good because there are people
out there who advise me to do so. ;-)
2. People just don't listen / read. They realise the headline
and adjust their perception - whatever you will tell them next.
I disagree. Meaningful names are useful, not useless.
Yep, but CDD is just not meaningful. It is even worse: It means
the wrong thing.
https://penta.debconf.org/penta/submission/dc8/event/239,
https://penta.debconf.org/penta/submission/dc8/event/242,
https://penta.debconf.org/penta/submission/dc8/event/243,
https://penta.debconf.org/penta/submission/dc8/event/244 and
https://penta.debconf.org/penta/submission/dc8/event/247
Those events are currently not visible to anyone execpt penta-admins and you.
Could you post those proposals to the list, please?
Uhm, stupid penta - I have no idea why this is not fixed for a long time.
Here it goes:
1. CDD renaming BOF
(yes, I registered this _before_ this thread started ;-))
We should stop confusing our users
Event type : bof
Track : DebConf
Language :
Event state : undecided
Progress : new
Abstract :
At DebConf 3 in Oslo those user oriented projects that formerly was named "Debian internal
projects" were renamed to "Custom Debian Distributions" to differentiate between
poor technical internal projects and customisations for special user interests inside Debian. The
experience of five years has shown that this name is terribly confusing and everybody who hears
this term immediately assumes that we are doing something outside Debian. Even DDs continuosely
fail to see the fact that we are something inside Debian. So it was a big mistake to drop the term
_internal_ from the name and even if naming discussions are as useful as color of bikeshed we
should start this because the continuos misunderstanding finally corrupts our intentions and might
keep users away or work contraproductively.
Description :
Further topics for the BOF in case the name discussion ends quickly (even if
this never happened before): * How to continue with Custom Debian Distrubution
tools? * New ideas for even better management? * CDD localized: How can local
language teams profit from CDD techniques?
2. Custom Debian Distributions
Making Debian the distribution of choice for specific work fields
Event type : lecture
Track : DebConf
Language : en
Event state : undecided
Progress : new
Abstract :
The idea of Custom Debian Distributions was born at DebConf 3 in Oslo and has
turned now into a solit toolset that can be used to organise packages targeting
at a specific work field inside Debian in a quite efficient way. After five
years it is time for a report about status and success as well as continuing to
spread the idea amongst people to enable them to spend a minimum effort for the
adoption of the tools to get a maximum effect in maintaining a CDD.
Description :
One goal of Custom Debian Distributions is to form a group of Debian developers
who care for a specific set of packages that are used in the day to day work of
a certain user group. The fact that Debian has grown to the largest pool of
ready to install packages on the net has leaded to the side effect that it has
become hard to maintain for beginners. A Custom Debian Distribution adds some
substructure that is focussed on user interest. These substructures are not
oriented on technical matters like Debian installer team, porting teams or
teams that are focussing to implement programming language policies. There are
some similarities to Debian-i18n which also has the pure goal to serve the
needs of certain end user groups with the difference that the users are grouped
not according to their field of work but according to their language. In fact
it makes even sense to create CDDs for languages that require certain technical
means to optimally support the language regarding direction of writing, special
fonts etc. It is known that some countries in Asia builded Debian derivatives
for this purpose but in principle it is not necessary to derive - the better
solution is to make Debian more flexible by starting a CDD effort inside
Debian. The talks will give some examples from the success of CDDs like
Debian-Edu and Debian-Med. One very important outcome of the CDD effort is the
ongoing reunification of Linex - the Debian derived distribution that is used
in all schools in Extremadura - with Debian-Edu. This step means that Debian
gets a very large implementation in all schools of Extremadura while on the
other hand the effort of development for the people who invented Linex will be
reduced. Debian featuring Debian-Edu now has a very good chance to become a
really good international school distribution because it has roots in five
countries (Norway, Spain, France, Germany and Japan) and might become
attractive for many more. The success stories of CDDs would not have been
possible outside Debian and thus leaving the path to build Zillions of Debian
derivatives that reach a very small user base and working together inside
Debian is the main idea of the talk. To make this idea more attractive in the
second part of the talk a description of tools that were developed in the CDD
effort will be presented. Especially the newly developed web tools that give a
good overview about the packages that are useful for a certain field of work
and the QA tools that enable the CDD team members to easily get an overview
about packages that need some action. So if people are not yet convinced that a
CDD for their purpose makes sense we will catch them by the tools they might
get for free if they follow the proposed strategy.
3. Debian-Science
Turning Debian into the distribution of choice for scientists
Event type : lecture
Track : DebConf
Language : en
Event state : undecided
Progress : new
Abstract :
The huge pool of packaged software inside Debian has the consequence that it also
contains a large number of software which is used in day to day work of scientists. But
the pure fact that packages are available is not enough to attract scientist who
frequently tend to so called "easy to install" distributions and just are not
aware which profit they might gain from Debian. Debian-Science has the goal to make
Debian really attractive for scientists.
Description :
After a talk at DebConf 5 in Helsinki three years ago the Debian-Science mailing list[1]
was created and there is a Wiki page[2]. It is basically about adding scientific FLOSS
software to the Debian package pool. The more than six year experience in the Debian-Med
project has shown that just adding packages to the Debian pool is nice but users deserve
more than just packaged software. Debian does a poor job in advertising the technically
good job that is done. Many users do not have an idea about the available software inside
Debian featuring a high level of quality and robustness. It is observed quite often that
scientists just choose a distribution that claims to be "easy to use" and once
they have got a nice shiny desktop environment they start to compile the software they
need for day to day work from scratch. So the task for a Debian-Science project is to
make Debian the distribution of choice for scientist which includes proper advertising
(i.e. listing software packages that are useful for scientific work), reasonable
preselection of packages, convey inter-package relations - in short: Turning Debian into
a scientific workbench that scientists are keen on using. From a technical point of view
the Custom Debian Distribution framework could be helpful to approach this goal. It
simplifies the the task to care about scientific software inside Debian in an organised
manner. Currently there is no structure in the scientific packages inside Debian - they
just exist. In principle a general science CDD is probably not the best solution and a
more fine grained structure would do better. The problem is that in fact there is nobody
who currently wants to do the grunt work to actually do something into this direction.
There exist some specific efforts for Chemistry and GIS related software but currently
except for Debian-Med which covers also all Biology related package these are rather
packaging teams than efforts to turn Debian into the distribution of choice for Chemists
and people who are working with geographical information. A Debian-Science CDD is about
answering the questions: - Who will define a list of software that should be included
into Debian to support a specific field of science even better? - Who will keep an eye on
the bugs scientific software packages are gathering? - Is there any solid group
maintenance and QA effort for scientists done by scientists inside Debian? [1]
http://lists.debian.org/debian-science/ [2] http://wiki.debian.org/DebianScience
4. Derivatives Round Table
Event type : podium
Track : DebConf
Language :
Event state : undecided
Progress : new
Abstract :
Description : <Uhm, something I do not like happened here with the
registration
I do not like. But it was a placeholöder for a common event (see below
"Debian
Derivers Roundtable"), so no harm is done because of the broken registration.
I'm a member of the commetee that organises events - so I'll sort this out>
5. Routine check - Debian-Med
Strategies for building a Custom Debian Distribution
Event type : lecture
Track : DebConf
Language : en
Event state : undecided
Progress : new
Abstract :
The talk will give an overview of the status of the Debian-Med project and how
it could work as an example for other CDDs. Considering that specific things
about medical software is of quite low interest for the DebConf audience the
main focus of the talk will be the way from a one-man idea to a fully grown
team that is working contiuosely to enhance Debian for a specific user group.
Experiences are shared how good tools and reasonable managemend can help to
attract people - users and developers.
Description :
The Debian-Med CDD was started in January 2002 and has evolved a lot since this time. Debian now
becomes the distribution of choice for people who are working in the field of medicine. On the one
hand this can be obtained from the increase of pure numbers of packages in the field of medicine.
On the other hand - which is even more interesting for general Debian development - a group was
formed that has developed a certain way of cooperation which might serve as an example for other
teams. Debian knows a lot of technical teams focussing onto technical issues (pkg-perl, pkg-python,
d-i, etc.). An important part of the project is to involve people who call themselves "pure
users" or "non-developers" (whatever this might mean) as it is done at a certain
amount by the i18n and Debian Edu team. So this talk is not about boring the audience by mentioning
medical Free Software - it exists at a certain amount out there as other specific software does as
well - but rather how to attract people to a topic where FLOSS is not common but should. It will
give examples for our way to advertise Free Software in medicine which is heavily dominated by
proprietary software, which tools we developed inside the CDD framework to be always up to date
with our web pages that are intended to attract users to Debian and last but not least the lessons
we have learned in the project that might be of high interest for other CDDs (or potential CDDs).
Examples are given for project management, attracting people by working techniques and making sure
that medical software finds a good home in Debian.
I suggested to have all these events (or at least those that became officially
accepted events) on one day. Moreover there are related events registered by
others:
Debian Derivers Roundtable (Benjamin Mako Hill)
Event type : podium
Track : DebConf
Language : en
Event state : undecided
Progress : new
Abstract :
The Debian-Derivers round-table will bring together representatives of
organizations involved in producing Debian derived distributions to discuss the
political, organizational, and social barriers to collaboration with Debian and
with each other. The round table will include representatives of Canonical and
Ubuntu, Skolelinux/Debian-Edu and a representative from the CDD community
(e.g., Enrico Zini, Andreas Tille, etc). If available, it may also include
representatives from any number of Spanish distributions distributions who may
be in attendance (e.g., Guadalinex, Llurex, LinEx), Userlinux, and others. A
complete roster will be created once conference attendees have been settled.
Debian-Custom and Debian-Derivatives (Vagrant Cascadian)
discussing common confusions over similar needs
Event type : bof
Track :
Language :
Event state : undecided
Progress : new
Abstract :
Description :
Frequently there is confusion over the terminology of Custom Debian
Distributions(CDDs) and Derived Debian Distributions(DDDs). As many of the same
technologies are used, there is considerable overlap between them, but the key
point of distinction is CDDs aim to work entirely within Debian, and DDDs
operate outside of Debian (to varying degrees). Since they are similar, in what
ways can we encourage existing DDDs to move towards CDDs? When is it
appropriate to be which kind of project? Hopefully we can review a summary of
some past discussions as a starting point, and work towards understanding
current trends and directions.
Well, it became a long reading until this point. Congratulations, you
are finished.
Kind regards
Andreas.
--
http://fam-tille.de
