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