[Aptitude-devel] On reviews, supervision, etc -- was Re: Bug#720750: aptitude: search returns different numbers of packages depending on sort order

Wed Feb 5 01:18:10 UTC 2014

2014-02-03 Daniel Hartwig <mandyke at gmail.com>:
> On 4 February 2014 01:27, Manuel A. Fernandez Montecelo
> <manuel.montezelo at gmail.com> wrote:
>> 2014-02-03 Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>:
>>> 2014-02-03 Daniel Hartwig <mandyke at gmail.com>:
>>>> On 3 February 2014 23:58, Manuel A. Fernandez Montecelo
>>>> <manuel.montezelo at gmail.com> wrote:
>>>>> 2014-02-03 Daniel Hartwig <mandyke at gmail.com>:
>>>>>> Duplicates are not desirable, even if it resolves the issue with
>>>>>> missing packages.  Anyway, lets just have it reverted and fixed on
>>>>>> wip-cmdline (weeks now, see below).
>>>>>
>>>>> It was a joke, that if one puts the terms twice, having duplicated
>>>>> output might be the intended behaviour.
>>>>>
>>>>> I agree that this the current solution is not good in the case of
>>>>> overlaps (or well, trades one bug for one undesired behaviour or bug,
>>>>> depending on the point of view).
>>>>>
>>>>
>>>> Trading one bug for another obvious bug is unacceptable on master.
>>>> Likewise, with the initial version of "installsizechange" being
>>>> obviously broken in the context of the rest of the module.
>>>>
>>>> You must be more thorough with your work.  These kinds of "quick fix"
>>>> are unsuitable for applying to the master branch.
>>>>
>>>>> So I will fix this within a couple of days, no problem.
>>>>>
>>>>>
>>>>
>>>> In the future, please submit your work as patches or prepare changes
>>>> on a separate branch for review.
>>>
>>>
>>> NACK.  And I already fixed bugs introduced by yourself in the last
>>> releases and present for many months, so please don't be so cocky.
>>>
>>> I was joking anyway, and the previous bug was present for 4 years, so
>>> living a few days in master is not the end of the world.
>>
>> With the bug present for 4 years I mean: *almost all* of the sorting
>> policies were broken by the previous, so my investigations and patches
>> already helped to uncover them.
>>
>> Not exactly useless my changes :-)
>>
>
> I do not suggest they are useless.  Just not of a quality suitable for
> release.  You knew about the issues with these changes and you
> committed them anyway, that is unacceptable.
>
> Submit your work for review before committing to master.

tl;dr: Not going to happen, nobody is going to supervise anybody in
those terms or play this bureaucracy game, and the sooner that you
come to terms with this the better.  It is not useful to anybody,
people don't have to ask you permission to contribute to aptitude, and
aptitude development is not going to stop when you are not around, or
even when you are.

I already said this in previous emails, or maybe some parts I wrote
but not sent to not cause more discussions.  But since you keep
insisting, I will be absolutely clear.  I'll keep this part
(relatively) short and hopefully it's the last time that I say this.

Nobody supervised your work or mine or anybody else's in the past in
aptitude, even when we were both complete newcomers and much more
unexperienced than we are now.  We were doing far more disruptive
things all along since the beginning (compared with what I've been
doing in the last few weeks), and we started doing important changes
only <5 months after Daniel Burrows made his last commits.  At that
time, nobody was telling us anything against our actions (much to the
contrary, Christian and Axel were very supportive and encouraged us
since the very beginning and giving us complete control!), in a
package so important as aptitude.

And yes, nowadays I am still a novice, but you also are still a novice
in aptitude, even if you think otherwise. Unfortunately, there are no
more skilled people around.  Daniel Burrows is the only person who can
be called long-term developer and maintainer, and the one who did
virtually all important design decisions and 90% or more of the
implementation.  The contributions from everybody else are peanuts in
comparison, not much more than basic maintenance, specially in the
design and overall architecture -- including yours.  And in recent
times, you did barely any contributions in more than a year since the
release in Nov 2012 (except perhaps BTS work in the first half of
2013), leaving development and package maintenance [almost] completely
unattended.  Your effective involvement has been scarcely more than a
year, 2012.

So you are not going to supervise my changes now before integrating in
master, nor me yours, nor anybody to supervise anybody.  And no
reverting of commits without discussion and good reasons.  Review of
commits and comments in BTS and mailing lists is fine and is enough,
and everybody can do that with anybody's contributions.

About commiting changes not qualified as suitable... well, I fixed
them quickly enough (with your help) and without even hitting a
release.  I left the comments in the code and a comment in a bug
report (#720750) to see if anybody had any comments, as you did.  In
other words, the process is working as intended.

The underlying bug that came into light has been released and in
production systems for ~3/4 years, and nobody complained very loudly,
only a single bug report 3 years after the bug is present, and the bug
never fixed or the report even triaged.  So even if the bug introduced
with my changes went to production releases, it's not the end of the
world.  The changes were fixing an arguably more important bug,
missing entries under some conditions rather than duplicate ones,
which can be worked around with a simple " | uniq" -- such an arcane
Unix power tool.

For a similar example, your changes caused #723821, and you left the
bug open and unattended for a few months (submitted in September,
confirmed the same day), which I fixed recently in master.  And my
reaction was not treating you as inexperienced or saying that your
code "not suitable for release", or that you are not dilligent enough
in handling the bug report, and requesting that you only submit
patches or discuss bug reports before fixing or closing them because
you are not trustworthy to leave you alone.  That would be
unreasonable.  It's a bug, and not even a very important one, and
that's it.  You didn't treat me in the same way in the bug that you
were discussing about.

Another more important example was when you wanted to upload 0.6.9 to
unstable just after Wheezy freeze in July 2012 [1], which would have
not migrated in time but would cause problems to update aptitude in
testing during the freeze.  It was a risky move, given the amount of
disruptive changes (which I hadn't noticed in my original reply), and
not a good decision from a maintainer's point of view.  But in that
occasion, I (and then Axel and Christian) friendly advised you about
the best thing to do and how to approach Release Managers if
necessary, and how to avoid making that mistake and upload to
experimental instead, always in a supportive way and trusting your
good sense.  Nobody treated you as a fool and incapable maintainer, in
condescending ways or insisted in supervising you and reserving the
decision on when to do the releases/uploads, even if those people
around you were and are far more knowledgable than you in Debian ways,
releases and package maintenance.

[1] http://lists.alioth.debian.org/pipermail/aptitude-devel/2012-July/002749.html

So well, in short, I demand and expect that in the future you treat me
(and all other possible contributors) with generosity and
friendliness, and be supportive and trustful, as you were treated so
far by everybody involved; and that you don't intend to veto actions
or revert changes unless absolutely justified because of major
disruptions.  The outcome will be much more positive for everyone.

I am also a bit tired of spending time in project politics (in the bad
sense) rather than contributing code and making aptitude better, so I
hope and expect to not have to enter in this kind of discussions in
the future.

Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>