[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ITR: gnomermind - failed review



On Fri, 5 Oct 2007 11:06:59 -0400
"Chess Griffin" <chess@chessgriffin.com> wrote:

> > > Hmm, first problem. As the new maintainer, you should also close 442580
> > > and 391172.
> 
> I have made a few changes package files that I will upload to
> mentors.d.n.  As to these other two bugs, 391172 might need to be
> reassigned to libgnome32.  I have had some follow up communications
> with the original bug reporter that can be seen in the bug report
> logs.  As for 442580, FTBFS if build twice in a row, is one that I am
> still investigating.

Your comments in 391172 worry me:
> I am not a C programmer, but digging through the gnomermind source
> code, it seems that to me that when the help menu is accessed,
> gnomermind calls the gnome_help_goto function, and this function uses
> "ghelp" to display the help files.

IMHO, being the maintainer of a package means you should at least be
able to work with the language used by the package. That is why I've
orphaned glipper because the new version is Python instead of C used
for the current version. I can't use Python, I have no knowledge of
fixing bugs in Python - IMHO it is unwise to attempt to be the
maintainer for a package that might as well be written in gibberish for
all I can do with python.

gnomermind is an old, old package and it's hard to tell if upstream is
still interested. Have you tried to contact upstream? I don't have time
to talk you through debugging the C code for this package - I expect
you, as the prospective maintainer of an old package that is likely to
need updating, to be able to fix or at least understand the bug reports
made against the package.

What would you do if a bug report contained a backtrace or a valgrind
report? How much C do you know and do you know any other programming
languages? (Not counting shell).

gnomermind, like many C packages for GNU/Linux, uses the autotools
which have their own problems and methods. It is also GTK1 (as you are
already aware) but this raises yet more issues because GTK1 is unlikely
to get fixes for anything other than the most serious or security bugs
- the same goes for the Gnome libraries built upon Gtk1. My concern is
that if you are unable to fix 391172, reassigning it to libgnome32 on
some vague "it must be there because that is what is being called" is
just not helpful. The reassigned bug would be even less likely to be
fixed than if gnomermind stays under the QA group. The solution to
442580 is likely to involve the autotools and not just debian/rules.

The reference you quote for how Ubuntu fixed their About.. box is
irrelevant because it does not relate to the same libraries. The other
two messages you found do not support your belief that this is a bug in
libgnome32. 

My main concerns are:
1. gnomermind is in Debian under the management of the Debian QA group.
391172 is unlikely to be fixed under that arrangement. 
2. Closing "fails to build twice in a row" bugs is a goal for Lenny so
I have to be reasonably confident that you *can* fix that bug as
maintainer because if you cannot, someone from the QA group would need
to do it as this will become an RC bug in due course.
3. If your knowledge of C is insufficient for you to be able to triage
bugs in C packages, maybe you should choose a package with a much more
active upstream and learn how C packages are maintained.
4. Following from the above, IMHO, 391172 is no more likely to be
fixed with you as maintainer than with the QA group as maintainer.
Unless you can show me that you can fix 442580 (which the QA group
would have to fix eventually), I'm at a loss to see the benefit of
transferring gnomermind from QA to you.
5. You need to learn more about the BTS - your comment about closing
391172 because of the (assumed) libgnome32 issue indicates that you
haven't understood the BTS docs correctly because there is a standard
way of reassigning bugs within the BTS from one package to another -
once you have *evidence* that the bug really does lie in a different
package.

Sorry, but I think you need to understand the language of the package
that you propose to maintain. It's one of those things that I thought
was implicit in the current guides, reference texts and FAQs but maybe
it needs to be spelt out.

Unless you can fix 442580 AND provide a more reasoned approach to
391172 that conforms to existing Debian BTS guidelines, I do not think
that you should maintain gnomermind in Debian. Ideally, I would want to
see a fix for 391172 within the gnomermind package before I would
consider sponsoring you as maintainer of gnomermind.

There are issues with yelp and gnome-help at the moment (see 443927)
but you should at least be able to fix gnomermind to the point where
the help window is opened, the index is displayed in a sidebar and the
main window displays what is described in 443927. Then you can mark
391172 as blocked by 443927 using the BTS.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgpVXmPuG1dKC.pgp
Description: PGP signature


Reply to: