Hi,
I'm proud to announce a new QA tool for all CDD^W Blends: Overview about
all bugs about Dependencies of our metapackages. For the impatient here
is a list of these pages:
Edu: http://cdd.alioth.debian.org/edu/bugs
GIS: http://cdd.alioth.debian.org/gis/bugs
Jr: http://cdd.alioth.debian.org/junior/bugs
Med: http://debian-med.alioth.debian.org/bugs
Science: http://cdd.alioth.debian.org/science/bugs
For the moment I hesitate to announce the DebiChem project here because
this is work is neither finished nor do I want to take over the fame of
announcing somebody elses project, but you might like to have a preliminary
look at
DebiChem: http://cdd.alioth.debian.org/debichem/bugs
as well. Please keep in mind that the tasks of this project are far from
ready and there are also some remaining problems in obtaining the metapackage
name in the page rendering code - I will fix this once the Debichem Project
might agree to join the Blends effort and decides for a name.
If you not care about the details of these pages but are interested in the
status of CDD -> Blends renaming you can skip some paragraphs now.
Motivation for the bugs pages
-----------------------------
My main motivation for Debian Pure Blends is that I see a need to find some
substructure in the large flat package pool of Debian. I'm absolutely
convinced that this has to be done based on user interest and needs and
so every Blend should be an entry point for a specific user group into the
large world of Debian. I think that a specific user group is interested
in a specific set of packages and consequently they might care more about
the bugs of these packages than in any random package. So how should we
attract users to have a look into this very specific package bugs?
The answer are these bug pages. Assume you are a mathematician and have
some time to spend on bugs inside Debian. Where would you like to start
seeking where to spend your time best? It should be helpful for both: For
Debian and for you personal work and you should feel competent about the
package you want to work on. Since today the answer is simple: Go to
http://cdd.alioth.debian.org/science/bugs/mathematics.html
and watch for bugs. On top of the page you see the note:
Immediately looking into bugs of the dependencies of this metapackage is
advised
so your help is obviosely welcome. You also see immediately that there
are two serious bugs in packages which are in the list of dependencies
(not only suggested) of science-mathematics. So you found your targets
quickly.
The Bugs pages are not (yet) internationalised. I'm a little bit
undecided whether this is really needed. I'm actually very keen on
translations whereever needed - but if we want to attract people
fixing the bugs they have to understand the bug report in English
language anyway. So people unable to understand the navigation might
probably be not able to work on the bugs. What do you think about this?
Realisation of the evaluation of bug status
-------------------------------------------
I tried to find a measure how much help is needed for the dependencies
of a metapackage. This measure is not about the quality of a metapackages
because this would require a normalisation according to the number of
packages. For instance a metapackage with 5 bugs in 25 dependendent
packages is probably of a better quality than a metapackage with 3 bugs
in 5 dependant packages. But I think we should care about the absolute
number of bugs if we want to attract people who are willing to fix them
and not about making some ranking inbetween metapackage quality.
Moreover I think that bugs in packages that are in the list of
Depends and Recommends should be weighted higher than those packages
which are only suggested. This is reflected in the fact that the
dependent packages are listed on top in a separate list. Below is a
list of suggested packages. The bugs which are done are listed as
well for historical reason - but they do n ot influence the bug status
of the metapackage - done bugs do not need to attract our attention
that much.
The evaluation is done by finding some weighting numbers for the different
severities ranging from 10 for the RC bugs until 0 for wishlist bugs (see
the currently used numbers in the footnote on the bottom of each page).
I decided to weight wishlist bugs with 0 not because I think that wishlist
bugs are not very interesting. IMHO every bug should be fixed - but
I think that it might be a very rare situation that on one page only
bugs with severity wishlist and so chances are quite low that wishlist
bugs are just overlooked because there is no mark on the index page
to visit this page.
These weighting numbers are multiplied by 3 if the package in question
is a dependent or recommended package to reflect their higher importance.
Lets make a simple example:
http://cdd.alioth.debian.org/science/bugs/linguistics.html
1 serious bug in a dependent package: 1*10*3 = 30
2 imoprtant bugs in a dependent package: 2* 5*3 = 30
1 normal || 1* 3*3 = 9
1 minor || 1* 1*3 = 3
___
weighted sum = 72
On the index page
http://cdd.alioth.debian.org/science/bugs
you have a legend about the evaluation parameters: 72 > 50 (for "pass")
which makes the coloring red for this package. Fixing the serious bug
would make the weighted sum 42 which would bring the metapackage in the
next better category "satisfactory" (< 50).
In other words: A metapackage can not be in status "good" if there is
at least serious (or higher) bug in a dependant package. It also can
not be "very good" if there is a RC bug in a suggested package - but
two RC bugs in suggested packages might qualify for "good" - if there
are only a very view other bugs which sounds quite improbable. Only
one normal bug in a dependent package and no important bug in a
suggested package do qualify for "excellent" - so this is really
hard to reach.
These numbers might be discussed and we even might consider making
them configurable per CDD in the according webconf file. This is
just a quick shot. For the moment I think it works somehow.
Todo for you
------------
1. Please comment on these pages. Comments with patches for
svn://svn.debian.org/cdd/cdd/trunk/blends/webtools
are even more welcome. There is no need to throw out a lot of
good ideas if there is the chance to turn them into code and
check it in. These pages are not my private pet it is our common
work which just was started by me.
2. Maintain your index page yourself.
David Paleino has created a really nice index page for Debian Med
http://debian-med.alioth.debian.org/
Actually all the design was adopted from him and many ideas from
his former tasks and bugs pages are implemented. The other index
pages are at
http://cdd.alioth.debian.org/<blend-name>
and can be changed at
alioth: /var/lib/gforge/chroot/home/groups/cdd/htdocs/<blend-name>
No, *I* will *NOT* work on this index page for your blend. I
consider the effort you spend in this page as a measure how much
your Blend is interested in the web tools provided by the
blends effort. If you think linking from a Wiki does the work
as well this is fine for me. But please care for making the
pages popular in your Blend. It is fine for me to provide the
technique, but I will not take over thr grunt work of documentation
for every single blend.
3. Design
As I mentioned above the basic design is from David. If you want
to enhance the page layout, colors, whatever, just have a look at
svn://svn.debian.org/cdd/cdd/trunk/blends/webtools/{inc,templates}
And now for somethinc completely different ...
Status of renaming CDD -> Blend
-------------------------------
When I go for a public announcement of the renaming I wanted to stress
the message: We are not people who are busy finding new names for some
stuff but we care for techniques and promotion of our project. That's
why the announcement of the bug pages comes first - and I hope you agree
that this is the important stuff we are doing.
But for attracting outsiders it is just needed to not confuse from
the beginning and transport a wrong message with a wrong name. The
fact that the old name Custom Debian Distributions just leaded to the
implication that this is something else than Debian finally leaded
to a renaming discussion which reached a raw consensus for the
suggestion
Debian Pure Blends
In the code inside Debian we use 'blend' for factorised code that
concerns a single Blend (given as an option or something like that
and 'blends' if it is working for all Blends in one context. The
Debian and Pure is evidend inside Debian internal code like packages
blends-dev (formerly cdd-dev) or blends-common (formerly cdd-common)
etc. Configuration for blends will go into /etc/blends (formerly
/etc/cdd. The term Blend is just easier to pronounce and makes
more sense than DPB or something like that.
Technically the renaming is not yet completely finished. The
web tools are renamed and a lot of the blend source package
(formerly cdd source package) but not everything and most imoprtantly
not the documentation part. I hope to finish this until Sunday
but I'll be offline from Friday evening to Sunday evening - so
the official announcment on debian-devel-announce will not
happen before Sunday evening.
Talk about Debian Pure Blends at Linux-Info-Tag (Dresden)
---------------------------------------------------------
For German speakers have a look at
http://www.linux-info-tag.de/100/detail/153
Comments for the talk which is available at
http://people.debian.org/~tille/talks/200811_dresden_blends/
are welcome as well.
Please comment on this announcement because I plan to post it to
debian-devel-announce once the renaming is finished (at least in SVN
and the doc).
Kind regards
Andreas.
--
http://fam-tille.de
_______________________________________________
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
