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 [email protected] 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
