Jonas Smedegaard wrote: > On Thu, Dec 10, 2009 at 10:57:45PM +0800, Thomas Goirand wrote: >> Jonas Smedegaard wrote: >>> As subject says, please package the newer upstream release: 1.1 was >>> released more than a year ago and 1.2 came out in late july. >>> >>> Last maintainer update was almost a year ago. If you have lost >>> interest in this package or would want help maintaining it, please >>> say so - I rely on it so might be persuaded to pour some love into it >>> if needed :-) > >> The thing is, I think it's useless to work more than once per Debian >> release cycle on a package, which is why I didn't work much on it. >> Now, as freeze is going to happen soon, I did the work already! :) > > I am shocked to here this: Debian release "when ready", so waiting until > "almost ready" simply extend the release cycle! > > Even worse: time between releases is used to *test* the wuality of > packages, so slipping in things at the last minute means lousy quality > assurance!
You don't get it. My point is NOT to send the package at the very end of the release cycle, but to do the work of packaging ONCE per release cycle. I believe it would have been useless to package 1.1 for example, have reports on it, then upload corrections, then upload 1.2, then have again corrections on it. On dkimproxy, I have spotted some issues on the 1.1, which is why I didn't package it. I want to release quality only packages as much as possible. Now, I'm really not the only one that acts like this, if you don't like it, then help me to be a DD. >> Here's where to get my package before I ask my sponsor to upload in SID: >> >> http://ftparchive.gplhost.com/debian/pool/lenny/main/d/dkimproxy/ > > I see no point in looking at your work as a special-case. If you > believe that your packaging is usable then release it to Debian to allow > *all* of us interested developers to test it concurrently! > > If you feel that your packaging is not yet ready then make it so - > either alone or together with those you develop your package with. I sent the package to the few that have sent BTS entries. I found it very reasonable to ask them to test it for FEW DAYS before I bother my sponsor for the upload (the plan was a week). If you don't like that way of doing things (I don't really either), then feel free to push so that an application manager is assigned to me quickly, so I can become a Debian Developer and upload faster without having to bother someone. While dealing with sponsored upload is ok for few packages, it's not when you maintain so many (I actually packaged about 20, not all of them are in the archive yet, and I had to skip some release too). > I do not like the concept of "sponsoring" packages - one of the reasons > is this situation of the people doing the actual work (you) being too > from the Debian mindset to realize weaknesses in packaging routines. > > Instead, I favor the concept of team maintainance, where at least one in > the team is a full Debian Developer. I really wish I was a DD, I applied 1 year and a half ago... Not my fault here. I hate the sponsoring thing as well. > If you are interested, we can work together as a team, maintaining this > package. As you may have noticed already I may be stubborn on some > things, however, but if you dare "try me out" it might actually be fun > working together :-) Great, thanks a lot for the offer. I'd still that if I was a DD it would help. Would you like to be my AM ? :) > I would want us to use Git and CDBS, as with my other 100+ packages that > I maintain (alone or in teams). I'd be happy to help you out with > understanding those tools if you are unfamiliar with them - so telling > you only for the case that you explicitly do not want to use them. Like many, I don't really like CDBS, sorry. But I love Git, many of the software I wrote are saved in Git: http://git.gplhost.com/gitweb/ >> This package solves all issues that have been reported in the BTS (at >> least, I hope I didn't forget any of them, you are welcome to check >> for it). > > Please post to those bugreports and inform about the work in progress! I did for one of them. It's a very unfortunate timing here, 2 or 3 days later, and the package would have been uploaded, closing the bugs. Now would you like to sponsor this upload this time? Here's the .dsc: http://ftparchive.gplhost.com/debian/pool/lenny/main/d/dkimproxy/dkimproxy_1.2-1.dsc > Frankly I think it is outright crazy to leave a package unmaintained for > a year due to disk space or sponsor annoyance concerns. Debian is much > more than releases, it is an ecosystem consisting also of "testing" and > "unstable" users, including derived distributions, which may cherry-pick > packages from those repositories. The issue is also my time. You may have noticed that I also maintain other packages, and I try to work as fast as I can. I had some work done for dkimproxy done for a while (even a 1.1-1 version on my laptop), but as I was not completely satisfied with it, and didn't want to release some partial work. I do think it's in a much better shape now, which is why I asked people to test it for a week before I could ask for an upload in Debian. I think it was the good thing to do, as some corrections have been added to the package thanks to this, and I believe it's ok now. Also, I'd like you to consider the difficulties with the Debian system to become a DD or to go by sponsoring: IT IS very annoying sometimes and adds unnecessary difficulties to the packaging work. One must be very motivated to overcome it. I'm not so good in promoting myself and the social thing of Debian (in fact, I'm not so interested in that part, I just want the job to be done), which is adding to the issues maybe. Maybe as well, going to a debconf and get to know people would help. Now, do you think that waiting for a week of testing by those who are interested in the package, before it's uploaded into SID, is totally unreasonable? If so, please explain to me why. I will keep in mind the derivative issue here (Ubuntu, etc.), and will try to not let packages become old like I did with dkimproxy. The reasons I stated above are explanations of why things happened this way, but not at all excuses. Do not understand it wrongly here, I do feel you are right. Thanks for exchanging your views, Please let me know if you can consider to be my AM or not, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
