Mailman 3 March 2016 - Mailman-Developers

Hello!
by Ojas Shirekar 23 Mar '16

23 Mar '16

Hello, I am writing this mail to introduce myself to the group. My name is Ojas Shirekar and I am currently in my 3rd year of Btech(CE) degree enrolled in NMIMS, India. I was going through the idea list for GNU mailman and found the following two ideas extremely interesting: * Discourse integration and, * GitLab development tools integration As for my programming experience, I have been coding small programs in python since the last summer or so. I write simple parsers(I study compiler design) and do competitive programming in python. I am very comfortable using git and a CI system like Travis-CI. Although incredibly late, I would be submitting my project proposal today. I am would be excited to work on this truly remarkable project. Not only to improve my python skills but also out of genuine interest. Even if I don’t get selected I would love to contribute to the project. I look forward to the community’s guidance. Thank you. Ojas Kishore Shirekar oshirekar(a)hotmail.com<mailto:oshirekar@hotmail.com> Mukesh Patel School of Technology, Narsee Monjee Institute of Management Studies

1 0

Willing to contribute to GitLab/development tools integration project in GSoC
by 翁学平 23 Mar '16

23 Mar '16

I have sent this email for serval days before, but have not received any response for this, so send this email again.I am through the GSoC in 2016 and find GitLab/development tools integration <http://wiki.list.org/DEV/Google%20Summer%20of%20Code%202016#GitLab.2Fdevelo…> for GSoC, and I am interested in this project. I have built gitlab for my lab and integrated the CI system, and I am maintaining it now. I am enrolled under Computer Science and Technology for master degree in Tsinghua University, and it's my first year. *My Programming skills:* - Comfortable with coding in Python and also have good experience in object-oriented programming - Comprehensive experience in application development, such as web, desktop applications, especially in python. - Experience in using git version control system for about three years. - Strong ability for algorithms and data struct. Looking forward to your favorable reply. -- Best wishes! XuepingWeng(翁学平) Database Research Group, Department of Computer Science and Technology, Tsinghua University, Beijing, China, 100084

1 0

Re: [Mailman-Developers] Gsoc'16 Project:GitLab/development tools integration
by Simon Hanna 22 Mar '16

22 Mar '16

Note that these are my personal thoughts and nothing official. :-) On 03/21/2016 10:50 PM, Shubham Ghiya wrote: > Hello, > > My name is Shubham Ghiya, a 3 year undergraduate from IIIT-Hyderbad. > > I was going through the GSOC 2016 ideas and found "GitLab/development tools > integration" project interesting. > > I have setup the mailman and postorius and have tried my hand on some bugs > also.Right now,I am learning more about hyperkitty which will help me learn > more about the implementation details for the project.I have a good > understanding of functionality of various modules and how mailman works. I > have also read the chapter on mailman by Barry Warsaw to understand mailman > in a much better way. > > For the project "GitLab/development tools integration" I figured out that > we are expected to create a tool that will extract the contents of the mail > on a mailing list and create an issue of it on Gitlab/Github through > various Gitlab/hub API's and python libraries. > > 1. For the extraction part Hyperkitty will be used from where we can > extract and parse the contents of the mail. Please note that it should be a thread not just one message of a thread. > > 2. For creating an issue on Gitlab, different API's will be used which I > have to figure out yet. It would be nice if you design your project so that it can be used with different providers/API's. You could add supporting Github, launchpad, etc. to your stretch goals. > > I know the above points are a very naive and a basic approach. Please tell > me if I am thinking in the right direction and how to proceed further. I think the most challenging part is to implement a UI that let's the users decide what gets included in the issue and what not. (Which messages of the thread, which parts of a message, attachments, ...) As this is only targeted at lists used by developers it would be nice if the plugin for hyperkitty is optional meaning you don't need to have it installed at all and if you have it installed, you don't need to enable it for a list. There might be other practical ways to trigger the creation of an issue. For instance by including specific headers in the email or putting a special string in the subject. I don't think you need to do that, but if you want something challenging you can think about it.

1 0

Re: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" .
by Barry Warsaw 22 Mar '16

22 Mar '16

