Werner,
I can certainly sympathise with with your workload for maintaining the
OPM archive, and your reply was very useful. There are two threads that
lead from this for me. The first is to get IBX on OPM up-to-date and
that we should deal with by direct EMail. The second is really more
general and to hopefully have a wider discussion on the how the OPM
archive should be maintained in future.
Looking at your response, the issue that leapt out for me is
"accountability". You seem to be taking on too much accountability when
it comes to code published on the OPM archive and especially when it
comes to checking that the code is at least compilable and is of an
appropriate standard.
You said "There should be at least one sample project. Otherwise I have
no way to test whether the code is working (I am not willing to write
test projects for foreign code)."
This implies that you are going to compile, test and look at the results
for every package submitted to OPM and potentially for each update (i.e.
lots of work for you). In the case of IBX you do at least have 17
example projects to choose from plus a comprehensive regression test
suite with 29 individual tests for the main package and a further 22 for
the underlying Firebird Pascal Interface package (fbintf) - but you need
to set up your own Firebird server to perform the tests/examples.
The regression tests make for a very stable and reliable package, but it
seems to be asking a lot for you to check the results and validate the
package as "good to go". My day job has been in safety critical aviation
software and so I am well aware as to how much work goes into third
party software certification.
Have you thought about requiring that submitted packages are signed by
the author/submitter? The author can then take responsibility for at
least the provenance of the code, correct licensing and that it compiles
- I would not go as far as "fitness for purpose" as open source software
can only work if the user accepts that part of the deal.
That way you can limit your checks to when the package is first
submitted and with updates the checking can be limited to signature
verification with the occasional deeper check.
Do you also send out automated regular EMails (e.g. every 6 months after
a package was first submitted asking authors to re-affirm that the
package is up-to-date - and removing any where the author has gone
AWOL)? If not, then that would be one way of avoiding stale packages on
the archive.
Tony Whyman
On 11/01/2025 18:50, Werner Pamler via lazarus wrote:
First of all: OPM was written and maintained by Balazs Szekely (aka
GetMem). For a year, however, I have not heard from him any more - I
really really hope that he is doing fine. For the moment OPM is
maintained by myself.
Your questions:
Am 11.01.2025 um 16:17 schrieb Tony Whyman via lazarus:
1. Who makes the decision about what is uploaded to the OPM repository?
2. How is a package put there and what precautions are taken to
ensure that the package is genuine and does not contain malicious
code - especially when the upload was not done by the original author.?
3. How are the OPM repository maintainers told that a new version of
a package is now available?
When the package owner has the feeling that a new version should be
released to OPM he notifies the OPM maintainer by mail to
o...@lazarus-ide.com containing a link to the new version or a zipped
file as attachment. I look over the code, compile it and run some of
the sample projects provided.
Anybody can submit packages for inclusion in OPM. Of course, I don't
know any of the submitters personally, and I have no idea whether
he/she is the original author. So, sorry that the your IBX files made
it into OPM without your knowledge. But I don't see a way how to
improve that without building up a huge beaurocracy.
Criteria to accept a package are for me (maybe they were different for
Balasz):
* The library must be a package. Individual, isolated units cannot
be handled by OPM.
* It must contain a brief description in the meta data and package file.
* It must contain a statement on the license. Commercial licenses
are rejected. I also reject packages which "smell" like being
pirated (for example, when there is the original Borland header in
the units).
* The package and its files must be in English - this is an
international community, and there is no other way to communicate.
* It must compile at least under the current releases of
Lazarus/FPC. Of course, the more combinations are welcome. The
working combinations should be specified in the meta-data (json),
as well as the widgetset for which it works.
* There should be at least one sample project. Otherwise I have no
way to test whether the code is working (I am not willing to write
test projects for foreign code).
* Ideally there should be some documentation, either included as
help files in the package, or as a separate wiki page, or similar.
* The package submitter must express his/her commitment to maintain
the package if, for example, it does not compile any more due to
compiler or widgetset changes. Unfortunately we have many
unmaintained packages already now, and I tend to remove a
non-functioning unmaintained package.
--
_______________________________________________
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
