On Tue, Jun 22, 2010 at 12:12:57AM +0200, Petter Reinholdtsen wrote:
> [Andreas Tille]
> > Probably not only you. I noticed that Petter was updating the
> > tasks/workstation file 8 days ago. Petter, do you see any
> > reasonable was to coordinate.
> I assume s/was/way/.
> Note, that as far as I know, the tasks/workstation file is part of the
> draft debian-gis meta package I wrote several years ago, and which
> have been largely untouched since then.
I have observed this fact (that the tasks file is untouched) for a long
time and I finally decided to give it some push for the reasons I layed
out in my previous mails.
> I stumbled across the live CD
> build part of the meta package a few days ago, did a test build and
> fixed some minor issues to get the live CD building, announced the new
> live CD and got tips about an alternative live CD and put some of the
> packages in the package list from that live CD into the debian-gis
> package. All of this was a stunt triggered by me finding the old live
> CD build directory, and is unlikely to result in any regular work on
> my part.
... and it seems also not by anybody else ...
> I created the meta package to show what direction we could take the
> Debian GIS project in, but never had time to follow up on it and
> no-one else seemed to trigger on the idea of providing a meta package
> for GIS tools.
I'm personally much in favour of the metapackages approach via tasks
files since it enables us to generate the web pages I continuosely try
to advertise. I have the (biased) impression that since I do so the
attraction of the project in question is growing. This is specifically
true in Debian Science and Debian Med (but has not stopped Debian Jr
dying or helped Debian Lex starting). I'm positively convinced that we
have quite good project groups but these groups fail to advertise their
work to the world and hope that some users or developers might stumble
upon the project by chance. IMHO the "effort of maintenance" to "effect
of advertising" ratio of using the tasks files is quite good and besides
this they turned out a really good QA tool (and I wished they would be
used much more as such - see my last rant on Debian Edu).
> I am regularly busy with other projects, and am unlikely to be able to
> spend serious time on the gis tools because of this. This make me
> want others to decide how the meta package should be maintained in the
> future. Is it wanted? Useful? Worth the effort? I do not know, but
> others need to answer yes to these for the package to move forward.
I would really like to *support* the work on this stuff, but as I said
I'm lacking some general overview over GIS packages. From the
experience in other Blends I'm perfectly convinced that you need to
widen your view from single package maintenance to try to form a
complete system which covers certain workfields. The example of Debian
Med shows (in a field which is probably much worse covered with FLOSS
than GIS): We now have about at least five more DDs because Debian Med
exists, Debian is reaching for the distribution of choice if it comes to
the use of Free Software in medicine and we have a very good cooperation
to several upstream developers. I don't know how things work in Debian
GIS and my way to (wild) guess how a team works is to look at the
mailing list activity graphs, which are available for Debian GIS
This shows what you probably know that Francesco is a very active
developer over all the time and he definitely is the backbone of Debian
GIS. He has got some supporters which changed over time but with
perhaps the exception of David (hey David, you just *know* the stuff I'm
talking about! ;-)) in the last two years none of them increased their
activity. The general activity on the general discussion list is
decreasing - even if I think the topic GIS becomes more and more
interesting. So I do not see a solidly formed team and the
run-over-by-bus factor is close to 1.
> > As I wrote: I do not really wanted to highjack and I'm fine with
> > maintaining the tasks files inside pkg-grass. So if you think this
> > is the best solution I even might subscribe pkg-grass - perhaps
> > granting commit permissions fo any DD would be easier (we have this
> > for Debian Med and Blends, you can ask Alioth admins for this).
> I suspect giving you write access to the pkg-grass alioth project is a
> good way to grant you access while still being able to give non-Debian
> Developers access to the source.
I applied for becoming a member of pkg-grass ... even if I have no
interest in packaging GRASS. You understood the second part of the
sentence? Always if I want to contact Debian GIS people I wonder
whether there are only these GRASS packagers hanging around. Yes, I can
read the description of the mailing list and I know that this is not the
case, but I'm afraid that there are other people out there which are
afraid about posting here if you are focussing that exclusively on
But from the naming issue back to my permission to the pkg-grass
repository: The fact that up to now nobody has cared about the tasks
files there is not convincing enough for me to do it for you on a
separate place than most of the other tasks files. If a single
member of the pkg-grass group starts working on it here because he
has no access to debian-blends I'm convinced. If not I would probably
use my commit permission to leave a note about the new home of the
files because all of the people who worked on it in the past do have
commit permission there. Please remember the Do-O-Cracy principle:
Who is doing the work decides what gets done. I will adapt *if*
anybody is doing something, if it turns out that I'll be the only
active person I will decide for my personal comfort.
> > Well, IMHO the most comparable thing with the tasks web pages is
> > http://pkg-grass.alioth.debian.org/debiangis-status.html
> Perhaps this is a better way to maintain the task list? We could
> maintain the meta package and get the status page for free. :)
That's the intention of the tasks pages. And my offer to implement
features you can not live without was honestly.
Pkg-grass-devel mailing list