On Mar 13, 2016, at 03:01 AM, Harshit Bansal wrote: >Sorry, I think I have used wrong terminology here. By 'copying' I >actually meant 'inheriting'. Just a quick follow up to my previous comment about multiple inheritance. I was thinking about the way it's done in the Python code now, but even there, a specific ordering is imposed (see LegacyDefaultStyle.apply() and LegacyAnnounceOnly.apply()). The point of this break down is because some things (and it's not a perfect separation) really won't be shared between mailing lists. OTOH, you might want site-wide bounce settings that all lists will inherit and shouldn't be able to change. Other sub-styles give the list its "flavor", i.e. an open discussion list where anyone can join just by confirming their email, or a one-way announcement list that can't be unsubscribed from because it's an "all-employees" roster. I know this gets complicated quickly and I don't mean to throw a wrench into things. Harshit, I think you're essentially on the right track and Steve is right that we should be careful not to overengineer the whole thing. I think you've got enough ideas, input, feedback, and comments to have plenty of fun with it, and no doubt you'll discover a lot as you work out the details and implementation. Cheers, -Barry

1 0

Re: [Mailman-Developers] Correcting the display name in the recipient address
by Barry Warsaw 22 Mar '16

22 Mar '16

On Mar 22, 2016, at 10:37 PM, Aditya Divekar wrote: >So according to what I've gathered from the conversation, the fall back on >the user name can be made implicit. The user name is to be always used in >case of missing display name for the subscribed address. Right. >The feature for suggesting the display names from the other records i.e. >linked via the user, but not subscribed, could, as suggested, be raised in >postorius for the UI part. Right, and thus, not in core. >@Barry The mr code would first check if a display name is provided while >subscription i.e. `member.address.display_name`. If not, it will check if >the linked user has a display name and use that if it exists >i.e. `member.user.display_name`. And as a final case when both these fail, it >will use an empty string. I'll go ahead and make these changes. Yes, I think that's it. Cheers, -Barry

1 0

Re: [Mailman-Developers] Correcting the display name in the recipient address
by Barry Warsaw 22 Mar '16

22 Mar '16

On Mar 17, 2016, at 11:27 PM, Aditya Divekar wrote: >Suppose you have a user with two linked addresses, one of which is the >preferred address. Only the preferred address has a display name, and the >user does not. Now in the scenario where the other linked address(not the >preferred one) is subscribed to a mailing list without providing a display >name, it would be natural to check if the user has a display name, and use >that if it exists. But the user too does not have a display name in this >case. In such a case should we perform a further check and try to use the >preferred address's display name if it exists or simply use an empty string >instead? > >In the opinion I gave, in case we are not supplied with a display name, we >should check the user display name followed by the preferred address >display name, and use them in the specified order respectively. If none >exist, empty string would be used. > >In a more general scenario, as pointed out by Barry to question this >method, suppose a user has multiple linked addresses, only one of which has >a display name, and its neither the preferred address, nor the subscribed >address. Should the display name search algorithm find that one too, since >it still is a linked address for the user and hence contains valid user >information? One other comment. In the more general case I outlined (i.e. your last paragraph), *if* we decide to use display_names in other linked addresses, we can only use ones that are associated with validated addresses. A user's preferred address will always be validated. The other thing about the more general case is that there's no natural ordering. So yes, we could use the preferred address first, and then pick an arbitrary ordering criteria for falling back to all linked, validated addresses. That could be alphabetical by email address, or chronological by validation or registration date. Cheers, -Barry

4 5

Re: [Mailman-Developers] Gitlab integration, GSOC'16
by Terri Oda 21 Mar '16

21 Mar '16

On 2016-02-28 1:34 PM, aahan bhatt wrote: > Please explain about the gitlab integration in layman terms. I would like > to contribute to the project. Gitlab integration can mean a lot of things, and we've left this particular project pretty open to see what people will suggest. The tweet linked talks about moving a discussion from a mailing list to a bug tracker. So imagine that you have a bunch of people discussing an issue on a mailing list and after a few posts someone says "hm, that configuration didn't work the way I expected, this sounds like a bug, maybe we should file it" -- we want a way to dump the whole discussion into a bug so when someone goes to fix it they have all the information. You'd need to think a bit about privacy (were the mailing list posts public? what about the bug tracker?) and relevance of information (what if I only want some of the posts? what if I want to link the discussion but only provide a summary?) to go from the idea of "make it easier to file bugs using information from a mailing list discussion" to an actual workable interface for doing that, but that's the core of it. If you want to understand the whole gitlab integration idea better beyond that one use case, try brainstorming a little bit about how the pieces could work together. How could a mailing list integrate better with a bug tracker? How could it integrate better with merge requests? What information would people want to pass from one system to the other and why? For an example you might want to take a look at idea #27 on this page: http://blog.linuxgrrl.com/2012/03/14/mailman-brainstorm-2/

