2014-02-03 Daniel Hartwig <[email protected]>: > On 4 February 2014 01:27, Manuel A. Fernandez Montecelo > <[email protected]> wrote: >> 2014-02-03 Manuel A. Fernandez Montecelo <[email protected]>: >>> 2014-02-03 Daniel Hartwig <[email protected]>: >>>> On 3 February 2014 23:58, Manuel A. Fernandez Montecelo >>>> <[email protected]> wrote: >>>>> 2014-02-03 Daniel Hartwig <[email protected]>: >>>>>> 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 <[email protected]> _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
