Re: [Ledger-smb-devel] Improving Documentation of support scripts

[Robert James Clay]

On Wednesday, December 30, 2015 02:16:34 PM David G wrote:
> Hi,
> 
> A while ago Erik and I were discussing the need to better document the
> various scripts and files that are not directly part of the LedgerSMB code.

   That also brings to mind; do we have any requirement or 'best practice'  to 
have copyright/license information explicitly in the scripts, etc?


> An alternative would be to require every script to provide a number of
> command line options. 
> The arguments I propose all executables (scripts and binaries) support are

>  * --help   displays a Usage Summary followed by more detail if
> required.

   Agreed...


> * --readme   displays a markdown formatted chunck containing
> script description an usage summary

   I can see possible issues where there are more documentation lines than 
code lines but that's not necessarily a bad thing and one can always just make 
sure that the '--help' option is markdown safe and use that for the '--readme' 
option as well. 
   

> * --version  reports the script version in "scriptname v1.0.0" format

Sometimes it doesn't have an explicit version number like that, but OTOH 
it can just display whatever it does use.


And this reminds me that a bash script that I have the Debian package install 
to the tools/ directory ('config-lsmb-db-user.sh'; used to configure the 
LedgerSMB DB admin user) needs to have such information added to it.





Jame





--
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] LedgerSMB 1.4.22 released

[Erik Huelsmann]

The LedgerSMB development team is happy to announce yet another new
version of its open source ERP and accounting application. This release
contains the following fixes and improvements:


Changelog for 1.4.22
* Fixed balance sheet language selection (Erik H)
* Fixed column headings translated in report language (Erik H)
* Fixed add report styling for financial reports PDF (Erik H, GH1080)
* Enhanced all accounts can be selected in trial balance (Erik H, GH1107)
* Fixed syntax errors in ms_MY.po and de.po (Erik H)
* Fixed translatable string detection (Erik H)
* Updated translation (source) files (Erik H)
* Integrated Transifex (transifex.com) translation process (Erik H)
  Note: To start helping to translate LedgerSMB, check out
 http://ledgersmb.org/community-guide/community-guide/translating

Erik H is Erik Huelsmann


The release can be downloaded from sourceforge at
  https://sourceforge.net/projects/ledger-smb/files/Releases/1.4.22/

These are the sha256 checksums of the uploaded files:

These are the sha256 checksums of the uploaded files:
130cd4e41e34db1edfe0faf51887ddf088f7af0a43a6f390f9d65605a01a2dd8  
ledgersmb-1.4.22.tar.gz
048a14c420ba1485882ea7b3103462e9bd2e2490dd1f4a726e129fc5105d8866  
ledgersmb-1.4.22.tar.gz.asc


--
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Copyright Dates

[Erik Huelsmann]

Hi David,

Good point; I haven't updated the copyright dates on any of the files that
I changed in 2015 (or 2014, for that matter, probably).

There is controversy over the desirability of this though; the FSF requires
it, but Danial Berlin, a (former) committer at Subversion *and* a lawyer,
says on the Subversion developers list that it's better *not* to have them.
(See http://svn.haxx.se/dev/archive-2015-03/0317.shtml or
http://svn.haxx.se/dev/archive-2015-03/#271 for the entire thread.)

Also note that copyright doesn't "work" on a per-file level, rather it
works for the Work as a whole (which defeats the purpose of having a
copyright per file).

Personally, I'd love to have the copyright year(s) in a few easy-to-update
files instead of everywhere in our source tree.


@Devs:
I think this is a question to our general entire developers community: Can
we have a simplified reference per-file which directs the reader to the
LICENSE file for the full copyright statement?


Regards,


Erik.


On Fri, Jan 1, 2016 at 3:00 AM, David G  wrote:

> Just reminding people since the year's ticked over yet again, don't forget
> to update copyright dates when you modify a file. It's a book-keeping task
> that's easy to overlook.
>
> Regards
> David G
>
>
> --
> ___
> Ledger-smb-devel mailing list
> Ledger-smb-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>



-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
--
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] String translation in setup.pl?

[Erik Huelsmann]

> At the moment I'm evaluating our translation experience and one thing I'm
> finding is that we've marked all strings for translation in setup.pl and
> dependent code (notably Upgrade_Tests.pm).
>
> However, there's no possibility to select another language than the
> default language in setup.pl, unless we start parsing the HTTP
> Accept-Language heading. [The same could be said for the front-page --
> login.pl.]
>
> What's the next step? Do we remove the translations from the lexicon, or
> do we parse the Accept-Language header and fall back to that when there's
> no user detected?
>

In IRC (irc://chat.freenode.net/ledgersmb), we went over the various
options here, leading to the creation of an issue to record the outcome in
order to help anyone picking up this task.

We came to the conclusion we want the language to be determined in this
order (first to last):

1. Take the language value from a query string "lang" parameter
2. Use the user's configured language preference when logged in *and* the
user saved a language pref
3. Use a LedgerSMB server-wide configured language, if one is configured
(default: no config)
4. Use the request's "Accept-Language" header, if present
5. Fall back to the built-in language ('en')


This is also recorded in issue #1187 (
https://github.com/ledgersmb/LedgerSMB/issues/1187)

-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
--
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] 1.5.0-beta4 over due / consequences for RC1?