2 1

Gsoc'16 Project:GitLab/development tools integration
by Shubham Ghiya 21 Mar '16

21 Mar '16

Hello, My name is Shubham Ghiya, a 3 year undergraduate from IIIT-Hyderbad. I was going through the GSOC 2016 ideas and found "GitLab/development tools integration" project interesting. I have setup the mailman and postorius and have tried my hand on some bugs also.Right now,I am learning more about hyperkitty which will help me learn more about the implementation details for the project.I have a good understanding of functionality of various modules and how mailman works. I have also read the chapter on mailman by Barry Warsaw to understand mailman in a much better way. For the project "GitLab/development tools integration" I figured out that we are expected to create a tool that will extract the contents of the mail on a mailing list and create an issue of it on Gitlab/Github through various Gitlab/hub API's and python libraries. 1. For the extraction part Hyperkitty will be used from where we can extract and parse the contents of the mail. 2. For creating an issue on Gitlab, different API's will be used which I have to figure out yet. I know the above points are a very naive and a basic approach. Please tell me if I am thinking in the right direction and how to proceed further. Thank you for your time. Looking forward to hear from you. Regars Shubham Ghiya IRC - shubham__

1 0

Re: [Mailman-Developers] Gsoc Support for Message queue based email archiver
by Barry Warsaw 20 Mar '16

20 Mar '16

On Mar 21, 2016, at 03:47 AM, Anirudh Dahiya wrote: >1. Reliability - Currently, as I see, the messages are archived in >Hyperkitty via a simple POST request, but in the event of some failure(like >hk server being down for a while), there is no way the message is being >tried to be archived again. Thus are we aiming to add some reliability to >the system via the message queue systems? I think that's correct. Currently if we can't deliver to HK, the message doesn't even get shunted. >Apart from this and extensibility, what all advanteges are we looking >forward to as a result of this project? I think part of it should also be a more robust distributed architecture. We do have some separation now because submitting to HK is a POST, but it still requires a localhost connection (for security purposes). >2. Should I add/mention the potential scope for adding mailman events (like >list creation etc) to our archivers? Probably so. >3. Am I supposed to alter Hyperkitty(as what seems to be mentioned in the >project description) or should the basic scope of the project stay about >building the pub/sub or message queue interface(as what seems to be mentioned >by some of our conversations on irc) That's up to Aurelien I think. The model of the HK plugin is a good one to follow though because the pub/sub doesn't necessarily need to be part of Core. Cheers, -Barry

1 0

Re: [Mailman-Developers] Gsoc Support for Message queue based email archiver
by Florian Fuchs 20 Mar '16

20 Mar '16

On Sun, Mar 13, 2016 at 16:22:25PM +0530, Anirudh Dahiya wrote: >Hello >I am a computer scrience undergrad at IIIT-Hyderabad, India. > >I was looking through the GSoC 2016 ideas and would like to know more about >the project "message queue based email archiver" Great to hear you're interested in this project. I've just responded to another question regarding this project that is equally relevant to you: http://www.mail-archive.com/mailman-developers%40python.org/msg16305.html >I have played with codebase of mailman and postorius for some time now and >am currently trying to understand how Hyperkitty works. >Also, as suggested to other students regarding this project, I have gone >through the chapter on mailman in the book The Architecture of Open Source >Applications, the pycon talk on mailman by Barry and have also gone through >relevant parts of the documentation. Sounds good. If you're already reading through the HyperKitty source, you might give special attention to its implementation of Mailman's IArchiver interface, as well as the implementations for the mail-archive.com and mhonarc archivers in the Mailman core projects. Florian > >Regards >Anirudh Dahiya >(spark on IRC) >_______________________________________________ >Mailman-Developers mailing list >Mailman-Developers(a)python.org >https://mail.python.org/mailman/listinfo/mailman-developers >Mailman FAQ: http://wiki.list.org/x/AgA3 >Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ >Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/f%40florianfuchs… > >Security Policy: http://wiki.list.org/x/QIA9

2 1