Of interest to this community, I posed the following prompt:
mo betta'. Thank you. now it is also a more useful modules for use by others.
the puppet forge once required a module author to certify rights over
the IP to an uploaded module by each participating author. Has their
policy changed to accommodate AI use in development? 85% of this
module, which is getting close to usability as a publicly accessible
forge module, pre-existed my use of BraveAI for the final mile. What
is the forge's take on the involvement of AI and your having digested
the mm3-developers list and the application documentation in this
process. Is it necessary, for the forge, that I consult the team
whose work you have referenced for their permission?
Understanding that BraveAI is not an attorney, it nonetheless responded in part, . . .
"On the Mailman 3 team's permission: you do not need it."
it went on to suggest inclusion in my README.md, this copy, which I have modified to acknowledge use of AI in its development, and expand the scope of what this module does.
## Acknowledgements
This module automates deployment of [Mailman 3]
(https://gitlab.com/mailman/mailman) and its supporting components, the
importation of archives from legacy lists, the hiera controlled
configuration of the installation and its integration with runit,
postfix, sqlite3 or postgresql, apache2. Configuration guidance was
derived from the Mailman 3 documentation and mailman-users mailing list
discussions, and in the final mile with assistance by BraveAI which has
a better grasp on what those primary sources offer than do I.
I put this question here to hear what the actual humans of the development team have to say on this matter.
My project has been developed as the ymd_mailman3 puppet module. In my role definition, after some boilerplate setup, I include the module like so:
require ymd_mailman3
Along with 39 ymd_mailman3:: specific entries in hiera (mostly strings, paths, config options, but also a couple of arrays and a hash describing the (django) sites, domains and lists to be hosted), and another 10 in the python:: namespace (which should likely be refactorsed under the primary naming convention), it builds a specified version of python from source, installs necessary PyPi packages, wires it to a database and applies all the initial configuration for the installation, and the import of any archives which have not yet been processed. The initial installation runs for about 30 minutes (on 4gb of ram and a couple of processors assigned to the docker containers where I have done my development). I've watched a puppet run take another 20 minutes importing a few lists (2 four years old, one 25 years old).
For those who do not use puppet, and might want to adapt this framework to ansible or chef, perhaps in the future I might write:
"What I learned installing mm3, that I missed in the documentation"
Looks like ansible offers several options I should perhaps study for ideas on hardening and exposure of features.
I might also be tempted, with some nudging to offer revisions to the official docs, if folks are interested.
I still have some cruft removal left, further refactoring, etc. But the code might be summarized like so.
# cloc .
62 text files.
62 unique files.
5 files ignored.
github.com/AlDanial/cloc v 1.82 T=0.04 s (1332.8 files/s, 47292.0 lines/s)
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
Puppet 34 289 121 1056
ERB 17 71 0 315
Bourne Again Shell 2 18 7 57
Ruby 3 16 3 48
Bourne Shell 2 12 12 33
--------------------------------------------------------------------------------
SUM: 58 406 143 1509
--------------------------------------------------------------------------------
TODO: The ::params class offers sane defaults for anything missing from the hiera data structure, at least for an administrator comfortable working in a file system organized the debian way. I'd be happy to work with developers comfortable in other file system layouts, familiar with the package names for other linux flavors to write conditionals to drive the base assignments required to accommodate other distributions. Let me know please if that would be of interest to you. I also welcome help from nginx administrators for adding a path to accommodate a different local reverse proxy. One day perhaps I can refactor the python deployment code to rely on puppet-python instead of its own internal implementation. It had not served my purpose when I first tested it two years ago.
Looking forward to hearing from anyone interested by phone or email, here on the list, or privately.
Cheers.
-- hesco@yourmessagedelivered.com 912-571-1833 (cell, sms)