On Wednesday 11 January 2006 12:08 pm, Christian Stimming wrote: > I'm very sorry and you will probably not like it, but I have to > fundamentally disagree about your statement here.
:-) > The code base under lib/libqof/ makes up a fundamentally vital part of > the gnucash application, as it includes the fundamental object model, > many fundamental data types, the rational number arithmetics, the data > file format and parser and similar stuff. In my opinion this makes it > necessary that this code base will continue to be double-checked by all > gnucash developers Sorry if I gave the impression that this oversight was ever to be removed! I agree with you and I've said the same to Derek before. I just want these checks to be complementary, not conflicting. I'm under no illusions about my programming abilities. Equally, oversight / peer review is a fundamental advantage of the entire free software community and it makes absolutely no sense for QOF to go it alone and leave all these advantages behind. I value the input and peer review immensely - I would just like to have more involvement and, dare I say, a little more consideration of my role. If there was a way of maintaining this oversight with libqof removed from gnucash I would explore it. Short of adding each of you to the QOF project at SF and making more work for everyone, I don't see a way. The use of svn and cvs makes it difficult (impossible?) to combine the two trees automatically. So what I am asking for is merely more cooperation from the other gnucash developers to ensure that external QOF is always available for gnucash. It makes sense at a packaging level to have close cooperation upstream. > , including the possibility to submit our changes > ourselves. I do consider it necessary that this code will continue to be > "a part of" gnucash and will remain under the control of the gnucash > developers. Each time that happens, you sacrifice external QOF support. It doesn't need to be that way. > The "external libqof" project, on the other hand, is developed solely by > yourself. It doesn't have to stay that way. True, I have non-gnucash tasks for QOF that require code that gnucash may not want to use but there are also other developments within external QOF that gnucash will certainly want to use. Some are being developed within gnucash code using the cashutil branch. Some uses of QOF will deliberately compile it so that gnucash cannot use it (i.e. on embedded systems where gnucash couldn't run anyway.) On platforms that *can* run gnucash, external QOF will always support gnucash, and gnotime and pilot-qof and a few others that I have planned. QOF has always had aspirations beyond it's life in gnucash, otherwise it would not have been spun out. > Now you are of course free to develop whatever project with > whatever code you like. But there has never been a discussion of whether > the gnucash project will actually accept to have a vital fundamental > part of its application to be provided by a separate library that is > only under control of you. I don't mind the discussion but I think the terms are wrong. I would like a discussion about how gnucash is going to work with QOF as an external library but at no point does it have to be under my sole control. It might not be worth making others part of the QOF external project, unless anyone would like this to be done. What we need is cooperation so that external QOF is always supported by gnucash. I would much rather have future gnucash releases as all dependent on external QOF. It makes far more sense to reduce the code duplication. To do this, I just need a little help from all of you to let me know when changes are needed in libqof. > I wouldn't care if this > discussion were about a sub-module that is only needed for special > actions (like libofx for the OFX importer), but I *do* care for *this > vital part* of the application. Perfectly reasonable. You can't compile gnucash without QOF, you can without OFX. > Instead, I think the appropriate level > of mutual trust is the current status: You, as well as (how many > actually? I think 5-7) 6 others, have write access to the same SVN, and > every change of each of us can and will be double-checked by others. On > that level of trust and mutual control I'm totally convinced that your > contributions are a good improvement for the overall project and they > are always very welcome. However, that level of trust and mutual control > does not hold any longer for your external libqof code. In that project > you are the only active developer -- no doubt you would gladly accept > more developers, but I for one don't want to join yet another project > but instead want to develop the gnucash-relevant code inside gnucash. Again, perfectly reasonable. Changes to libqof by gnucash developers ARE welcome - I would just like more coordination. > That is why I *do* consider the lib/libqof code base to still be an > integral part of gnucash. I do *not* agree to treat it as an external > library. Would you agree to at least work with me on libqof changes? i.e. prior to the commit? > I *do* encourage every gnucash developer to treat it exactly as > we would treat every other part of the gnucash codebase: Fix bugs > everywhere, discuss improvements with the involved developers. Now that's what is NOT happening. Improvements in libqof are not being discussed with the involved developers - e.g. me. The commits are coming in undiscussed and without relevance to release activity in the external QOF library. This will come back to bite us if we don't agree on a way of simply notifying people about changes that will (or are expected to) affect external code. Packagers should always have the option to use external QOF support for gnucash. Consider gnotime - I don't have write access there, I do maintain external QOF support and the gnotime package works perfectly well with external QOF. True, it's a tiny application by comparison, but I am intent on maintaining binary compatibility throughout libqof1 and on supporting gnucash using external QOF. All I seek is a little coordination and cooperation. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgp6RMQKzG9f5.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
