- devel - lists.freelock.com

customizations
by R. Ransbottom 27 Aug '17

27 Aug '17

Hello. Sorry to be away. Various infections and physical traumas have left me doing only the basics for about seven weeks. That seems to be passing. Re: 1.5.9 What are recommendations for customizing and adding tables (and all that follows)? Tools? Naming conventions? etc. For parts, adding about 25 fields and 4 constraining tables similar to salutations. Lesser invasions to vendors and customer data. Suggestions and references will also be appreciated. Thanks, Rob

1 0

When to factor out code into a stand-alone CPAN release?
by Erik Huelsmann 27 Aug '17

27 Aug '17

Hi, In a recent issue, Chris proposed to factor out part of the code base into a stand-alone CPAN release (which would IMO mean into a more-or-less stand alone project). The same happened some years ago when he factored out DBObject into PGObject, so, we have precedence here. The other way around (refactored our code to use releases from CPAN) has happened as well. >From my perspective, the reasons to refactor our code to make use of (pre-existing) CPAN code are clear: * Using pre-existing code from CPAN outsources maintenance (to an external maintainer) * Opens up opportunities for wider use in our own code base, because usually replaces specific with generic code * Ensures better testing of code in a wide variety of settings (hopefully with bugfixes) * Improves code-sharing in the wider Perl community (hopefully free-ing up resources to take Perl and its modules a step further) To me, the other way around would roughly work the same way. Meaning, that we should be thinking about placing our code on CPAN, if: * Our code is sufficiently generic to solve problems for others * Others can depend on us to do the maintenance of the code * Our code comes with sufficient quality assurance measures to be helpful to others * Our code is sufficiently stable not to require large refactorings to the projects (which would mean that people can't really depend on the code - yet) Especially the last point - I think - is tricky: when largish refactorings are in order, the fact that part of the code being refactored is loaded onto Travis CI through CPAN is a major limitation on the speed that can be had during the refactoring. The recent PGObject 1.x->PGObject 2.x refactoring showed that. I'm wondering: Is there anything else to be considered? (Reasons to factor out, problems to be met after having separated, etc...) Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 2

ledgersmb project owned repository naming
by David G 26 Aug '17

26 Aug '17

Hi, Currently we have 30 repositories in the LedgerSMB github project. over half of them are related to PGObject modules and are reasonably named in the form of PGObject-foo-bar However, not all of our repositories are named so sensibly. In particular we now have 4 "packaging" repositories - pkg-ledgersmb - pkg-ledgersmb-1.4 - pkg-ledgersmb-1.5 - lsmb-overlay From the names, it's obscure at best which distro etc each of those repositories is for, more confusing is the fact that the first 3 seem to be duplicates of each other, excepting for the fact that they target different releases of our code. The first 3 are for debian packages, while the fourth is the new repo Chris has added for gentoo packaging. To help with "discoverability" and generally make it more obvious what a repo is for, I'd propose a naming scheme along the following lines. $purpose-$project-$detail For true "project" repositories such as LedgerSMB, and PGObject projects $purpose may not make sense, but for others it likely does. Some examples - LedgerSMB - PGObject - PGObject-Type-DateTime - pkg-debian-LedgerSMB - pkg-gentoo-LedgerSMB - migration_test_data-LedgerSMB - docker-LedgerSMB - docker-LedgerSMB-selenium-grid - OPOS-LedgerSMB-integration - LedgerSMB-PHP-bindings I think it's probably early enough in the lifecycle of most of the repositories that could do with renaming to rename them now. I say that as the ones that would change have little use outside of our project controlled resources. As for having the pkg-ledgersmb-1.x repositories as well as the unversioned one, Unless Jame has a reason to do otherwise, I'd suggest we simply use tags in the pkg-ledgersmb repo instead. Consider the situation if we ended up with packaging repos for every different distro, and also every release series we do in the future, things would quickly become unmanageable

2 2

Fwd: ledgersmb project owned repository naming
by Robert J. Clay 26 Aug '17

26 Aug '17

Sorry, forgot to send to the mailing list as well... ---------- Forwarded message ---------- From: Robert J. Clay <rjclay(a)gmail.com> Date: Sat, Aug 26, 2017 at 2:30 PM Subject: Re: [ledgersmb-devel] ledgersmb project owned repository naming To: David Godfrey <info(a)sbts.com.au> David, On Sat, Aug 26, 2017 at 6:43 AM, David Godfrey <info(a)sbts.com.au> wrote: > Currently we have 30 repositories in the LedgerSMB github project. > over half of them are related to PGObject modules and are reasonably named > in the form of > PGObject-foo-bar > > However, not all of our repositories are named so sensibly. > > In particular we now have 4 "packaging" repositories > .... > - lsmb-overlay > > ...., while the fourth is the new repo Chris has added for gentoo packaging. For an 'ebuild' for Gentoo, which is not quite the same thing... (A "package" for gentoo looks to be just an application source archive, which an 'ebuild' for that app uses to build and install the application as necessary.) > Some examples .... > - pkg-gentoo-LedgerSMB An "overlay" is not a package it's an ebuild and having the word "overlay' in the repo name for them is very commonly related to Gentoo. (Or so it seems to be judging from a search on GitHub...) -- Robert J. Clay rjclay(a)gmail.com -- Robert J. Clay rjclay(a)gmail.com

1 0

Cleaner tree for UI/ ?
by Erik Huelsmann 26 Aug '17

26 Aug '17

Hi, Since we moved to being a single-page app on the main app, I'm looking to improve clarity in the UI/ tree. What's the problem? I see a number of things being unclear: * Out of all the files stored in UI/, only these are actual "top level" documents: - UI/login.html - UI/logout.html - UI/main.html - setup/*.html * All files, also the bits that are "html fragments" these days, include a full html start- and end-tags as well as a header definition (which are being thrown away upon receipt!) * There are non-HTML documents (ODS, XLS, CSV, ...) in that directory (which suggests that it's not solely about UI, but also about data-export/report generation) Apart from the mix of HTML documents, the directory contains assets that *are* being served: javascript/images/css/... . Should we separate the HTML fragments in order to clarify the status as being a "non-toplevel document"? Another thing: I think we should separate out the templates which have not *just* an HTML representation, meaning that they are not (primarily) UI related elements. Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

3 5

Setting a policy for our dependencies
by Erik Huelsmann 26 Aug '17

26 Aug '17

Hi, Sending this mail to the mailing list, because I think that's where we need to set our policies. I'm starting this topic because I feel like it's come up several times now and I think it's time to set a policy, with documented reasons as to why we're working the way we do. First, let me re-iterate what I think are our shared goals for LedgerSMB (as related to our choice of dependencies). We want: LedgerSMB to be easy to install, meaning * On as many platforms as possible * Allowing people to use their distro's packages as much as possible * Running first and foremost on Perl versions in most distros * Allowing for a wide range of PostgreSQL versions * Integrating (through PSGI/reverse-proxy) with people's favorate webserver Translating the above into requirements for modules we depend on, I think we want to: * Use modules which have been around for a while (to increase chances of being packaged) * Allow the widest possible version range on any module, disallowing individual malfunctioning versions to further extend the range * Require as few a possible modules in the expanded dependency tree (prefer modules as direct dependencies which are already depended on implicitly) * Not depend directly on modules which have overlapping functionalities * Not require modules which only provide nice-to-have functionality * Group feature dependencies into their respective features as much as possible (so as to not require them for a more basic installation) With respect to modules used in development, I'd like to be less strict, but only marginally so: we want it to be "simple enough" to create a development setup for LedgerSMB. Comments? Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

ledgersmb project owned repository naming
by David Godfrey 26 Aug '17

26 Aug '17

1 0

[devel] Turning off Coveralls commenting on PRs?
by Erik Huelsmann 26 Aug '17

26 Aug '17

Hi, Currently, all PRs are tested by Coveralls and Travis CI. Travis CI doesn't comment on our PRs, but Coveralls does. Initially, maybe, there wasn't a good way for Coveralls to indicate success/failure otherwise. However, since both Coveralls and Travis have the "tests in progress" section on the PR, every PR will show the latest Coveralls state right above the merge button. So, I propose we stop Coveralls from generating these comments. Anybody who does want the Coveralls notifications would need to create a coveralls account, add the LedgerSMB repo to his account and set up e-mail notification. With that, you'll receive mail notification of every Travis CI build with coverage information. If no objections by the end of Sunday, I'll modify the settings in Coveralls accordingly. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 1

Looking at building Gentoo packages
by Chris Travers 24 Aug '17

24 Aug '17

Hi; For another project I have had to learn Gentoo packaging. I think having a LedgerSMB overlay for Portage would be very helpful in attracting development effort, and I don't expect this to be a difficult one to maintain. I could probably manage to automate everything from build testing to actual builds on our releases. However, this leads to a few questions: 1. For Gentoo should we support multiple side-by-side versions (I.e. slotting with 1.4 and 1.5 occupying different slots)? If we do, should we automate having these share a starman instance? 2. My plan is to add the CPAN dependencies unspotted and assume they may be shared. 3. From here I plan to talk with a Gentoo maintainer to see if we can get the overlap to have some sort of official status and made available out of the box by the tool layman. Any thoughts or objections? -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more

1 0

Re: [ledgersmb-devel] Primary key for tables "eca_to_contact", "entity_to_contact", "entity_bank_account"
by David G 23 Aug '17

23 Aug '17

Your proposed change looks good to me. Sent from my Samsung Galaxy Note 4 on the Telstra Mobile network -------- Original message -------- From: Erik Huelsmann <ehuels(a)gmail.com> Date: 23/08/2017 05:22 (GMT+08:00) To: devel(a)lists.ledgersmb.org Subject: [ledgersmb-devel] Primary key for tables "eca_to_contact", "entity_to_contact", "entity_bank_account" Hi, While working on some of the 1.5.10-planned fixes, I'm running into the problem that the three tables in the subject have primary keys which contain non-numeric data. More specifically, in case of the bank account data, the pkey contains the bic and account number and in case of the contact data, the pkey contains a user-description of the contact item in the pkey (together with a class). Knowing about the privacy protection regulations in the EU, I think that having the bic+iban in the pkey of a table which is to describe that data isn't practical (both because it already exposes the primary data through the pkey and because it exposes heavily sensitive data to all tables which want to enable looking this data up. For the contact table, things are a bit different: I'm thinking that having an (editable) user description in the pkey simply isn't a great idea. Proposed way forward: All three tables get a serial "id" column, which is made the PKEY, where we can opt to make a UNIQUE index out of the columns which currently determine the PKEY. Comments? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP.Robust and Flexible. No vendor lock-in.

1 0