[gcompris-devel] Release gcompris4.0PRE3

[rami]

> > OK. Will you do it or will I? I haven't quite figured out yet what my
> > responsabilities exatly are in bugzilla, and don't want to step on your
> > feet ;-).
> > 
> I don't know either. I'm glad is you and others take some
> responsalilities on gcompris ;)

Well, I'm glad there are people like you coding and managing and working
late on these sort of projects :-). The minimum we users can do is help
you out when possible. Besides, gcompris is getting quite mature and
diversified now, and has really helped my girlfriends' kid getting good
grades. When I have some time and get my old laptop working again, I'll
try to do a demo at his school. So thank you and all other contributors
to gcompris for this fine app. It's intellectually extremely rewarding
for us users to give a little and get thousandfold in return :-).

> I would think that the one who has the bug assigned to must close it,
> now on the other end, we could say only the QA close it. What's your
> preference. We can decide quick, if we don't like the option we choose
> we'll change it as quick.

Well, what we can do is that the person who decides to fix or has found
a workaround for the bug assigns it to himself and makes the comment. I
can check regularly (once or twice a week) if there are any new orphan
bugs that still need to be assigned, try to reproduce them on the
current MDK or SuSE, or make someone reproduce them (Red Hat, Debian,
Knoppix, Slackware, etc.. users anywhere interested? I guess that  at
least for Debian there's someone responsible for the .deb package) and
then assign it to you if it is reproductible. Otherwise I'll contact the
person who has filed the bug, or mark the bug as duplicate if it's
indeed a duplicate of an older bug.
As for closing, we can say that whoever fixes the bug makes the comment,
saying in which version it is fixed. Once there are rpm's or .deb's or
anything precompiled for the fix, I test it on MDK and SuSE (and
eventually make people on other distros test it) and finally close the
bug. This has the disadvantage of being quite long in the final closing
of the bug, but the advantage of having something working for basic
users behind and rtc connection (like me ;-)) who don't pull the code
from CVS.

On the other hand, my opinion is that the bugzilla thing shouldn't take
too much importance over the mailing list and direct mails to the
maintainer. Bugzilla looks more professional and structured, but it's
also more impersonal IMHO.

> The esc=quit option was taken out a long time ago. currently, esc let
> you quit the current board or get up a level in the menu, but not quit.
> The problem is with young kids. Parents/teachers expect to put their
> kids in front of gcompris an leave. Since they won't be able to start
> gcompris again, is is bothering if they quit too easy.
> Also, little kids who get into a menu quit yes/no won't be able to
> understand this.
> I first looked at evolution and galeon and they use ctrl-Q to quit. We
> could use this and document it in the inline help (ok, implemented).

OK. ctrl-Q is fine for me, since it's used in other gnome apps as well.
Opera uses it, too. 

> > It seems that from time to time there's a refresh problem of the bottom
> > menu after opening a navigator to view the gcompris documentation, too.
> > So implementing a refresh key would be a good idea, too.
> > 
> OK, I coded that but found that when there is a refresh bug, it means
> the internal status of the canvas is wrong and calling refresh doesn't
> do it either. I keep this trick to see if it can help others.

Too bad. It's still the gnomecanvas refresh bug?

Amicalement,

Rami


_____________________________________________________________________
Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France