Re: R-Survaillance (Was: [med-svn] r3007 - trunk/packages/R/r-cran-surveillance/trunk/debian)
On Mon, 19 Jan 2009, Steffen Moeller wrote:
I did this looonng before the nice new alioth portal
popped up. And I did it only for me.
Good to hear that you like it.
Yes I like everything that transparently displays the status and
interconnection of packages which puts a single package into a
wider context.
It cannot since the packages are non-functional.
Common - 'cannot' does not really fit in computer science, right. ;-)
We have our "yellow" section. Currently the yellow section contains
everything that has either packages in experimental, unofficial
packages and projects which feature some preliminary stuff in SVN
or some other kind of source package. So in short any project
where something is done in the direction of an official package.
That's more than the red section without any packaging stuff.
I admit - and Daniel critisized in his last Jmoal related mail this
fact indirectly - that this is quite an indifferent mass and you are
probably not happy about this. But what is the default procedure
if you are not happy about something? Report a problem write a
wishlist bug report. So what do you want me to implement to
enable you to accept the inclusion of your "non-functional"
packages? Just make a a suggestion and I'll try to implement this
as soon as possible.
It would be missleading to indicate that
Debian would have packages ready, DFSG-compliant or not, that could be used for Taverna or
the jars it depends on - with a few exceptions.
So let us just express the real facts. How would you call the
section, what should be the criterion to put a prospective
package into this section? Should we split experimental, unofficial
and packaging stuff in SVN/source package for testing under three
different headlines and color them all yellow or would you
regard this as worth a differnt color code. Should we indicate
somehow reaosns like non-free license, technical problems in
packaging or whatever?
Please make a constructive suggestion.
And this was (and is) my main motivcation behind pkg-escience. I can dump skeletons of
packages without disturbing others or without imposing any levels of quality be their
availability in a particular repository.
This IMHO describes perfectly any unreleased packaging stuff in
our SVN. You should not assume that stuff inside trunk will
really build a releasable package. So what exactly do you
understand by 'skeletons of packages' and why do you need a
'playround' instead of using 'UNRELEASED' in the changelog entry
(according to packaging policy) or other ways to inform potentialy
interested people abou tthe status (comments forwhen commiting etc.)
You are right: You will not disturb others by using a private
playground but the cost of this comfortable playground is that
you will not attract helpers for your project and force people
to reinvent the wheel instead of making your stuff working.
I totally fail to see the advantage of this approach.
Well, right. But I don't even want to distract the force of the team for non-functional
packages. There will be a time when I will finish yet another package. And then I go for a
completion.
You are not responsible if somebody is "distracted" by your
stuff. The members of the teams I know who are potential
readers of your work are all clever enough to see after a
short time what status your work has. So I can not imagine
a scenario where somebody takes your work and after 8 hours
of work realises: Oh, this does not work. I'd regard it
way more possible that a member of the team says:
- Well, that's not ready and obtaining from the time stamps
Steffen is working currently on this / has most probably
stalled his work on this.
- Depending from the result and the need this team member
has he might decide whether to contact you or to do some
more other stuff.
- If you might maintain a todo list for your stuff he might
even provide the work for one or two items on the list.
hint to those two people who asked him for the packaging stuff -
but Daniel mentioned no e-mail adresses ...).
I am probably one of them.
Daniel mentioned Michael Koch and/or Egon Willighagen [1] -
and that's what I mean: there is no coordination between
people who should coordinate their work.
This does not answer the question why these people maintain
their stuff in a place where chances are low to get some help.
It is a regular alioth project. Chances are not low.
As well as collab-maint [2] which is a completely unstructured
container for all packages that do not fit into any other container
but should be maintained on alioth. I like to stress my point
to pick up the phone line again (will send you my number in private
mail) because I notice that I completely fail to transport my
message: Perhaps it works like this: "Do good things and talk
about them." You just are doing good things and stays silent
about it.
Michael knows about pkg-escience. I had forgotten about that package myself and it was
outdated anyway.
So what is the point in having a repository that is ignored
by people who know it? In principle I should know it as
well (you announced it here) - but I never understood what
is it good for. Moreover the description you gave on [3]
puts all work perfectly into Debian Med scope.
pkg-escience can disappear once the infrastructure for Taverna is available. Maybe I
should have called it pkg-taverna.
I don't have problems with the actual name. I have a problem
with the fact that it is separate from Debian Med and / or
Debian Java and I fail to see why you want to integrate once
the work is done and not before.
It is more of a publicly inspectable packaging with no time pressure to arrive at DFSG
compliant solutions.
In how far is the time pressure less if you use a separate repository?
All repositories are hosted on Alioth. Where is it said that stuff
with DFSG problems can not be prepared in any of these?
I don't disturb. And I have everything together.
Don't disturb whom? I really do not feel disturbed by a directory
in our SVN which contains not yet finished stuff? Have you ever
asked on this list whether somebody would becurious about a
taverna dir in SVN? You want to have everything together?
Fine, make a subdirectory in one of the suggested repositories and
use it as your playground. Putting a README directly into it might
help perfectly and THAN everything is together.
We can move them later. At the moment, there just is not overly much to move, really.
Well, I have no handle to force you or anybody else neither would
I ever try to force anybody. But I take the freedom to raise my
voice with the opinion that I'd regard your strategy as inefficient
and not really team oriented. Please think twice about this.
As a technical compromise I would think about a link to pkg-escience
as external SVN source which provides a direct connection. What
do you think?
http://cdd.alioth.debian.org/science/tasks/statistics.html
is not a proper place for any R related package?
Hm. No, you are right, all the debian-med R bits could move right there.
So I'll go on moving my R stuff to debian-science ...
It is a non-issue. Someone wasting an hour here or there on something that has already
been done is not too bad. Probably more ideas arise when comparing the efforts for a later
merger.
I do not think that the comparison with a formerly done non functional
package will be done by anybody if there is a working package. I
repeat: I care about the time you might waste. You are an
important brick in our Debian Med building and would try to
make you as strong as possible which is not the case if you
spend your time on stuff which is simply removed later on.
I am very emotionless in this issue.
Good to hear this! Same on my side (even if it might seem differently).
Kind regards
Andreas.
[1] http://lists.debian.org/debian-med/2008/03/msg00097.html
[2] http://alioth.debian.org/projects/collab-maint/
[3] http://alioth.debian.org/projects/pkg-escience/
--
http://fam-tille.de
Reply to: