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
Werner Pamler wrote 56 lines
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20250112/e2c68947/attachment.htm>
