[Mailman-Developers] Re: Migrating mailman 2 to mailman 3.1
On Wed, Aug 14, 2019, at 10:28 AM, Abhilash Raj wrote: > > > On Wed, Aug 14, 2019, at 10:08 AM, Stephen J. Turnbull wrote: > > sandeep kumar writes: > > > > > Now that we are ready to go into production. We are currently > > > running mailman 2 in our production. Now the biggest challenge is > > > we have to migrate around 3000 lists from mailman 2 to mailman 3. > > > Is there any documentation > > > > There's a small amount, but we're not satisfied with it. We have an > > on-going Season of Docs project to create migration documentation. > > > > > or any inputs from the team would be appreciated and will be very > > > helpful. > > > > Abhilash and Mark have substantial experience with migrating lists, > > and operating Mailman 2 in parallel with Mailman 3 (ie, gradual > > migration, not the same list on both servers!) However, they've been > > doing this at scale of dozens of lists, maybe a dozen at a time. > > > I've also been (very slowly) working on automating the workflow for > migration to a level that it requires minimal user intervention. This > hasn't been tested or completed yet[1]. > > It is mostly complete, but if you can help complete it, it should > be a bit nicer than manually porting every list (i.e. multiple-commands per > list right now) vs single command with exception handling to keep > working till it reaches end. For 3k lists, it might be useful :) > > > [1]:https://gitlab.com/mailman/mailman/merge_requests/531 > > > > > I hope that some of our really large-scale users will have something > > to say, but the cases I'm aware of are at your stage more or less -- > > no post-mortems yet that I know of. > > > > > Iam trying to access docs.mailman3.org but it is not opening don't > > > why.? > > > > It appears that recent Firefox is very picky about the TLS versions it > > will connect to, and somehow mailman3.org doesn't support that. > > Abhilash? > > DNS records need updating, I'm gonna poke at Barry. It should now be working! > > > > > In the meantime, try other browsers which may not be so picky about > > crypto algorithms. Also you can try mailman.readthedocs.io. > > > > Steve > > > > -- > thanks, > Abhilash Raj (maxking) > -- 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: Implementing `bounce_you_are_disabled_warnings_interval` in `Send_Warnings` function.
Stephen writes: >If we receive a bounce that indicates that the address does not exist, >we should stop sending warnings there. Somebody has screwed up pretty >badly, and it wasn't us. That is the main hurdle, bounce extraction cannot determine the exact cause so we cannot ever say with surety the reason. Stephen writes: >In most cases, this deletion will be valid and intended by the user >(or well-deserved for abusing the account). In those cases, the >address should be unsubscribed. Yes, this is the expected `good` behaviour which is most suitable in cases like these. Stephen writes: >Do we unsubscribe on the theory that it's almost always correct to >do so, or do we keep it around and just disable without further >warnings in case of resurrection and to associate mail "From" that >address with the user? (This has issues in case the address is >resurrected but assigned to a different person.) As mentioned above, since cannot know the reason so we should not rush with the actions like unsubscribing from the mlist or deleting the address. I think we should let the normal implementation run its course then make some actions. I mean: - First, `bounce_score_threshold` will be crossed. - Then a probe will be sent if this probe bounces then `DeliveryStatus` is disabled of that `member`. - Then warning emails will be sent, till the count reaches `bounce_you_are_disabled_warnings`. - When both of them are exhausted then we can unsubscribe the user. - I can make a separate template telling the reason for this type of unsubscription. - I think `Address` instances or the `Member` instances should not be deleted as when the person will subscribe with the same email, data will be restored, but as you pointed out if the email is different then nothing of that sort will happen and space will be wasted. This I am not sure of and `Mark`, `Abhilash` and `Stephen` please point your opinion on this. If not much is clear on this then the default is I will not delete the data. Stephen writes: >If the user has other addresses, should Mailman warn them about this situation? This seems to overcomplicate things, keeping the `address` instances separate will be simple and no problems will arise. It can be implemented but I am not sure about its priority as of now. Default I will not implement this. Stephen writes: >Should the user be allowed to post "From" that address? Probably not. For a case when only `DeliveryStatus` is disabled then I think the user can post. But when the case happens such that the condition which I explained above in the points are met then we will unsubscribe that user and then there won't be any problem. Stephen writes: >Should the address be deleted? It's possible that the user will >use this address in From. Technically this is probably invalid >(the user doesn't have the right to use that address at all if >they can't receive mail there). But I don't see a good reason not >to associate such mail with their Mailman user. As explained above, I am not sure whether the address should/shouldn't be deleted, but if the user is unsubscribed then there won't be any problem if the user uses the address in From as the mailing list will not recognize it. If something is not explained well-enough please point out. Am I missing something here? ___ 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.
Stephen writes: >You wrote some posts that indicated you were specifically worried >about the timing of the warning mails. When the conversation >continued without much explanation of your concerns, I assumed that >you were still thinking about the concurrency issues that arise in an >asynchronous system such as email. Well, since you pointed out the rarity of this being very low in your replies, I then ignored this problem and started to ask more on the implementation. I apologize for not mentioning my transition. ___ 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: Migrating mailman 2 to mailman 3.1
On Wed, Aug 14, 2019, at 10:08 AM, Stephen J. Turnbull wrote: > sandeep kumar writes: > > > Now that we are ready to go into production. We are currently > > running mailman 2 in our production. Now the biggest challenge is > > we have to migrate around 3000 lists from mailman 2 to mailman 3. > > Is there any documentation > > There's a small amount, but we're not satisfied with it. We have an > on-going Season of Docs project to create migration documentation. > > > or any inputs from the team would be appreciated and will be very > > helpful. > > Abhilash and Mark have substantial experience with migrating lists, > and operating Mailman 2 in parallel with Mailman 3 (ie, gradual > migration, not the same list on both servers!) However, they've been > doing this at scale of dozens of lists, maybe a dozen at a time. I've also been (very slowly) working on automating the workflow for migration to a level that it requires minimal user intervention. This hasn't been tested or completed yet[1]. It is mostly complete, but if you can help complete it, it should be a bit nicer than manually porting every list (i.e. multiple-commands per list right now) vs single command with exception handling to keep working till it reaches end. For 3k lists, it might be useful :) [1]:https://gitlab.com/mailman/mailman/merge_requests/531 > > I hope that some of our really large-scale users will have something > to say, but the cases I'm aware of are at your stage more or less -- > no post-mortems yet that I know of. > > > Iam trying to access docs.mailman3.org but it is not opening don't > > why.? > > It appears that recent Firefox is very picky about the TLS versions it > will connect to, and somehow mailman3.org doesn't support that. > Abhilash? DNS records need updating, I'm gonna poke at Barry. > > In the meantime, try other browsers which may not be so picky about > crypto algorithms. Also you can try mailman.readthedocs.io. > > Steve > -- 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] Migrating mailman 2 to mailman 3.1
sandeep kumar writes: > Now that we are ready to go into production. We are currently > running mailman 2 in our production. Now the biggest challenge is > we have to migrate around 3000 lists from mailman 2 to mailman 3. > Is there any documentation There's a small amount, but we're not satisfied with it. We have an on-going Season of Docs project to create migration documentation. > or any inputs from the team would be appreciated and will be very > helpful. Abhilash and Mark have substantial experience with migrating lists, and operating Mailman 2 in parallel with Mailman 3 (ie, gradual migration, not the same list on both servers!) However, they've been doing this at scale of dozens of lists, maybe a dozen at a time. I hope that some of our really large-scale users will have something to say, but the cases I'm aware of are at your stage more or less -- no post-mortems yet that I know of. > Iam trying to access docs.mailman3.org but it is not opening don't > why.? It appears that recent Firefox is very picky about the TLS versions it will connect to, and somehow mailman3.org doesn't support that. Abhilash? In the meantime, try other browsers which may not be so picky about crypto algorithms. Also you can try mailman.readthedocs.io. 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
