[Aptitude-devel] Stepping down as maintainer/developer

[Daniel Hartwig]

Hi Manuel

On 27 February 2012 20:14, Manuel A. Fernandez Montecelo
<manuel.montezelo at gmail.com> wrote:
>
> So about the nitpicking, for example I don't agree that delaying the
> release of a new aptitude package for lack of a [obsolete] webpage and
> similar lintian warnings *present for years* is a valid reason to
> delay an important release with ~50 fixes even if it's only for a day.
>  By allowing the most buggy package to stay for longer you're not
> improving the quality of Debian, the quality actually decreases, even
> if you firmly believe the contrary.
>

I thought it was clear from the original discussion that this "delay"
was just the standard sponsership process.  Yes there were lintian
issues raised, but it was also mentioned that they were not blockers.

Sufficient time is required for the sponser to inspect and test the
package.  This is just plain prudence.

The whole process from mentors to unstable lasted two days.  I
can't say that I share your concern about the length of that period.


> Also, even if my code and coding practices are not going to make it to
> the "Beautiful Code" book,

This was not a matter of which style is "beautiful"--such discussion
is moot--rather that the project has a clearly established use of
style C.

It is a very minor adjustment for a developer to use the project's
style.  Any large project requires this.


> I prefer to spend time actually having some
> fun coding and making the project overall better than creating the
> perfect commit everytime.  And after being working on aptitude for all
> of the weekend, spending two hours reading things like "fixing a
> string->const& string in an unrelated commit" is bad, I feel quite
> miserable.

Clean commits and a clean commit history are also a valuable part of
improving (and maintaining) a project.  It takes a trivial amount of
time to keep distinct changes separate, and git is a powerful tool for
enabling this.  This is not always required, but desirable.

Some other aspects of the changes (e.g. the code style, and commit
messages) suggested to me that you may not be aware of the widely
considered best practices in these regards.  These were friendly
pointers *just incase* for the benefit of everyone involved with the
project.  If you are already aware, that's great.

Certainly now that they have been mentioned I have no intention of
harassing you on these…


>  It's not that I cannot stand criticism, but dealing with
> the 8 year old and often obsolete bug reports is dull enough, no need
> to make the fun part dull as well.

Developing code is fun.  Working on a real project with many users is
rather rewarding.  That's great, and I agree.  However, please note:

Aptitude is a system tool.  It interacts with the core functional
parts of a system in various and complicated ways.  This is a serious
project.

There are many people and ogranizations that rely upon it daily to
perform critical operations on critical systems.  These users
absolutely need the project to provide a level of quality.

Any work performed on such an important piece of software is going to
be subject to scrutiny.  That scrutiny is going to come under a wide
range of topics.  It is going to come from a wide variety of
sources--including your fellow developers, people who are working
towards the same goals as yourself.

Dealing with ancient bug reports *is* tedious.  This does not exclude
development from being scrutinized.  Nor does it make "having fun" the
primary concern for new development.


Noone wishes to see you leave the project.  Having one's work
critiqued is a fact with any serious project, and it makes the project
stronger.  It is truly a shame if this demotivates you but I ask you
to consider:

  Will future critiques also demotivate you if they are absent of the
  non-technical issues?  Now that such minor issues and pointers have
  been mentioned, you will not find them repeated in the future.


>  I also have some nit-picks about
> your ways of doing things, but I saved you from the pain because
> overall they're not that important.
>

Please do raise them.  Small things are easy to fix.

At the moment I believe that the changes I have worked on are
more-or-less consistent with the project and presented in a useful
manner.  If this is not the case then I certainly would like to be
made aware of that.


>  I suspect that if Daniel Burrows had some
> nitpickers around him scrutinising every mistake, aptitude would not
> be what it's today.
>

But there has been plenty of scrutiny of aptitude over the years:
choice of colours, symbols for representing expandable tree items,
behaviour A vs. B, order of the grouping policies, flat-vs-tree view
as the default, …

More is still occuring at a steady rate.  This is a healthy part of
any project--people are using it and commenting, that's great!