[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal for 1.6 and above: small new-code-only developer release

On 2016-07-14 21:46, Chris Travers wrote:
> Hi;
> I was talking with Kaare yesterday and we were looking at the structure
> of the old code and the question came up "why don't you throw it out and
> start from scratch?"  Obviously we haven't been in a position to do this
> because of a need to support existing users, but I was starting to think
> about this again as a result of his question.

This is a question which comes up fairly often I think.  There are a
number of questions in response to that that I think are worth coming up
with answers to:

* Does it seem like some form of usable package can be formed when you
end up throwing out all "old code" right now?
* Are you looking at creating two sub projects (which might in the
future be merged into a single project again)?
* What are your main goals in throwing out all the "old code which we
haven't been able to replace"?

Just a few off the top of my head.

> One of the difficulties we have had for a while is the ability for new
> developers to come in and contribute, in part because of the code
> quality of the older code layers (most particularly the SQL Ledger
> codebase but also our earlier work)  One possibility would be to
> establish a parallel release that would only be new code.  One reason we
> haven't done that is that right now, if we did this, we couldn't meet
> anyone's needs.

This seems to be looking at the first two questions:

* There may be a possibility for a somewhat usable (but not full
featured) product with just new code in it.
* This will be a parallel release, thus development on current code base
would continue with the possible goal of merging the two projects, as
the functionality (and probably code) become closer to the same.

That raises a question of:

* Do we currently have enough energy that this splitting of the project
would allow both to successfully move forward.

> But I was thinking.  With the current work regarding GL, maybe in 1.6 we
> could start with a parallel release which would include only fully
> re-engineered code.  In particular this would mean:
> 1  A more consistent set of dependencies
> 2. A more consistent codebase
> 3. Something we could point developers to and say "here is where you start."
> 4. Since the goal would be to get everyone on this version sooner or
> later, it would mean that this could prioritize next steps and
> functionality to move.

This seems to answer the question of "what are the goals".  These seem
to be pretty reasonable.  But again it leads back to the question of if
the current energy is there, and if we actually could be looking at more
or less bringing this parallel project up as the code develops for this.

That would be, would someone like me, who is looking at parts.pl
throwing an error in 1.5, be able to find a way to dig into something
which would be able to bring that to the new codebase, along with fixing
the issue in the existing codebase?

> The biggest problem I see is that 1.6 would feature a very minimal
> application of this sort.  Basically gl and financial reports only. 
> Maybe we could get contact management in but it woudn't be connected to
> anything.   A goal could then be to get ar/ap transactions (i.e. service
> invoices by amount only) in by 1.7, and then start on parts, orders and
> invoices after that.

I think that this would be a reasonable start of an application to begin
with.  If we have the contact management code, I think it would be worth
bringing that up, even if it only is (at this time) contact management,
as it gives a key part of the invoice creation process.

> What do people think of this idea?

I like this idea.  Though I am not sure that the application that we can
create with "new code" would be attractive to very many people at this
point.  Though the idea of having *something* which could end up being
easier to get a new developer to actually work on, as a bit of an
incentive to give them some contact with a working product, which
doesn't end up having confusing logic as good parts of the "old code"

I guess maybe the question is, have we had someone who has wanted to
work on the project, but ended up doing nothing after having looked at
what it would take to do that, and does this even really address this?

I recently saw a post which was talking about migrating from LSMB, to
SL, for some reason.  I believe they were running LSMB 1.4, and we've
moved significantly enough away that the database migration for the
transition from LSMB to SL is essentially impossible (though someone
could potentially figure it out if they had enough of a reason to feel
it was more worthwhile to do that, then it would be to put the effort to
address the deficiencies (perceived or real), within the LSMB codebase.

I know that it is difficult to know what percentage of current users
would be potential people who would move to some part of development
with the right incentive.  I think that this may be a good question to
ask on the -user list to see if there might be people who we already
have attracted to using, who we haven't attracted to any role in terms
of development.

Jigme Datse Yli-Rasku

Jigme Datse Yli-Rasku
..hidden.. (Preferred address for new messages)

Jigme Datse Yli-Rasku
PO Box 270
Rossland, BC V0G 1Y0

... This message should be electronically signed, and if the sender ...
... has your public key, may also be encrypted.                     ...
... If you have any questions about this, please email, or call.    ...
...                                                                 ...
... Note, unknown calls likely will go to voicemail.                ...
... Please leave a message if you get voicemail.                    ...

Attachment: signature.asc
Description: OpenPGP digital signature

What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
Ledger-smb-devel mailing list