[m-dev.] New release?

Mark Brown mark at mercurylang.org
Wed Oct 21 13:29:43 AEDT 2015

On Wed, Oct 21, 2015 at 11:14 AM, Julien Fischer <jfischer at opturion.com> wrote:
> On Wed, 21 Oct 2015, Paul Bone wrote:
>> On Wed, Oct 21, 2015 at 10:25:57AM +1100, Julien Fischer wrote:
>>> There was a list of things we wanted to do to address the "too many
>>> grades"
>>> problem.  Some of these have been done (e.g. hiding user facing
>>> documentation
>>> for experimental grade components), others haven't yet (e.g. merging the
>>> 'tr'
>>> and 'trseg' grade components and renaming the grade component options).
>>> See
>>> the following thread:
>>> <http://www.mercurylang.org/list-archives/reviews/2014-September/017297.html>
>> When this came up recently Micheal (despite how he raised the issue) made
>> a
>> good suggestion that we should document not just what the grade components
>> mean (which mostly exists in the user guide) but which combinations make
>> sense / are supported / are well tested.

This doesn't address the key problem, which is that users need to know
anything at all about what the grade components mean when they are
installing Mercury. We know the common use cases for installation;
most users should only have to pick which one they want. E.g.:

- user who wants to compile some code they have found
- developer who wants profilers, debugger, etc
- developer who knows exactly the set of grades they want
- sysad who wants everything because they don't want to be bothered by
follow-up requests
- user who wants to bootstrap from ROTD

The configure script ought to be able to decide the set of grades
based on this choice, perhaps with some additional tweaks available.

> The main thing that remains to be done is to add new grade component
> options.  The reason we want to do that is so that we can deprecate the
> existing options.  We want to do that so we can change, for example,
> '--debug' to means "choose the best available installed debug grade" intead
> of
> "add the debug grade component to the current grade".

Exactly. With options like these, and a configure script as above,
most users won't need to learn the details of grade components.

I think the deprecation of the existing options should be announced
right away - i.e., tell users the options will be changing meaning


More information about the developers mailing list