Re: Debian blends tasks
Hi Olе,
On Thu, May 23, 2013 at 11:39:23AM +0200, Olе Streicher wrote:
> Andreas Tille reminded me that I should put the ITP packages into the
> appropriate Debian Blends tasks (astronomy and astronomy-dev) soon, and
> I agree that we should discuss this here on the list a bit.
+1
> Putting packages into Debian Blends tasks has really not a very high
> priority for me -- usually I do this when I anyway "polish" the packages
> (in parallel to editing their debtags).
Hmmm, looking at the web sentinel[1] more than 10 packages are not yet
DebTagged. That's not your fault - I just want to demonstrate a feature
of the tasks and a problem in DebTags (but see below).
> For me, the significance of Debian Blends tasks is not really clear:
> what is their use case? I could imagine f.e. the following:
>
> * User X needs a specific program (f.e. ds9) which his institute's
> collegues use.
> --> package manager
Fine.
> * User Y needs a package to do a specific task (f.e. view FITS data cubes).
> --> debtags and search with package manager
As far as DebTags are available to the package manager. We just have a
discussion on debian-blends@l.d.o about
a) how can we make sure that DebTags are always in sync
b) how we can integrate DebTags better into the Blends framework
> * User Z is cosmologist and wants to browse the relevant packages to get
> an overview and install the most interesting packages.
> --> debtags? (and Blend tasks?)
Why not asking a cosmologist Z whether he prefers DebTags or the web
sentinel[1]? I'm honestly keen on hearing the answer. May be you know
some colleagues who could serve as test users of category Z.
> * Use T wants to install a standard suite of programs for radio astronomy.
> --> virtual packages?, external link lists?
Well, in the Blends framework we call it metapackages and exactly this is
the answer. Before you answer that the current metapackages do contain
to much besides radio astronomy please read below. I have no idea what
you mean by "external link list" - but most probably my answer to this
question will be: No.
> What is the place for Debian Blends there? What are the advantages
> compared to Debtags?
It might be interesting to read the Blends documentation[2]. In general
the question tasks *or* DebTags is simply wrong because these are no
competing techniques. As I said the question is rather how we could
properly integrate DebTags into the Blends framework - may be the GSoC
project might bring something new.
The point is that Blends do not have a technical part *only*. It also
tries to establish a communication channel between team members (like
this list), a team policy[3]) and also provides better means of
communication to upstream and users.
Assume you want to ask upstream for say fixing their license. In Debian
Med we are doing it a long time via mails and you can pick from the
following two options what might be more successful:
1. Hi, I'm Andreas and like to ask you whether you would like to
change your license foo to bar.
2. Hi, I'm writing you on behalf of the Debian Med team which tries
to assemble all software with a free license covering tasks in
the field X. So far we have assembled the following [link to
tasks page]. If you like to be listed there for very easy
installation at your target users system we would like you to
change your license from foo to bar.
I guess it becomes obvious that the tasks page is a very simple means to
show people who might be only vaguely interested in the first place that
we are not doig just fun but there is real work done and it becomes
attractive to use. I do not think you can gain this impression if you
want to let them poke around with some DebTags tool.
Upstream becomes even more interested if there is just another chance to
propagate their scientific publications on a totally different but well
received channel (debian.org is well received - but out of this usual
publication business circle). This really gains extra points from
upstream - and it is orthogonal to DebTags.
I could add other features you can see on the tasks page like
Screenshots, Popcon values, translated descriptions etc.
On the other hand those people who want to help Debian have a very easy
means to do this. Assume this tasks page will attrakt astronomers in
the first place. Who do you think will be the better translator of a
package description for a package in the field astronomy: An astronomer
or a random translator? So these pages have a very easy interface to
submit (or fix!) the translation on DDTPS.
You can also easily find packages that are lacking DebTags or a
Screenshot. So you see you can also very easily use the tasks page as
QA tool - if there is something yellow on this page there is some work
to do. At least *I* *am* doing this and it always makes me wonder why
people would miss this chance to use the pages in a similar way.
As I mentioned before (and my private ping was about this) you can move
even not yet uploaded packages right to the tasks page. I'm talking
about the prospective packages [1a] which can give very valuable
information for users (who could for instance build packages from your
VCS and test) and it also shows some todo list which is way more lucid
than trying to check WNPP. BTW, those packages not yet inside Debian
will be added as Suggests inside the metapackages and if there might
be a local repository available you can perfectly install these via
`apt-get --install-suggests install ...`. Just to name another thing
which is totally impossible using DebTags.
Finally there are developer oriented bugs pages[4]. I admit they are
not as developed as I would like these to see - the main flaw is that
they are not update regularly because the current method to render the
pages is stress testing UDD too much. But that's a detail that can
be fixed. The idea is: If you are an astronomer and would like to
spend a time span t to fix some bugs inside Debian - do you want to
look for random bugs or to bugs affecting packages in your field?
These pages try to provide an answer to this question.
> For me, the main drawback seems that they are much too rough: There is
> just not a common thing "Astronomy" from the software side. There are
> cosmologists, radio astronomers, astroparticle physicists, optical and
> IR astronomers, amateur astronomers, highscool students. Between them is
> a smooth transition,
Well, there is a short answer to this allegation: That's not a fault of
the Blends principle - that's your fault. OK, that's a bit harsh but
I'll give a positive example: Would you like to have a look at the
DebiChem tasks[5]? Well, DebiChem came before Debian Science and thus
they have just settled as a (small) team. They are maintaining their
tasks themselves and you can perfectly see how they split the different
fields of chemistry. BTW, when checking the chemistry page of Debian
Science I admit this could be done better: There is a long standing
never implemented idea to just mention debichem tasks on the chemistry
task and resolve the dependencies automatically.
So if you might have been convinced that Blends provide some interesting
features for astronomers you could ask me to help you to go the other
route than DebiChem: Split your Astronomy Blend from the general Debian
Science (which I always regarded rather as an umbrella for those
specific Blends) and create your own tasks. Then you can get the needed
granularity yourself and create reasonable metapackages for tasks that
might make sense. To come back to my initial rude answer: You now see
how you can change what is making you unhappy at the moment. It is
definitely not hard to do. I have once proven to get a skeleton for
Debian Games ready while I was watching a 40min talk about Debian Games
at DebConf. "Ready" in this sense means: Metapackages created, web
sentinel online. All what is really needed is your personal experience
to properly name and describe the tasks and move the packages into them.
That's all.
> as well as between "user" and "developer": Are
> one-time python scripts already a "-dev" task?
The "-dev" tasks in this sense are suboptimal. Currently we try to
assemble here lib*-dev packages and python modules but just no user
applications. You can design these -dev tasks in an imaginary Astronomy
Blend better to fit your needs. DebiChem has decided to not use them
and there is no existing law that would force you to use them if you
think they do not serve any reasonable purpose.
> Maybe, you could explain a bit what the goal of the debian blends task
> is for a strawman like me :-)
I do by no means regard you as a strawman. I'm always watching the
commit list and as you know ITP bugs and you are doing an amazing work!
That's really cool and is always impressing me. And so I will also give
a word of warning. In 2002 when I started Debian Med (which somehow
formed my imagination about Blends) I was doing it in a similar manner
like you: adding / fixing relevant packages (not at your speed, thought
;-)). Today we have assembled a team[6] where 10 developers explicitly
confirmed that they only are Debian Developers *because* the Debian Med
Blend existed. Otherwise they would do something else with Debian,
local repositories, whatever. You can very easily see the development
of the team on the graphs listed on our entry page[7]. (So making
sure your team evolves nicely is also a Blends "technique".)
The warning is about the fact that your focus will move. It moves more
to educating supporting other people, inviting newcomers (see my MoM
effort [8]), sponsoring people (see [9]) etc. so you somehow drift from
package development to some manager work (finally what I'm also doing
currently with this e-mail). You also need to attend conferences and
talk about your Blend[10]. I have no idea whether you like this - but
for me it is really interesting how many people are joining our team.
We just have people with no connection to the topic itself - they just
joined our team because it is nice to work together.
So if you would like to go this path my first advise is to send a kind
and inviting e-mail to all maintainers listed on astronomy related
packages (to come back to the difference with DebTags: I have no idea
how to get this list via DebTags but parsing[1] would answer the
question sufficiently good - I could also do a UDD query to do this
automatically via Blends techniques). Invite them to join a Debian
Astronomy Blend an have fun together. If you look at the graphs[7] from
Debian Med I guess you have a way better starting point than me!
> @Andreas: If you happen to be at Linuxtag in Berlin on Saturday, we
> could meet and discuss this directly as well.
Well, I have hold talks about Debian Med at LinuxTag twice but when I do
not talk I do not join this event any more. It is to commercial for
*my* taste (I don't say it is bad - it is just not for *me*). I'll be
at DebConf (for sure!) and I always be at Chemnitzer LinuxTage. But you
can also give me a phone call if you like to chat about this a bit.
Uhmm, thanks for reading that far
Andreas.
[1] http://blends.alioth.debian.org/science/tasks/astronomy
[1a] http://blends.alioth.debian.org/science/tasks/astronomy#pkgvcs-debs
[2] http://blends.alioth.debian.org/blends/
[3] http://debian-science.alioth.debian.org/debian-science-policy.html
[4] http://blends.alioth.debian.org/science/bugs/astronomy.html
[5] http://blends.alioth.debian.org/debichem/tasks/
[6] https://wiki.debian.org/DebianMed/Developers
[7] http://debian-med.debian.net/
[8] https://wiki.debian.org/DebianMed/MoM
[9] https://wiki.debian.org/DebianPureBlends/SoB
[10] http://people.debian.org/~tille/talks/
--
http://fam-tille.de
Reply to: