On 06/25/2015 06:32 PM, Francesco Ariis wrote:

On Thu, Jun 25, 2015 at 05:55:47PM +0200, Bardur Arantsson wrote:

...

I noticed another thing while perusing the source code: There seem to be quite a few TODO comments scattered about.

Is there some sort of convention whereby it is permitted to add TODOs as long as the person doing so pinkie-promises to fix/remove them later? Or is it somehow related to severity? Or is it just that people couldn't be bothered to make issues and just have them in out-of-band instead? Is it all just legacy from before issue tracking was introduced? Do people spontaneously clean up TODOs that others have left behind?

I recently released a little something [1] to scan for TODOs in a codebase (after being overwhelmed by them), so after your comment I felt compelled to see how cabal and its repo would fare!

Oh, yes, I actually saw your announcement and should have remembered to use it :). Just to take a tiny sample from the top: 40 Not sure about JHC 41 This file should probably be removed. Are these useful TODOs to have? Who (if anybody) is going to do anything about them?

I attach the output: there are a lot of todos but the number more or less on the same level with projects of similar complexity. I guess it is inevitable.

Unless you just ban them. Don't accept code which has TODOs in pull requests -- it's really pretty simple According To Me(TM). Unless it's your sole way of tracking issues, there are three categories of TODOs: 1) The ones that are imporant enough to become Issues in a tracker. Put them in the tracker. 2) The ones that aren't imporant enough to become Issues in a tracker. Remove them or change them to a little explanatory comment in case someone should find that place again during debugging. (Just in case you were wrong that it was a small/unimportant issue.) In some cases I find it more useful to put them in the commit comment as explanation -- commit messages *can* be a useful way to track such things. See e.g. Linux's general policy wrt. commit messages. (Granted, GitHub makes it harder to ensure commit message quality.) 3) No, actually I think those two categories are probably enough. That's it. Simple, as long as reviewers are willing to enforce the rule. (Actually, I kind of lie. I don't think they should necessarily be completely forbidden, but they *must* have a direct reference to an *open* issue.in a tracker. This is just to make the reference from the issue tracker to the relevant code more robust during unrelated changes to the code, i.e. it just serves as a "marker" for robust linking. This should ideally be checked automatically by periodic/on-pull-req code validation.) The reasoning for getting rid of TODOs entirely is simply that they are another distraction that you don't need when maintaining code: Either it's serious enough that it has to be addressed, or it's not serious enough... in which case you shouldn't be distracted by it while maintaining surrounding/adjacent code. Regards,

On 06/25/2015 06:54 PM, John Alfred Nathanael Chee wrote:

On Thu, Jun 25, 2015 at 8:55 AM, Bardur Arantsson wrote:

...

Do people spontaneously clean up TODOs that others have left behind?

There's been a case where a TODO was nullified by resolving an issue on Github, in that case I deleted the TODO.

Good on you!

If you understand the code well enough to understand the request in the TODO, I'd suggest fixing it and submitting a pull request.

Certainly! In fact I was very tempted by one earlier today, but I realized that it would require a lot of refactoring of functions with ~5-10 parameters... and so I didn't bother since that's not what I was there to fix. I'm guessing a lot of people have been in a similar situation. My point is mostly to do with visibility: Either it isn't serious (in which case it shouldn't be there), or it should be addressed (in which case it should be an Issue.) Regards,

On 06/25/2015 07:12 PM, Bardur Arantsson wrote:

On 06/25/2015 03:16 PM, Bardur Arantsson wrote:

...

Hi all,

As some of the project owners have probably noticed (hi, sorry about the ticket spam!),

Sorry about even more spam, but it's become a sort of perverse pursuit to see if I can bring the issue list down to 23(!) pages at this point. ;). I promise I'll stop at 23.

We're at 23 pages, guys&gals! :p (I'll have a proper look through all the issue comments tomorrow.) Regards,

Sorry if this is "me too" noise, but I can't help sending Bardur a huge thank you for the fantastic work on the issues list. It's hard to overestimate the value of this. On Sat, Jun 27, 2015 at 4:20 AM Bardur Arantsson wrote:

...

On 06/25/2015 07:12 PM, Bardur Arantsson wrote:

...

On 06/25/2015 03:16 PM, Bardur Arantsson wrote:

...

Hi all,

As some of the project owners have probably noticed (hi, sorry about

On 06/27/2015 03:14 AM, Bardur Arantsson wrote: the

...

...

...

ticket spam!),

Sorry about even more spam, but it's become a sort of perverse pursuit to see if I can bring the issue list down to 23(!) pages at this point. ;). I promise I'll stop at 23.

We're at 23 pages, guys&gals! :p

Btw, thank you to all the peeps who have gone through my numerous comments and closing the issues (as appropriate). :)

Regards,

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Hi Bardur, On Thu, Jun 25, 2015 at 3:39 PM, Bardur Arantsson wrote:

On 06/25/2015 03:16 PM, Bardur Arantsson wrote:

...

Hi all,

[--snip rant, again :)--]

So, I've been going over even more issues for a few hours and the overwhelming feeling I'm sensing is apathy/indifference. (I should say these are mostly the issues imported from Trac, so I'm sure there's a certain bias there towards old/languishing issues. This will, of course, colour my judgment.)

I have been slowly re-working our issue tracker to follow a workflow similar to that used by GHC. Most of our bugs are at least categorized now. The next step is to close issues in the `_|_` milestone. Then, we need to consistently reorganize the issues after each release. I haven't closed the _|_ issues yet because I'm not looking forward to the blowback :) Cabal is easily the most reviled open source project; very soon hundreds of already-disgruntled developers are going to get hundreds of notifications from me that their pet issue is being closed. Not that they cared while it was open.

I'm not sure what to make of this, or if any of the people involved[1] have anything to say on this, but I just thought I'd bring it to the light. (For all I know, the principals may be on vacation or working 24h shifts for people who pay actual money right now. If so, I apologize for the "ambush".)

I don't know about 24 hr shifts, but the only person I know of getting paid to work on anything related to Cabal right now is our GSoC student. We're also spread out over many timezones, so that will influence the type and timing of response you get.

I'm also sensing a bit of "everyone-is-responsible-therefore-nobody-is" about the whole project, but that's really just a very subjective feeling. Do any casual contributors feel the same way? Relatedly, I'm curious as to whether there's an actual "project lead" who sets the direction or if it's just a sort of "democratic" thing...?

For the most part, each subsystem is maintained by the person who wrote it, or whoever made the last major overhaul. Noteworthy exceptions are the compiler interfaces (usually maintained by someone from that compiler's team). For example, I usually deal with the bugs around `cabal test` because I wrote it. I'm also the last person who overhauled profiling support, saved build configurations, and a few other things, so I field those issues. Mikhail usually responds to bugs related to `cabal sandbox` and `cabal repl`, for example. We have a release manager who sets the timeline for everybody to get their commits in. The closest thing we have to project leads is a few senior developers to whose judgement the rest usually yield.

[1] Going through the issues, I think I just about managed to insult every single maintainer of Cabal/cabal-install. I didn't mean to and don't bear any personal animosity, but I can be... blunt. Forgive me, guys! It was for a good cause, I think.

Uh, this is nothing compared to the abuse I take in other Haskell circles. -- Thomas Tuegel