Re: [bika-dev] Worrying renames

[C. <ro...@up...>]

On Tue, 2006-09-26 at 09:35 +0200, bika - lemoene wrote:
> ok this post pre-dates some of those circulated now ....
>=20
> Roch=E9 Compaan wrote:
>=20
> >I see a lot of renames=20
> >
> job cards to work sheets
> statements to invoices ?
>=20
> >being checked into the trunk at the moment and
> >this worries me for the following reasons:
> >
> >1. They haven't been discussed at all.
> > =20
> >
> They've been in the issue tracker for long, brought on now by latest=20
> rounds of lab visits, available development capacity and request by the=
=20
> sponsor of upcoming development. I cleared the changes with existing cl=
ients
>=20
> But yes they should've been mentioned here, my apologies. There might b=
e=20
> users of Bika out here who would not like the name changes but are not=20
> actively participating or contributing. Active sponsors - mainly Bika=20
> lab systems and her clients - would naturally be heard clearest

Current users that download and evaluate Bika might become future
sponsors. Given this I would encourage a process where we discuss
changes on the lists so that everybody can see that we have a sound
process. Even existing sponsors might benefit from this.

> Comment, suggestions please
>=20
> >2. Why do we risk such a major refactoring just before getting ready f=
or
> >a release.
> > =20
> >
> Relatively small risk calculated. We are testing and the initial releas=
e=20
> of 1.2 will be as 'Release Candidate' not intended for conversions, see=
=20
> below

I got the impression that the 1.2 release is quite urgent and I had
always thought that migration code is a necessity, especially for
existing sponsors running Bika 1.1. Doing this refactoring viewed in
this light is risky in my opinion. Even the sponsors will have to wait
until a complete set of migration scripts are written.

> >3. How will the data of existing bika installations out there be
> >migrated or are simply going to say "INCOMPATIBLE".
> > =20
> >
> For the release candidate, yes. Downloads are continuing apace at the=20
> moment and we want to rather give new downloaders a better product. A=20
> lot of refinement has gone into Bika since 1.1 months ago

For sure, but a lot of the improvements lies in code that does not
impact previous releases. The accreditation branch for instance adds on,
rather than modifies the existing code.

> >4. Are you sure you've got the semantics right. I for instance don't
> >feel that the semantics are clear with regards to statement and invoic=
e.
> > =20
> >
> The current Bika 'statement' is really an invoice as it does not reflec=
t=20
> receipts. The name was inherited from our first client. Bika's upcoming=
=20
> financial software interfaces will export this data as invoices to be=20
> incorporated in true statements. Bika's invoices currently don't includ=
e=20
> orders (of lab products other than analysis services) information and=20
> this will be modified for version 1.3

The current Bika statement is still closer to a statement than an
invoice. An invoice lists items purchased by a client, like Analyses,
and demands a payment for the items purchased. A statement is a summary
of invoices and payments and reflects the current balance on the
client's account. The current Bika statement is a summary of analysis
requests. Analysis requests play the part of invoices if they sum the
cost of analyses.

If we record payments and display them on the statement, we honour the
definition of a statement.

> >In fact I don't even think financial stuff belongs in the core but
> >didn't want to risk taking this out before releasing 1.2.
> > =20
> >
> In my experience most commercial labs want financials, intra=20
> organisational labs for cost centre accounting. When Bika's accounting=20
> side grows bigger, we may decide to skin it off

If it is a separate product it can be easily installed. If it is not it
is in the way of labs that have financial systems in place. And most
commercial entities have financial systems in place.

> >Am I missing a spec for the above? When was it reviewed and discussed?
> > =20
> >
> The invoices issue is a long open feature request. Renaming Jobcards wa=
s=20
> not documented. I really don't think either deserves a spec as it is a=20
> simple enough top level concept

I thought they might have been paragraphs in existing specs that I had
missed. The bottom line to me is if we want to collaborate on the code
base we need to talk about changes. We did talk about Anneline merging
the accreditation branch to the core. We did not talk about other code
changes. I don't want to be critical of the effort so far, I just want
to encourage more communication.

--=20
Roch=E9 Compaan
Upfront Systems                 http://www.upfrontsystems.co.za