Hi all, (When I refer to cabal below, I'm mainly referring to cabal-install.)
As some of the project owners have probably noticed (hi, sorry about the ticket spam!), I've been sampling a few issues from the issue tracker here and there to look into the potential issues I could tackle and which would make sense to actually implement. A few observations: - The issues imported from the old tracker are almost completely useless. A huge number of them are "enhancement" level and there's usually there not even any way to get in contact with the original reporter since it's just Trac usernames. Since Bryan O'Sullivan did the original import his username "bos" is the "reporter" for all the imported issues. - The issues in the _|_ milestone seem to suffer from largely the same problems. I'm sure there's some overlap between this and the previous issue list. I would suggest that *all* "enhancement" level issues from the above lists which have lain dormant for >1 year (or so) be closed. After that amount of time, it's obviously not going to happen. On a similar note, I've stumbled on quite a lot of issues which seem to arise from people wantonly manipulating sandboxes directly, (ab)using symlinks, and/or expecting to be able to build (or whatever) in the same sandbox in parallel, and issues of a similar nature. From various comments in tracker by @tibbe, I gather that the idea is to do away with the need for a lot of the direct sandbox manipulation that (esp. multi-package) developers need to do to get their setups working. Therefore I would suggest aggressively closing as many of these tickes as is feasible as "wontfix", even if they may technically be bugs. (Of course it depends on the priority of the bug, but...). I can probably spend a few hours today to scour through the bug list and find + "report" (via comment) bugs of this nature if there's interest in that. In general: The issue tracker is in an atrocious state and it's almost impossible for a noob like me to find anything even remotely relevant that's a) relevant to work on from a "this is the direction we want to be going" perspective, and b) is interesting from the "has any potential users" perspecitve[1]. I'm sure this has a lot to do with the overall uselessness of GitHub's issue tracker for anything above 20 issues and the fact that going through bugs is probably boring as hell for most people. Therefore I'd also suggest instituting a general guideline that *all* issues with no discernible activity for >1 year (or so) be aggresively closed. If nothing has happened in that time we're not talking about anything that's (realistically) going to happen given that nobody(?) is actually working on Cabal/cabal-install full-time. I guess a comment to the effect of "If you still care about this please re-open" to the original poster would be manageable. In any case, the default must be to close -- not to just keep issues open just-in-case they're still relevant. As it currently stands the tracker is unfortunately all but useless. In fact, it's actively discouraging because it's so daunting :( Sorry about the bile, but it has to be said because I think it's terribly discouraging for potential contributors and could be causing a massive waste of time fixing/implementing things which are irrelevant for FutureCabalInstall. I should stress that I don't mean any of this as any kind of negativity towards the project owners/maintainers themselves (it's a thankless job!) -- it just needs to be said. As mentioned, I'll be happy to help out a bit with the weeding-out of issues, but unless we can agree to some of the above then I'm not going to waste my time. Regards, P.S. There seems to be a bit of a pull request backlog too. (I'm *not* talking about my own PRs here!) There seem to be 5-6 pull requests that have lingered since 2014(!). IMO they should either be merged or rejected (back into issue tracker if necessary). It doesn't serve anyone to have pull requests linger for a year. [1] A lot of the issues seem to be extremely niche feature requests, many revolving around needs which users with homemade scripting (or cabal-dev, henv, or what have you) have had at one time or another. _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
