26 Aug
2017
26 Aug
'17
4:45 p.m.
Hi,
Although CPAN can be seen as a distribution mean, I do not think that we
fit there.
For me, their purpose is mostly to distribute packages and libraries
used to fit in a larger application and that ain't LedgerSMB, although
one could argue that it would fit in a suite of business applications.
We should use a consistent set of CPAN/distro packages as much as
possible to ensure quality, outsource maintenance and to free ourselves
from specific versions and distributions.
But at the end, we will remain a business application, focused on a very
specific need.
Yves
Le 2017-08-26 à 12:06:14, Erik Huelsmann a écrit :
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 <http://efficito.com/> -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
_______________________________________________
devel mailing list
devel(a)lists.ledgersmb.org
https://lists.ledgersmb.org/mailman/listinfo/devel