Developers,
Here's a proposal. My understanding is that this proposal for a
change of policy will not take effect until it is accepted.
Proposal:
GnuCash developers should refrain from making changes (1) to QOF
that are visible to users of the QOF API (2). (i.e. changes such that if
the QOF
On Monday 30 January 2006 5:15 pm, Chris Shoemaker wrote:
> Developers,
> Here's a proposal. My understanding is that this proposal for a
> change of policy will not take effect until it is accepted.
I propose that no change is made prior to the release of GnuCash 2.0.0. Then
we can revisit th
On Monday 30 January 2006 8:02 pm, Neil Williams wrote:
> On Monday 30 January 2006 5:15 pm, Chris Shoemaker wrote:
> > Developers,
> > Here's a proposal. My understanding is that this proposal for a
> > change of policy will not take effect until it is accepted.
OK, let me just explain a bit a
I propose we table this discussion until after 2.0 is released.
-derek
Chris Shoemaker <[EMAIL PROTECTED]> writes:
> Developers,
> Here's a proposal. My understanding is that this proposal for a
> change of policy will not take effect until it is accepted.
>
> Proposal:
>GnuCash developer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Developers,
now that 2.0 is released, we could pick up and finally close the old
issue from January/February. At the time, the question was whether the
code in gnucash's lib/libqof should be treated any different compared to
any other code in the gnuc
A few of us discussed this on IRC today. The executive summary:
* QOF has forked and we can/should just ignore what happens in
QOF-CVS. Indeed, we might even just want to move lib/libqof/qof ->
src/qof in our source tree to make it more clear.
* We should keep goffice/libgsf as long as it's
