On Fri, Dec 11, 2009 at 10:38:22AM +0800, Thomas Goirand wrote:
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.
I suspect that _you_ do not get it: Releasing packages once per release cycle is bad. Doing it close to freeze time is even worse.
It is no excuse that others do similar.I fail to understand why I should help you become a DD if you insist on using a bad packaging style even when pointed out to you.
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).
Great that you are only few days from releasing. I was unaware of that.That does not, however, change my opinion on discrete "proof-reading". Be transparent: Post to the bugreports if you want someone to test a patch before released to Sid - others than the original bugreporter might follow the bugreport - and perhaps even wants to help test.
Again, I fail to understand how you becoming a DD changes (as you explained yourself) a deliberate choice of minimizing to a single upload per release cycle, postponed until late in the cycle.
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.
You do not need to be a DD to join a team. Each team need only a DD to take responsibility of final packaging uploads into Debian.
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 ? :)
Working in teams is ortogonal to becoming a DD. No, I do not want to work as an AM currently. But thanks for asking!
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.
Fair enough. I strongly recommend you to join some other existing team, then. Especially since you also yourself dislike the sponsoring system.
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?
As I mentioned earlier I do not like the sponsoring system. So no, I do not want to sponsor your package. All too often I experience sponsored packaged that are badly maintained - the sponsor have no special interest in the package so forgets about looking after it, and the packager is not "hanging out" in Debian so often forgets about it too.
Great that this is not the case here. You just happen to deliberately choose to stay silent for a year and then (silently except one) fix all bugs within few days.
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.
If your interest in Debian is specifically about packaging, not other parts, then I strongly recommend that you join a team and not apply for DD, as it is unneeded, and your contributions are equally appreciated as a non-DD.
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.
First you argue that the timing was deliberate, then you promise to speed up in the future, and then you say that the speed until now is sensible. I am confused.
Kind regards, and looking forward to your continued dkimproxy packaging - Jonas P.S. Please respond only to the bugreport, without cc'ing me personally. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
