[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Sun, 28 Oct 2007 00:38:03 +0100 tom@xxxxxxxxxx wrote: > Ideally it would be done on that basis of having lots of different ideas > posted and then trying to find the two or three that people would develop. OK, so ideas before the event - that could work. > A nice example would be if I suddenly thought that gnucash needed an extra > exit button. :-) We could do that - just don't expect upstream to accept it because by their reading of the Gnome Human Interface Guidelines, there shouldn't BE an exit/quit button on the application toolbar as it duplicates the X button. (IMHO, that is dependent on the window manager and a quit button is useful because not every window manager gives you a usable close button but gnucash upstream and I don't have a particular history of agreement.) A good tip here is to focus on a smaller application with less inherent problems of build tree size (gnucash is >90Mb), build time (testing each modification of the patch requires a rebuild which isn't particularly interesting until it fails) and build complexity. Gnucash fails on all three. ;-) LinuxFormat did a tutorial on exactly this thing using Gimp as the example. Gimp is big but an inherently simpler build than gnucash because Gimp sticks to C and doesn't get involved in "weird-stuff" like guile and Scheme. Another thing to consider here is that there are different meanings of "source". Upstream consider their CVS/RCS/SVN/git/foo as "the source" but a lot of upstream packages have bizarre and complex dependencies - even more than the package itself. This is especially true of gnucash which - between releases - can be a pig to build on anything except what upstream use (Fedora 5 IIRC). Yes, Fedora is now 7 or later but hey, at least it isn't Fedora 3. So a working solution is the distribution source - at least we know that it will build from source on the same distribution. Problem there is that patches against this source may or may not apply successfully against upstream source. If our patch is only for our benefit that doesn't matter. The distribution maintainer might be interested .... An alternative is anything in perl. Rebuild time disappears, source problems disappear and distribution-specific problems generally disappear too. Python or ruby could be options here - just not for me as I have no experience of either. > Now that may or may not be considered for the next release but > probably not many people want it. I post and you decide that you could help > write a simple patch. Then we can look over it. Yes, I can do that. > The main reason for this is not really the value added to the project by that > one patch but the suggester learning a bit about the package and then how > they could write other patches. I suppose it is almost a tailored coding > lesson but it should produce at least something useful and others who didn't > suggest it could learn as well. It'll be hard enough finding a match between your itch and a programmer within the LUG with experience of the package. Getting something that upstream will accept is another level of complexity. If we do manage to create a patch useful to upstream it'll be a bonus. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgp68I015nMDp.pgp
Description: PGP signature
-- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html