Repository structure (Was: R-Surveillance (Was: [med-svn] r3007 - trunk/packages/R/r-cran-surveillance/trunk/debian))
On Tue, 20 Jan 2009, Steffen Moeller wrote:
we have it this way for biojava. as a compromise from my side: we do it conversely? If I
don't need to do it myself, please feel free to move (or have moved) the packages
currently residing in pkg-escience to anywhere in debian-science, pkg-scicomp, debian-med
or pkg-java. A note on the Wiki page indicating where a package has ended up would be fine.
I'm hesitant to move anything anybody has put somewhere else on purpose
but I will inspect in detail every part and will inform you about my intent.
Those listed on the Debian-Med project page should be listed in "red", not in "yellow".
The latter would indicate that the package is current and functional. The packages _may_
be functional, but they certainly are outdated (except for a few).
For all yellow listed packages we do NOT guarantee that packages or
the stuff which is linked to is working. That's what unofficial means:
Somebody else gave it a try and your milleage may vary. Yellow says:
well, some work has started. So if you want to distinguish the yellow
parts regarding some criterions please make a suggestion. The information
which is given in the yellow section is basically: Just consider having
a look into what exists before you start from scratch. Chances for
getting a "green" package *might* be better than for the yellows than
for the red ones because there is obviosely somebody who took some time
to work on this.
IMHO this perfectly fits for your work. If there were known problems
with some package I used to express this verbally in the end of the long
description to give no false hope. Se for instance my remark at
http://debian-med.alioth.debian.org/tasks/imaging.html#micromanager
This is more valuable information than simply moving it to the red
section:
1. There is something the user might try on his own risk.
2. The reasons why it is not "green" are expressed.
Please send me reasonable text for your packages - or just put it into
the control files in your packaging stuff so that I might be able to
copy your text.
So I'll go on moving my R stuff to debian-science ...
^^
Save your time, I'd say. The debian/control file indicates where to find the source. And
at least r-cran-qtl is not too wrongly found under the hood of Debian-Med.
I will move *my* stuff, not yours. I just commited some preconditions
for r-survaillance in which are not Med related. I will not touch stuff
who whas previousely there for a reason!
We had a case _within_ Debian-Med when Charles did not find libbioperl-runtime and started
an effort on his own for bioperl-runtime. You cannot avoid such things. And it has little
to do with the Blend or Alioth project one is in.
I admit that this always might happen. I just want to reduce the
probability. The fact that it happens even in our own repository
makes my arguing even stronger, IMHO.
You have some good points in what you are saying. The integration of pkg-escience with
some blend certainly helps visibility, particularly since debian-med.alioth.debian.org is
up. However, the current situation lets single developers join many alioth projects, and
the contributor to a single package has the rights to edit many. I don't like that since
changes (intentionally or not) may not be noticed.
I see your point. The chances to not note something are reduced by
using the commit mailing list but anyway it might happen. On the
other hand I never observed a harmful unwanted change on any of
my packages in practice.
pkg-scicomp and pkg-java are basically
too large to check out as a whole.
Valid point. I hope the the mr tool might be of some help here. I personally
check out only parts of the repository.
And Debian-Med develops towards such a complexity, too.
Also a valid point (see above).
An "all in one" or "poly in oligo" will not scale for long, at least not if we are
successful. We should start thinking about what is coming next.
I fully agree here. I'm not sure whether a restructuring of our repository
might make sense.
1. starting the whole tree with trunk just makes no sense so we
might community and packages to the root
2. Perhaps we should think about categorising our packages somehow.
The first idea which comes to mind is using the tasks we just
have. Most people feel obliged to a certain task and it sounds
reasonable to assume that checking out the "interesting" task
for a developer helps to reduce the download. On the other hand
the bio task would be quite filled anyway.
What do you think? Better suggestions.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: