[Mailman-Developers] Re: mailman3 merge strategies (squashing commits vs. leaving commits as they are)
On Fri, Aug 9, 2019, at 9:39 AM, Jim Popovitch via Mailman-Developers wrote: > On Fri, 2019-08-09 at 17:10 +0900, Stephen J. Turnbull wrote: > > Abhilash Raj writes: > > > + Mailman Developers, since this seems like a general discussion topic. > > > > > > On Thu, Aug 8, 2019, at 2:01 AM, Mike Gabriel wrote: > > > > Hi Abhilash, > > > > > > > > I just looked into the two recent merges from Daniel on mailman's > > > > master branch. > > > > > > > > I noticed that you squashed the MR branch commits into one commit > > > > before the merge and that this one commit uses the latest commit > > > > messages of the MR branch to describe what the squashed commits do. > > > > Unfortunately, that commit messages does not appropriately describe > > > > what the commit in fact does. > > > > I seem to recall that somebody (one of the VCSes? one of the web repo > > hosting services?) has a system that squashes the commits and > > concatenates all the log messages for the merged branch. Perhaps > > gitlab has an option to do this? It doesn't, atleast not that I could find. The only two strategies that it will use is to either use any commit with multi-line commit message or just pick up the MR's title. We ideally want it to always do the latter but I can't see a config for that. I can manually change the message when merging, which I what I am going to try, if I can keep it in my mind when merging ofc ;-) > > Yes, gitlab has an option to do this, it's a checkbox during the > creation of the MR. Yes, Gitlab does have this option and we do use that often. The discussion is mostly about the output of the squashing and how does the commit message looks like. > > -Jim P. > ___ > Mailman-Developers mailing list -- mailman-developers@python.org > To unsubscribe send an email to mailman-developers-le...@python.org > https://mail.python.org/mailman3/lists/mailman-developers.python.org/ > Mailman FAQ: https://wiki.list.org/x/AgA3 > > Security Policy: https://wiki.list.org/x/QIA9 > -- thanks, Abhilash Raj (maxking) ___ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
[Mailman-Developers] Re: mailman3 merge strategies (squashing commits vs. leaving commits as they are)
On Fri, 2019-08-09 at 17:10 +0900, Stephen J. Turnbull wrote: > Abhilash Raj writes: > > + Mailman Developers, since this seems like a general discussion topic. > > > > On Thu, Aug 8, 2019, at 2:01 AM, Mike Gabriel wrote: > > > Hi Abhilash, > > > > > > I just looked into the two recent merges from Daniel on mailman's > > > master branch. > > > > > > I noticed that you squashed the MR branch commits into one commit > > > before the merge and that this one commit uses the latest commit > > > messages of the MR branch to describe what the squashed commits do. > > > Unfortunately, that commit messages does not appropriately describe > > > what the commit in fact does. > > I seem to recall that somebody (one of the VCSes? one of the web repo > hosting services?) has a system that squashes the commits and > concatenates all the log messages for the merged branch. Perhaps > gitlab has an option to do this? Yes, gitlab has an option to do this, it's a checkbox during the creation of the MR. -Jim P. ___ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
[Mailman-Developers] GNU Mailman Season of Docs Proposal Selection
To the applicants to Google Season of Docs with GNU Mailman: Cc: Mailman Developers [This is an abbreviated version of the message sent directly to the applicants.] Thank you all for your interest in GNU Mailman, and for applying to Season of Docs with the Mailman organization. First, I would like to congratulate Ariessa Norramli, whose project "Instructions for Migrating from Mailman 2 to Mailman 3" we selected for implementation this autumn. The list of all projects selected is available on the Season of Docs website at https://developers.google.com/season-of-docs/docs/participants/ Public discussion of the project will take place on the Mailman Developers mailing list . We will also negotiate a blogging requirement during the community bonding period. Of course Mailman is a public project on GitLab, and you can follow progress of the documentation project there. URLs for the blog and the repo will be posted to the mailing list. I hope all of the applicants will find some way to participate in the Mailman project as suits time and interest. About the Selection Process: Eight technical writers in some way expressed interest in Season of Docs with GNU Mailman, of whom five entered proposals via the Season of Docs website. Two of those proposals were stubs containing little or no content, which were eliminated quickly. The remaining three proposals were all very high quality, and in fact we could have selected any of them. Each had small advantages and disadvantages compared to the other two. The tie-breaking criterion was the content of the proposal: after consulting with Abhilash, I decided that the migration instructions project was our biggest documentation need based on the questions we get on the Mailman 3 users mailing list. -- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnb...@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN ___ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
[Mailman-Developers] Re: mailman3 merge strategies (squashing commits vs. leaving commits as they are)
Abhilash Raj writes: > + Mailman Developers, since this seems like a general discussion topic. > > On Thu, Aug 8, 2019, at 2:01 AM, Mike Gabriel wrote: > > Hi Abhilash, > > > > I just looked into the two recent merges from Daniel on mailman's > > master branch. > > > > I noticed that you squashed the MR branch commits into one commit > > before the merge and that this one commit uses the latest commit > > messages of the MR branch to describe what the squashed commits do. > > Unfortunately, that commit messages does not appropriately describe > > what the commit in fact does. I seem to recall that somebody (one of the VCSes? one of the web repo hosting services?) has a system that squashes the commits and concatenates all the log messages for the merged branch. Perhaps gitlab has an option to do this? Steve -- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnb...@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN ___ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
[Mailman-Developers] Re: Implementing `bounce_you_are_disabled_warnings_interval` in `Send_Warnings` function.
Another one that got hung up in my drafts folder. Same as the other, I think the basic coding probably is solved by now, but I'm worried we're not communicating about what the design problems are. Aaryan Bhagat writes: > According to me, I think a new command which takes all the > `Address` instances and in each instances checks which tuple of > `bounce_info` have `disabled` attribute true. If it sees the > `disabled` attribute of a tuple to be true it will roughly: > - Send a warning Shouldn't you first check if the disabled_warning_interval has been exceeded, and if it has, send a warning? Or is that what you mean by "check with the threshold" below? > - Increase warning counter Incrementing the warning counter should always happen if the mail is successfully sent. > - Check with the threshold What "threshold"? The disabled_warning_interval? > - Updates last_warning_sent timestamp value Updated this timestamp should always happen if the mail is successfully sent. I don't know offhand how any of the above operations could fail, and most likely to fail is sending mail, which is handled by the virgin, outgoing, and retry queues, not by the logic you're working on here. Still, perhaps some of the operations should be conditional on success. Also, you need to think about what happens if the warning fails for some address. Probably you just treat that as equivalent to a bounce in most cases, but what happens if it's a "no such address"? Is that already handled? Note that adding to the virgin queue probably can't fail (except in really bad circumstances such as out of memory), but simply adding the message to the retry queue may not be appropriate (I forget how often that queue gets flushed). If that doesn't make sense given what you know about how the queues work, then don't worry about it -- you probably know more about the queues than I do at this point. > The newly updated tuple ( with the updated counter and timestamp ) > will be stored again. > I will add it to a cron job. Cron job is what Mark suggested so that seems fine. Steve ___ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
[Mailman-Developers] Re: Implementing `bounce_you_are_disabled_warnings_interval` in `Send_Warnings` function.
Sorry, this got hung up in my drafts folder. The basic coding probably is solved, I think, but I'm worried we're not communicating about what the design problems are. So here goes. Aaryan Bhagat writes: > Thanks for the reply, Stephen! > > Stephen writes: > >I don't understand why there's any problem here. In what scenario is > >the database corrupted relative to what is desired? What variables > >are set differently from desired, and how? What are the user > >consequences of the incorrect database? > > What I mean is if we take the example of `BounceEvents` column > which has all the bounce messages stored, after processing each > message I have to set the `processed` attribute of that message as > true, so that will require modification of the database. > > Also in the case where I will be sending_warnings, there is > warning_count and warning_limit ( not the exact names of the > attributes ) of each `Address` instance with respect to each > `Mailing List` so I have to increase the warning_count counter and > save again in the database. I understand the details of the algorithm, that there are different attributes of certain objects that need to be modified. I don't understand why you believe there are conditions under which Mailman will do something undesirable, such as create a very long delay from the time "something" (such as mailing a disabled warning) *should* happen until it *does* happen. ___ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
