From johan.tibell at gmail.com Wed Jun 3 15:41:38 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 3 Jun 2015 17:41:38 +0200 Subject: HEADS UP: Final call for 7.10.2 is soon In-Reply-To: <1433338843.17852.23.camel@scico.botik.ru> References: <1433338843.17852.23.camel@scico.botik.ru> Message-ID: There have been some requests for a Cabal library release for 7.10.2. I remember something about truncate directories/symbol names being an issue. I'm CC:ing the Cabal mailing list for comments. On Wed, Jun 3, 2015 at 3:40 PM, Sergei Meshveliani wrote: > Please, > consider my recent bug report > "overlapping instances in 7.10.1" > (see my resent email to this list). > > ------ > Sergei > > > > On Tue, 2015-06-02 at 16:31 -0500, Austin Seipp wrote: > > Hi *, > > > > I've just finished merging all the latest patches for GHC 7.10.2 into > > the STABLE branch. All in all, we've fixed a lot of bugs (over 80 > > tickets closed)! > > > > So, we'll probably be doing a 7.10.2 release here in a few weeks. The > > tentative plan was around the 14th, although it's not set in stone. > > (At worst, it would be pushed from the 14th to the 21st). > > > > With that in mind, if I could quickly direct your attention to the GHC > > bug tracker and the status page[1] - it would be really helpful if you > > check if the things you want are fixed! > > > > Specifically, if you want something fixed for the 7.10.2 release: > > > > - Make sure there is a ticket. It really needs to exist or we'll just > forget! > > > > - If your bug is critical, please explain why! We really want to > > kill showstoppers ASAP, because bugs are much cheaper to fix early. If > > that's the case we can bump the priority if it's necessary to make > > things clear. > > > > - Set the milestone to 7.10.2. It'll automatically appear on the > status page. > > > > That should be it - we'll be monitoring the status page regularly to > > keep track of new things. The current bug list is pretty small - we > > may move some of them out, or fix several more. So just try to let us > > know. > > > > As a sidenote, I'm quite happy with this release - it's fixed dozens > > of tricky bugs, improved some nasty corner cases in compiler > > performance, and overall seems like it will be high quality. Thanks to > > everyone who submitted patches! > > > > I'll send out another email next week as another reminder. > > > > [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at ryant.org Mon Jun 8 21:04:45 2015 From: ryan at ryant.org (Ryan Thomas) Date: Mon, 8 Jun 2015 22:04:45 +0100 Subject: HEADS UP: Final call for 7.10.2 is soon In-Reply-To: References: <1433338843.17852.23.camel@scico.botik.ru> Message-ID: Let me know if there's a need for a release for 7.10.2. On 3 June 2015 at 16:41, Johan Tibell wrote: > There have been some requests for a Cabal library release for 7.10.2. I > remember something about truncate directories/symbol names being an issue. > I'm CC:ing the Cabal mailing list for comments. > > On Wed, Jun 3, 2015 at 3:40 PM, Sergei Meshveliani wrote: >> >> Please, >> consider my recent bug report >> "overlapping instances in 7.10.1" >> (see my resent email to this list). >> >> ------ >> Sergei >> >> >> >> On Tue, 2015-06-02 at 16:31 -0500, Austin Seipp wrote: >> > Hi *, >> > >> > I've just finished merging all the latest patches for GHC 7.10.2 into >> > the STABLE branch. All in all, we've fixed a lot of bugs (over 80 >> > tickets closed)! >> > >> > So, we'll probably be doing a 7.10.2 release here in a few weeks. The >> > tentative plan was around the 14th, although it's not set in stone. >> > (At worst, it would be pushed from the 14th to the 21st). >> > >> > With that in mind, if I could quickly direct your attention to the GHC >> > bug tracker and the status page[1] - it would be really helpful if you >> > check if the things you want are fixed! >> > >> > Specifically, if you want something fixed for the 7.10.2 release: >> > >> > - Make sure there is a ticket. It really needs to exist or we'll just >> > forget! >> > >> > - If your bug is critical, please explain why! We really want to >> > kill showstoppers ASAP, because bugs are much cheaper to fix early. If >> > that's the case we can bump the priority if it's necessary to make >> > things clear. >> > >> > - Set the milestone to 7.10.2. It'll automatically appear on the >> > status page. >> > >> > That should be it - we'll be monitoring the status page regularly to >> > keep track of new things. The current bug list is pretty small - we >> > may move some of them out, or fix several more. So just try to let us >> > know. >> > >> > As a sidenote, I'm quite happy with this release - it's fixed dozens >> > of tricky bugs, improved some nasty corner cases in compiler >> > performance, and overall seems like it will be high quality. Thanks to >> > everyone who submitted patches! >> > >> > I'll send out another email next week as another reminder. >> > >> > [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 >> > >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > From ryan at ryant.org Tue Jun 16 18:59:35 2015 From: ryan at ryant.org (Ryan Thomas) Date: Tue, 16 Jun 2015 19:59:35 +0100 Subject: ANN: Cabal and cabal-install 1.22 minor releases Message-ID: Hi all, A release of Cabal has been made in order to get some fixes into GHC 7.10.2. This is version 1.22.4.0, a corresponding version of cabal-install (1.22.5.0) has also been released. The changelogs for these releases are below: Cabal: 1.22.4.0 Ryan Thomas June 2015 * Add libname install-dirs variable, use it by default. Fixes #2437. (Edward Z. Yang) * Reduce temporary directory name length, fixes #2502. (Edward Z. Yang) * Workaround for #2527. (Mikhail Glushenkov) cabal-install: 1.22.5.0 Ryan Thomas June 2015 * Reduce temporary directory name length, fixes #2502. (Edward Z. Yang) These are now available on the dowloads page and on Hackage. The checksums are listed below. Cheers, ryan da3c6977749ed5ea1422d58e8aed7265d57f7280 Cabal-1.22.4.0.tar.gz dbe6af3d3bd99e8e34392d28fe8d9e97e697757c cabal-install-1.22.5.0.tar.gz From ryan at ryant.org Wed Jun 17 08:21:38 2015 From: ryan at ryant.org (Ryan Thomas) Date: Wed, 17 Jun 2015 09:21:38 +0100 Subject: ANN: cabal-install-1.22.6.0 has been released Message-ID: Hi all, A new minor release of cabal-install has been released, this is to pick up a fix for @ezyang's fix for #2502. This is now available on hackage and the downloads page and the sha1sum is listed below. Cheers, ryan d474b0eef6944af1abef92419cea13cee50993f3 cabal-install-1.22.6.0.tar.gz From mietek at bak.io Thu Jun 18 00:32:52 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Thu, 18 Jun 2015 01:32:52 +0100 Subject: ANN: cabal-install-1.22.6.0 has been released In-Reply-To: References: Message-ID: <64E078D3-786C-4613-B726-24CFDF6D143D@bak.io> Thanks. cabal-install 1.22.6.0 (and 1.22.5.0) can now be installed with Halcyon: halcyon install --cabal-version=1.22.6.0 Supported platforms include: - Amazon Linux 2014.09 - Arch Linux - CentOS 6, 7 - Debian 6, 7, 8 - Gentoo Linux - openSUSE 13.2 - OS X 10.8, 10.9, 10.10 - Red Hat Enterprise Linux 6, 7 - Slackware 14.1 - SUSE Linux Enterprise Server 12 - Ubuntu 12.04 LTS, 14.04 LTS, 14.10, 15.04 - Fedora 20, 21 -- Mi?tek https://mietek.io On 2015-06-17, at 09:21, Ryan Thomas wrote: > Hi all, > > A new minor release of cabal-install has been released, this is to > pick up a fix for @ezyang's fix for #2502. > > This is now available on hackage and the downloads page and the > sha1sum is listed below. > > Cheers, > > ryan > > > d474b0eef6944af1abef92419cea13cee50993f3 cabal-install-1.22.6.0.tar.gz > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From spam at scientician.net Fri Jun 19 18:14:23 2015 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 19 Jun 2015 20:14:23 +0200 Subject: Multi-library/package support for cabal Message-ID: Hi all, Given that I'm often quite annoyed by the almost-total lack of support for developing a set of coherent libraries together in a convenient fashion[1] using Cabal, I'd like to ask a) are there any current plans or GitHub issues on implementing any support for this workflow that I should be aware of? b) are there any wiki pages (or similar) detailing any requirements that people might have for this type of workflow? c) would there be *interest* in somebody (e.g. me) implementing support for such a workflow? d) if "yes" to c), how should one go about it? What kind of consensus needs to gathered and whom do I need to convince of the brilliance of this idea? I should note that I have *very* little experience with Cabal/cabal-install's code (a couple of pretty trivial patches, I think), but it's Haskell, so how bad could it be, right? I have a week's vacation coming up next week (and probably a few more a little later in the summer), and I think I may be able to dedicate quite a bit of time to getting this done, *but*... if I'm going to spend that time, I want something that can be integrated into cabal-install *and* I want something that has a reasonable chance of actually getting merged. (Of course, I don't expect bad code to be merged, but I'm quite happy to fix bad code whenever it's pointed out to me.) Otherwise, I'll just keep using cobbled-together one-off Python scripts (and terribly inefficient workflows)... and complaining constantly about it :). So... how can get this ball rolling? Regards, [1] E.g. I have a set of cqrs-* libraries + demo executable packages in a single git repository, each with their own subdirectory and .cabal file. These libraries may depend on each other in arbitrary non-circular ways and I want to be able to conveniently build all of it in the appropriate order and with a consistent set of dependencies in a single sandbox. From spam at scientician.net Fri Jun 19 18:24:55 2015 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 19 Jun 2015 20:24:55 +0200 Subject: Multi-library/package support for cabal In-Reply-To: References: Message-ID: On 06/19/2015 08:14 PM, Bardur Arantsson wrote: > Hi all, > [--snip--] Oh, yes, I should add. I've been thinking about a couple of approaches for how to achieve this ("UI-wise" so to speak) and would like some "guesstimate" of feasibility by people in the know. 1st approach: Use a single cabal file to describe a full set of libraries (and executables) and perform dependency resolution over the whole set, thus hopefully at least ensuring internal consistency. Some sort of shorthand would perhaps be useful to avoid having to specify common dependencies and version bounds redundantly. I could imagine Hackage would have issues with this, but if anyone who knows more about Hackage internals could chime up...? I guess it might be possible to "split" such a meta-.cabal file into smaller files for upload to Hackage -- if nothing else then to avoid backward-compatibility issues. 2nd approach: Some sort of meta-tooling which could gather up multiple cabal files, create a single sandbox and resolve dependencies for all subprojects in a single step. Probably easier to implement, but less elegant. A general observation: In either case we want the compile/install step to report errors and warnings consistently. At least my current hobbled-together Python script uses the ability to do "cabal install [flags] dir1 dir2 dir3 ...", but this means that you miss out on warnings in many cases since warnings for dependencies aren't printed by default for "install". These are the kinds of annoyances that I want to avoid. Regards, From ttuegel at gmail.com Fri Jun 19 18:59:06 2015 From: ttuegel at gmail.com (Thomas Tuegel) Date: Fri, 19 Jun 2015 13:59:06 -0500 Subject: Multi-library/package support for cabal In-Reply-To: References: Message-ID: On Fri, Jun 19, 2015 at 1:14 PM, Bardur Arantsson wrote: > Hi all, > > Given that I'm often quite annoyed by the almost-total lack of support > for developing a set of coherent libraries together in a convenient > fashion[1] using Cabal, I'd like to ask > > a) are there any current plans or GitHub issues on implementing any > support for this workflow that I should be aware of? There are two that I am aware of. [1] is very similar to one of your workflows. [2] is related, but centers around improving the interaction between sandboxes and multiple packages, and less on the actual workflow of managing multiple packages simultaneously. [1]. https://github.com/haskell/cabal/issues/1367 [2]. https://github.com/haskell/cabal/issues/2631 > c) would there be *interest* in somebody (e.g. me) implementing support > for such a workflow? Yes, definitely! > d) if "yes" to c), how should one go about it? What kind of consensus > needs to gathered and whom do I need to convince of the brilliance of > this idea? If what you have in mind is like #1367, I would say that consensus has already been reached. > I have a week's vacation coming up next week (and probably a few more a > little later in the summer), and I think I may be able to dedicate quite > a bit of time to getting this done, *but*... if I'm going to spend that > time, I want something that can be integrated into cabal-install *and* I > want something that has a reasonable chance of actually getting merged. > (Of course, I don't expect bad code to be merged, but I'm quite happy to > fix bad code whenever it's pointed out to me.) I think there is some overlap with #2631, so I would suggest chiming in there to avoid duplicating efforts. This is a frequently requested feature; I think the chances of anything you write *not* being merged are very, very small. -- Thomas Tuegel From spam at scientician.net Fri Jun 19 19:03:32 2015 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 19 Jun 2015 21:03:32 +0200 Subject: Multi-library/package support for cabal In-Reply-To: References: Message-ID: On 06/19/2015 08:59 PM, Thomas Tuegel wrote: [--snip--] Thank you, I'll have a thorough look at everything you pointed out tomorrow. Likewise for anyone else who'd care to chime in! :) Regards, From cheecheeo at gmail.com Tue Jun 23 22:04:35 2015 From: cheecheeo at gmail.com (John Alfred Nathanael Chee) Date: Tue, 23 Jun 2015 15:04:35 -0700 Subject: Multi-library/package support for cabal In-Reply-To: References: Message-ID: Hi Bardur, https://github.com/haskell/cabal/issues/2004 is another bug that seems like it could be related. The idea is to use a single sandbox across multiple packages so if you have a directory layout like top/ application/ library1/ library2/ If you were to then: cd top, cabal sandbox init, cd library2, cabal install, cd ../library1, cabal install, cd ../application, cabal install The packages library1, library2 and their dependencies would all be installed in the sandbox in top and the cabal install inside the application directory would resolve dependencies from that sandbox. Each folder would still maintain its own cabal configuration so global analysis wouldn't be possible (or on the other hand, necessary). On Fri, Jun 19, 2015 at 12:03 PM, Bardur Arantsson wrote: > On 06/19/2015 08:59 PM, Thomas Tuegel wrote: > [--snip--] > > Thank you, I'll have a thorough look at everything you pointed out > tomorrow. Likewise for anyone else who'd care to chime in! :) > > Regards, > > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > -- Love in Jesus Christ, John Alfred Nathanael Chee http://www.biblegateway.com/ http://web.cecs.pdx.edu/~chee/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Thu Jun 25 13:16:25 2015 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 25 Jun 2015 15:16:25 +0200 Subject: Issues, issues, issues... Message-ID: 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. From spam at scientician.net Thu Jun 25 15:55:47 2015 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 25 Jun 2015 17:55:47 +0200 Subject: Issues, issues, issues... In-Reply-To: References: Message-ID: On 06/25/2015 03:16 PM, Bardur Arantsson wrote: > Hi all, > [--snip rant--] 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? Regards, From fa-ml at ariis.it Thu Jun 25 16:32:14 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 25 Jun 2015 18:32:14 +0200 Subject: Issues, issues, issues... In-Reply-To: References: Message-ID: <20150625163214.GA7916@casa.casa> 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! 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. [1] http://hackage.haskell.org/package/lentil -------------- next part -------------- Cabal/Distribution/Compat/TempFile.hs 40 Not sure about JHC 41 This file should probably be removed. 80 We want to tell fdToHandle what the file path is, as any exceptions etc will only be able to report the FD currently 89 bits copied from System.FilePath [fixme] 96 Should use System.FilePath library [fixme] 104 Copied from GHC.Handle [fixme] Cabal/Distribution/Compiler.hs 92 In some future release, remove 'parseCompilerFlavorCompat' and use ordinary 'parse'. Also add ("nhc", NHC) to the above 'compilerMap'. Cabal/Distribution/License.hs 66 * remove BSD4 Cabal/Distribution/PackageDescription.hs 356 dedupe? 547 By having a 'testEnabled' field in the PackageDescription, we are mixing build status information (i.e., arguments to 'configure') with static package description information. This is undesirable, but a better solution is waiting on the next overhaul to the GenericPackageDescription -> PackageDescription resolution process. 688 See TODO for 'testEnabled'. 921 many of the places where this is used, we actually want to look at unbuildable bits too, probably need separate functions [fixme] 1141 make PackageDescription an instance of Text. Cabal/Distribution/PackageDescription/Check.hs 162 make this variant go away we should always know the GenericPackageDescription 202 check for name clashes case insensitively: windows file systems cannot cope. 466 recommend the bug reports URL, author and homepage fields 467 recommend not using the stability field 468 recommend specifying a source repo 597 check location looks like a URL for some repo types. 876 check sets of paths that would be interpreted differently between Unix and windows, ie case-sensitive or insensitive. Things that might clash, or conversely be distinguished. 880 use the tar path checks on all the above paths 1145 If the user writes build-depends: foo with (), this is indistinguishable from build-depends: foo, so there won't be an error even though there should be [xxx] 1285 What we really want to do is test if there exists any configuration in which the base version is unbounded above. However that's a bit tricky because there are many possible configurations. As a cheap easy and safe approximation we will pick a single "typical" configuration and check if that has an open upper bound. To get a typical configuration we finalise using no package index and the current platform. Cabal/Distribution/PackageDescription/Configuration.hs 115 treat Nothing as unknown, rather than empty list once we support partial resolution of system parameters [fixme] 123 Add instances and check 207 The current algorithm is rather naive. A better approach would be to: 495 we need to find a way to avoid pulling in deps for non-buildable components. However cannot simply filter at this stage, since if the package were not available we would have failed already. 550 One particularly tricky case is defaulting. In the original package description, e.g., the source directory might either be the default or a certain, explicitly set path. Since defaults are filled in only after the package has been resolved and when no explicit value has been set, the default path will be missing from the package description returned by this function. Cabal/Distribution/PackageDescription/Parse.hs 681 this should take a ByteString, not a String. We have to be able to decode UTF8 and handle the BOM. [fixme] 1228 make this use section syntax add equivalent for GenericPackageDescription Cabal/Distribution/PackageDescription/PrettyPrint.hs 80 this is a temporary hack. Ideally, fields containing default values would be filtered out when the @FieldDescr a@ list is generated. 228 this ends up printing trailing spaces when combined with nest. Cabal/Distribution/ParseUtils.hs 125 what is this double parse thing all about? Can't we just do the all isSpace test the first time? 251 this is a bit smelly hack. It's because we want to parse bool fields liberally but not accept new parses. We cannot do that with ReadP because it does not support warnings. We need a new parser framework! Cabal/Distribution/Simple.hs 402 should we write the modified package descr back to the localbuildinfo? Cabal/Distribution/Simple/Bench.hs 115 This is abusing the notion of a 'PathTemplate'. The result isn't necessarily a path. Cabal/Distribution/Simple/Build.hs 521 build separate libs in separate dirs so that we can build multiple libs, e.g. for 'LibTest' library-style test suites Cabal/Distribution/Simple/BuildPaths.hs 102 This should be determined via autoconf (AC_EXEEXT) | Extension for executable files (typically @\"\"@ on Unix and @\"exe\"@ on Windows or OS\/2) 110 This should be determined via autoconf (AC_OBJEXT) | Extension for object files. For GHC the extension is @\"o\"@. Cabal/Distribution/Simple/Command.hs 585 eliminate this function and turn it into a variant on commandAddAction instead like commandAddActionNoArgs that doesn't supply the [String] Cabal/Distribution/Simple/Configure.hs 372 should use a per-compiler method to map the source package ID into an installed package id we can use for the internal package set. The open-codes use of InstalledPackageId . display here is a hack. 400 mention '--exact-configuration' in the error message when this fails? 544 Do we need the internal deps? NB: does *not* include holeDeps! [xxx] 944 we don't check that all dependencies are used! 1023 internal dependencies (e.g. the test package depending on the main library) is not currently supported 1429 Refine this check for signatures 1474 produce a log file from the compiler errors, if any. 1539 do we also need dependent packages' ld options? Cabal/Distribution/Simple/GHC.hs 461 do we need to put hs-boot files into place for mutually recursive modules? 572 problem here is we need the .c files built first, so we can load them with ghci, but .c files can depend on .h files generated by ghc by ffi exports. 729 do we need to put hs-boot files into place for mutually recursive modules? FIX: what about exeName.hi-boot? 869 problem here is we need the .c files built first, so we can load them with ghci, but .c files can depend on .h files generated by ghc by ffi exports. Cabal/Distribution/Simple/GHC/Internal.hs 220 should be using --supported-languages rather than hard coding 400 perhaps override? Cabal/Distribution/Simple/GHCJS.hs 344 do we need to put hs-boot files into place for mutually recursive modules? 454 problem here is we need the .c files built first, so we can load them with ghci, but .c files can depend on .h files generated by ghc by ffi exports. 572 do we need to put hs-boot files into place for mutually recursive modules? FIX: what about exeName.hi-boot? 705 problem here is we need the .c files built first, so we can load them with ghci, but .c files can depend on .h files generated by ghc by ffi exports. Cabal/Distribution/Simple/Haddock.hs 713 these should be moved elsewhere. Cabal/Distribution/Simple/Install.hs 74 decide if we need the user to be able to control the libdir for shared libs independently of the one for static libs. If so it should also have a flag in the command line UI For the moment use dynlibdir = libdir Cabal/Distribution/Simple/LHC.hs 211 does lhc support -XHaskell98 flag? from what version? [fixme] 343 do we need to put hs-boot files into place for mutually recursive modules? 470 discover this at configure time or runtime on Unix The value is 32k on Windows and POSIX specifies a minimum of 4k but all sensible Unixes use more than 4k. we could use getSysVar ArgumentLimit but that's in the Unix lib 508 do we need to put hs-boot files into place for mutually recursive modules? FIX: what about exeName.hi-boot? Cabal/Distribution/Simple/LocalBuildInfo.hs 113 inplaceDirTemplates :: InstallDirs FilePath 159 what about non-buildable components? Cabal/Distribution/Simple/PackageIndex.hs 119 Clarify what "preference order" means. Check that this invariant is preserved. See #1463 for discussion. [fixme] Cabal/Distribution/Simple/PreProcess.hs 125 deal with pre-processors that have implementaion dependent output eg alex and happy have --ghc flags. However we can't really inlcude ghc-specific code into supposedly portable source tarballs. 227 try to list all the modules that could not be found not just the first one. It's annoying and slow due to the need to reconfigure after editing the .cabal file each time. 274 eliminate sdist variant, just supply different handlers 295 This is a somewhat nasty hack. GHC requires that hs-boot files be in the same place as the hs files, so if we put the hs file in dist/ then we need to copy the hs-boot file there too. This should probably be done another way. Possibly we should also be looking for .lhs-boot files, but I think that preprocessors only produce .hs files. [fixme] 498 install .chi files for packages, so we can --include those dirs here, for the dependencies 513 perhaps use this with hsc2hs too 514 remove cc-options from cpphs for cabal-version: >= 1.10 551 move this into the compiler abstraction 552 this forces GHC's crazy 4.8.2 -> 408 convention on all the other compilers. Check if that's really what they want. [fixme] Cabal/Distribution/Simple/Program/HcPkg.hs 180 this could be a lot faster. We're doing normaliseLineEndings twice and converting back and forth with lines/unlines. 241 use a proper named function for the conversion from source package id to installed package id Cabal/Distribution/Simple/Program/Run.hs 251 discover this at configure time or runtime on unix The value is 32k on Windows and posix specifies a minimum of 4k but all sensible unixes use more than 4k. we could use getSysVar ArgumentLimit but that's in the unix lib [fixme] Cabal/Distribution/Simple/Register.hs 129 there's really no guarantee this will work. registering into a totally different db stack can fail if dependencies cannot be satisfied. [fixme] 166 eliminate pwd! 169 the method of setting the InstalledPackageId is compiler specific this aspect should be delegated to a per-compiler helper. Cabal/Distribution/Simple/Setup.hs 112 Not sure where this should live [fixme] 274 the configPrograms is only here to pass info through to configure because the type of configure is constrained by the UserHooks. when we change UserHooks next we should pass the initial ProgramConfiguration directly and not via ConfigFlags ^All programs that cabal may run [fixme] 359 reverse this 1519 this one should not be here, it's just that the silly UserHooks stop us from passing extra info in other ways 1554 re-enable once we have support for module/file targets ++ " " ++ pname ++ " build Foo.Bar " ++ " A module\n" ++ " " ++ pname ++ " build Foo/Bar.hs" ++ " A file\n\n" ++ "If a target is ambiguous it can be qualified with the component " ++ "name, e.g.\n" ++ " " ++ pname ++ " build foo:Foo.Bar\n" ++ " " ++ pname ++ " build testsuite1:Foo/Bar.hs\n" 1687 re-enable once we have support for module/file targets ++ " " ++ pname ++ " repl Foo.Bar " ++ " A module\n" ++ " " ++ pname ++ " repl Foo/Bar.hs" ++ " A file\n\n" ++ "If a target is ambiguous it can be qualified with the component " ++ "name, e.g.\n" ++ " " ++ pname ++ " repl foo:Foo.Bar\n" ++ " " ++ pname ++ " repl testsuite1:Foo/Bar.hs\n" 1744 do we need this instance? 1756 think about if/how options are passed to test exes 2128 kill off thic bc hack when defaultUserHooks is removed. Cabal/Distribution/Simple/Test/ExeV10.hs 155 This is abusing the notion of a 'PathTemplate'. The result isn't necessarily a path. Cabal/Distribution/Simple/Test/LibV09.hs 159 This is abusing the notion of a 'PathTemplate'. The result isn't necessarily a path. Cabal/Distribution/Simple/UHC.hs 114 determine in some other way 139 Actually make use of the information provided in the file. Cabal/Distribution/Simple/Utils.hs 497 handle exceptions like text decoding. 509 this probably fails if the process refuses to consume or if it closes stdin (eg if it exits) Cabal/Distribution/System.hs 197 probably should disallow starting with a number Cabal/Distribution/Version.hs 93 maybe move this to Distribution.Package.Version? (package-specific versioning scheme). Cabal/tests/PackageTests/PackageTester.hs 312 Convert to a "-v" flag instead. Cabal/tests/PackageTests/ReexportedModules/Check.hs 23 Turn this into a utility function Cabal/tests/Test/Distribution/Version.hs 311 see equivalentVersionRange for details [fixme] 557 this is wrong. consider version ranges "<=1" and "<1.0" this algorithm cannot distinguish them because there is no version that is included by one that is excluded by the other. Alternatively we must reconsider the semantics of '<' and '<=' in version ranges / version intervals. Perhaps the canonical representation should use just < v and interpret "<= v" as "< v.0". [fixme] cabal-install/Distribution/Client/BuildReports/Anonymous.hs 194 this does not allow for optional or repeated fields [fixme] cabal-install/Distribution/Client/BuildReports/Storage.hs 63 make this concurrency safe, either lock the report file or make sure the writes for each report are atomic (under 4k and flush at boundaries) 88 make this concurrency safe, either lock the report file or make sure the writes for each report are atomic 103 In principle, we can support $pkgkey, but only if the configure step succeeds. So add a Maybe field to the build report, and either use that or make up a fake identifier if it's not available. cabal-install/Distribution/Client/BuildReports/Upload.hs 71 do something if the request fails [fixme] cabal-install/Distribution/Client/Check.hs 36 this may give more warnings than it should give; consider two branches of a condition, one saying ghc-options: -Wall and the other ghc-options: -Werror joined into ghc-options: -Wall -Werror checkPackages will yield a warning on the last line, but it would not on each individual branch. Hovever, this is the same way hackage does it, so we will yield the exact same errors as it will. cabal-install/Distribution/Client/Compat/Time.hs 104 What if the result is not representable as POSIX seconds? Probably fine to return garbage. cabal-install/Distribution/Client/Config.hs 253 NubListify 255 NubListify 267 NubListify 278 NubListify 280 NubListify 285 NubListify 291 NubListify 293 NubListify 296 NubListify 313 NubListify 315 NubListify 351 NubListify 353 NubListify 450 misleading, there's no way to override this default either make it possible or rename to simply getCabalDir. 610 this is only here because viewAsFieldDescr gives us a parser that only recognises 'ghc' etc, the case-sensitive flag names, not what the normal case-insensitive parser gives us. [fixme] 616 The following is a temporary fix. The "optimization" and "debug-info" fields are OptArg, and viewAsFieldDescr fails on that. Instead of a hand-written hackaged parser and printer, we should handle this case properly in the library. 682 this is a hack, hiding the user name and password. But otherwise it masks the upload ones. Either need to share the options or make then distinct. In any case they should probably be per-server. [fixme] 697 next step, make the deprecated fields elicit a warning. cabal-install/Distribution/Client/Configure.hs 256 should warn or error on constraints that are not on direct deps or flag constraints not on the package in question. cabal-install/Distribution/Client/Dependency.hs 264 the top down resolver chokes on the base constraints below when there are no targets and thus no dep on base. Need to refactor constraints separate from needing packages. 284 this should work using exclude constraints instead 295 this should work using exclude constraints instead 305 this should work using exclude constraints instead 498 warn about unsupported options 513 is this needed here? see dontUpgradeNonUpgradeablePackages cabal-install/Distribution/Client/Dependency/Modular/Assignment.hs 74 This function is (sort of) ok. However, there's an open bug w.r.t. unqualification. There might be several different instances of one package version chosen by the solver, which will lead to clashes. cabal-install/Distribution/Client/Dependency/Modular/Builder.hs 123 data structure conversion is rather ugly here 128 Should we include the flag default in the tree? 148 We could inline this above. cabal-install/Distribution/Client/Dependency/Modular/Dependency.hs 78 This isn't the ideal location to declare the type, but we need them for constrained instances. 137 Different pairs might have different conflict sets. We're obviously interested to return a conflict that has a "better" conflict set in the sense the it contains variables that allow us to backjump further. We might apply some heuristics here, such as to change the order in which we check the constraints. cabal-install/Distribution/Client/Dependency/Modular/Explore.hs 134 This isn't quite optimal, because we do not merely report the shape of the tree, but rather make assumptions about where that shape originated from. It'd be better if the pruning itself would leave information that we could pick up at this point. cabal-install/Distribution/Client/Dependency/Modular/IndexConversion.hs 77 Installed packages should also store their encapsulations! 187 Nothing should be treated as unknown, rather than empty list. This code should eventually be changed to either support partial resolution of compiler flags or to complain about incompletely configured compilers. [fixme] cabal-install/Distribution/Client/Dependency/Modular/Linking.hs 360 The enumeration of OptionalStanza names is very brittle; if a constructor is added to the datatype we won't notice it here cabal-install/Distribution/Client/Dependency/Modular/Package.hs 33 More information is needed about the repo. cabal-install/Distribution/Client/Dependency/Modular/Preference.hs 212 It would be better to actually check the reverse dependencies of installed packages. If they're not depended on, then reinstalling should be fine. Even if they are, perhaps this should just result in trying to reinstall those other packages as well. However, doing this all neatly in one pass would require to change the builder, or at least to change the goal set after building. cabal-install/Distribution/Client/Fetch.hs 97 when we add support for remote tarballs then this message will need to be changed because for remote tarballs we fetch them at the earlier phase. cabal-install/Distribution/Client/GZipUtils.hs 37 alternatively, we might consider looking for the two magic bytes at the beginning of the gzip header. cabal-install/Distribution/Client/Get.hs 111 add command-line constraint and preference args for unpack cabal-install/Distribution/Client/HttpUtils.hs 58 print info message when we're using a proxy based on verbosity 157 check the content-length header matches the body length. [fixme] 158 stream the download into the file rather than buffering the whole thing in memory. cabal-install/Distribution/Client/IndexUtils.hs 97 make getInstalledPackages use sensible verbosity in the first place [fixme] cabal-install/Distribution/Client/Init.hs 382 really should use guessed source roots. [xxx] cabal-install/Distribution/Client/Init/Heuristics.hs 178 we should probably make a better attempt at parsing comments above. Unfortunately we can't use a full-fledged Haskell parser since cabal's dependencies must be kept at a minimum. [xxx] cabal-install/Distribution/Client/Install.hs 220 use a better error message, remove duplication. 228 Make InstallContext a proper data type with documented fields. | Common context for makeInstallPlan and processInstallPlan. 233 Make InstallArgs a proper data type with documented fields or just get rid of it completely. | Initial arguments given to 'install' or 'makeInstallContext'. 372 this just applies all flags to all targets which is silly. We should check if the flags are appropriate [fixme] 412 this is a general feature and should be moved to D.C.Dependency Also, the InstallPlan.remove should return info more precise to the problem, rather than the very general PlanProblem type. 554 This is a bit of a hack, pretending that each package is installed It's doubly a hack because the installed package ID didn't get updated... [fixme] 668 this should be a proper function in a proper place [fixme] 770 does not handle flags [fixme] 855 might be nice if the install plan gave us the new InstalledPackageInfo 1293 'cabal get happy && cd sandbox && cabal install ../happy' still fails even with this workaround. We probably can live with that. cabal-install/Distribution/Client/InstallPlan.hs 652 It would be nicer to use ComponentDeps here so we can be more precise in our checks. That's a bit tricky though, as this currently relies on the 'buildDepends' field of 'PackageDescription'. (OTOH, that field is deprecated and should be removed anyway.) As long as we _do_ use a flat list here, we have to allow for duplicates when we fold specifiedDeps; once we have proper ComponentDeps here we should get rid of the `nubOn` in `mergeDeps`. 661 use something lower level than finalizePackageDescription cabal-install/Distribution/Client/InstallSymlink.hs 112 do we want to do this here? : createDirectoryIfMissing True publicBinDir cabal-install/Distribution/Client/List.hs 380 exclude non-buildable exes 440 installed package info is missing synopsis cabal-install/Distribution/Client/ParseUtils.hs 24 replace this with something better [fixme] cabal-install/Distribution/Client/Sandbox.hs 39 move somewhere else [fixme] 220 should we allow multiple package DBs (e.g. with 'inherit')? 246 Instead of modifying the global process state, it'd be better to set the environment individually for each subprocess invocation. This will have to wait until the Shell monad is implemented; without it the required changes are too intrusive. 379 path canonicalisation is done in addBuildTreeRefs, but we do it twice because of the timestamps file. [fixme] 599 use a better error message, remove duplication. 742 Is this compatible with the 'inherit' feature? [fixme] 748 configPackageDB' and configCompilerAux' don't really belong in this module [fixme] 762 make configCompilerAux use a sensible verbosity [fixme] cabal-install/Distribution/Client/Sandbox/Index.hs 104 Move this to D.C.Utils? 175 return only the refs that vere actually removed. [fixme] 180 removing snapshot deps is done with `delete-source .cabal-sandbox/snapshots/$SNAPSHOT_NAME`. Perhaps we also want to support removing snapshots by providing the original path. [fixme] cabal-install/Distribution/Client/Sandbox/PackageEnvironment.hs 84 would be nice to remove duplication between D.C.Sandbox.PackageEnvironment and D.C.Config. 148 Currently, we follow cabal-dev and set 'user-install: False' in the config file. In the future we may want to distinguish between global, sandbox and user install types. 334 Use substPathTemplate with compilerTemplateEnv ++ platformTemplateEnv ++ abiTemplateEnv. 342 Also check for an initialised package DB? 411 Should we make these fields part of ~/.cabal/config ? [fixme] cabal-install/Distribution/Client/Sandbox/Timestamp.hs 71 We should keep this info in the index file, together with build tree refs. [fixme] 214 This function is not thread-safe because of 'inDir'. [fixme] 261 What if the clock jumps backwards at any point? For now we only print a warning. [fixme] cabal-install/Distribution/Client/Setup.hs 44 stop exporting these: 1456 remove when "cabal install" avoids 1918 this should be an 'add-source'-only flag. [fixme] 2058 this is too GHC-focused for my liking.. 2193 Disabled for now because it does not work as advertised (yet). 2223 do we want to allow per-package flags? cabal-install/Distribution/Client/SrcDist.hs 129 use runProgramInvocation, but has to be able to set CWD cabal-install/Distribution/Client/Tar.hs 798 check integer widths, eg for large file sizes cabal-install/Distribution/Client/Targets.hs 416 should we warn if there are no world targets? 716 use Text instance for FlagName and FlagAssignment [fixme] cabal-install/Distribution/Client/Types.hs 114 I wonder if it would make sense to promote this datatype to Cabal and use it consistently instead of InstalledPackageIds? cabal-install/Distribution/Client/Upload.hs 38 how do we find this path for an arbitrary hackage server? is it always at some fixed location relative to the server root? [fixme] 59 better error message when no repos are given [fixme] cabal-install/Main.hs 660 It'd be nice if 'cabal install' picked up the '-w' flag passed to 'configure' when run inside a sandbox. Right now, running 683 Redesign ProgramDB API to prevent such problems as #2241 in the future. 703 Passing 'SandboxPackageInfo' to install unconditionally here means that 'cabal install some-package' inside a sandbox will sometimes reinstall modified add-source deps, even if they are not among the dependencies of 'some-package'. This can also prevent packages that depend on older versions of add-source'd packages from building (see #1362). [fixme] cabal-install/tests/PackageTests/Freeze/Check.hs 45 Test this against a package installed in the sandbox but not depended upon. [xxx] cabal-install/tests/PackageTests/PackageTester.hs 3 This module was originally based on the PackageTests.PackageTester module in Cabal, however it has a few differences. I suspect that as this module ages the two modules will diverge further. As such, I have not attempted to merge them into a single module nor to extract a common module from them. Refactor this module and/or Cabal's PackageTests.PackageTester to remove commonality. 2014-05-15 Ben Armston 229 Convert to a "-v" flag instead. cabal-install/tests/UnitTests/Distribution/Client/Dependency/Modular/DSL.hs 55 Perhaps these should be made comments of the corresponding data type definitions. For now these are just my own conclusions and may be wrong. From cheecheeo at gmail.com Thu Jun 25 16:54:48 2015 From: cheecheeo at gmail.com (John Alfred Nathanael Chee) Date: Thu, 25 Jun 2015 09:54:48 -0700 Subject: Issues, issues, issues... In-Reply-To: References: Message-ID: 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. If you understand the code well enough to understand the request in the TODO, I'd suggest fixing it and submitting a pull request. -- Love in Jesus Christ, John Alfred Nathanael Chee http://www.biblegateway.com/ http://web.cecs.pdx.edu/~chee/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Thu Jun 25 16:56:34 2015 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 25 Jun 2015 18:56:34 +0200 Subject: Issues, issues, issues... In-Reply-To: <20150625163214.GA7916@casa.casa> References: <20150625163214.GA7916@casa.casa> Message-ID: 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, From spam at scientician.net Thu Jun 25 17:00:15 2015 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 25 Jun 2015 19:00:15 +0200 Subject: Issues, issues, issues... In-Reply-To: References:

