Re: removed bugs from lily-bugs

[Erik Sandberg]

On Wednesday 02 June 2004 00.13, Heikki Johannes Junes wrote:
> > Personally, I do not think that there will be a big public interest in
> > the history of lilypond bugs. What I believe could be interesting, is the
> > set of open bugs, and the set of very recently closed bugs. I.e. what
> > will be in CVS with my latest suggestion.
>
> I disagree. Think you were a fun of grace notes, but you were annoyed by
> the early, non-synchronized midi output .. then you stop doing graces,
> because the timings of midi channels become erronous. Then at some point
> you find out that there have been a big revise with graces, and you would
> like to know whether the same bug still exists -- and, hopefully, get also
> some kind of correct synchronized midi output withgrace notes. Then you
> look at the ChangeLog file in order to find out when did the brilliant
> people fix the early bug?! And, in the best case, you find that the bug
> does not exist anymore in any other place than the history files.

I might be wrong, but I don't think a changelog will be good for this either. 
As a user, you would have to know 1) that the lilypond-bugs archive exists, 
and 2) that the bug in question is called midi-grace (the changelog will be 
long, so you have to grep for it).

And the interest of closed bugs has made me decide to keep closed bugs in the 
future, probably in the lilypond-bugs/closed/ directory. This would work even 
better for this purpose; just browse that directory for the bug.

I think the normal thing would be to try running lilypond on your old file 
that lilypond bugged on, and see if it still bugs. Or you can tell me to 
notify you about the bug getting fixed.

Another point is that the bug list is intended & optimised for bug-fixing 
developers, not users (unlike e.g. the regression tests). I always try to 
minimise bugs to something as small & uninteresting as possible, and it may 
sometimes be hard to realise that your bug is equivalent to the bug in the 
repository. 

> IMHO, one should remember their errors, in order not to make the same
> (programming) error twice. I agree that when everything goes smoothly,
> nobody reads the ChangeLog files. But when there are some problems, they
> may be the first place to look at.
>
> The ChangeLog file also shows whether the project has been active or not.
> Actually, it is quite impressive that some program has been developed for
> so many years with only few less-active seasons.

This information would exist in the cvs as well. Just go to the webcvs & sort 
reports by date, in closed and open.

> Also, ChangeLog is like a guest book: it collects comments from the
> developers -- sometimes even feelings of the programming.

This does however not apply here. It will only contain comments like
foo added.
bar closed.
etc. And basically everything will be written by me.

btw, is there an automated way to create changelogs in conjunction with 
writing commit messages in CVS? All changelogs look quite standardised; so i 
just suppose the process is automatised somehow.

(if I have to do something manually, then I'm still not convinced that it's a 
good idea)

> If a New 
> Developer comes to work on some particular part of the program, he might be
> interested on the history of his/her part.

AFAICS, this only makes the Changelog of _lilypond_ interesting. Not the 
changelog of the bug repository.

> This being said, I would say that the set of closed bugs is interesting. It
> tells that bugs have been repaired! It does not matter if the size of the
> ChangeLog files starts to exceed the size of other files in the collection.
>
> In the end I have a guesting to the bug-meister. How to decide between a
> feature request and a bug? In other words, should some feature request be
> collected into the bug collections? This is how it is done with bugzilla.

I have decided to handle bugs only, though a few reports which are more 
feature requests than bugs have been added as well. Anyone who is interested 
in maintaining a feature request list is very much welcome to do so, and in 
that case the lily-bugs repository is probably a good place to keep this 
list. There was a discussion on this topic last week:
http://lists.gnu.org/archive/html/lilypond-devel/2004-05/msg00119.html

Erik