On 6/16/19 4:25 PM, Aaryan Bhagat wrote: > > I wanted to make this method more robust so that users should not be > subscribed even if their email is working fine, but if you say this, you say > it by experience and I acknowledge that. I also mentioned my approach and > implementation several times during GSoC selection phase.
And I didn't follow everything you posted, so I'm coming in late here. It would have been better if I had been more involved at the time, but I wasn't. > So, If the old approach as Mailman2 should be adopted I should follow that, > if my modification according to the proposal looks fine, then I should > continue it, I have no problem and will do whatever the community thinks is > the best for the community. I think your approach is probably valid, but it adds complexity to the process. Complexity is not necessarily bad, but unnecessary complexity is bad because it makes things more fragile and bug prone and more difficult to maintain. So the bottom line question is whether this additional complexity is worth it. I am not convinced that it is. I am not saying absolutely that it isn't. I can't say that for sure without understanding the benefits it provides, but at this point, I'm skeptical. -- Mark Sapiro <m...@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ 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
