On Wed, Oct 16, 2013 at 03:51:06PM +0200, Holger Levsen wrote:
> Hi Andreas,
>
> (are you still subscribed to the edu list?)
Sure I am! And according to the liststats[1] I'm struggling hard to
remain the top 6th poster but I'll probably loose this position soon to
Mike. ;-)
> On Mittwoch, 16. Oktober 2013, Andreas Tille wrote:
> > The approach remains valid - but this is *not* the problem in your tasks
> > files at all. You did not updated your tasks files with not *yet*
> > available packages - you are just keeping cruft.
>
> Thats my point: if we collect not yet packaged packages there, there is no
> way
> to distinguish those from cruft.
Yes, there is a way. Inspecting the log I've posted. Could you please
have a real look at the list? I'm really wondering how you could come
up with the thesis that old stuff from future stuff is hard to
distinguish after having at least a slightest look.
Moreover: Future packages should get some additional information inside
the tasks file - you might really want to reread the docs[2]. So cleaning
up is simple: Remove everything that is not found that has no additional
information provided. That should be very simple. But as I repeatedly
said: Watch for alternatives / renamed packages.
> And a wiki seems better
I think we had left behind the Wiki discussion about ten years ago. A
Wiki for the intended purpose is *way* worse. And please do not use the
argument that a Wiki is always up to date. A Wiki is only up to date if
enough people care. Please trust me: All those Wiki pages createt for
Blends related package list either were never finished or are outdated
now. The major advantage is that you can *check* the metadate inside a
task file (see this bug report) but you can not with a Wiki. What lets
you assume that given you have not maintained the list of packages inside
the tasks file on what you are relying technically anyway a Wiki might
be maintained more reliable. And even if you might be right which I
doubt heavily: Why should anybody spent time in migrating the (assumed)
maintained Wiki content into the tasks file.
I really hope I misunderstood you.
> for keeping such a
> list anyway, so I'm all for your cleanup plan.
I'm doing this cleanup regularly for Debian Med and Debian Science and
it takes some time but if you try to let the amount of work not to pile
up that much as it is now that's no problem at all. BTW, I'm to lazy to
search the list, but I have given hints on this problem several times in
the past (also several times with bad timing for various freezes).
> One minor problem though: I'd prefer to do all jessie related work in git
> now,
> and keep svn exclusivly for wheezy+squeeze support (unless where we already
> use git), thus migrating the debian-edu git package is somewhat a blocker for
> fixing this bug. Else I say: please go ahead, remove all the cruft! :-)
You can keep Blends sources in SVN or Git at your preference. I could
provide a script to do the migration (or for some kind of $DRINK when we
might meet next time I'd volunteer to do this ;-)).
Kind regards
Andreas.
[1] http://blends.debian.net/liststats/authorstat_debian-edu.png
[2] http://blends.alioth.debian.org/blends/ch-sentinel.en.html#s-packageslist
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
