Re: Drastic Prelude changes imminent
On Tue, Jan 27, 2015 at 2:17 PM, Mikolaj Konarski < mikolaj.konarski@gmail.com> wrote:
We already have a process that works pretty well. Create a wiki page that specifies the implementation. Notifying every Haskell user is pointless if there is no specification for them to look at. I have no idea why the specification step was skipped for this change.
Because code was the shortest specification in this case? Or, alternatively, the specification was too vague, as in, the most sensible set of changes that make these 5 imports coexist without an error? Or because the best specification was a set of detailed, readable commit messages that show the road from this vague specification to the actual decisions and code changes? With lots of time in between for others to offer suggestion for subsequent commits and catch problems?
I don't mean there's no communication problem, but specifications are not always a solution. Perhaps a wiki page should list the commits, as they were created. Or perhaps they were listed somewhere?
None of these rhetorical questions are satisfactory. I understand the need to iterate on a design and start with a vague specification. But by the time something concrete is figured out, it should be explained. Explaining the iteration process with a few of the code examples would answer a lot of the questions here. In the end, the changes have been explained many times over now, just not coherently in one place.
None of these rhetorical questions are satisfactory. I understand the need to iterate on a design and start with a vague specification. But by the time something concrete is figured out, it should be explained. Explaining the iteration process with a few of the code examples would answer a lot of the questions here. In the end, the changes have been explained many times over now, just not coherently in one place.
Greg, if that ticket was (it almost is:) a wiki page, would that be satisfactory? https://ghc.haskell.org/trac/ghc/ticket/9586 I assume it wasn't linked to and advertised enough. Where would we need to link to it, how often (e.g., after each major commit?) and what modifications would be necessary, if it's not clear enough?
On Tue, Jan 27, 2015 at 2:51 PM, Mikolaj Konarski
None of these rhetorical questions are satisfactory. I understand the need to iterate on a design and start with a vague specification. But by the time something concrete is figured out, it should be explained. Explaining the iteration process with a few of the code examples would answer a lot of the questions here. In the end, the changes have been explained many times over now, just not coherently in one place.
Greg, if that ticket was (it almost is:) a wiki page, would that be satisfactory?
Perhaps, if the discussion on the ticket was summarized into an explantation. But it is too much to wade through right now.
I assume it wasn't linked to and advertised enough. Where would we need to link to it, how often (e.g., after each major commit?) and what modifications would be necessary, if it's not clear enough?
At some point a link to the proposal would need to appear in the mail list. Updating as iteration occurs is a good question. That is going to end up being a judgement call. Every time there is a major change or decision, particularly among alternatives that cause breakage, it would be good to mention it on the mail list. I would imagine that ended up happening a few times in this case.
participants (2)
-
Greg Weber -
Mikolaj Konarski