[Erik Huelsmann]

Hi,

The 1.5.0-rc1 milestone is set for the middle of January,  with the last
beta to be released by the end of December last year.

Obviously, we didn't make the deadline for last year :-) There are still 3
bugs open that are marked 'blocking', after I triaged some to be solved by
RC1 and others even later.

With these 3 bugs still open (1 documentation, 2 real code changes, one of
which I think even needs a bit of design), I'm wondering: should we
reschedule the release of 1.5.0-RC1? If so, by how many days/weeks? Or
should we defer the Sqitch-like (or really sqitch) idea to 1.6 and just
solve the documentation issue and the broken Salary screens?

Regards,

-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
--
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Cleaning up the repository. How does the community feel about it?

[John Locke]

Hi,

On 01/01/2016 09:57 AM, Erik Huelsmann wrote:



On Fri, Jan 1, 2016 at 6:45 PM, Robert James Clay > wrote:


On Thursday, December 31, 2015 09:50:59 AM David G wrote:
>
> It is worth pointing out that it is undesirable to use an OS
package to
> provide dojo as there are known to be issues from minor release
to minor
> release that would break LedgerSMB.

  What are those issues and how do they break LedgerSMB? That is; 
how is that

being tested and what does that find?  And why are those minor
releases"  being
used, if they cause such issues?

John says he has experience that there are slight incompatibilities 
between versions 1.7, 1.8, ...  and that very careful testing is 
required to be sure your code remains working. Assuming that's true, I 
can be nothing but extremely disappointed about the development 
processes used.
One of the questions that come to mind though is: how do they keep 
their own stuff working if the various versions break expectations? It 
seems some widgets haven't been changed since the early days of Dojo. 
Surely those would be broken now if this goes on too long?


So I actually have not even used 1.9 or 1.10, my experience is based on 
moving from 1.2 to 1.3, to 1.5, to 1.7... every time we upgraded our 
single-page app, stuff broke and needed to get rewritten.


The stuff that broke were largely custom widgets we wrote, using 
underlying Dojo classes for widgets and templates -- they kept 
refactoring these and changing the API in subtle ways that broke our 
custom code.


For LSMB this might not be much of an issue -- yet. At least not before 
LSMB 1.5. But 1.5 relies upon Dojo far more than any previous version 
(is it even in 1.3? And for 1.4, it's only used for simple form elements 
and some layout stuff in the Contacts area -- I don't think we've built 
any actual custom complex widgets).


It's certainly possible that things have shaken out and gotten more 
stable -- as it is the jump from Dojo 1.5 to 1.7 (which introduced AMD) 
was so great we still have not completely upgraded our internal app, and 
are still using 1.5.


And then also realize that there's no server-side testing that would 
reveal a problem with Dojo -- it's purely client-side. So testing it 
properly is largely visual regression testing, stuff on top of 
Selenium/PhantomJS or similar, or using writing tests for Dojo's own 
test runner, DOH (if that's still around... looks like they now promote 
"intern" which looks interesting...)


Dojo does have its own test suite. But the problem I've experienced with 
Dojo upgrades is in its base widget classes (dijit/_Templated, 
dijit/_Widget, etc) which have changed far more than you would think 
should be acceptable within a minor release. If we're not extending 
those, then we're not affected -- yet. But the ability to extend those 
to have smart widgets is the main reason I was advocating for Dojo in 
the first place, over simpler widget systems like jquery.ui and the like.


And as previously noted, I have not experienced any issues with updating 
a patch release within the same minor version (e.g. 1.5.1 to 1.5.3), 
only between the minor versions (1.5 to 1.7). And Dojo itself is still 
releasing patch releases for 1.5 -- if they expected everyone could 
upgrade easily, they would not still be issuing patches for 1.4



Remember that JS libraries don't need to only consider what else is on 
the Linux server -- it's something that needs to support all major 
browsers on all operating systems. Microsoft Edge, IE11, IE10, Safari, 
Chrome, Firefox on Windows, Mac, Linux, Android, iOS, ChromeOS, etc. As 
Javascript itself evolves into ECMAScript 6, with greatly varying 
degrees of OS support, JS libraries need to evolve and change much 
faster than probably any other package on a Linux server. And HTML5 was 
in its infancy 5 years ago -- we were still mostly doing XHTML. And 
unfortunately, sometimes JS libraries have functions that get turned 
into reserved words in newer JS version or particular browsers... jQuery 
has the same issues with upgrading between minor version releases.


Can you point me to any major web application that actually depends upon 
the Debian dojo or jquery packages, instead of bundling the exact 
version they have fully tested? What I see using apt-rdepends are a 
bunch of local applications -- so many desktop toolkits work with 
Javascript, it makes sense to use a system JS library for a desktop app. 
Not for a web app with a huge range of other targets... Drupal and 
WordPress both have Debian packages, and both ship/use jQuery... and do 
not require or reference the Debian libjs-jquery (or any other jquery) 
package.


Cheers,
John
--
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net