Note that due to illness; although I updated our 'ledgersmb-1.6' pkg for v1.6.10 I haven't yet updated the 'ledgersmb' pkg for that version so what's in Debian Testing is still only v1.6.9. And since the hard freeze in preparation for the Debian release of Buster as the new stable has gone active, there is no more auto migration to Testing for updated packages in Debian unstable until after the new version has been released. Besides still waiting for the last 3 debconf translations so that the pkg can be updated with them, I've also been thinking about a major change in the package; that being changing it so that it uses the dojo distributed in the LedgerSMB archive instead of that in Debian like is already being done with our 'ledgersmb-1.6' package, on the basis that the version in Debian is not the same as that actually being used by the app itself. There's not that much of a dojo related version difference with what LedgerSMB 1.6 uses (Debian testing has v1.14.2) but that's not the case for LSMB 1.7 so it's something I need to look at in any case. A ledgersmb package with major changes could always be uploaded to Debian Experimental (& our package repos, of course), so that's what I'll be looking at doing if necessary. Related to that is still getting the autopkgtest functionality done for the package. That (which does 'as installed' testing) is useful I think in any case but in particular having to do related to the different dojo versions. But that is based on my thinking that the JS code is actually being at least somewhat exercised in the 't/' and or 'xt/' testing, which I was wondering about due to something one the other devs said/ but which I've been assured that the JS code is being exercised in the bdd tests in xt/. So I figure to work on getting the t/ tests working for the autopkgtest to start off with and continue from there to the xt/ tests. Any comments/questions/etc, please let know. -- Robert J. Clay jame@rocasa.us rjclay@gmail.com
On 3/23/19 7:45 PM, Robert J. Clay wrote:
Note that due to illness; although I updated our 'ledgersmb-1.6' pkg for v1.6.10 I haven't yet updated the 'ledgersmb' pkg for that version so what's in Debian Testing is still only v1.6.9. And since the hard freeze in preparation for the Debian release of Buster as the new stable has gone active, there is no more auto migration to Testing for updated packages in Debian unstable until after the new version has been released.
Besides still waiting for the last 3 debconf translations so that the pkg can be updated with them, I've also been thinking about a major change in the package; that being changing it so that it uses the dojo distributed in the LedgerSMB archive instead of that in Debian like is already being done with our 'ledgersmb-1.6' package, on the basis that the version in Debian is not the same as that actually being used by the app itself.
There's not that much of a dojo related version difference with what LedgerSMB 1.6 uses (Debian testing has v1.14.2) but that's not the case for LSMB 1.7 so it's something I need to look at in any case.
Actually I don't think that is a good idea. The release cycle starts again after buster is ready, and there is enough time to get dojo in sync with what is in LedgerSMB. Also it is the general policy in Debian to use the available packaged version instead of including it in the application package. This is for various good reasons (maintenance, security, package size, ...). Regards Racke
A ledgersmb package with major changes could always be uploaded to Debian Experimental (& our package repos, of course), so that's what I'll be looking at doing if necessary.
Related to that is still getting the autopkgtest functionality done for the package. That (which does 'as installed' testing) is useful I think in any case but in particular having to do related to the different dojo versions. But that is based on my thinking that the JS code is actually being at least somewhat exercised in the 't/' and or 'xt/' testing, which I was wondering about due to something one the other devs said/ but which I've been assured that the JS code is being exercised in the bdd tests in xt/. So I figure to work on getting the t/ tests working for the autopkgtest to start off with and continue from there to the xt/ tests.
Any comments/questions/etc, please let know.
-- Ecommerce and Linux consulting + Perl and web application programming. Debian and Sympa administration. Provisioning with Ansible.
On Mon, Mar 25, 2019 at 5:27 AM Stefan Hornburg (Racke) <racke@linuxia.de> wrote:
On 3/23/19 7:45 PM, Robert J. Clay wrote:
.... I've also been thinking about a major change in the package; that being changing it so that it uses the dojo distributed in the LedgerSMB archive instead of that in Debian like is already being done with our 'ledgersmb-1.6' package, on the basis that the version in Debian is not the same as that actually being used by the app itself.
There's not that much of a dojo related version difference with what LedgerSMB 1.6 uses (Debian testing has v1.14.2) but that's not the case for LSMB 1.7 so it's something I need to look at in any case.
Actually I don't think that is a good idea. The release cycle starts again after buster is ready, and there is enough time to get dojo in sync with what is in LedgerSMB.
Or at least, with the dojo toolkit itself. A reason why LSMB includes it is because that version can get of sync, pariticularly with released LSMB versions, which track the major/minor version of dojo from at the time that the LSMB version was released.but might get the patch level version number sync'ed occasionally. (This is done using sub-modules in the LSMB code repository against the dojo code repository.)
Also it is the general policy in Debian to use the available packaged version instead of including it in the application package. This is for various good reasons (maintenance, security, package size, ...).
Yes, I know; it's why I changed the 'ledgersmb' pkg to use the Debian dojo pkgs when LSMB started using dojo 3 years ago. I also know that the policy [1] is a 'should' not a 'must'. OTOH; I don't yet know how much, if any, the version difference might actually make. Especially over a patch level difference like that between 1.14.2 & 1.14.3. Which likely means that I should really focus first on gettting the 'ledgersmb' pkg working with autopkgtest. -- Robert J. Clay rjclay@gmail.com jame@rocasa.us [1] https://www.debian.org/doc/debian-policy/ch-source.html#convenience-copies-o...
Hi Robert, Stefan, On Tue, Mar 26, 2019 at 3:37 PM Robert J. Clay <rjclay@gmail.com> wrote:
There's not that much of a dojo related version difference with what LedgerSMB 1.6 uses (Debian testing has v1.14.2) but that's not the case for LSMB 1.7 so it's something I need to look at in any case.
Actually, as I read that sentence, you're saying that LedgerSMB 1.7 doesn't use Dojo 1.14.2 (and depending on how you read it, that LedgerSMB 1.6 does). However, that's incorrect: It's LedgerSMB 1.7 (which isn't currently in Debian Testing/Buster) uses 1.14.2, but LedgerSMB 1.6 - which *is* in Testing - uses Dojo 1.13. To be honest, I see that Dojo 1.15.0 has been released and I'll likely at least switch master over to that. (I think it's too close to the 1.7 release to change the Dojo library version right now.)
Actually I don't think that is a good idea. The release cycle starts
again after buster is ready, and there is enough time to get dojo in sync with what is in LedgerSMB.
Well, the problem is that in the past I've seen different versions of 1.x Dojo requiring adjustments in our code base to support Dojo version upgrades or downgrades. As a result, we advise to run LedgerSMB against the Dojo version it comes with, or optionally any other patch-level version, but *not* any other minor-level version, not even when that version is higher than the minimum required.
Or at least, with the dojo toolkit itself. A reason why LSMB includes it is because that version can get of sync, pariticularly with released LSMB versions, which track the major/minor version of dojo from at the time that the LSMB version was released.but might get the patch level version number sync'ed occasionally. (This is done using sub-modules in the LSMB code repository against the dojo code repository.)
Yes. Patch-level version differences are ok, although I've seen patch-level releases break functionality LedgerSMB depends on (unintentionally, with follow-up patch level releases fixing it again). All in all, the Dojo release being used seems somewhat fragile and needs thorough testing before the combination is geing changed.
Also it is the general policy in Debian to
use the available packaged version instead of including it in the application package. This is for various good reasons (maintenance, security, package size, ...).
Yes, I know; it's why I changed the 'ledgersmb' pkg to use the Debian dojo pkgs when LSMB started using dojo 3 years ago. I also know that the policy [1] is a 'should' not a 'must'. OTOH; I don't yet know how much, if any, the version difference might actually make. Especially over a patch level difference like that between 1.14.2 & 1.14.3. Which likely means that I should really focus first on gettting the 'ledgersmb' pkg working with autopkgtest.
The difference in lines of code between 1.14.0 and 1.14.1 was pretty small, but it did mean broken file-uploads in LedgerSMB on Safari. Yes, getting the package build working with automated testing seems like a great way to do the required quality assurance needed to make sure another Dojo version can be used with LedgerSMB than the one that comes with the tar archive. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
participants (3)
-
Erik Huelsmann -
Robert J. Clay -
Stefan Hornburg (Racke)