[Mailman-Developers] GSOC'15 blog report - mailman client in JS
Hello everyone, I have put up a blog report http://black-perl.me/black-perl-gsoc-with-mailman-pre-end-term-report/ . Interested people can have a look and any feedback is always welcomed. Thanks, Ankush Sharma IIT-BHU Varanasi, India - 221005 http://black-perl.me ___ 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] Mid term blog report
On 2015-07-02 11:17 AM, Ankush Sharma wrote: Hello everyone, I have put up a blog post regarding my GSoC project *Mailman Client in JS. *Interested people can follow this link : http://black-perl.me/black-perl-gsoc-with-mailman-mid-term-report Expecting feedback from your side ! You mention that a bunch of the tests are failing due to code changes. Is this something the rest of us can help you out on? There's no requirement in GSoC that you write and fix every single test personally, and sometimes test fixes are tasks suitable for people who want a small, self-contained contribution opportunity or a quick thing to do. Would these maybe be something like that, or would you need to understand your code really deeply to work on the fixes? Terri ___ 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] Mid term blog report
Hi, Thanks Terri for giving feedback on the report. I have written the tests from scratch for the implementation of the mailman-client in JS. So, I got to a point where I need to do a bit of refactoring to the code base to remove some redundant logic. Due to this some minor issues are coming with the testing. Yeah, I agree with you that these things could provide opportunities for beginners. So, I will try to work on the tough one's first that require deeper understanding of code and later on may be the easy ones' or may be leave them for beginners. Thanks, Ankush Sharma https://black-perl.me On Tue, Jul 7, 2015 at 11:22 PM, Terri Oda te...@toybox.ca wrote: On 2015-07-02 11:17 AM, Ankush Sharma wrote: Hello everyone, I have put up a blog post regarding my GSoC project *Mailman Client in JS. *Interested people can follow this link : http://black-perl.me/black-perl-gsoc-with-mailman-mid-term-report Expecting feedback from your side ! You mention that a bunch of the tests are failing due to code changes. Is this something the rest of us can help you out on? There's no requirement in GSoC that you write and fix every single test personally, and sometimes test fixes are tasks suitable for people who want a small, self-contained contribution opportunity or a quick thing to do. Would these maybe be something like that, or would you need to understand your code really deeply to work on the fixes? Terri ___ 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/ankush.sharma.ece12%40itbhu.ac.in Security Policy: http://wiki.list.org/x/QIA9 ___ 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 - Interested in contributing to Hyperkitty
Stephen commented on my proposal that instead of storing all downloads on the server, we should only cache recent ones and build the others on request, because many archives are only downloaded once when they are ported to a different archiver. Since this is in contradiction to the suggestion Aurelien made, I'm going to leave my proposal as-is for now. Hopefully the link to this thread in my proposal will be a source of up-to-date information on project constraints during the application review process. On Thu, Mar 26, 2015 at 11:15 AM, David Udelson d...@cornell.edu wrote: I'm already using the jobs infrastructure provided by the django-extensions package: http://django-extensions.readthedocs.org/en/latest/jobs_scheduling.html Cool. I didn't know about this extension, but it looks like it does what we need. So the background process would be its own file in the jobs directory, and we could leave it to the admin to setup the crontab? I have another test server with more current info if you want, but I break it regularly. It's lists-dev.cloud.fedoraproject.org Thanks for linking this. I got my own local dev server working yesterday, but this one is much more populated. We do put the attachment in the mbox, as a MIME component like in every email. I see how this works now. Are the attachments always Base64 encoded? Another possible nice-to-have feature I thought of yesterday is a download link that scripts can use to get archives (e.g. /download?year=xmonth=y). On the other hand, maybe this is just a security risk that has no actual use case, but I'd still like to have a second opinion on this. Well, there still is the authentication issue. I guess getting the scripts to authenticate would be a little complicated, but otherwise does this seem like something worth including? If my proposal gets accepted, I'm ok with leaving this as an open question until it becomes clear whether or not I'm going to have extra time at the end of the summer. Thanks, David On Thu, Mar 26, 2015 at 7:33 AM, Aurelien Bompard aurel...@bompard.org wrote: In my proposal I suggested using any of several asynchronous job queue libraries, such as Celery or Huey. These all use redis as a back-end. Because I have no experience with asynchronous job queues, I'm not sure if this is too much baggage for our purposes. Maybe we just don't want the extra dependencies. Yeah, we don't want to add another database or an AMQP server just for that. We must keep it simple for admins to deploy. Regarding cron jobs, there's also django-background-task which is a simple django addon that might do what we need. Again, if we don't want/need the extra dependency, rolling our own cron job should be fairly straight-forward. I'm already using the jobs infrastructure provided by the django-extensions package: http://django-extensions.readthedocs.org/en/latest/jobs_scheduling.html I did consider django-background-task but django-extensions seemed like a better fit, because django-background-task seems written for delayed tasks, not periodic tasks (well, a task could call itself again when done, but it seems like a hack). I'm not opposed to switching to django-background-task if we use the delayed job feature or if we need the extra flexibility of choosing exactly how many seconds apart we want our tasks to run. If we choose to pre-build the mbox files, we can't simply have them served through the webserver, because some lists are private Then there is also an authentication step? Yeah, we must use HyperKitty's authentication and check if the user is allowed to see the archive. So the files can't be served by the webserver like static files. I noticed on the test server that I can't actually look at any of the mailing lists because they're all private. If you're looking at lists.stg.fedoraproject.org, it's currently very outdated (still running the Python2-compatible branch of Mailman 3). I have another test server with more current info if you want, but I break it regularly. It's lists-dev.cloud.fedoraproject.org When we create the mbox file, do we simply note that an attachment existed (e.g. Attachment: myattachment.txt) or do we actually put the attachment in the mbox? AFAIK mbox is a plaintext format, so if the latter is the case then I'm not exactly sure how this would work... We do put the attachment in the mbox, as a MIME component like in every email. If you choose view source when looking at an email with attachments, you'll see how it's done. Are there going to be any issues handling unicode foreign characters or with file locks? Right now it looks like we should only have one process handling the mbox, but is it possible that more than one could be spawned somehow? No, mbox files are not designed for concurrent writes, so it's better to have a single process write to them. Another possible nice-to-have
Re: [Mailman-Developers] GSoC 15 - Interested in contributing to Hyperkitty
In my proposal I suggested using any of several asynchronous job queue libraries, such as Celery or Huey. These all use redis as a back-end. Because I have no experience with asynchronous job queues, I'm not sure if this is too much baggage for our purposes. Maybe we just don't want the extra dependencies. Yeah, we don't want to add another database or an AMQP server just for that. We must keep it simple for admins to deploy. Regarding cron jobs, there's also django-background-task which is a simple django addon that might do what we need. Again, if we don't want/need the extra dependency, rolling our own cron job should be fairly straight-forward. I'm already using the jobs infrastructure provided by the django-extensions package: http://django-extensions.readthedocs.org/en/latest/jobs_scheduling.html I did consider django-background-task but django-extensions seemed like a better fit, because django-background-task seems written for delayed tasks, not periodic tasks (well, a task could call itself again when done, but it seems like a hack). I'm not opposed to switching to django-background-task if we use the delayed job feature or if we need the extra flexibility of choosing exactly how many seconds apart we want our tasks to run. If we choose to pre-build the mbox files, we can't simply have them served through the webserver, because some lists are private Then there is also an authentication step? Yeah, we must use HyperKitty's authentication and check if the user is allowed to see the archive. So the files can't be served by the webserver like static files. I noticed on the test server that I can't actually look at any of the mailing lists because they're all private. If you're looking at lists.stg.fedoraproject.org, it's currently very outdated (still running the Python2-compatible branch of Mailman 3). I have another test server with more current info if you want, but I break it regularly. It's lists-dev.cloud.fedoraproject.org When we create the mbox file, do we simply note that an attachment existed (e.g. Attachment: myattachment.txt) or do we actually put the attachment in the mbox? AFAIK mbox is a plaintext format, so if the latter is the case then I'm not exactly sure how this would work... We do put the attachment in the mbox, as a MIME component like in every email. If you choose view source when looking at an email with attachments, you'll see how it's done. Are there going to be any issues handling unicode foreign characters or with file locks? Right now it looks like we should only have one process handling the mbox, but is it possible that more than one could be spawned somehow? No, mbox files are not designed for concurrent writes, so it's better to have a single process write to them. Another possible nice-to-have feature I thought of yesterday is a download link that scripts can use to get archives (e.g. /download?year=xmonth=y). On the other hand, maybe this is just a security risk that has no actual use case, but I'd still like to have a second opinion on this. Well, there still is the authentication issue. Aurélien ___ 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 - Proposal A Dashboard for Admins/Owners/Moderators
Hi guys, I have updated my proposal for A Dashboard for Admins/Owners/Moderators project. I have tried to address the issues raised. Reviews on it are welcome. Regards, Shreyas Lakhe ___ 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 - Interested in contributing to Hyperkitty
I'm already using the jobs infrastructure provided by the django-extensions package: http://django-extensions.readthedocs.org/en/latest/jobs_scheduling.html Cool. I didn't know about this extension, but it looks like it does what we need. So the background process would be its own file in the jobs directory, and we could leave it to the admin to setup the crontab? I have another test server with more current info if you want, but I break it regularly. It's lists-dev.cloud.fedoraproject.org Thanks for linking this. I got my own local dev server working yesterday, but this one is much more populated. We do put the attachment in the mbox, as a MIME component like in every email. I see how this works now. Are the attachments always Base64 encoded? Another possible nice-to-have feature I thought of yesterday is a download link that scripts can use to get archives (e.g. /download?year=xmonth=y). On the other hand, maybe this is just a security risk that has no actual use case, but I'd still like to have a second opinion on this. Well, there still is the authentication issue. I guess getting the scripts to authenticate would be a little complicated, but otherwise does this seem like something worth including? If my proposal gets accepted, I'm ok with leaving this as an open question until it becomes clear whether or not I'm going to have extra time at the end of the summer. Thanks, David On Thu, Mar 26, 2015 at 7:33 AM, Aurelien Bompard aurel...@bompard.org wrote: In my proposal I suggested using any of several asynchronous job queue libraries, such as Celery or Huey. These all use redis as a back-end. Because I have no experience with asynchronous job queues, I'm not sure if this is too much baggage for our purposes. Maybe we just don't want the extra dependencies. Yeah, we don't want to add another database or an AMQP server just for that. We must keep it simple for admins to deploy. Regarding cron jobs, there's also django-background-task which is a simple django addon that might do what we need. Again, if we don't want/need the extra dependency, rolling our own cron job should be fairly straight-forward. I'm already using the jobs infrastructure provided by the django-extensions package: http://django-extensions.readthedocs.org/en/latest/jobs_scheduling.html I did consider django-background-task but django-extensions seemed like a better fit, because django-background-task seems written for delayed tasks, not periodic tasks (well, a task could call itself again when done, but it seems like a hack). I'm not opposed to switching to django-background-task if we use the delayed job feature or if we need the extra flexibility of choosing exactly how many seconds apart we want our tasks to run. If we choose to pre-build the mbox files, we can't simply have them served through the webserver, because some lists are private Then there is also an authentication step? Yeah, we must use HyperKitty's authentication and check if the user is allowed to see the archive. So the files can't be served by the webserver like static files. I noticed on the test server that I can't actually look at any of the mailing lists because they're all private. If you're looking at lists.stg.fedoraproject.org, it's currently very outdated (still running the Python2-compatible branch of Mailman 3). I have another test server with more current info if you want, but I break it regularly. It's lists-dev.cloud.fedoraproject.org When we create the mbox file, do we simply note that an attachment existed (e.g. Attachment: myattachment.txt) or do we actually put the attachment in the mbox? AFAIK mbox is a plaintext format, so if the latter is the case then I'm not exactly sure how this would work... We do put the attachment in the mbox, as a MIME component like in every email. If you choose view source when looking at an email with attachments, you'll see how it's done. Are there going to be any issues handling unicode foreign characters or with file locks? Right now it looks like we should only have one process handling the mbox, but is it possible that more than one could be spawned somehow? No, mbox files are not designed for concurrent writes, so it's better to have a single process write to them. Another possible nice-to-have feature I thought of yesterday is a download link that scripts can use to get archives (e.g. /download?year=xmonth=y). On the other hand, maybe this is just a security risk that has no actual use case, but I'd still like to have a second opinion on this. Well, there still is the authentication issue. Aurélien ___ 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:
Re: [Mailman-Developers] GSoC 15 - Interested in contributing to Hyperkitty
Hey David, here are my thoughs on the challenges: 1) Determine which messages to include in the mbox. An entire list archive is clearly one choice, but is there also interest in generating mbox files for specific threads, list archieves between specific dates, etc.? Hmm, depending on the architecture we choose, we may not have a lot of options. I'd like to see at least whole-list and last 30 days archives though, this last one being useful to those who want to use their mail client and seed it with the latest discussion to reply in-thread. 2) For each message, append plaintext to mbox file. Is this the part where we risk blocking the UI? Certainly for hundreds of thousands of messages, this will be a computationally intensive step, so will this have to be run in a separate thread? Yeah, with a lot of messages, and with possible attachments, we may be creating hundred of megabytes or maybe gigabytes of data. This has to be done outside of the webserver process, so we'll need something like a task queue and a daemon process or a cron job. Or we could be building and appending to the mbox files when new messages arrive, which would take up more disk space but would be more fluid from a UI point of view. It would also probably be much more resource-intensive than a cron job, because the mbox files will be large and should be gzipped, so it would be better to append a batch of emails than opening and closing on each incoming email. I'm leaning towards pre-rendering the mbox files in a regular cron job and warning the user in the UI that the archive contains all email up to the last hour, for example. We can't use the prototype archiver because we need to filter the messages content and escape email adresses to protect from spam harvesters, like MM2.1 currently does. 3) Present mbox file to user for download. I'm hoping this is a trivial step, but I'm not sure about some of the specifics. For example, is Hyperkitty only able to run on apache, or is the choice of web server entirely up to the web admin? How we ultimately serve the file will depend on these details. HyperKitty runs on Django, which can be served by whichever WSGI-compliant server the admin chooses (Apache's mod_wsgi, uWSGI, gunicorn, etc.). If we choose to pre-build the mbox files, we can't simply have them served through the webserver, because some lists are private (only available to subscribers). I hope that clearifies a bit. Aurélien ___ 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 - Interested in contributing to Hyperkitty
Thanks for your feedback Aurelien. we'll need something like a task queue and a daemon process or a cron job In my proposal I suggested using any of several asynchronous job queue libraries, such as Celery or Huey. These all use redis as a back-end. Because I have no experience with asynchronous job queues, I'm not sure if this is too much baggage for our purposes. Maybe we just don't want the extra dependencies. Regarding cron jobs, there's also django-background-task https://github.com/lilspikey/django-background-task, which is a simple django addon that might do what we need. Again, if we don't want/need the extra dependency, rolling our own cron job should be fairly straight-forward. If we choose to pre-build the mbox files, we can't simply have them served through the webserver, because some lists are private Then there is also an authentication step? I noticed on the test server that I can't actually look at any of the mailing lists because they're all private. So we should be able to use pre-existing code for this step? with possible attachments, we may be creating hundred of megabytes or maybe gigabytes of data When we create the mbox file, do we simply note that an attachment existed (e.g. Attachment: myattachment.txt) or do we actually put the attachment in the mbox? AFAIK mbox is a plaintext format, so if the latter is the case then I'm not exactly sure how this would work... Are there going to be any issues handling unicode foreign characters or with file locks? Right now it looks like we should only have one process handling the mbox, but is it possible that more than one could be spawned somehow? Another possible nice-to-have feature I thought of yesterday is a download link that scripts can use to get archives (e.g. /download?year=xmonth=y). On the other hand, maybe this is just a security risk that has no actual use case, but I'd still like to have a second opinion on this. Additionally, here are some tentative weekly goals I have for the project. Feedback on the order/plausibility of these would be awesome! Week 1) Given an email message, the message headers and body are extracted and stored in a local file in mbox format. All unit tests passing. Week 2) Attachments are represented in the mbox file as well. Email addresses are escaped. There are no encoding errors (no boxes or ?s). All unit tests passing. Week 3) Explore options for possible asynchronous queue managers. Weeks 4-5) When a mailing archive is created, a background process (implemented using chosen backend) is attached to it for managing its mbox files. Existing processes are started when the server starts, and the server can efficiently manage all of these (possibly tens/hundreds?) of tasks. All unit tests passing. Week 6) Clean code and tests before midterm review. All unit tests passing. Week 7-8) Each background process unzips two mbox files, one for the entire list and one for the past month, adds any messages that have come in in the past hour (in mbox format) and rezips the archive. All unit tests passing. Week 9-10) Mbox archives are served by hyperkitty upon request. Hyperkitty does not at this point authenticate users. All unit tests passing. Week 11) Hyperkitty authenticates the user before serving the mbox request. If the request is denied, the user is notified via the UI. All unit tests passing. Week 12) Code review and cleaning, final check on unit tests (they should all be passing). Thanks, David On Wed, Mar 25, 2015 at 4:18 AM, Aurelien Bompard aurel...@bompard.org wrote: Hey David, here are my thoughs on the challenges: 1) Determine which messages to include in the mbox. An entire list archive is clearly one choice, but is there also interest in generating mbox files for specific threads, list archieves between specific dates, etc.? Hmm, depending on the architecture we choose, we may not have a lot of options. I'd like to see at least whole-list and last 30 days archives though, this last one being useful to those who want to use their mail client and seed it with the latest discussion to reply in-thread. 2) For each message, append plaintext to mbox file. Is this the part where we risk blocking the UI? Certainly for hundreds of thousands of messages, this will be a computationally intensive step, so will this have to be run in a separate thread? Yeah, with a lot of messages, and with possible attachments, we may be creating hundred of megabytes or maybe gigabytes of data. This has to be done outside of the webserver process, so we'll need something like a task queue and a daemon process or a cron job. Or we could be building and appending to the mbox files when new messages arrive, which would take up more disk space but would be more fluid from a UI point of view. It would also probably be much more resource-intensive than a cron job, because the mbox files will be large and should be gzipped, so it would be better to append a batch of emails
Re: [Mailman-Developers] GSoC 15 - Interested in contributing to Hyperkitty
David Udelson writes: Thanks for your feedback Aurelien. we'll need something like a task queue and a daemon process or a cron job In my proposal I suggested using any of several asynchronous job queue libraries, such as Celery or Huey. [...] So far, this is good discussion for the list. IMO, you want to link to the archives for this thread in your proposal on Melange. Additionally, here are some tentative weekly goals I have for the project. Feedback on the order/plausibility of these would be awesome! IMHO, this part should just have been directly edited into the proposal on Melange with a remark here that you did it. Most of the people on this list are either uninterested or not competent to comment on the list of goals. Alternatively, do both but it should definitely be in your proposal already. ___ 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 - Interested in contributing to Hyperkitty
My proposal has been updated. I apologize if I breached mailing-list ediquette, I'll get the hang of this eventually :) On Wed, Mar 25, 2015 at 10:14 PM, Stephen J. Turnbull turnb...@sk.tsukuba.ac.jp wrote: David Udelson writes: Thanks for your feedback Aurelien. we'll need something like a task queue and a daemon process or a cron job In my proposal I suggested using any of several asynchronous job queue libraries, such as Celery or Huey. [...] So far, this is good discussion for the list. IMO, you want to link to the archives for this thread in your proposal on Melange. Additionally, here are some tentative weekly goals I have for the project. Feedback on the order/plausibility of these would be awesome! IMHO, this part should just have been directly edited into the proposal on Melange with a remark here that you did it. Most of the people on this list are either uninterested or not competent to comment on the list of goals. Alternatively, do both but it should definitely be in your proposal already. ___ 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 - Interested in contributing to Hyperkitty
David Udelson writes: My proposal has been updated. I apologize if I breached mailing-list ediquette, I'll get the hang of this eventually :) No etiquette problem. Those are my personal views about effective use of the mailing list and Melange, respectively. I suspect from past experience my views reflect those of other mentors and mailman developers pretty well, but if they don't, I'm sure they'll speak up. :-) There's no doubt about updating Melange from your point of view: we mentors are human, we get a ton of mail (Melange pings us on every change to any proposal in our org, and several of us are org admins increasing the mail signficiantly), and mail is easy to drop on the floor unless you deal with it completely immediately. Unfortunately, we do that. OTOH, in theory you proposal document on Melange can always reflect your best efforts in one place, and we won't miss it. ;-) ___ 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-Proposal for A Dashboard for Admins/Owners/Moderators
Hi guys, I have updated my application on melange for A Dashboard for Admins/Owners/Moderators project. Reviews on it are welcome. Regards, Shreyas Lakhe ___ 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 - Interested in contributing to Hyperkitty
I'm interested in contributing to the Hyperkitty archiver. Specifically, it looks like some requested features for Hyperkitty include rss syndication for entire mailing lists/specific users/specific threads, and the ability to view entire threads as plaintext and download that plaintext. We don't have either feature yet, but I think RSS syndication would be much too short for a GSOC project. There's always been demand for a way to download a list archive as an mbox file, and it's reasonably complicated if you want to avoid blocking the UI, so this may be a good project similar to the plaintext threads feature you mention. Aurélien ___ 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 - Interested in contributing to Hyperkitty
I have submitted a proposal on Google Melange. Any feedback I could get about my project constraints would be great! Thanks, David On Tue, Mar 24, 2015 at 8:23 AM, Aurelien Bompard aurel...@bompard.org wrote: I'm interested in contributing to the Hyperkitty archiver. Specifically, it looks like some requested features for Hyperkitty include rss syndication for entire mailing lists/specific users/specific threads, and the ability to view entire threads as plaintext and download that plaintext. We don't have either feature yet, but I think RSS syndication would be much too short for a GSOC project. There's always been demand for a way to download a list archive as an mbox file, and it's reasonably complicated if you want to avoid blocking the UI, so this may be a good project similar to the plaintext threads feature you mention. Aurélien ___ 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/dru5%40cornell.edu Security Policy: http://wiki.list.org/x/QIA9 ___ 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 - Interested in contributing to Hyperkitty
Sent this email to Aurélien's personal email by mistake the first time (sorry Aurélien!). I'll get used to the mailing list evenually There's always been demand for a way to download a list archive as an mbox file This is a feature I am interested in pursuing. From a very (very) high level, the process of creating an mbox file out a list archive should entail: 1) Determine which messages to include in the mbox. An entire list archive is clearly one choice, but is there also interest in generating mbox files for specific threads, list archieves between specific dates, etc.? 2) For each message, append plaintext to mbox file. Is this the part where we risk blocking the UI? Certainly for hundreds of thousands of messages, this will be a computationally intensive step, so will this have to be run in a separate thread? 3) Present mbox file to user for download. I'm hoping this is a trivial step, but I'm not sure about some of the specifics. For example, is Hyperkitty only able to run on apache, or is the choice of web server entirely up to the web admin? How we ultimately serve the file will depend on these details. Aurélien, just because I'm new to the codebase, what are the challenges you see in implementing this feature? Whatever details you can give me will help me set my milestones. Thanks, David On Tue, Mar 24, 2015 at 8:23 AM, Aurelien Bompard aurel...@bompard.org wrote: I'm interested in contributing to the Hyperkitty archiver. Specifically, it looks like some requested features for Hyperkitty include rss syndication for entire mailing lists/specific users/specific threads, and the ability to view entire threads as plaintext and download that plaintext. We don't have either feature yet, but I think RSS syndication would be much too short for a GSOC project. There's always been demand for a way to download a list archive as an mbox file, and it's reasonably complicated if you want to avoid blocking the UI, so this may be a good project similar to the plaintext threads feature you mention. Aurélien ___ 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/dru5%40cornell.edu Security Policy: http://wiki.list.org/x/QIA9 ___ 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 - Interested in contributing to Postorius
Hi My name is Akshay Shah. I'm currently pursuing my undergraduate degree at PES University, Bangalore (India). I have 2 years of experience with python and 3 years of experience with Javascript and HTML. I am interested in contributing to the Postorius Web UI. Some of the ideas on the 'Ideas Page' took my interest. More specifically, the Dashboard for admins/owners/moderators, Mailman client written in Javascript and the subscriber-profile pages. Regarding these, I have the following questions: 1. Can the Dashboard and Subscriber profile page be done together within the GSoC timeline? Is there any way that I can display my ability to pursue both of these? 2. I have fairly good amount of experience with NodeJs, will my resume be a good enough factor for you to decide or would you rather have me do a pre-project (I would love to do a pre-project)? 3. [NEW IDEA] Introducing search feature in the Web UI. Search lists, members, settings, and/or domains. Would introduction of Elastic Search with NodeJs be a feasible option for the GSoC Timeline? How detailed should I get about introduction of this topic? Sincerely Akshay ___ 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 - Interested in contributing to Postorius
Akshay Shah writes: My name is Akshay Shah. Pleased to meet you, Akshay. Welcome to Mailman! 1. Can the Dashboard and Subscriber profile page be done together within the GSoC timeline? I think this would not be useful as the users' tasks are quite different. It's better to pick one and do a super job on it than to do merely satisfactory work on both. 2. I have fairly good amount of experience with NodeJs, will my resume be a good enough factor for you to decide or would you rather have me do a pre-project (I would love to do a pre-project)? Rather than a pre-project we prefer you to do a bugfix. Any bug, easy is OK. Feature implementation is also OK. The point is that you become familiar with our workflow as much as it is for us to see your work output. https://bugs.launchpad.net/mailman Use the advanced search link with tag = easy (the tag entry field is way down at the bottom). Note that most of the easy issues seem to be taken in that somebody's already working on them, check the comments to find out who. Most likely most of the issue have *not* been checked for easy so don't let lack of an easy tag stop you from working on an interesting issue. If it isn't clear how to proceed after a few minutes, you might want to ask here if the issue is maybe too hard for a GSoC application before continuing (and maybe try a different issue in the meantime). 3. [NEW IDEA] Introducing search feature in the Web UI. Search lists, members, settings, and/or domains. Would introduction of Elastic Search with NodeJs be a feasible option for the GSoC Timeline? How detailed should I get about introduction of this topic? I don't see why this feature needs to be so complex. There are a few sites like universities and project forges that deal with thousands of lists and tens of thousands of users, but thousands is still easy and efficient enough to do with a simple database lookup (and regexp matching on the results if desired) through the Django ORM (HyperKitty and Postorius) or SQLAlchemy and the REST interface (Mailman core), and it will be consistent with the code in the rest of the applications. If you have use cases where a more complex search would be helpful, please explain it. Regards ___ 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 - Interested in contributing to Hyperkitty
On 2015-03-22 10:23 PM, David Udelson wrote: I'm interested in contributing to the Hyperkitty archiver. Specifically, it looks like some requested features for Hyperkitty include rss syndication for entire mailing lists/specific users/specific threads, and the ability to view entire threads as plaintext and download that plaintext. I have the following questions regarding these features: I talked with David on IRC, but in case anyone else is wondering: RSS feeds was a project a few years ago: http://www.google-melange.com/gsoc/project/details/google/gsoc2013/joanna/5831844033462272 I don't know offhand if the code was merged into upstream, but my preference is as always to make use of code we have if we can, so RSS feeds are maybe not going to make for a good hyperkitty project this year. Terri ___ 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 - Interested in contributing to Postorius
Hi My name is Akshay Shah. I'm currently pursuing my undergraduate degree at PES University, Bangalore (India). I have 2 years of experience with python and 3 years of experience with Javascript and HTML. I am interested in contributing to the Postorius Web UI. Some of the ideas on the 'Ideas Page' took my interest. More specifically, the Dashboard for admins/owners/moderators, Mailman client written in Javascript and the subscriber-profile pages. Regarding these, I have the following questions: 1. Can the Dashboard and Subscriber profile page be done together within the GSoC timeline? Is there any way that I can display my ability to pursue both of these? 2. I have fairly good amount of experience with NodeJs, will my resume be a good enough factor for you to decide or would you rather have me do a pre-project (I would love to do a pre-project)? 3. [NEW IDEA] Introducing search feature in the Web UI. Search lists, members, settings, and/or domains. Would introduction of Elastic Search with NodeJs be a feasible option for the GSoC Timeline? How detailed should I get about introduction of this topic? Sincerely Akshay ___ 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 - Interested in contributing to Hyperkitty
Hello, My name is David Udelson. I am a freshman Computer Science undergraduate at Cornell University. I have 3 years of experience with python under my belt, but I've never contributed to an open source project because I've never known where to begin. I'm hoping GSoC will provide me with that starting point, as well as an opportunity to make some meaningful contributions to the open source community. I'm interested in contributing to the Hyperkitty archiver. Specifically, it looks like some requested features for Hyperkitty include rss syndication for entire mailing lists/specific users/specific threads, and the ability to view entire threads as plaintext and download that plaintext. I have the following questions regarding these features: 1) Are these features definitely expected to be in future releases, or are they just nice-to-haves? If there are more important/pressing issues that the Hyperkitty devs think I could implement instead, I would prefer to work on those. 2) Are both of these features implementable within the GSoC timeline, or should I only pursue one of them? Thanks, David ___ 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
DA-IICT,Gandhinagar
On Sat, Mar 21, 2015 at 9:03 AM, Stephen J. Turnbull step...@xemacs.org
wrote:
Abhilash Raj writes:
Admin can change there values.
You meant 'their' here and not 'there'.
(-: Lighten up on the spelling stuff. *I* make that typo regularly
(I think I mostly manage to correct it before posting, I hope :-).
You're right about reviewing the language, though. I had no idea what
Prakhar (@prakhar126: is that your preferred form of address?) was
talking about. Thanks for the translation!
Prakhar is fine. yeah prakhar126 is my email address.
I will have table for style which will be having only changed
attributes in it and rest of the attributes will be null.
I'm not a fan of this API using nulls. I would prefer a special value
of inherit or defer to indicate that omission of a value is
deliberate. (This can be hidden from end users.)
So you want to store only changed attributes under a specific list style in
the table ? Isn't that make the table dynamic in width as sometimes only
one attribute is stored and sometimes 3-4 attributes are stored ?
It's possible that None (or NULL in the backing store) is an
appropriate way to implement inherit, but only if concrete styles
(that is, styles that are actually part of a mailing list) have all
attributes required. I don't see how this is possible if we want to
allow for extensibility by users.
By extensibility you mean to add new attributes ? or add new class as there
are few classes in the mailman/src/mailma/styles/base.py (but that can't be
possible through web interface, I guess? )
For example if admin has changed the attribute
send_welcome_message under discussion and other attribute like
advertise under public list then these two attributes with
their values defined by admin will be stores under the list style
name and rest all the attributes which have been there in the
mailinglist table will be null for the list style table. Now by
using apply function on list style table the values of attributes
will be overwritten on the mailing list table when admin apply
that list.
I don't understand when apply happens. I'm guessing that the
proposal is to have a stack of styles in the configuration UI:
{ name: list specific, read-only: no, notmetoo_default: no }
{ name: anonymous_overlay, read-only: yes, redact_all_addresses: yes }
{ name: discussion, read-only: yes, usual discussion list options ... }
If there are more than 1 attributes in the last section of above list style
configuration then the list table will not have the same width ?
where unspecified attributes are inherit, and when the admin is
done, they hit an apply button, which searches the stack from top down
and takes the first non-inherit value found. The constructed
configuration is validated for all required options being set.
Finally, the list configuration is instantiated in the list table.
unspecified attributes ? You mean attributes other than that of mailing
list table ?
Only admin will be able to change the settings and by having user
section I mean we have to specify the admin of each style so that
at time of showing present styles for a particular admin we will
fetch only styles with that admin name from the style table, as
we don't want other (admins) to change saved styles for
particular admin. That is why admin field is essential in the
style table.
Lists may have multiple admins AFAIK. I think the list field I
propose above is a better construct.
Yeah that read only and editable thing will be better and no need to add
user_id for each list style.
If we create styles for ease-of-implementation of Admins and Moderators,
it is required that we support some level of authorization to edit/use
those styles. So for that purpose each style create would belong to a
`User` and can only be viewed/edited by him. Ideally it would be nice if
we could set different access levels for styles, like public, read_only,
private.
I thought about this for a few minutes, and I think we need a concrete
schema and some use cases. For example, I don't see why styles would
need to be private. And although I used read-only myself, I just
meant writing not authorized. One could also simply have all styles
be read only once registered (unused locally-defined styles could be
garbage-collected or explicitly deleted).
yeah that's the main objective.
This is not the association of users with styles, it is just
meant for authorization purpose.
Sure, users are always about authorization in this kind of
application. My point is that there are too many kinds of user in
the mailing list context, and that in Mailman 3, ordinary subscribers
are included when we talk about user in the sense used in the code.
Here by user I mean admins and I will take care of it in future to be
specific.
I think we are still not
Re: [Mailman-Developers] GSOC'15: Improving styles for lists
Prakhar Joshi DA-IICT,Gandhinagar On Sat, Mar 21, 2015 at 9:10 PM, Stephen J. Turnbull step...@xemacs.org wrote: I think we're pretty much in agreement on most things. Please update your proposal on melange to reflect this discussion. (The quoting has gotten too fragmented to be very useful in understanding what progress has been made.) Okay Will include all the key points discussed here in the proposal and will update it on milange . Thanks, ___ 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
I think we're pretty much in agreement on most things. Please update your proposal on melange to reflect this discussion. (The quoting has gotten too fragmented to be very useful in understanding what progress has been made.) ___ 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:
So you want to store only changed attributes under a specific list
style in the table ? Isn't that make the table dynamic in width as
sometimes only one attribute is stored and sometimes 3-4 attributes
are stored ?
That's a feature of object-relational managers (ORM) like SQLAlchemy.
In the background there will be a special value in the backing RDBMS
such as 'inherit' or perhaps NULL. But NULL is risky because it has
assorted interpretations.
By extensibility you mean to add new attributes ?
Attributes.
or add new class as there are few classes in the
mailman/src/mailma/styles/base.py (but that can't be possible
through web interface, I guess? )
Anything's possible, but Zope's experience with that level of
through-the-web extensibility was pretty bad. We don't need it.
{ name: list specific, read-only: no, notmetoo_default: no }
{ name: anonymous_overlay, read-only: yes, redact_all_addresses: yes }
{ name: discussion, read-only: yes, usual discussion list options ... }
If there are more than 1 attributes in the last section of above list style
configuration then the list table will not have the same width ?
I'm not sure what you're asking. Tables have to have the same width
by definition. You use NULLs or other special values to simulate
absence of a value, or a table join with optional attributes in a
separate table. Object-oriented DBs can have different attributes for
each object.
unspecified attributes ? You mean attributes other than that of mailing
list table ?
No, I mean the attributes I was too lazy to write in the schematic
example above.
I think we are still not on same page for list style storage as
still there are few things that I have in my mind like admin can't
create its own new attribute, he/she can just change the value of
the attribute, right ?
Probably. What I had in mind was that site admins could add new
Handlers that define attributes that aren't in the standard set, or
somebody could want to import a style from a later version of Mailman
that has such attributes.
And if that is true(admin can't add new attributes) than how can we
just store only changed/modified attributes in the styles table as
than the table will not have same width, lets assume for style A we
will store one attributes and for style B we will store two/more
attribute.
To create attributes on the fly is easy, even in RDBMS. You have a
table user_defined_attributes with columns foreign_key, attribute_id,
and attribute_value. Then do a select on the foreign key.
Basically the style table will be copy of mailing list table and
will have same number of column same as mailing list table with one
more column about permission (read_only or editable).
You need to be more careful about this. I'm not sure exactly how this
is implemented in Mailman 3, but a mailing list has attributes (such
as the owner and the moderator list) that are not relevant to styles.
There is going to be a question of whether to refactor the list schema
into a stylable part and a list-specific part (so that the
stylable part is literally a copy of the style) or to copy the
individual attributes from styles to the list configuration.
___
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
DA-IICT,Gandhinagar
On Sat, Mar 21, 2015 at 4:53 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
prakhar joshi writes:
So you want to store only changed attributes under a specific list
style in the table ? Isn't that make the table dynamic in width as
sometimes only one attribute is stored and sometimes 3-4 attributes
are stored ?
That's a feature of object-relational managers (ORM) like SQLAlchemy.
In the background there will be a special value in the backing RDBMS
such as 'inherit' or perhaps NULL. But NULL is risky because it has
assorted interpretations.
Yeah we will put values in the backing of RDBMS like the default values and
not NULL.
By extensibility you mean to add new attributes ?
Attributes.
See we have a lot of attributes in mailing list table so admin can create
extra attribute other than those or admin will just play with the present
attributes in mailman3 mailinglist table. (I am considering the later one)
or add new class as there are few classes in the
mailman/src/mailma/styles/base.py (but that can't be possible
through web interface, I guess? )
Anything's possible, but Zope's experience with that level of
through-the-web extensibility was pretty bad. We don't need it.
{ name: list specific, read-only: no, notmetoo_default: no }
{ name: anonymous_overlay, read-only: yes, redact_all_addresses: yes }
{ name: discussion, read-only: yes, usual discussion list options
... }
If there are more than 1 attributes in the last section of above list
style
configuration then the list table will not have the same width ?
I'm not sure what you're asking. Tables have to have the same width
by definition. You use NULLs or other special values to simulate
absence of a value, or a table join with optional attributes in a
separate table. Object-oriented DBs can have different attributes for
each object.
Yeah we will add other special values(like the default values) to simulate
the absence of a value in style table.
unspecified attributes ? You mean attributes other than that of mailing
list table ?
No, I mean the attributes I was too lazy to write in the schematic
example above.
I think we are still not on same page for list style storage as
still there are few things that I have in my mind like admin can't
create its own new attribute, he/she can just change the value of
the attribute, right ?
Probably. What I had in mind was that site admins could add new
Handlers that define attributes that aren't in the standard set, or
somebody could want to import a style from a later version of Mailman
that has such attributes.
See we have all the attributes in mailinglist table for list settings and
in the Handler we pick some set of attributes which are in mailing list
table and combine these attributes in a style name. right ? So that if
admin applied that style then the attributes set in that style will be
overwritten in the mailinglist table, Am I right ?
And if that is true(admin can't add new attributes) than how can we
just store only changed/modified attributes in the styles table as
than the table will not have same width, lets assume for style A we
will store one attributes and for style B we will store two/more
attribute.
To create attributes on the fly is easy, even in RDBMS. You have a
table user_defined_attributes with columns foreign_key, attribute_id,
and attribute_value. Then do a select on the foreign key.
Basically the style table will be copy of mailing list table and
will have same number of column same as mailing list table with one
more column about permission (read_only or editable).
You need to be more careful about this. I'm not sure exactly how this
is implemented in Mailman 3, but a mailing list has attributes (such
as the owner and the moderator list) that are not relevant to styles.
There is going to be a question of whether to refactor the list schema
into a stylable part and a list-specific part (so that the
stylable part is literally a copy of the style) or to copy the
individual attributes from styles to the list configuration.
In mailman3 the mailinglist table contains all the attribute so we will
copy only those attributes in the style table that are related to
styles(settings ) of the list only. Yeah I should have mentioned that
before.
Basically I was trying to store a style directly with its name, permission
and attributes like reply to address,send welcome message (Admin will
define values of these attributes and rest will have default values in the
style table) and when a style is applied to any list than these attributes
will be overwritten on the mailing list table from style table. This is the
way I was trying to store the style ( a very basic model for storing
styles) Now we will have the generic way to copy the attributes from a
particular style to the mailing list. I hope I am clear this
[Mailman-Developers] GSOC'15
hi, I am prakhar (pjoshi) . I have submitted my proposal on melenge site. Hoping for feedback. thanks, Prakhar Joshi DA-IICT,Gandhinagar ___ 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
Hi Prakhar, I see that you mentioned below the details of our conversation, but the language looks confusing to me. Please look out for simple mistakes in your English before sending the mail, not just here but anywhere. On Friday 20 March 2015 12:37 PM, prakhar joshi wrote: hi, For the storage of list we will have table for list styles and when the admin creates a new list he/she will edit some attributes of particular list. By attribute I mean the options under each mailing list style like announce list have allow list post. Admin can change there values. You meant 'their' here and not 'there'. style table will have all the attributes(same attributes that are listed in mailing list table) in column but the values of attributes that user will change will be stored in the table and rest values will be null. With improving the apply method for styles we can over write the present settings of the mailing list. I hope this is making sense to you ? What he means to say is we can create a generic Style class, another implementation of IStyle interface which instead of having static values of attributes like existing styles would have methods to dynamically fetch the stored styles from database. This new class would have all the attributes of a MailigList class that can be customized using list styles ( we can leave out attributes like list_name, list_id). I will have table for style which will be having only changed attributes in it and rest of the attributes will be null. For example if admin has changed the attribute send_welcome_message under discussion and other attribute like advertise under public list then these two attributes with their values defined by admin will be stores under the list style name and rest all the attributes which have been there in the mailinglist table will be null for the list style table. Now by using apply function on list style table the values of attributes will be overwritten on the mailing list table when admin apply that list. Only admin will be able to change the settings and by having user section I mean we have to specify the admin of each style so that at time of showing present styles for a particular admin we will fetch only styles with that admin name from the style table, as we don't want other (admins) to change saved styles for particular admin. That is why admin field is essential in the style table. If we create styles for ease-of-implementation of Admins and Moderators, it is required that we support some level of authorization to edit/use those styles. So for that purpose each style create would belong to a `User` and can only be viewed/edited by him. Ideally it would be nice if we could set different access levels for styles, like public, read_only, private. 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. This is not the association of users with styles, it is just meant for authorization purpose. Also `user_id` would be better option to use as a ForeignKey instead of `user_name` which is an optional argument for `User`. -- thanks, Abhilash signature.asc Description: OpenPGP digital 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
Re: [Mailman-Developers] GSOC'15: Improving styles for lists
hi Abhilash, Thanks for all these corrections. Prakhar Joshi DA-IICT,Gandhinagar On Fri, Mar 20, 2015 at 7:03 PM, Abhilash Raj raj.abhila...@gmail.com wrote: Hi Prakhar, I see that you mentioned below the details of our conversation, but the language looks confusing to me. Please look out for simple mistakes in your English before sending the mail, not just here but anywhere. I will definitely take care of it in future. On Friday 20 March 2015 12:37 PM, prakhar joshi wrote: hi, For the storage of list we will have table for list styles and when the admin creates a new list he/she will edit some attributes of particular list. By attribute I mean the options under each mailing list style like announce list have allow list post. Admin can change there values. You meant 'their' here and not 'there'. Yes. style table will have all the attributes(same attributes that are listed in mailing list table) in column but the values of attributes that user will change will be stored in the table and rest values will be null. With improving the apply method for styles we can over write the present settings of the mailing list. I hope this is making sense to you ? What he means to say is we can create a generic Style class, another implementation of IStyle interface which instead of having static values of attributes like existing styles would have methods to dynamically fetch the stored styles from database. This new class would have all the attributes of a MailigList class that can be customized using list styles ( we can leave out attributes like list_name, list_id). yeah, that is what I want to say. I will have table for style which will be having only changed attributes in it and rest of the attributes will be null. For example if admin has changed the attribute send_welcome_message under discussion and other attribute like advertise under public list then these two attributes with their values defined by admin will be stores under the list style name and rest all the attributes which have been there in the mailinglist table will be null for the list style table. Now by using apply function on list style table the values of attributes will be overwritten on the mailing list table when admin apply that list. Only admin will be able to change the settings and by having user section I mean we have to specify the admin of each style so that at time of showing present styles for a particular admin we will fetch only styles with that admin name from the style table, as we don't want other (admins) to change saved styles for particular admin. That is why admin field is essential in the style table. If we create styles for ease-of-implementation of Admins and Moderators, it is required that we support some level of authorization to edit/use those styles. So for that purpose each style create would belong to a `User` and can only be viewed/edited by him. Ideally it would be nice if we could set different access levels for styles, like public, read_only, private. Yeah we can provide option these options to admin. 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. This is not the association of users with styles, it is just meant for authorization purpose. Also `user_id` would be better option to use as a ForeignKey instead of `user_name` which is an optional argument for `User`. Yeah, basically we need to relate each style with its owner so user_id will be more appropriate. -- thanks, Abhilash ___ 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
On Mar 19, 2015, at 03:31 PM, Stephen J. Turnbull wrote: 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've always thought that styles should be compositional for exactly the reasons you describe. Mailing lists have a weird amalgam of attributes, inherited and flattened from the MM2.1 mixin strategy. Cheers, -Barry ___ 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 : 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
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
[Mailman-Developers] GSOC'15: Improving styles for lists
hi, I am thinking of storing the styles in the database by creating a table for the styles in the db 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 really need to discuss that thing with you people as I am new to this organization so I have very little experience with mailman core. Thanks, Prakhar Joshi DA-IICT,Gandhinagar ___ 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 - Regarding A Dashboard for Admins/Owners/Moderators project
Hi guys, I have uploaded my proposal for the A Dashboard for Admins/Owners/Moderators project. Review on it are welcome. Regards, Shreyas Lakhe ___ 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
Florian Fuchs writes: Am 16.03.2015 um 14:50 schrieb Sagar Ghai: Hi, I would be interested in contributing to one of the projects named: anonymous lists as part of GSOC'15. I am a second year undergraduate student at IIT-Mandi, India. Can someone let me know how to move forward with this. Hi Sagar, there has already been quite a bit of discussion about this project on this list. You could start by checking the archives and read what has been discussed so far. I'm sure this will get you started pretty well. But start by reading the project page, especially the section Mentors are Not Teachers, and the linked essay How to SPAM. You need to be the active party here. Nobody has interest in mentoring a student who needs to be told what the next step is all the time. Good luck! ___ 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 : Student applications start today
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 signature.asc Description: OpenPGP digital 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] Gsoc'15
Hi, I would be interested in contributing to one of the projects named: anonymous lists as part of GSOC'15. I am a second year undergraduate student at IIT-Mandi, India. Can someone let me know how to move forward with this. ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 16.03.2015 um 14:50 schrieb Sagar Ghai: Hi, I would be interested in contributing to one of the projects named: anonymous lists as part of GSOC'15. I am a second year undergraduate student at IIT-Mandi, India. Can someone let me know how to move forward with this. Hi Sagar, there has already been quite a bit of discussion about this project on this list. You could start by checking the archives and read what has been discussed so far. I'm sure this will get you started pretty well. Florian ___ 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/f%40florianfuchs.com Security Policy: http://wiki.list.org/x/QIA9 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVBw4FAAoJEEceGbPdavl7GcIH+gMFTEP7S0fgxfEE/NNqGnKG StkVGbL+vwmtzJsEZCv6Tse0q/8H3sQA9ZMBZaUEMgLAyrTJsQLtwNoMOIyVFNn2 u3IWyUp5QXs5qM0FAMw5Ec65eodYtc9PrpSGioNc97S/E6OKZmvKf9q45PC27boF /SD7q7ZGHglVGTcXAJqs+jrJEFUYsvEr1GY7hrnCAnM3/fCpbL1SRVGALGfKsVL8 tWUknjsCFmmDPy5Rn8kO6lqghmHjkClXQWdD9Zjqnu+OXoT5Cf4bvYiwjwdX2WVo 9M2W/cXwNT+IF7VADVF6Iv14Y2jGTEdpsBqrPKeMX/n8NlxIELHkRogU+CmY68U= =5/hs -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
Re: [Mailman-Developers] GSoC 15
HI Shreyas, On 12 March 2015 at 23:17, Shreyas Lakhe shreyasla...@gmail.com wrote: Hi guys, I am Shreyas Lakhe and want to contribute to GNU Mailman as part of GSoC 15. You will find all the necessary resource for getting started on Ideas Page. Remember that you need to fix atleast one bug as a part of your application for GSoC. I want to work on the A Dashboard for Admins/Owners/Moderators project as part of GSoC 15. There has been a lot of interest and discussion about this project on this list lately. Try to follow through the archives of this mailing-list (link in the footer) and please ask any specific questions that you have. Below is the link to the basic prototype of the Dashboard page that I would like to implement. Any suggestions on it are welcome. https://moqups.com/srlakhe/weZugpFL/ It looks like a good start, but we would need a more detailed version of this. Also, I think that creating and deleting lists are not regular tasks for a list admin. So its not logical to let those blocks cover space on the dashboard. -- 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
Hi guys, I am Shreyas Lakhe and want to contribute to GNU Mailman as part of GSoC 15. I want to work on the A Dashboard for Admins/Owners/Moderators project as part of GSoC 15. Below is the link to the basic prototype of the Dashboard page that I would like to implement. Any suggestions on it are welcome. https://moqups.com/srlakhe/weZugpFL/ Thanks, Shreyas ___ 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 Idea of Better handling of list styles
hi, I will like to add that we have to create setting or some features/ functionalists for Site Admins of different types like Discussion list, organization list etc. Cheers!! Prakhar Joshi DA-IICT,Gandhinagar On Thu, Mar 5, 2015 at 1:03 PM, prakhar joshi prakhar...@gmail.com wrote: hi, I am Prakhar from DA-IICT graduating in 3rd B.tech. I will like to work on the project name Better handling of list styles. I need the guidance to start and will also like to discuss the whole idea (so that it may help in preparing proposal). I like to develop things in python. I have worked in Django too. I will really like o contribute to mailman this summer. Hoping for reply. Cheers!! IRC name:- pjoshi Prakhar Joshi DA-IICT,Gandhinagar ___ 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 Idea of Better handling of list styles
hi, I am Prakhar from DA-IICT graduating in 3rd B.tech. I will like to work on the project name Better handling of list styles. I need the guidance to start and will also like to discuss the whole idea (so that it may help in preparing proposal). I like to develop things in python. I have worked in Django too. I will really like o contribute to mailman this summer. Hoping for reply. Cheers!! IRC name:- pjoshi Prakhar Joshi DA-IICT,Gandhinagar ___ 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 Interested in project Mailman client written in Javascript
Hi,
I'm an Engineering student(computer science) pursuing my degree from
Government Engineering College(Calicut University), Thrissur, India. I went
through Mailman gsoc idea list.I'm interested in the project Mailman client
written in Javascript.
I have good skills in JavaScript, nodejs, angular, python.
I am looking forward for a good response from your side regarding details
about the projects so that I could start contributing towards it.
Skills:
Languages: JavaScript, nodejs, python, HTML5, CSS3, C, C++
Libraries: jQuery, underscorejs, zeptojs, KineticJS
Frameworks: Angularjs, Express, Django,
Tools: Vim, Git, Grunt, bower, Yeoman
Thank you,
{
name: Kiran P S,
email: pskir...@gmail.com,
github: github.com/kiranps,
google+: plus.google.com/+kiranps1,
twitter: @pskirann
}
___
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 Interested in project Mailman client written in Javascript
Hi Kiran, On 28 February 2015 at 14:42, kiran ps pskir...@gmail.com wrote: Hi, I'm an Engineering student(computer science) pursuing my degree from Government Engineering College(Calicut University), Thrissur, India. I went through Mailman gsoc idea list.I'm interested in the project Mailman client written in Javascript. I have good skills in JavaScript, nodejs, angular, python. Right now Mailman3 has only one REST Client which is written in python[1]. This project would involve creating something similar to it in JS. You can get started with mailman by setting up a dev environment using the docs and then try fixing some beginner friendly bugs. You can find links to everything in the wiki page itself. [1]: https://launchpad.net/mailman.client -- 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
