Re: [Ledger-smb-devel] Proposal for 1.6 and above: small new-code-only developer release

[Jigme Datse Yli-Rasku]

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"
does.

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 

Re: [Ledger-smb-devel] Proposal for 1.6 and above: small new-code-only developer release

[Chris Travers]

Hi;

On Fri, Jul 15, 2016 at 11:16 AM, Erik Huelsmann  wrote:

> Hi Chris,
>
>
>
>> 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.
>>
>
> Thanks for bringing this up! It also very much relates (IMO) to the thread
> I started some time ago about a next-10-years vision (
> http://archive.ledgersmb.org/ledger-smb-devel/msg06409.html).
>
> As we talked a bit about it between us, you know I have my concerns,
> detailed below. Let me start by stressing I think it's important to hear
> from others what their opinion is, because these are just *my* concerns;
> others may think very differently and I'd like to know about those opinions.
>
> There's a rather fundamental question to be asked here, if you bring  up
> the "on boarding of other developers", which might come down to a  "chicken
> and egg problem": should we expect more developers to be joining the team?
> I mean, is there a group of developers out there that we expect to be able
> and willing to contribute to our accounting application?
> It just so might happen to be that (apart from the fact that we were lucky
> to have 2 in the first 6 months of the year), there are extremely few devs
> who would love to work on LedgerSMB (or any other web-erp) instead of some
> hyped app.
>
> And if such a group of developers were to exist, what would stir their
> interest in LedgerSMB instead of in, say, Odoo? Wouldn't having something
> that *almost* works be a better choice for a business to run their
> operations on? And from there, contribute to the further development of the
> application.
>

Well, ideally we have something that works flawlessly for one thing and
pretty close to working for the next.

Also I think it would be easier, not harder, to get a good user experience
if we have a few solid pieces first as well.

>
> 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.
>>
>
> I can see how that would an absolute relief :-) However, do we think we
> can attract new developers with it? I mean, looking at yourself: would you
> join a team with the perfect code base, even though you can't really use
> the product yet? Or would you join a team where you can use the product,
> but simply want it improved, because the code base has real problems?
>

To be honest, my thinking is that when we get the AR and AP transactions
ported over, thats when I think we will get new developers.  But I think
there may be a few users that could really use a dedicated GL app that
interfaces nicely with other systems.


>
> Just to answer that question for myself: I needed an accounting
> application, was already running SL and wanted to get off that, when I
> joined the team here. I guess I fall in the latter category.
>
> 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.
>>
>
> How much effort would you estimate this to be? I mean, the initial
> creation of such a release? I'm finding we're thin on resources as it is
> and the above sounds like spreading them even thinner.
>


I don't expect it to be a lot of effort long-run because effectively we are
talking about a subset fo the application with its own test runs etc.

That being said, i wonder if it would be better to phrase this as:

Assuming someone finds this worth doing, is this something we want to
support as a project?  One thing I have learned is that volunteering other
people's time in open source is really not a good idea.


> Just to note: if you don't want old code in the code base, then if you
> take today's code base, you have to remove AR/AP/Timecards/Orders/RFQs;
> basically you'd even have to remove the GL entry code, but that's easily
> replaced with something more modern, I guess :-)
> So, that would leave us with *only* GL entry and GL reports?
>

My thinking is:
1.  GL entry, reports, and financial statements to start (the financial
statements would have to be ported, or some of the old db structures left
in for compatibility - I am not actually adverse to initially just
including the whole same db schema for ease of migration and management).
2.  We could, optionally, include contact management though then that
starts to feel like two different applications


> From a 

Re: [Ledger-smb-devel] Proposal for 1.6 and above: small new-code-only developer release

[John Locke]

Hi,

On 07/15/2016 02:16 AM, Erik Huelsmann wrote:

Hi Chris,

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.


Thanks for bringing this up! It also very much relates (IMO) to the 
thread I started some time ago about a next-10-years vision 
(http://archive.ledgersmb.org/ledger-smb-devel/msg06409.html).


Not entirely opposed to the idea, but I think the focus should be on the 
overall system design -- don't want to get sucked into too much 
module-by-module rewriting.



I'm thinking we should be focused on three key design areas:

- What is the desired user experience we want to have? The BDD tests are 
crucial for this, and we should develop those before doing any forking 
into parallel branches.


- What sort of API can we put in place to act as a contract between the 
user experience, any external integrations, and the back end?


- Do we have the best underlying data schema in place going forward? 
(E.g. the multi-currency stuff that Erik has created -- are there any 
other ways our current schema limits what LSMB can do effectively?)



I think a strong focus on these 3 key areas will make our project 
progress based on a much more cohesive intention, rather than fighting 
fires/bugs/fixing things as they arise and doing battle with the old code...


I would like to see us develop these 3 things first, define what we want 
the system to do and how we want it to behave -- and try to wrap as much 
of the old code in as possible. I do expect we may hit some big 
roadblocks in some parts of the code that are just not possible to wrap 
or fix without rewriting -- but how many of these have you already blown 
through and rewritten? I suspect with proper design, it may be possible 
to rewrite the implementation much more quickly, making the new code 
work the way it should work, and not just a better version of a crap design.




There's a rather fundamental question to be asked here, if you bring  
up the "on boarding of other developers", which might come down to a  
"chicken and egg problem": should we expect more developers to be 
joining the team? I mean, is there a group of developers out there 
that we expect to be able and willing to contribute to our accounting 
application?
It just so might happen to be that (apart from the fact that we were 
lucky to have 2 in the first 6 months of the year), there are 
extremely few devs who would love to work on LedgerSMB (or any other 
web-erp) instead of some hyped app.


I don't think we need to focus on onboarding other developers. I do 
think we should start more marketing. I think the work Erik has been 
doing on BDD is fantastic, and if we start talking about it more, we're 
sure to attract other developers. And if we have a solid API and BDD 
framework, I think it will be easier to solicit contributions from new 
developers...




And if such a group of developers were to exist, what would stir their 
interest in LedgerSMB instead of in, say, Odoo? Wouldn't having 
something that *almost* works be a better choice for a business to run 
their operations on? And from there, contribute to the further 
development of the application.




Totally agree here -- having something that mostly works and a bunch of 
companies using it, and evolving that to better tested, more reliable 
code is a big win. While I do think it's a good idea to start a fresh 
branch with only working code, that also becomes a huge barrier to 
contribution if nobody is using that code in production. It becomes such 
a massive undertaking with really far-off payoff.


I mean, I would love if somebody would do this work -- AFTER we know 
what it should look like, with as much of the new design dropped into 
the currently working version as possible. As long as it got done at 
sometime useful, and didn't happen at the expense of having a working 
production version.




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.


I can see how that would an absolute relief :-) However, do we think 
we can attract new developers with it? I mean, looking at yourself: 
would you join a team with the perfect code base, even though you 
can't really use the product yet? Or would you join a team where you 
can use the product, but simply want it improved, because the code 
base has real problems?


Maybe we can put new API/interfaces in as stubs, build out the whole 
design in the current release? Throw "unimplemented" exceptions where 
the new code isn't built yet, build the 

Re: [Ledger-smb-devel] Proposal for 1.6 and above: small new-code-only developer release

[Erik Huelsmann]

Hi Chris,



> 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.
>

Thanks for bringing this up! It also very much relates (IMO) to the thread
I started some time ago about a next-10-years vision (
http://archive.ledgersmb.org/ledger-smb-devel/msg06409.html).

As we talked a bit about it between us, you know I have my concerns,
detailed below. Let me start by stressing I think it's important to hear
from others what their opinion is, because these are just *my* concerns;
others may think very differently and I'd like to know about those opinions.

There's a rather fundamental question to be asked here, if you bring  up
the "on boarding of other developers", which might come down to a  "chicken
and egg problem": should we expect more developers to be joining the team?
I mean, is there a group of developers out there that we expect to be able
and willing to contribute to our accounting application?
It just so might happen to be that (apart from the fact that we were lucky
to have 2 in the first 6 months of the year), there are extremely few devs
who would love to work on LedgerSMB (or any other web-erp) instead of some
hyped app.

And if such a group of developers were to exist, what would stir their
interest in LedgerSMB instead of in, say, Odoo? Wouldn't having something
that *almost* works be a better choice for a business to run their
operations on? And from there, contribute to the further development of the
application.

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.
>

I can see how that would an absolute relief :-) However, do we think we can
attract new developers with it? I mean, looking at yourself: would you join
a team with the perfect code base, even though you can't really use the
product yet? Or would you join a team where you can use the product, but
simply want it improved, because the code base has real problems?

Just to answer that question for myself: I needed an accounting
application, was already running SL and wanted to get off that, when I
joined the team here. I guess I fall in the latter category.

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.
>

How much effort would you estimate this to be? I mean, the initial creation
of such a release? I'm finding we're thin on resources as it is and the
above sounds like spreading them even thinner.
Just to note: if you don't want old code in the code base, then if you take
today's code base, you have to remove AR/AP/Timecards/Orders/RFQs;
basically you'd even have to remove the GL entry code, but that's easily
replaced with something more modern, I guess :-)
So, that would leave us with *only* GL entry and GL reports?
>From a user-perspective: what would a user (potential contributor) gain by
installing this version over the version which *does* have the old code,
where this user simply does not use it?

Basically, from a development point of view, I've taken exactly this
approach, btw: I've been working around the old code, putting a foundation
in place which can replace the old code after we rip it out, without ever
needing to touch the old code. In that sense, the existence of the old code
in the code base hasn't bothered me much over the past year, other than
that I have had to fix bugs in our old code, because people were running
into problems.

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.
>
> What do people think of this idea?
>

While I still want to know what others think, I personally see more in the
direction that we've been working on over the past 2 years:

 - Have good tools in place to assess UI stability
 - Replace the UI with a Dojo UI
 - Replace the supporting backend code with web-services

Because that way, we can offer our existing users a stable application and
a stable migration path. For new users, we'll become more-and-more
interesting as the web-services backend opens up the development of