Message-ID: 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, From spam at scientician.net Thu Jun 25 17:12:52 2015 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 25 Jun 2015 19:12:52 +0200 Subject: Issues, issues, issues... In-Reply-To: References: Message-ID: 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. Regards, From spam at scientician.net Thu Jun 25 20:39:54 2015 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 25 Jun 2015 22:39:54 +0200 Subject: Issues, issues, issues... In-Reply-To: References: Message-ID: 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'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'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...? Regards, B?r?ur [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. From ttuegel at gmail.com Thu Jun 25 23:12:16 2015 From: ttuegel at gmail.com (Thomas Tuegel) Date: Thu, 25 Jun 2015 18:12:16 -0500 Subject: Issues, issues, issues... In-Reply-To: References: Message-ID: 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 From spam at scientician.net Sat Jun 27 01:14:26 2015 From: spam at scientician.net (Bardur Arantsson) Date: Sat, 27 Jun 2015 03:14:26 +0200 Subject: Issues, issues, issues... In-Reply-To: References: Message-ID: 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, From spam at scientician.net Sat Jun 27 01:19:04 2015 From: spam at scientician.net (Bardur Arantsson) Date: Sat, 27 Jun 2015 03:19:04 +0200 Subject: Issues, issues, issues... In-Reply-To: References: Message-ID: On 06/27/2015 03:14 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 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, From gale at sefer.org Sun Jun 28 08:29:49 2015 From: gale at sefer.org (Yitzchak Gale) Date: Sun, 28 Jun 2015 08:29:49 +0000 Subject: Issues, issues, issues... In-Reply-To: References: Message-ID: 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/27/2015 03:14 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 > 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: