Re: [ft-devel] address@hidden [Was: issue with ArialMT in 2.1.9]

[David Turner]

Hi Antoine,

Antoine Leca wrote:

> Ian Brown wrote yesterday:
>  
>
> > Ps: now that you have moved to savannah, will it be possible
> > to make bug reports in the tracker there? It would seem like a
> > better place to report such things than here.
> >    
>
> Sorry if I ask something obvious.
>
> Why do you believe it would be a better place?
>
> Particularly, since there is a *lot* of packages out there which
> specify that bugs are to be reported to the address@hidden list
> anyway (so address@hidden only is not an option IMHO), what
> value would add the use of the tracker system in addition to the
> use the mailing list?
>
>  
There are multiple values to having a searchable bug database:

- generally more easily searchable than a mailing list archive, which
 also contain topics that are not related to bugs and enhancements,
 or even a commitlog (fugly file !!)

- help to sort/prioritize developments before the next release

- provides a useful timeline of the project's development history

Of course, all of this is true in theory. In practice, these benefits 
can only
be reaped when you properly maintain the CVS and Bug databases in sync,
which generally means having some sort of wrappers around CVS, or use
some special tagging in your commit messages so that post-commit scripts
can do their magic with them. If you don't, you end up with something that
is slightly more an annoyance than anything else.

At my work, we changed the way we manage changes in our software by
_requiring_ that _each_ commit made on the head branch be associated to
a given "issue" (i.e. bug or enhancement request) number. This has a number
of drawbacks:

- we can't use "cvs commit", but specific wrapper scripts that perform some
 heavy lifting for us. These are written in Perl, nobody really understands
 them except one gal in the company. And each commit is slow as hell :-)

- we must create a issue number for every change, even minimal ones, which
 is somewhat a pain because this involves the agreement of several people
 (issue states are: opened => analyzed => assigned => fixed => validated =>
 accepted => close)

- if we need to do something more experimental, with the ability to perform
 intermediate commit, we need to go through special hoops to do it, but 
it's
 still possible (basically by creating a temporary branch, then merging the
 result with a correct "issue" number)

In our context however, this has a lot of benefits, but that's mainly 
because
we sell highly-customized software to each customer from a more or less
common source pool. E.g. knowing exactly what's in each binary release that
was sent two or three years ago to a small client helps us when they 
come back
and want an updated version for a lot more licenses...

Well, you get the idea. This is more industrial, but it also takes a lot 
more time.
This time is paid off in the long run, because we're a commercial 
company with
specific customer profiles. And we're paid to handle such complexities.

I'm all for a bug database for FreeType, but I want it as simple as 
possible to use.
What this means:

- only core developers should be allowed to enter issues in the database
 (otherwise, some "candide" users are going to incorrectly populate it for
 us, more quickly than you can imagine)

- I don't want a ton of stupid fields to create a single issue. Last 
time I checked
 bugzilla, it was the mother of all stupid fields !! hughhh....

- We should try to enter every non-cosmetic bug and enhancement we 
really intend
 to develop. (this is why easy creation of issues is important, I don't 
want to spend
 more than 20 seconds writing to create a new one). Otherwise, the bug 
database
 isn't going to be very useful to track the project's history.

As a side note, I invite those that do not know it to read the following 
essays:

Painless Bug Tracking: 
http://www.joelonsoftware.com/articles/fog0000000029.html
The Joel Test: http://www.joelonsoftware.com/articles/fog0000000043.html

If I had time, I'd wrote an essay to explain why we don't need unit 
tests for
FreeType at the moment (basically, 99.9% of the bugs uncovered in the 
library
wouldn't have been caught by these kinds of tests, we have tons of 
"testers", and
we're certainly not paid enough to code the tests :-)

I haven't seen what Savane provides yet, but I'll have an interested 
look this week-end

Regards,

- David


> Antoine
>
>
>
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freetype-devel
>