On Mon, Mar 07, 2011 at 08:46:15AM -0800, Kevin B. McCarty wrote: > > It's certainly fine by me, just be aware that I won't be able to > provide much (if any) mentoring support. You and Bastien will need to > find sponsors and/or join the Debian Science team for uploads. Do > please re-read [1] one more time ;-)
Whoever wants to work on these libs should definitely join the Debian Science team. I'm to some extend up for mentoring and sponsoring - I guess there are some others hanging around here on this list as well. > Looks like FTP-masters have been very responsive at following up the > removal requests, so when you have packages to upload, they'll need to > go back through NEW. That's a bit unfortunate - but usually packages which was in Debian formerly (and thus are fine license-wise) have a good chance to pass NEW smoothly. I'd regard it a very good idea to announce the intend to remove a package here before contacting ftpmaster. > Sorry for the hassle, I hadn't thought anyone > cared at all about these packages anymore based on the lack of > follow-up on any FTBFS bugs. I actually had some look into it a couple of weeks ago but have just realised that fixing these was not as cheap as my time frame for this task would have allowed. > On the other hand, the packaging might very well benefit from a > redo-from-scratch, as it's evolved very cruftily over the years. Part > of the point of the extra cruft was originally that it should be > possible for non-Debian users to be able to build easily from the > source package, but maybe that isn't so important these days? A lot > of the cruft is necessary though, as Cernlib's original source > building infrastructure is an utter abomination. I do not remember what package exactly was affected but I once had one package which had several tarballs inside th eupstream tarball. It might make sense to ship these as separate sources (but I might be wrong here because I simply missunderstood the intention behind this). > One issue that may have irritated upstream is the fact that Christian > felt strongly about keeping the Debian packaging stuff in upstream > revision control (so that users could run e.g. "make debian" to build > .debs during the period in which there were not officially provided > Debian packages). If he is no longer able to spend time on the > packages, that's a decision that a new set of maintainers could > conceivably revisit. I'm always in favour of the contrary: The debian/ dir does NOT belong to upstream. Those who might want to build Debian packages themselves should rather visit our VCS (be it SVN or Git) and obtain the Debian related stuff here. If this is the problem with upstream communication we should be able to solve it quite simple. Kevin, thanks for those detailed hints to your successors and thanks for all the time you spended previousely in these packages. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110308074007.gd26...@an3as.eu