Hi Manuel On 27 February 2012 20:14, Manuel A. Fernandez Montecelo <[email protected]> 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! _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
