On Wed, Mar 19, 2008 at 09:03:48AM +0100, Andreas Tille wrote: > On Wed, 19 Mar 2008, Michael Hanke wrote: > >>> This pool contains several backported packages. I would recommend >>> using backports.org for a better consolidation and helping users to >>> find this stuff at a central place. >> Right, this is true. The reason why I will not do this, at least in the >> near future is, that I am not a DD. I would have to ask for sponsoring >> (twice). I am in close contact with me prefered sponsor, but I do not >> want to put this additional burden on him. > > Hmmmm, did you got the feeling that the sponsoring does not work > in the Debian-Med team???? Even if you stick to your policy to > "put no burden on your prefered sponsor" using a common SVN would > be a great help for anybody (including this person). Moreover you > might consider (re)reading our policy[1] about group maintenance your > arguing becomes weak. Nearly all packages in the biology section are group > maintained with DDs and non-DDs attached as Uploaders and those packages > that are group maintained are in a really good state. No doubt, they are in good shape. Moreover, what I said was not meant to be an argument -- just an explaination of my behavior :-) > Please keep in > mind that the Lenny freeze comes closer. If you will not manage to move > your packages to official Debian in time your prefered sponsor will be kept > busy with backports for estimated additional 1.5 years with backports for > Lenny. Sure sure, the release is coming. But with a package in Debian or not my sponsor has no additional work, because I do the backporting myself. However, I always try to make the packaging compatible to last stable and recent ubuntu releases. They should simply be re-buildable for non-unstable targets. So, if anybody wants to see them at backports, just upload them if you think they are appropriate -- I do not do this, as I cannot really test them on releases I do not use. That is why I keep the backports separate and attach I big warning sign to them. >> ATM there is only one prospective package that I'd consider a candidate >> for Debian that I also want to maintain by myself (read: willing to invest >> time in it, not occupying by sticking my name on it). > > OK, fine, so group maintenance seems to be no problem for you. No, indeed not. >> This package is >> called 'caret' and is my only open ITP. All other I made in the past, >> because I thought they might be needed as deps for other packages. >> However, the situation change significantly and I do not maintain them >> anymore. > > Well, this is information we are keen on hearing here on this list. > It is about coordination. It would be a shame to leave packages > prepared until some point bit rotting anywhere and nobody knows > about the status. Well, the packages you are refering to were never really meant to go into Debian. AFIAK they are not really maintained anymore and I only kept them around to eventually package another piece which needed them. Because of this status I never even filed an ITP for them. If you look at the packages you can see that there is not much work done to them (I guess it could be re-done in minutes). >> I've uploaded all of them to mentors some time ago. Feel free >> to fetch them from there (the ones that are not yet in Debian) and >> inject them into the deb-med-svn, if they look appropriate. > > I will do so in the next couple of days. Great. >> Per visibility: So far the packages seem to be in good shape. For me the >> current approach debian-med has taken with svn and deb+patches-only >> is a quite high threshold. > > I consider this as a valid argument. While several people are fine > with this we should not put any presure on potential maintainers to > do so. I have no problem to implement alternatives if they are > _documented_. Experience in the past has shown that there are > kind people hanging around on this list who converted stuff where > just the changed files were checked in to patches. Just try it. Right, my major problem ATM is lack of time, but when I solve it, I will for sure take a look. >> ATM I'd consider this more work for me not >> less, as I got used to use git plus its tools and the repositories on >> Alioth. Maybe times will change ... ;-) > > Well, times will come when we will see more git adictives. I have > no problem with freedom of choice for the tools and we will have to > live with some divergence. Unfortunately there is no ultimative > tool. So are you willing to implement a Debian-Med git repository > modelled after the current SVN and document it as alternative in > our policy document? > If not your argument you can not use svn because you are using git > sounds week after having heard a talk about git at LinuxTage Chemnitz: > Git is perfectly able to export to svn and thus you might be able > to use this repository as well. Of course it is doable, but again it needs time I do not want to invest ATM. > If nothing sounds like an option for you to enhance teamwork please > at least drop us some information which work you have done, which > is stalled for some reason, where are the git repositories and the > stuff at mentors. > >> PS: The caret package needs a tiny bit of more work, so it is not yet >> ready to go. This is mainly due to the size of the datasets shipped with >> it. I have a solution, but it has to be polished before it can serve as >> a proposal how to deal with big datasets. > > Feel free to discuss those issues here. It has been discussed before on -devel (cannot look for URL now). The issue is how to ship huge data packages. There were some proposed solutions but so far the only approach that was taken was to simply upload packages that become larger and larger. For caret we are talking about >200MB (which is not even considered huge anymore). For the missing fsl-data package (i also provide in my repository) that complementes fsl and fslview we are talking about 1.1GB -- I wonder where the limit is ... ;-) To summarize, there is nothing I have to say about stalled processes as there are none. Everything I do is documented in the wiki. Cheers, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050
Attachment:
signature.asc
Description: Digital signature