Re: custom vs. derivative (Re: packages.gz corrupt, missing packages and other issues)
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
Reply to: