[Aptitude-devel] Stepping down as maintainer/developer
Manuel A. Fernandez Montecelo
manuel.montezelo at gmail.com
Tue Feb 28 10:01:16 UTC 2012
2012/2/27 Axel Beckert <abe at debian.org>:
> Nevertheless I still think nearly all of them were easy to fix and low
> hanging fruits and Daniel Hartwig fixed them all in no time. So thanks
> Daniel! So I still don't see the point why they shouldn't be fixed if
> they were easy and quick to fix.
Removing all the low hanging fruits is the best way to not get new
contributors, who are eager to contribute but are overwhelmed by the
size and legacy of the project.
> I don't think sponsoring requirements should be lowered at such
> points, just because at _other_ points there's a lot of legacy in the
> package, which I fully understand and respect.
The quality of the package is not composed solely, nor even mainly, by
the quality of the packaging (except in extreme cases, all of them out
of question and not present in the current package), but for the
quality of upstream itself. For example:
- A shoddy packaging of GCC, with lots of lintian warnings about
missing man pages and obsolete standards and what not, is light-years
away better than tcc.
- The way to improve quality in aptitude is maybe not provide a
manpage for aptitude-gtk, but remove aptitude-gtk altogether (#619759
#572137 #619767 #619765 ... and especially #547415).
So I found your phrase "Well, and the common approach for sponsoring
is to be picky. And high expectations are one of the reasons for
Debian's quality" in :
a) slightly insulting; because it assumes that us, who looked more
closely at the package for months and know much better its state, have
lower standards of quality;
b) and quite misleading, because again by delaying the release "by one
or two weeks [to implement the build-indep thing]"  (which was the
thing that I was against) you actually decrease the quality of Debian,
depriving many users of tens of bugfixes, e.g. much better
translations and hardened builds, which have much higher impact in the
lives of users than a lintian warning about relatively non-urgent
 Daniel Hartwing in the same message: "Now, would you rather I
quickly make these changes to the current version and reupload, or
leave them a week or two while I ready some other packaging changes
(build-indep for docs and split out many files to aptitude-common)?"
So all in all, you have the right to not sponsor the package if it
doesn't meet your standards.
On the other hand, I have the right to not bother trying to convince
you or anybody else of things that are so obvious to me, that's why I
take the easiest decision.
More information about the Aptitude-devel