Enterprise and Debian Pure Blends
Hi,
inspired by the talk of Russ Allbery at DebConf[1] I would like to give
an introduction into Debian Pure Blends[2] in the hope that this might
be helpful for enterprise issues. Before I start I would like to
introduce myself a bit, because I think while this mailing list is not
really new it might have seen a lot of new members (including me)
recently and it seems good to know who is involved.
I'm personally not connected to what we would call enterprise relevant
stuff. I started the Debian Med project in 2002 and found a lot of
similarities between several user oriented projects (Debian Junior,
Debian Edu, Debian Science, Debian Accessibility) to get the idea to
technically join those projects via common tools. This effort which
is called Debian Pure Blends since 2008 was quite fruitful because
each project has developed some technical stuff which somehow turned
out to be useful for others as well.
My main idea which I outlined at DebConf 7[3] is that we need to
introduce a new abstraction level when looking at our package pool:
Looking at a single package level you are just lost in the large pool
and thus we should rather have a view on package groups which are
useful to do certain tasks. This is implemented in so called tasks
files which are used as basic source of information in Blends. All
currently existing tasks files are in Alioth SVN[4]. The format is
described in the Blend doc[2] and also in my talk at MiniDebConf in
Berlin[5].
By using the blends-dev package you can easily build metapackages from
these tasks files. The so called web sentinel contains user oriented
tasks pages which are rendering all interesting information in several
languages (as far as there are DDTP translations) including
screenshots, popcon, debtags etc. Moreover the tasks pages are
featuring "calls for action" for users who might provide DDTP
translations easily (hint: a user visiting a page with packages he is
interested in is a potentially better translator than a random
volunteer who might not necessarily understand the description text)
or screenshots for screenshots.debian.net. Moreover there is a
developer oriented bugs overview which lists all bugs of packages
which are part of the task in question. Same idea as above: A
developer who is interested in a certain task might have a good
motivation to keep packages of this task clean.
If you are interested in the web sentinel I would recommend to have a
look at the entry page at Alioth[6]. Just follow some links to tasks
and bugs pages.
The application of these tools for Debian Enterprise might be
challenging because there is no such thing like "the" enterprise. The
problems we might face here will be probably higher than we discussed
in Debian Accessibility[7] which is probably not using metapackages
but are fine with the web sentinel stuff.
>From my point of view we are currently rather at the beginning of
developing the techniques: I currently believe that the power of
metapackages is not (yet) fully used but it might turn out that we
need to replace this technique or provide additional alternatives
which enables us to handle sets of packages even better (I do not know
any alternative, I'm perfectly happy with them - just brainstorming
and expressing that this does not need to be the only road of Blends
technique). As I said in the beginning I'm not really involved in the
enterprise field - so do not hesitate to make better suggestions if
you see better techniques which might be useful inside Debian to
handle groups of packages as kind of a substructure layer between
single packages and Debian as a huge distribution.
Please also do not underestimate the not so technical aspect of
forming a team: Group maintenance of packages is not mandatory in a
Blend but it has turned out to be very convenient. Imagine that a
real niche area in Free Software like medical software has gathered at
least five people who now are DDs *because* the Debian Med project
exists. If people see there is some powerful team they tend to join
and strengthen the team. (There are also counter examples like Debian
Junior which did not succeeded to form a team and is now orphaned.)
Currently I'm testing some code which sends weekly reminders to Blends
mailing lists about packages of the Blend with newer upstream versions
available and which have RC bugs. I intend to implement more of these
QA tools always based on the set of packages defined in the tasks
files. I have a lot more ideas and hope some are useful for
enterprise issues as well that I hope that some people of Debian
Enterprise might bring in other ideas (ironed out in code ;-)).
Thanks for reading up to this point of the long mail - hope this was
the longest one I wrote to this list.
Kind regards
Andreas.
[1] http://penta.debconf.org/dc10_schedule/events/578.en.html
[2] http://blends.alioth.debian.org/blends
[3] http://people.debian.org/~tille/talks/200706_debconf7_cdd/
(unfortunately the video recording is not available from
video archive - I pinged video team)
[4] svn://svn.debian.org/svn/blends/projects
[5] http://people.debian.org/~tille/talks/201006_minidebconf/
[6] http://blends.alioth.debian.org/
[7] http://lists.debian.org/debian-accessibility/2010/07/msg00025.html
+ other mails in this thread
--
http://fam-tille.de
Reply to: