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 -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) 250-505-6117 Jigme Datse Yli-Rasku PO Box 270 Rossland, BC V0G 1Y0 Canada ....................................................................... ... 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 reports.http://sdm.link/zohodev2dev
_______________________________________________ Ledger-smb-devel mailing list ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel