Re: Welcome to Debian Astronomy!
Hi Fred,
On Mon, Mar 24, 2014 at 12:04:02PM +0100, picca wrote:
> > I would see it quite the other way around: Having specialized blends
> > would actually attract people and interest from this field and therefore
> > help in maintaining the packages.
>
> This is why I like the tasks files of the blends
+1 :-)
> or the work around the neuro debian.
I would like their really good work even more if they would enable it to
work together with Blends techniques. While I discussed this with
Michael Hanke in the Debian Science workshop in Grenoble that this would
be a nice goal they did not make much progress in generalising their
hacks around some Blends data. I admit I also never delivered the data
in the form they wanted it to have - it is simply a manpower problem.
So if you really like stuff presented by NeuroDebian it might help
working on the technique to open it for everybody. Since last years
summer of code work this became *lot* easier since everything is in UDD
and can be used from there.
> This is an appealing way to present software and create a community
> for a specialize area of debian-science.
... and that's why I really like the Debian Astro approach.
> > Can you be more specific on what you mean with the danger of
> > fragmentation? As an astronomer, I am also a scientist, and therefore
> > would feel as a part of the scientific computing approach of
> > Debian. But: as debian-astro, we may also get amateurs which may not
> > count themself as scientists.
>
> for me the problem is that some discussion of the astonomers can be interesting
> for other field of science.
IMHO astronomers are sensible people. They might CC Debian Science list
or move on here this kind of discussion. IMHO this worked perfectly when
we started with citations stuff in Debian Med and moved it here.
> for exemple the cpl pipeline used in astronomy is quite interesting also
> for detector analyses in synchrotron radiation facilities. This is nice
> to see the work around this in Debian-science
>
> If this kind of discussions move to debian-astro it will be more
> difficult for peoples following debian-science to hear about your
> software even if they are not interest first in astromony.
If it is only to "hear about software" the tasks pages will remain. It
is a long term todo item to inject so called "meta-depends" where we
could include the dependencies of a task into other tasks (for instance
all astro-* tasks into science-astronomy). Since all data are now
easily accessible in UDD this could be done way easier than before
but not as easy as some 30min coding.
> I hope that you will create a vibrant community around astronomy
> software. :)
+1
> from my point of view this flat organisation is nice
> it is very easy to remember the location of a package of debian-science.
>
> git.debian.org/git/Debian-science/packages/<package>
Hmmm, since debcheckout exists or some
apt-cache showsrc <pkg> | grep ^Vcs
there is not much to remember IMHO.
> if we start to create subdirectory this will be a pain.
>
> I think that this hierarchical presentation is not the purpose of the
> repository. This is more what is provided by the task pages of the
> blends.
>
> I like also the dgit project which try to unify around git the
> management of packages in the archive. This way we can forget about repo
> organisation and it is possible to create automatic tools which can work
> at the full distribution level.
... and this (even if I did not dived into dgit yet).
> the pity is that it does not work properly with format 3.0 (quilt)
> which is really usefull when you work with the upstream.
+1
> > whether a repository is in /git/debian-science of in /git/debian-astro?
> > What kind of "maintenance" do you mean here?
>
> For exemple dh_python migration, add of new X- flag in the control file.
> mpitc2 -> mpich migration, upstream files addition.
>
> this kind of things which can be handle by the Team work.
If ACLs are properly set any DD can do some changes. This worked nicely
when James McCoy changed debian/upstream -> debian/upstream/metadata in
different repositories without even beeing a member of any team.
> The problem is that we do not have visibility on a roadmap of the
> debian-science team. This should help peoples work together if we had
> one.
Having a roadmap would be nice.
>From my perspective for effective cooperation in a team also means that
every team member checks for RC bugs of team packages. This does not
really work in Debian Science since the number of packages became really
large (OK, in Debian Perl it works even with more packages) but the
technicque behind the packages is quite diverse (why comparison with
Debian Perl is not valid). It happened in the past that I was
addressed *personally* (not via the list) since the Debian Science team
was considered non-functional. I do not subscribe this and I think the
situation has enhanced over the years but when I made some QA research
(RC bugs, packages not uploaded for a very long time) and even the
maintenance of the Blends tasks Debian Science was not performing as
good as smaller dedicated teams. My hope is that dedication for certain
sciences could enhance the situation a bit more while I see no obvious
drawback as long as some main people of each team will remain here.
> > I would draw some more attention to the Policy, where debian-astro
> > should not deviate too much from debian-science.
>
> For Debian-PAN, I would use the same policy with the addition thaht all
> packages should be backportable out of the box (best effort). Because we
> are using these software in production and whant to work wit the stable
> release.
>
> Maybe the debian-science policy should contain some reference to sub
> projets and specific recommendations.
Definitely. Would you volunteer to just inject this into the Policy
document?
> This way it should be clear thaht astro is a subproject of the bigger
> debian-science.
I havn't seen the science related Blends this way since they are
currently technically independent. Before you come up with this you
probably should *define* what a subproject means exactly.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: