On Thu, Apr 7, 2016 at 9:25 AM, Goswin von Brederlow <goswin-...@web.de> wrote: > The BTS is not just for the maintainer. It also documents things for > users. Like what bugs are already known. > > When I see a package with lots of patches in the BTS my willingness to > patch something myself goes right down the drain. Who would want to > spend their time writing patches if the maintainer will just ignore > them for years?
There are only 3 patches in there all together. They have all been reviewed and rejected by upstream. Maybe one, if rewritten, could be a candidate for a Debian specific patch (tmp files location). > > I'm sure you handled all the security stuff as you say but you are the > only one that knows that. Everyone else looks at the BTS and sees bugs > tagged security. When I see a package in the BTS with bugs tagged > security then I start to worry. You have a point there, appearances may give the wrong impression. I will take a look at getting rid of these, for example the LDAP bug you mention below. Also since some very uninformed people may not understand that we backport all valid security fixes to stable (I've seen lot a of stupid remarks lately). > That would be just a drive-by shooting. You won't get more info just > ebcause someone sets the more-info tag. One also has to track down the > submitter and at least test the issue itself too. Since I don't use > LDAP that would be rather a lot of work. And what for? If I write a > patch it's just going to rot in the BTS form all apearances. See my > point? That bug was maybe not a good example, but there are many places where a drive-by contributor can be useful. Of course someone with a longer perspective is much preferred. But often large contributions starts with small steps, scratching their own itch, for then to be pulled in. > > Saddly that is also not how it works. Usualy a package rots away for > years getting worse and worse before it finally blows and someone else > gets so fed up with it and steps up to take over. You are doing a too > good job for that to happen. Sometimes you have to get the word out > that help is needed or simply just wanted to attract someone. I think we both are just sketching up possible ways this works or not. Anyway, it is probably good if I make clear that I am welcoming co-maintainers. This is how we ran it before, just that the previous co-maintainer had more important issue to attend to and had to step down. Unlike some other maintainers I am in favour of collective and shared maintenance. > > Front desk is part of the new maintainer process and is staffed by a > few people: > > https://nm.debian.org/public/managers > > I think the alias for it is front-d...@debian.org. And the long line > of people longing to help out is every person wanting to become Debian > Maintainer or Debian Developer. So yeah, there is aline. Wether they > will stay with your package after they completed the NM process or not > is up in the air. Maybe they will, maybe they won't. It's unlikely > though. But hey, if you do this once every 3 years the BTS will look a > lot cleaner and eventually someone will stick. :) Thanks for the link, I will check it out. Regards, Tormod
