Re: issue classification debate

[Graham Percival]

On Sun, Dec 13, 2009 at 12:36 PM, Ian Hulin <address@hidden> wrote:
> Hi Graham,
> Graham Percival wrote:
>>
>>
>> %% for Type, we match the first relevant item on the list.
>> Type-build: new type, but I think it's worth it.  Used for GUB,
>> makefiles, stepmake, and python scripts which are used in the build
>> system.
>
> Just a thought, use two new types:
> Type-kit-generation: for GUB and other things that generate the build
> Type-build: for the build files themselves that actually compile and install
> Lily on a particular platform.  E.g. you could classify a bug using this
> type to get an emergency patch out so Lily will build on a specific
> platform, and then handle any GUB changes under a kit-generation issue so
> you and Jan could spend a bit more time getting GUB to produce the right
> thing.

I'd rather not have too many Types; 8 is already pushing it.  We're
not going to have all that many build issues, anyway.  :)


> Which side of the line does *user-perceived* missing functionality go? In
> the sense of it's something Lilypond hasn't done yet, but users coming to
> Lilypond with experience of other music-setting software feel is really
> lacking.  E.g. former Igor user reporting midi-playback not observing
> dynamic and tempo changes and repeats. The user may feel this is a defect,
> developers may take the view it's an enhancement request.
> We need a decision here, not a debate.  My feeling would be log it as an
> enhancement request, but make sure you record that the original reporter
> considers it a defect.

It would be logged as an enhancement, with no record that the original
reporter thought it was a defect.  We don't need yet another layer of
virtual paperwork to take care of; the initial reporter's opinions
about the classification don't matter.


>> Warning: renamed from "warning-nitpick" due to the way google deals with
>> tags.
>>    I'm going to add a link to "label:warning" from the CG, since these are
>>    AFAIK easy things for Frogs to work on.
>
> Does this cover things like the compilation squawks we see currently in the
> C++ files: warning converting int64 -> int may change a value, and suchlike?

Hmm... I guess it could.  I hadn't really thought about that.  The
basic idea behind "warnings" is "the output is exactly as expected,
but either 1) it should generate a warning (say, a bar-line check
failed?) or 2) it generates a false warning (generally a programming
error").  We can apply this to the compilation process as well.

... hmm, now I'm wondering if such issues would be better put under
Build.  Actually, I'm pretty certain I'd rather see them in Build.

Cheers,
- Graham