Re: Improving our response to "duplicate" packages in Debian
On Sat, 30 Jun 2012, Michael Hanke <email@example.com> wrote:
> I think this is approaching the problem from the wrong end. Instead of
> preserving the status quo and asking oracles to predict the future we
> should have better means of removing software that has proven to be
> inferior of an equivalent alternative in Debian. The advantage is that
> we have objective criteria to be able to make an informed decision --
> not a guess based on heuristics and opinion. The disadvantage is that it
> imposes work on other volunteers -- but see below...
More automated bug filing systems would be a good thing. If a package doesn't
get used much then it tends not to get bug reports or NMUs so it can quietly
languish without anyone noticing.
If you maintain more than a few packages it's easy to forget about some that
don't get bug reports.
> > We really need to find better ways to involve new users in core teams,
> > and that means removing from our collective consciousness the idea that
> > you come in Debian to package your new favorite piece of software.
> I have to disagree -- and I would even make the bold claim that
> "packaging your favorite piece of software" is a very common (if not the
> most common) entry point for people into Debian. One could see the
> "pet projects" as the price we need to pay to make participation in
> Debian very attractive (not even talking about the role that "pet
> projects" play in the context of perceived universality of Debian) .
> Getting people to participate in Debian, make them become confident and
> experienced is IMHO a requirement for increasing the chance of anyone
> joining core teams.
Yes. Also I don't think that the members of "core teams" really want to have
people learning while maintaining their packages. When people inevitably
stuff up while learning things it's good to do so while working on something
that's not so important.
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/