These should be *new* lists on libre-soc.org (retire libre-riscv-dev) 1) Libre-SOC-Dev, for hardware and software development (productive) discussion 2) Libre-SOC-Org, for discussion about related to the organization itself, such as funding, investing, finances, domain change, website design, members, ethics, business, administration, you get my point 3) Libre-SOC-Misc, for everything else (the non serious stuff that I can safely ignore unlike the first two which should have important stuff only) 4) Bugtracker separate list, readonly announce only, and replyto set to bugzilla ready for when/if incoming bugzilla is ever set up 5) auto-build-notification (logs and build success/fail)
TBD after domain move.
what this bugreport is about: i just got word that michael had to unsubscribe from the list, because he was overwhelmed by the quantity of messages (697 in february at time of writing) but not just the quantity: he found that, after not reading for a couple of weeks, 95% of them were "discussion", not technical issues which is what he's interested in keeping up with. we therefore need to think more carefully and plan a suite of lists that are relevant to specific topics. thoughts appreciated on what those should be: michael suggested (1) (2) and (3) so far.
argh i just reviewed jan feb and mar 2020 and michael is right, the quantity is huge. i am going to suggest adding the bugtracker under its own list and make it readonly for now until a secure 2way setup can be arranged.
(In reply to Luke Kenneth Casson Leighton from comment #0) > These should be *new* lists on libre-soc.org (retire libre-riscv-dev) > > 1) Libre-SOC-Dev, for hardware and software development (productive) > discussion > 2) Libre-SOC-Org, for discussion about related to the organization > itself, such as funding, investing, finances, domain change, website > design, members, ethics, business, administration, you get my point > 3) Libre-SOC-Misc, for everything else (the non serious stuff that I > can safely ignore unlike the first two which should have important > stuff only) > 4) Bugtracker separate list, readonly announce only, and replyto set to > bugzilla ready for when/if incoming bugzilla is ever set up I think the above proposal is a good idea. When we finally shut-down libre-riscv-dev, I think we should send out a single notification email to everyone who's subscribed even if they have mail delivery turned off. We should also announce our name & domain change on crowdsupply. Is everyone ok with the above plan?
(In reply to Jacob Lifshay from comment #4) > (In reply to Luke Kenneth Casson Leighton from comment #0) > > These should be *new* lists on libre-soc.org (retire libre-riscv-dev) > > > > 1) Libre-SOC-Dev, for hardware and software development (productive) > > discussion > > 2) Libre-SOC-Org, for discussion about related to the organization > > itself, such as funding, investing, finances, domain change, website > > design, members, ethics, business, administration, you get my point > > 3) Libre-SOC-Misc, for everything else (the non serious stuff that I > > can safely ignore unlike the first two which should have important > > stuff only) > > 4) Bugtracker separate list, readonly announce only, and replyto set to > > bugzilla ready for when/if incoming bugzilla is ever set up > > I think the above proposal is a good idea. When we finally shut-down > libre-riscv-dev, I think we should send out a single notification email to > everyone who's subscribed even if they have mail delivery turned off. i can do that. i'd also like to just "migrate" everyone currently on the dev list to... the dev list and let them decide from there > We > should also announce our name & domain change on crowdsupply. yes. > > Is everyone ok with the above plan? fine with me.
(In reply to Jacob Lifshay from comment #4) > (In reply to Luke Kenneth Casson Leighton from comment #0) > > These should be *new* lists on libre-soc.org (retire libre-riscv-dev) > > > > 1) Libre-SOC-Dev, for hardware and software development (productive) > > discussion > > 2) Libre-SOC-Org, for discussion about related to the organization > > itself, such as funding, investing, finances, domain change, website > > design, members, ethics, business, administration, you get my point > > 3) Libre-SOC-Misc, for everything else (the non serious stuff that I > > can safely ignore unlike the first two which should have important > > stuff only) > > 4) Bugtracker separate list, readonly announce only, and replyto set to > > bugzilla ready for when/if incoming bugzilla is ever set up > > I think the above proposal is a good idea. When we finally shut-down > libre-riscv-dev, I think we should send out a single notification email to > everyone who's subscribed even if they have mail delivery turned off. We > should also announce our name & domain change on crowdsupply. > > Is everyone ok with the above plan? I am also fine with it.
public-inbox needs to be set up for each list as well see /home/publicinbox and fortunately it's possible to have a per-list-filter despite all messages going into /home/publicinbox/Maildir the config (/home/publicinbox/.public-inbox/config) basically has a filter to look for (the listid) and, when spotted, sucks that message out. btw, i recall now: we are *not* using Maildir, the messages are delivered *directly* to publicinboxmda, actually in exim4: /etc/exim4/conf.d/router/890-local_publicinbox: local_parts = publicinbox
we also will need an auto-build (continuous integration) list where notifications (read-only) about builds and tests are sent.
I have set up the list Libre-soc-dev here: http://lists.libre-soc.org/mailman/admin/libre-soc-dev/general I have copied users across and been through and applied digest choices (by hand) & administrative 'nomail' settings. I could not set a user 'nomail' setting for flisu@flisu.pl - they can reset if they want to. The list should work. I have unset the new-user-welcome-message - so no one knows that they are on the list - we will set that when we are happy with it; then send something to the list telling them about it. When we enable the new list I suggest that we set emergency moderation on the old one, discard everything sent to it & have the bounce text say something suitable. I can also set up a Libre-soc-org list - please tell me that you are happy with the above first. Should I copy users to that or let people subscribe ?
ok http://lists.libre-soc.org/mailman/listinfo looks great, alain. two more: * libre-soc-builds * libre-soc-bugs both of these need to be subscribable but put into "moderator" mode, with only two (authorised) posters permitted. one of those we know right now (bugzilla-daemon@libre-soc.org), this should be the *only* permitted poster to libre-soc-bugs@lists.libre-soc.org the other one we will sort out later (with jacob's help and input)
(In reply to Luke Kenneth Casson Leighton from comment #10) > ok http://lists.libre-soc.org/mailman/listinfo looks great, alain. > two more: > * libre-soc-builds > * libre-soc-bugs > > both of these need to be subscribable but put into "moderator" mode, > with only two (authorised) posters permitted. one of those we know > right now (bugzilla-daemon@libre-soc.org), this should be the > *only* permitted poster to libre-soc-bugs@lists.libre-soc.org > > the other one we will sort out later (with jacob's help and input) I'm guessing the source address will be git-mirroring@jacob-build-server.programmerjake.tk If you can, the Reply-To: header for both special-use mailing lists should be set to libre-soc-dev@libre-soc.org
(In reply to Jacob Lifshay from comment #11) > I'm guessing the source address will be > git-mirroring@jacob-build-server.programmerjake.tk ah if you install ssmtp and set it up similar to how it is done on the ppc64 server, we can make it look like the messages are coming from libre-soc.org. take a look in the /etc/ssmtp directory on the pp64 server > If you can, the Reply-To: header for both special-use mailing lists should > be set to libre-soc-dev@libre-soc.org hmmm a case could be made for teaching people "um no you go to the bugtracker" by rejecting replies. otherwise they will think that they _should_ reply and we are back to square one.
(In reply to Luke Kenneth Casson Leighton from comment #12) > (In reply to Jacob Lifshay from comment #11) > > > I'm guessing the source address will be > > git-mirroring@jacob-build-server.programmerjake.tk > > ah if you install ssmtp and set it up similar to how it is done on the > ppc64 server, we can make it look like the messages are coming from > libre-soc.org. If we use the lettre.at library for sending build emails, we could set it to just connect directly to libre-soc.org over the vpn without needing a local email server. We could also make the source address be builds@libre-soc.org instead of git-mirroring@jacob-build-server.programmerjake.tk that way it won't change if we move to a different server. > take a look in the /etc/ssmtp directory on the pp64 server > > > If you can, the Reply-To: header for both special-use mailing lists should > > be set to libre-soc-dev@libre-soc.org > > hmmm a case could be made for teaching people "um no you go to the > bugtracker" by rejecting replies. otherwise they will think that they > _should_ reply and we are back to square one. We could add a link to the new bug page to the emails sent out to the builds mailing list. If we are going to reject replies we should set Reply-To: to no-reply@libre-soc.org instead of leaving it as the default.
(In reply to Jacob Lifshay from comment #13) > (In reply to Luke Kenneth Casson Leighton from comment #12) > > (In reply to Jacob Lifshay from comment #11) > > > > > I'm guessing the source address will be > > > git-mirroring@jacob-build-server.programmerjake.tk > > > > ah if you install ssmtp and set it up similar to how it is done on the > > ppc64 server, we can make it look like the messages are coming from > > libre-soc.org. > > If we use the lettre.at library for sending build emails, we could set it to > just connect directly to libre-soc.org over the vpn without needing a local > email server. ssmtp is not a local email server it's a redirector. the less that gets done here the better. can you arrange for the command to call an external command - the faster this gets done in the least amount of time the better. (there's no need to use a complicated advanced rust mail library: get the information out as fast as possible and let *another* external command do that job, this provides flexibility) > We could also make the source address be builds@libre-soc.org > instead of git-mirroring@jacob-build-server.programmerjake.tk that way it > won't change if we move to a different server. yes. > > take a look in the /etc/ssmtp directory on the pp64 server > > > > > If you can, the Reply-To: header for both special-use mailing lists should > > > be set to libre-soc-dev@libre-soc.org > > > > hmmm a case could be made for teaching people "um no you go to the > > bugtracker" by rejecting replies. otherwise they will think that they > > _should_ reply and we are back to square one. > > We could add a link to the new bug page to the emails sent out to the builds > mailing list. If we are going to reject replies we should set Reply-To: to > no-reply@libre-soc.org instead of leaving it as the default. yep good idea.
Maybe it would be a good idea to ask marc.info to add our mailing lists to their archive: https://marc.info/?q=about
don't know that this is the right bug report: the CI build status mailing list and the sendmail bash script and the calling gitlab-ci-archiver all need to be set up -- gitlab-ci-archiver will probably be running on jacob-build-server. the gitlab rust library that's used needs to have the changes upstreamed which is mostly stalled, additionally, the upstream is currently rewriting the API in a different way than how I had written the API modifications that gitlab-ci-archiver is relying on. The pull requests for my modifications: https://gitlab.kitware.com/utils/rust-gitlab/-/merge_requests/215 https://gitlab.kitware.com/utils/rust-gitlab/-/merge_requests/217 The upstream changelog for the upstream API modifications: https://gitlab.kitware.com/utils/rust-gitlab/-/blob/master/CHANGELOG.md#new-api-strategy
Since we have completed the domain move, and we now have pitch meetings with potential investors coming up, I think it is essential that we set up the Libre-SOC-Org mailing list. In addition to this, I'd like to suggest that we have a short weekly meeting (~30 min) to discuss organizational matters, which should be recorded and made available somehow. I found the OPF virtual coffee call to be very good for adding some more connection to our highly distributed team. I think the purpose of these meeting should be to discuss and layout proposals, for further discussion on, and subject to unanimous approval by the Libre-SOC-Org mailing list. I'm writing this here because it's directly related to mailing lists. If you find my idea of the video organizational chats to be worthy of further discussion, then I think this will merit the creation of a new bug report. I think it's also a good idea to add a new category of bug report to the thee existing "Libre-SOC Website", "Libre-SOC First SOC", and "TODO IIT Madras 180nm Foundry", perhaps "Systemes Libres Organization", such that technical bugs are not mixed with non-technical bugs.
(In reply to Cole Poirier from comment #17) > Since we have completed the domain move, and we now have pitch meetings with > potential investors coming up, I think it is essential that we set up the > Libre-SOC-Org mailing list. they're done several weeks ago: i don't believe anyone realises that they're there: http://lists.libre-soc.org/mailman/listinfo > In addition to this, I'd like to suggest that we have a short weekly meeting > (~30 min) to discuss organizational matters, which should be recorded and > made available somehow. I found the OPF virtual coffee call to be very good > for adding some more connection to our highly distributed team. I think the > purpose of these meeting should be to discuss and layout proposals, for > further discussion on, and subject to unanimous approval by the > Libre-SOC-Org mailing list. > > I'm writing this here because it's directly related to mailing lists. If you > find my idea of the video organizational chats to be worthy of further > discussion, then I think this will merit the creation of a new bug report. yes go for it, i like it. > I think it's also a good idea to add a new category of bug report to the > thee existing "Libre-SOC Website", "Libre-SOC First SOC", and "TODO IIT > Madras 180nm Foundry", perhaps "Systemes Libres Organization", such that > technical bugs are not mixed with non-technical bugs. separate bugreport for that, too :)
(In reply to Luke Kenneth Casson Leighton from comment #18) > (In reply to Cole Poirier from comment #17) > > Since we have completed the domain move, and we now have pitch meetings with > > potential investors coming up, I think it is essential that we set up the > > Libre-SOC-Org mailing list. > > they're done several weeks ago: i don't believe anyone realises that they're > there: > > http://lists.libre-soc.org/mailman/listinfo You're right, I saw the emails in april, but didn't realize then that this was complete. Thanks so much Alain! I think this discussion now falls under the scope of bug #366. > > In addition to this, I'd like to suggest that we have a short weekly meeting > > (~30 min) to discuss organizational matters, which should be recorded and > > made available somehow. I found the OPF virtual coffee call to be very good > > for adding some more connection to our highly distributed team. I think the > > purpose of these meeting should be to discuss and layout proposals, for > > further discussion on, and subject to unanimous approval by the > > Libre-SOC-Org mailing list. > > > > I'm writing this here because it's directly related to mailing lists. If you > > find my idea of the video organizational chats to be worthy of further > > discussion, then I think this will merit the creation of a new bug report. > > yes go for it, i like it. Done. Bug #367 <https://bugs.libre-soc.org/show_bug.cgi?id=367> > > I think it's also a good idea to add a new category of bug report to the > > thee existing "Libre-SOC Website", "Libre-SOC First SOC", and "TODO IIT > > Madras 180nm Foundry", perhaps "Systemes Libres Organization", such that > > technical bugs are not mixed with non-technical bugs. > > separate bugreport for that, too :) Done. bug #366 <https://bugs.libre-soc.org/show_bug.cgi?id=366>
just checking by subscribing to libre-soc-misc, should they be libre-soc-misc@lists.libre-soc.org or libre-soc-misc@libre-soc.org i kiiinda prefer the convention of a separate domain name
(In reply to Luke Kenneth Casson Leighton from comment #20) > just checking by subscribing to libre-soc-misc, should they be > libre-soc-misc@lists.libre-soc.org > > or > > > libre-soc-misc@libre-soc.org > > i kiiinda prefer the convention of a separate domain name I Agree. I prefer libre-soc-misc@libre-soc.org
(In reply to Cole Poirier from comment #21) > (In reply to Luke Kenneth Casson Leighton from comment #20) > > just checking by subscribing to libre-soc-misc, should they be > > libre-soc-misc@lists.libre-soc.org > > i kiiinda prefer the convention of a separate domain name > > I Agree. I prefer libre-soc-misc@libre-soc.org turns out they are in fact at lists.libre-soc.org because exim4 can't easily be configured to merge mailman on one vhost and email addresses on another.
i've created libre-soc-bugs@lists.libre-soc.org the next major task is to move almost every "cc" in all 385 bugs over to that list (except for the new "Organisation" ones)
(In reply to Luke Kenneth Casson Leighton from comment #23) > i've created libre-soc-bugs@lists.libre-soc.org > the next major task is to move almost every "cc" in all 385 bugs > over to that list (except for the new "Organisation" ones) this turns out to be easy: change the email address of the cc "user"
(In reply to Luke Kenneth Casson Leighton from comment #23) > i've created libre-soc-bugs@lists.libre-soc.org > the next major task is to move almost every "cc" in all 385 bugs > over to that list (except for the new "Organisation" ones) I'll take care of this Luke, unless... Does your comment "this turns out to be easy: change the email address of the cc 'user'" mean that this has to be done 390 times, once for each bug? Or just changing something at the toplevel takes care of all 390 with one change of email address?
(In reply to Cole Poirier from comment #25) > I'll take care of this Luke, unless... Does your comment "this turns out to > be easy: change the email address of the cc 'user'" mean that this has to be > done 390 times, once for each bug? no done already i simply changed the user email address in admin console. > Or just changing something at the > toplevel takes care of all 390 with one change of email address? yyyep :)
Resolved June 2020