Re: [Mailman-Developers] GSOC '15 : Student applications start today
Few other points: * You need to submit your proposals to GNU Mailman organization and *not* Python Software Foundation like last year. We have been selected as a separate organization this year. * The application template is up on melange, please have a look before you submit your application. It is very similar to the PSF template that I mentioned in my previous email, only a few details here and there. * Once you submit your proposal, all the mentors are automatically notified about the submission. You will be notified by melange when any mentors comments (reviews as posted as comments) on your proposal. You can notify on mailing list/IRC iff you have anything specific to discuss about in your proposal. On 16 March 2015 at 16:09, Abhilash Raj raj.abhila...@gmail.com wrote: GSoC Applicants, The student application period for Google Summer of Code 2015 starts from today (March 16 at 19:00 UTC). We encourage each of you to submit your proposal as soon as possible on melange, since it has been known to crash in the days near to deadline. You can edit your proposal as many times you like till the deadline. In past we have been following the application template from PSF and this year too there is no change in that front. You can find it here[1]. Remember that blogging is an important part of GSoC and thus it is must that you have your personal blog setup along with RSS/ATOM feeds. Feeds helps us to follow your blogs without visiting the webpage everytime. If you have problem setting up just sign up on on Blogger[2]). [1]: https://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2015 [2]: https://www.blogger.com/ All the best! -- thanks, Abhilash -- thanks, Abhilash Raj ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] GSOC'15: Improving styles for lists
prakhar joshi writes: I am thinking of storing the styles in the database by creating a table for the styles in the db Mailman's databases are not relational dbs, they're object-oriented. Underneath the objects are stored in relational dbs and managed by an ORM (SQLAlchemy), of course, but the Mailman API is object-based. If you want to think of your schema in terms of tables, I don't think you'll have any trouble in design, but when you get to the implementation stage you'll have to shift gears to OODB style. and this table will contain all the attributes of a style and these entries can be null too. So a table which will contain a style name with all its attributes. Now as we have table for mailing list containing all the attributes in the mailing list table. So now the style table will contain all these attributes and in the mailing list table we will just store the mailing list name and the style name and this way we can connect the two table by providing foreign key of style_id to the mailing list table? I think this is probably not the best way to go. Some of the attributes change over time, some attributes flip back and forth, and so on. Some lists may have a unique combination not very useful for other lists/list owners. So I think a library of templates so that you can set many attributes at once by applying a template is a better way to go. Also, I suspect it would be useful to allow very incomplete templates so that you could apply template A to get the basic character, then apply template B (which is very incomplete and only changes two attributes) to get the effect you want. I haven't thought about it carefully, so don't just assume everything I wrote is right. Maybe it will be useful for refining your proposal. ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Fine grained subscription control, scaling, noise, relevancy, subscription rules, dynamic lists
Refer to the bottom of this email for some previous quotes from @barry on this topic. I’ve also had off list discussions with Barry in which he has mentioned this same topic so it seems to have some previous thought gone into it. I’m wanting to raise the topic of “fine grained subscription control” (for want of a better term) for discussion. Please note these thoughts refer to discussion style lists rather than notification style lists. Please prefix every sentence here with IMO - I’m not saying I’m right about anything, just putting forward food for thought. Also, I’m no Mailman expert so if my assumptions are plain wrong please let me know. One of the core problems of mailing lists (at least as implemented in Mailman) is that there’s not much middle ground between being very involved (i.e receive all posts to list), or being almost-not-involved (i.e. receiving daily digests or no digest). List noise and relevancy is the main problem and it’s a big impediment to lists being more widely used. Very engaged users might be ok with constantly deleting messages that they are not interested in (i.e. irrelevant noise). Less engaged users will be annoyed with the noise and unsubscribe, or will switch to digest notification which I suggest to you is close to unsubscription anyway because that user no longer sees emails that they might have been interested in had they known there was a message on that subject. Digest users I suggest are at best observers rather than participators. The more active the list, the greater the noise problem, the more users will drop out of the list. As a list gains more subscribers, eventually even the most engaged user will have had enough of the volume of messages and will drop back to digest or write some mailbox rule that moves the emails to a folder, effectively dis-engaging them from the list conversation flow. Thus Mailman discussion-style lists currently don’t scale. Even for low volume lists, noise is a major inhibitor to usage in certain contexts. Consider for example the CIO of a company or the manager of a division of 30 developers. There are various mailing lists being used by the various projects that they are responsible for. The leader is not participating however because the noise from those lists would be overwhelming. They would however like to be partipcating in list discussions either that they initiated, are explicitly copied into, or relate to topics (keywords) that they are interested in. In reality, I’m not convinced Mailman would often be used in contexts like this currently because the relevancy/noise/digest/unsubscribe problem is a showstopper. The systers have recognised this problem and their solution is Dynamic sublists as described here: http://wiki.list.org/DEV/Dynamic%20Sublists List subscribers can decide whether to be a part of new conversations or not. If the users decide to subscribe to new conversations, then they will receive all the messages of a new conversation unless they explicitly unsubscribe from it. If they otherwise decide to unsubscribe from new conversations,then they will receive only the first message of every new conversation unless they explicitly subscribe to it.” I don’t think dynamic sublists are an effective solution (IMO, remember?). Getting the root message in all conversations is still too noisy and its a clumsy mechanic to have to opt in to further discussion and my thinking is that opt-in-to-discuss will impose a barrier to engagement that will reduce user interaction - put another way - “opt in to every discussion? too hard”. Possibly a solution worth considering is fine-grained subscription control, in which there is a set of SEND and DONTSEND rules at a List default level and at a user level. SEND: Discussions where list member email address is in to/from/cc: Discussions where to/from/cc contains one or more of: sa...@example.org, dav...@example.org, *.example.com Discussions where subject contains keyword: hyperkitty Discussions where body contains keyword: hyperkitty DONTSEND: Discussions where list member email address is in to/from/cc: Discussions where to/from/cc contains one or more of: sa...@example.org, dav...@example.org Discussions where subject contains keyword: Java Discussions where body contains keyword: ruby The technical hurdle to making this work is that Mailman needs access to historical messages to make it work (i.e. integrating some level of aqrchive like functionality into the Mailman database). I suggest this this may not be as hard as it sounds and hey, we’ve got a database there anyway so why not use it? One possibility is that this could be pushed into archiving but I don’t think that actually is practical - such concepts really need to be built deep into the core. I’m not advocating archiving-in-core here because I think archiving should like outside core. I do think however that there is value in the core having access to
Re: [Mailman-Developers] GSOC'15: Improving styles for lists
hi, so we should have templates already created in a folder with default values of the attributes in it. the templates will be of BASIC OPERATION, BOUNCES etc. and under each of the template we will gonna have attributes for it and then we can apply these templates on the list and even user can edit these templates, right ? One thing how these templates will be stored for the user is still a doubt for me ? Can you please help me with that ? Thanks, Prakhar Joshi DA-IICT,Gandhinagar On Thu, Mar 19, 2015 at 12:01 PM, Stephen J. Turnbull step...@xemacs.org wrote: prakhar joshi writes: I am thinking of storing the styles in the database by creating a table for the styles in the db Mailman's databases are not relational dbs, they're object-oriented. Underneath the objects are stored in relational dbs and managed by an ORM (SQLAlchemy), of course, but the Mailman API is object-based. If you want to think of your schema in terms of tables, I don't think you'll have any trouble in design, but when you get to the implementation stage you'll have to shift gears to OODB style. and this table will contain all the attributes of a style and these entries can be null too. So a table which will contain a style name with all its attributes. Now as we have table for mailing list containing all the attributes in the mailing list table. So now the style table will contain all these attributes and in the mailing list table we will just store the mailing list name and the style name and this way we can connect the two table by providing foreign key of style_id to the mailing list table? I think this is probably not the best way to go. Some of the attributes change over time, some attributes flip back and forth, and so on. Some lists may have a unique combination not very useful for other lists/list owners. So I think a library of templates so that you can set many attributes at once by applying a template is a better way to go. Also, I suspect it would be useful to allow very incomplete templates so that you could apply template A to get the basic character, then apply template B (which is very incomplete and only changes two attributes) to get the effect you want. I haven't thought about it carefully, so don't just assume everything I wrote is right. Maybe it will be useful for refining your proposal. ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSOC'15: Improving styles for lists
what if we create separate tables for each class in the mailman/src/mailman/styles/base.py and store the name and their attributes in it with user_name with it. I think the attributes for the classes defined already will be fixed? So now if we feel the requirement of including new things to style (like an additional class in that file ) Then we will add new table for that also. And now the flow will be like.. the mailing list table will be same as right now. And each of the new table we will get the attributes filled by the admin. So the list styles will be stored in that way. And we have user name also so only that user will get the styles which are created by him/her. Thanks, Prakhar Joshi DA-IICT,Gandhinagar On Thu, Mar 19, 2015 at 1:40 PM, prakhar joshi prakhar...@gmail.com wrote: hi, so we should have templates already created in a folder with default values of the attributes in it. the templates will be of BASIC OPERATION, BOUNCES etc. and under each of the template we will gonna have attributes for it and then we can apply these templates on the list and even user can edit these templates, right ? One thing how these templates will be stored for the user is still a doubt for me ? Can you please help me with that ? Thanks, Prakhar Joshi DA-IICT,Gandhinagar On Thu, Mar 19, 2015 at 12:01 PM, Stephen J. Turnbull step...@xemacs.org wrote: prakhar joshi writes: I am thinking of storing the styles in the database by creating a table for the styles in the db Mailman's databases are not relational dbs, they're object-oriented. Underneath the objects are stored in relational dbs and managed by an ORM (SQLAlchemy), of course, but the Mailman API is object-based. If you want to think of your schema in terms of tables, I don't think you'll have any trouble in design, but when you get to the implementation stage you'll have to shift gears to OODB style. and this table will contain all the attributes of a style and these entries can be null too. So a table which will contain a style name with all its attributes. Now as we have table for mailing list containing all the attributes in the mailing list table. So now the style table will contain all these attributes and in the mailing list table we will just store the mailing list name and the style name and this way we can connect the two table by providing foreign key of style_id to the mailing list table? I think this is probably not the best way to go. Some of the attributes change over time, some attributes flip back and forth, and so on. Some lists may have a unique combination not very useful for other lists/list owners. So I think a library of templates so that you can set many attributes at once by applying a template is a better way to go. Also, I suspect it would be useful to allow very incomplete templates so that you could apply template A to get the basic character, then apply template B (which is very incomplete and only changes two attributes) to get the effect you want. I haven't thought about it carefully, so don't just assume everything I wrote is right. Maybe it will be useful for refining your proposal. ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSOC'15: Improving styles for lists
prakhar joshi writes: what if we create separate tables for each class in the mailman/src/mailman/styles/base.py and store the name and their attributes in it with user_name with it. Who are these users (subscribers? admins?) and why do you want to associate styles with users? Please use more descriptive terms unless you really need to describe something generic. But here IIRC the styles are for lists, and therefore the relevant users are list admins. However, why would a style be associated with a list admin? The same admin might have announce lists and discussion lists as well as anonymous lists, and so on. ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GitHub/development tools integration project Gsoc'15
Sumana Harihareswara writes: http://en.flossmanuals.net/GSoCStudentGuide/ http://www.harihareswara.net/sumana/2013/05/12/1 and http://www.harihareswara.net/sumana/2014/02/26/0 helpful in guiding you. Thanks for the blog references! But these are generic, do you have anything more about the specific issues you are encountering in Mailman vs. GitHub etc? ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Invitation to adopt pytest month
This is spam. Don't do it without checking with the list owner (coursemailman-developers-ow...@python.org) first. Brianna Laugher writes: [spam deleted] ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Use of the mailing list during the application period
Hi! First, let me thank you all for your applications. I was a little worried when were approved as an org ourselves, but we've got a bunch of good ideas and nicely done applications here, so we aren't going to have trouble filling our slots, I think. Second, I don't necessarily speak for the other mentors, but I have a reasonably good track record in channeling Barry and Mark and Terri at least. So judge for yourself if my rules of the list make sense for you. Now, to the main topic. As I see it, you should use the mailing lists: 1. *Before* you have filed an application at all. (However, at this point I would suggest filing *something*. Remember, we can't accept any student who is unknown to Melange no matter how much he or she contributes on the list. We will make the decision based on what's on Melange at the deadline, and you can edit until then.) 2. If Melange is unavailable. 3. For asking about requirements. What is it that Mailman doesn't do that it should? What do subscribers, moderators, list owners and site admins want it to do? What does it do that is annoying and should stop, or should be optional? Of course your opinions are relevant, but in the end if you're the only user, you can fork and be happy. So the lists are where you'll get opinions from real users, and know what will benefit the whole community. 4. For communicating with others about parts of Mailman *not* directly related to your project, such as installation, testing, use of the VCS, how to write schedules, etc. 5. To poke the mentors when they really seem to be asleep (no activity for 36-48 hours). 6. (Maybe) To announce that your initial proposal has been posted. But see #1 under should not. 7. To announce important updates to your *blog* that may be of general interest. For example, you could post your proposal there for non-mentors to see (I don't necessarily recommend that, see #2 below). You should *not* use the mailing lists, but rather use Melange: 1. To announce updates to your proposal. Mentors will get pings from Melange about changes to your proposal, and should be looking frequently anyway. Other participants in the mailing list have no need to know and probably don't care to know. And I'm really busy and getting a ton of mail right now, and so are several other mentors. There's a good chance that anything on the list will get dropped on the floor if I don't address it right away. I will be looking at all Mailman proposals (as well as some PSF and Systers proposals) daily in any case. 2. To ask about design and scheduling issues. There are two reasons for this. First, most of you are concentrated on two or three projects, and so are competing with each other. Personally, I give extra points to people who openly discuss their ideas in the spirit of may the best proposal win, but realistically, you may not want to depend on that, and keep your proposal between you and the mentors until acceptance decisions are made. Second, this is the same division of responsibility as between MLs and issue trackers. If you post to the ML and a mentor replies there, both the question and the answer stand a fair chance of getting dropped on the floor and not helping to improve your proposal. If the Q A take place in comments on the proposal, or even in the proposal itself, points that didn't get addressed early on will be right there for your later review, etc. Hope this helps. Steve ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MIME footers
Murray S. Kucherawy writes: The difference between this idea and l= is that there's still a signature covering the added part, that of the MLM. No, there isn't, not when it leaves the poster's MTA. This is the same for your proposal and for l=. People have learned to deal with top-posting, they could have learned to deal with adding all new content at the end, too. But they haven't. By contrast, l= leaves the appended bit unsigned. But it need not. The MLM (or its MTA) can sign the whole message on the way out. So this too is the same for your proposal and for l=. This scheme does sign individual parts as well, OK. As long as individual parts are signed, we can have a way to get at the trust-per-part issue, and MUAs and Mediators have a way to partially quote preserving upstream signatures (although the granularity of the trimming is awfully coarse!) Steve ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Message threading - requesting some wisdom
Andrew Stuart writes: I assume a great deal of thought has gone into message threading and how it works. Is there anyone willing to share the basics with me - specifically as it relates to Mailman and related projects? Currently Mailman and Postorius don't care at all. HyperKitty has its own threading mechanism, and this is a core function of an MUA or archive (which is sort of a read-only MUA). AFAICS, Jamie's threading.html is all you really need to know about this. There's also the IMAP THREAD extension, an alternative specification of Jamie's algorithm: https://tools.ietf.org/html/rfc5256. a Mailman oriented understanding I don't understand what you mean by this. Mailman's current distribution and administration functions don't care about threads at all, and (as I alluded to above) HyperKitty is just a read-only MUA for this purpose. Dynamic sublists (as implemented by the Systers fork) and some proposals for anonymous lists using threading information, but Systers does it by creating a separate channel (which may have subthreads defined by links) while the anonymous list use case is as yet undesigned. example, this description of Gmail threading http://xkahn.zoned.net/software/evolution/threads/ seems to suggest that Gmail includes arbitrary business rules for threading based on message content (i.e. subject prefix). Jamie's algorithm also uses the subject field when links are unavailable. ** What data defines how emails are connected to one another? The In-Reply-To and References header fields are references to earlier messages in the thread. Most MUAs also create pseudo-threads by sorting on Subject and Date when those fields are unavailable. ** How is that connecting data organised (i.e. in a tree, a flat list, by date, whatever)? Organized where? Conceptually it's a tree. ** What happens when thread data is missing (i.e. a message in a thread is deleted)? Implementation detail. ** Are there any algorithms/mechanisms/patterns that are effective for implementing threading? The two documents referenced above. ** Any code in Mailman/Hyperkitty/elsewhere that is particularly good to study? HyperKitty must do threading, but what algorithm it uses I don't know. I find that mailing lists are generally not very demanding of the threading algorithm, most work fine. ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GitHub/development tools integration project Gsoc'15
Hello. I am the person who originally wrote up this idea. I am not going to mentor it; I am not skilled enough at working with Mailman, and I have other time commitments, so I will not be mentoring this or any other Google Summer of Code student or idea. On 18/03/15 12:48, Stephen J. Turnbull wrote: Prabhanshu Abhishek writes: but the thing i want to know is, 1) what are the other feature you want to implement through this.other than the mailing a thread,or pull requests. The fact that the project doesn't have a mentor listed probably means you'll need to flesh out the requirements yourself. Correct. 2)the gsoc idea page says that it is necessary to fix at least one bug, but i have not been able to find some bug that is beginner friendly and related to my project, can you give me some bug to work on that will help me on my project. Since this is a new feature, there probably are no directly related bugs. For easy, some of the bugs in launchpad have an easy tag; you should look at those. 3)some other necessary things that i should work upon before submitting my proposal. Read the first four sections of the ideas page again, and read the references there, especially How to SPAM. 4)and lastly who will be my mentor, can you tell me? I don't know; perhaps the person who suggested this project will step forward in a few hours. No, I will not mentor this project. If no one has specifically said I will mentor this project then no one is assigned to mentor it. However, a good student, someone who writes well and shows resourcefulness and gives the impression that she/he would be interesting to work with, could potentially attract a mentor who wants to work with that student. You may find http://en.flossmanuals.net/GSoCStudentGuide/ http://www.harihareswara.net/sumana/2013/05/12/1 and http://www.harihareswara.net/sumana/2014/02/26/0 helpful in guiding you. -- Sumana Harihareswara http://brainwane.net ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Dynamic Sublist Proposal Queries
Hello I recently submitted my proposal for Dynamic Sublists, since I haven't had much discussion on this idea with mentors it would be nice to have some reviews. I request Terri, Barry and Steve to have a look whenever they find suitable and other mentors can also help me if they wish too. There are many sections in the proposal for which I particularly need reviews like 1. Dealing with two different delimiter inside rules and I'm confused in selecting between command runners and new Dlist runners. 2. The implementation of dlists in mailman2.1 by systers uses a second pipeline for dlists. But it might be possible that we could re-use the existing default-posting-pipeline with a new dlist-recipeints handler. Or we could just modify calculate-recipients handler to check for dlists and calculate the recipients like it is calculated in dlist-recipeints handler. Personally I would like to have a separate pipeline and handler to keep the whole process clean and to reduce the errors caused by the checks (assuming the implementations of theory is not always perfect), but I am open to the opinions from the mentors. I have written the proposal according to my understanding of Systers' implementation in Mailman 2.0 and Mailman 3.0's architecture and I assume there are many changes required in the proposal. I also need some help with my time-line, though I am thinking of implementing the thread based model for message in mailman in my early stages and send an upstream pull request since many of the GSoC project are using this functionality. -- *Pranjal Yadav* *IIT Kharagpur* ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MIME footers
On Tue, Mar 10, 2015 at 6:51 PM, Stephen J. Turnbull step...@xemacs.org wrote: It's certainly the case that this proposal only deals well with footers. The specific algorithm is to construct a MIME tree and sign parts of it; specifically, sign all of it, and then verify all of what you get first. I think this is the wrong algorithm. I suspect that the community is going to be almost as leery of this proposal as they are of l=, and for similar reasons. Given that, I really think the right thing to do is to take the MIME structure seriously and sign part-by-part. The difference between this idea and l= is that there's still a signature covering the added part, that of the MLM. It has taken some responsibility (where some means an unspecified amount, but not zero) for the added content. By contrast, l= leaves the appended bit unsigned. This scheme does sign individual parts as well, and then does merged signatures in each non-leaf node (corresponding to a multipart/blah node in the tree). This makes it easy to figure out below which non-leaf node(s) a change occurred. If you have two signatures in-hand (one author, one mediator), it's fairly straightforward to isolate the change and then figure out if you want to render/scan/remove/whatever it. -MSK ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GitHub/development tools integration project Gsoc'15
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 18.03.2015 um 16:29 schrieb Prabhanshu Abhishek: 2)the gsoc idea page says that it is necessary to fix at least one bug, but i have not been able to find some bug that is beginner friendly and related to my project, can you give me some bug to work on that will help me on my project. It doesn't have to be related to that particular project idea. If you don't find a bug in our bug trackers, it can be also be a small feature or improvement you come up with yourself. It could also be a test case for a piece of code not yet covered by a test (if the test case is not all too obvious). 3)some other necessary things that i should work upon before submitting my proposal. 4)and lastly who will be my mentor, can you tell me? We generally don't know yet who's going to mentor which project. Cheers Florian -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVCzhaAAoJEEceGbPdavl7KSEH/igYUM4wUq3+y0prO2pQ9gyl vb1L1kVlwmoOCFnmOfStRPfH0AAhrvzM+MYpyzJtHQaJZUFTg+Qs0hWb0u7wvU96 5Iy6Zev4UAvzzJ6sVE3UiAovs6IjurQsu4qwzsgYKPpH65gYPBEtb/qSh8UF9vvm Vw9UgfSBzuPM9R+SsxLpliB2oYXDj1/RqpIdhtnAC9xORnCu3D5xpyHS6Ge8ZUAV qLPJiaSIC/Js/xumiPl1Uq+xLgwnlO1+FsJrkwF6rgV79x5Of80gI3ysuEWhwyrn /AbScAjxCBirW2qV5m4FFwMJ0QSztc3OnKEOx61rZ8dZgANFlMn8AjVSiqY2RuI= =AdNV -END PGP SIGNATURE- ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Message threading - requesting some wisdom
Hi folks I assume a great deal of thought has gone into message threading and how it works. Is there anyone willing to share the basics with me - specifically as it relates to Mailman and related projects? There is of course plenty of information on google which I am researching including the seminal http://www.jwz.org/doc/threading.html but if there is anyone on the Mailman team willing to give me a Mailman oriented understanding that would be great. It appears to me there are a number of ways to implement threading, and how it is done is somewhat arbitrary. For example, this description of Gmail threading http://xkahn.zoned.net/software/evolution/threads/ seems to suggest that Gmail includes arbitrary business rules for threading based on message content (i.e. subject prefix). In particular I want to know the basics of message threading - i.e. ** What data defines how emails are connected to one another? ** How is that connecting data organised (i.e. in a tree, a flat list, by date, whatever)? ** What happens when thread data is missing (i.e. a message in a thread is deleted)? ** Are there any algorithms/mechanisms/patterns that are effective for implementing threading? ** Any code in Mailman/Hyperkitty/elsewhere that is particularly good to study? ** Anything else I should know? I’m wanting to find the most simple and effective way to deal with threading which of course has the potential to be complex if I get it wrong. thanks! as ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] GitHub/Development tools integration project Gsoc'15
Hi, I am Prabhanshu Abhishek, second year undergraduate student at Indian Institute of Technology,Kanpur (IIT Kanpur), studying Computer Science and Engineering. I am very much interested in the project GitHub/Development tools integration under Gsoc'15. I have given much thought on how it can be implemented, can i get feedback on my implementation. The draft for the proposal: Creating a tool that will take a thread from a Mailman mailing list and turn it into a thread on a GitHub issue. In short: I propose to make a user interface which will be accessible to the list administrator. If the administrator thinks that a thread or multiple threads could be an issue for his/her development organisation's repository, he/she can mark the thread for posting, and the backend will process it with the GitHub API to send it to the repository as an issue. In detail: 1) User interface: A simple webpage that will have an option to mark threads and a send_to_github button which initiates the backend process to convert the thread into a series of comments used to raise the issue. 2) Processing emails: The UI for the administrator will have an interface to edit emails so as to discard any unwanted piece of the emails (such as the reply emails containing the previous mails' conversation). The backend process will also be able to do the initial work for this on its own (as the previous mail conversation probably starts with ). 3) Github API: The thread's subject will be, by default, used as the main title for the issue, or the administrator can provide an alternate title. The backend will find out which other emails are to be posted as comments (as the emails header contains an in reply to: field). The tool will use the administrator's GitHub username as the creator of the issue. It will use OAuth2 authentication with GitHub. The issue comment will contain content of the email within the original mailing list thread. The tool will use this information to post the issue to the GitHub repository's issue tracker, using the GitHub API. Actually, the user interface can be made available to all the users subscribed to that mailing list. 4) The backend will be written in Python, which will interact with the REST API and the GitHub APIs to do all its work. I have some specific questions also, like: Should this be a standalone web interface, or should it be a plugin for HyperKitty or Postorius, or should it be a command-line tool. Hoping for some feedback on the proposal'draft. Also, I think there is no mentor specified to the project, so, i want to ask if some of you might be interested in this project. Thanks, Prabhanshu Abhishek ___ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
