As a Debian fanboy and also a mailman addict, I'd like to try packaging it
in Debian. As I'm not a DD and as I'm not in a hurry, I'd like to take some
time to think about what would be relevant.
For that, I'd like to have some help. And I was suggested to come here and
I decided to use https://gitlab.com/groups/mailman as a basis for my work.
First of all, to create the source package, I've to think about what to put
It seems that if I want to have a good source package, I need 5 repos :
- HyperKitty - MailMan Plugin
My first question is "Am I right?". And the second one is whould I consider
looking into mailman-suite-doc and also have it in the source package?
On another way, I also see that there is a standalone postorius repo and
also some django project files for HyperKitty in another one. I have the
impression it is more designed for people to work on as standalone -
forkable projects for other features, and so I wouldn't need them in a
Am I also right?
Thanks for your answer, I hope I'll be able to make this package look as
you'd like. :)
Rishab Jaju writes:
> Hi Abhilash,
> I am interested in the following project: "Subscriber Profile
> Pages". Can I work on this project, or is somebody else working on
Even if somebody else is working on it, they may appreciate the help.
Even if they are but don't want help, you can try yourself (but of
course competing implementations means yours is less likely to
actually get integrated).
Now that you have posted here, I would recommend getting to work
unless you have an alternative project you would prefer to work on.
Remember, at this stage you'll spend most of your time learning about
Mailman, and your code is likely to get a lot of suggestions for
improvement, so you won't be making much in the way of wasted effort
even if you end up abandoning this particular project for whatever
reason at an early stage. While digging into the code, you may also
find a more interesting (to you) project before GSoC opens, or you may
find that to do the profile page project you need to add basic
facilities, and do that for GSoC. Don't commit yourself to a specific
project for GSoC yet.
The next thing to do is to check the tracker. I found these:
Neither seems to suggest that anybody is actually working on this
project. Note that the issues are titled "User Profile Pages" rather
than "Subscriber Profile Pages" -- searching for appropriate issues is
an art. Don't kill yourself trying to do an exhaustive search or
coming up with the perfect keywords.
If you decide to work on this, come up with a summary of what *you*
want to do (it may help to refer to the existing issue descriptions),
and post it as an RFE (request for enhancement), most likely on the
Postorius tracker. That will allow others interested in the project
(both potential users and developers) to find you. Mention that you
are working on the project, and link to the existing issues.
A bit of advice: I tend to disagree with Our Fearless Leader: I think
there's more of a role for "core" in this. Specifically,
discoverability of resources. Resources are spread across the three
main components, and the list archives at least will have multiple
implementations in common use.
On 12/29/2015 06:32 PM, Rishab Jaju wrote:
> Hello everybody,
> I am a third year student looking to contribute towards GNU Mailman for the
> upcoming Google Summer of Code program.
> I am very proficient in C++, Java, Python and Scheme. I have done some
> projects in machine learning as well as NLP.
> What level of knowledge would I need to contribute to the project? What
> sort of project would be appropriate for my skill set?
There is no specific knowledge level that is required to contribute to
GNU Mailman project except basic Python and common sense. You can get
started by looking at the issues and reading code for the mailman
project that you can find at the project website. If it is not already
clear from the website, I would tell you that the development is focused
around Mailman 3.0 and its sister projects.
Getting started is same as every year, so you can look at the last
year's GSoC page in the mailman wiki till we create and update the new
page for 2016.
> Thank you,
> Rishab Jaju.
> Mailman-Developers mailing list
> 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/raj.abhilash1%40…
> Security Policy: http://wiki.list.org/x/QIA9
I am a third year student looking to contribute towards GNU Mailman for the
upcoming Google Summer of Code program.
I am very proficient in C++, Java, Python and Scheme. I have done some
projects in machine learning as well as NLP.
What level of knowledge would I need to contribute to the project? What
sort of project would be appropriate for my skill set?
On Dec 24, 2015, at 09:55 AM, Tom Browder wrote:
>In my opinion, that link should replace ALL other links under the
>Documentation menu at the top of the home page (www.list.org), and it
>should clearly specify MM 3, something like:
> Mailman 3 => http://docs.mailman3.org/en/latest/
>I am ready (finally) to start new lists with MM 3 and that, I assume,
>is where I should look.
Although, I do like the "quick links" nature of the Documentation menu. One
less click once you know where you want to go.
Maybe the docs.mailman3.org page can be linked from an "Overview" menu item?
On Dec 24, 2015, at 11:08 AM, Tom Browder wrote:
>Where should I look for the complete, definitive documentation on the
>MM3 REST API?
Sadly, there's no programmatic way to gather the specifications for the REST
API. The best you have is the online documentation...
...and the source. You can refer to two other projects which access the API
though, and which might also help.
https://gitlab.com/mailman/mailmanclient - is the official Python bindings to
the REST API.
https://gitlab.com/astuart/mailmania - is Andrew Stuart's authenticating
proxy, which exposes a public REST API bridging to the internal REST API that
the core exposes. At some point, we'll pull this in as an official
I'd welcome contributions to help make the REST API more discoverable and/or
Abhilash did a lovely job on the new website, but while the layout has
changed, a lot of the content hasn't. And I'm not sure what we've got
lines up very with what people want out of our website, so I'm thinking
Right now, I suspect that when people visit list.org, these are the
things they want to do:
1. Find out what mailman is.
We're good at that right now: there's good info on the main page and
then links to features.
2. Find out how to get and install the latest version of Mailman.
Need improvement here. Mailman 2.1 download links are good. Mailman 3
directs you to PyPI but then there's nothing explaining about how
Mailman now is a suite and it's this bunch of packages. Also nothing
about how you can use mailman-bundler rather than trying to make the
magic happen yourself.
I wrote something up and put in a merge request, pending someone
3. Find out how to report a bug
We kind of fail on this one, except if you want to report a security
issue. Again, this is more complex than it might seem since there's a
bunch of different components.
4. Find the docs / get help with an issue.
The good: they're linked right there in the top bar. The bad: is
someone looking at this going to know they want the docs for postorius
vs hyperkitty? Will any of that make sense? I think we might need a
landing page here.
We do have a "help" link and the "wiki" link in this area too, but I
think a landing page could bring this all together more nicely.
5. Find out how to contribute.
This is going to be especially gsoc students. We've got some nice
developer links and yeay, this is one of the pages that lists out all
the parts of Mailman! But we could really use a startup guide here.
We do have a nice Donate link for financial contributions, though.
6. Figure out how to get in touch with us.
This page is pretty decent, with the mailing lists and IRC and all.
Maybe if we had a "how to report a bug" page it should be linked here,
but otherwise full marks.
7. Learn more about Mailman
We've got some good resources: features, media, the code of conduct,
etc. But probably we should group this all together so that it's easier
for people to find the other important things they want without wading
through all these links.
I'd suggest we keep the top of page links as they are, since they're
super useful to people who know what they're looking for already, and
have the left side menu be more about the guides.
But I think we should replace all the links down the left-hand side of
the page with links that match up with those goals, so the menu would
probably look something like:
* About Mailman
- combine all the about mailman stuff here, although we also want to
leave the main page as is, so there may be a bit of duplication here.
* Get Mailman
- Links to source code and install guides, high level description of
what to do.
* Help and Documentation
- landing page with a link to the docs, wiki and mailing lists, with
instructions. Maybe some search boxes? Userguides go here too.
* Report an issue / Contact Us
- landing page with reminder about reporting security bugs, links to bug
trackers, mailing lists, irc
* How to Contribute
- new contributors guide here, prefaced by the basic source/gitlab links
Thoughts on better ways to set this up? Other suggestions of things
people often want out of our website?
On 2015-11-24 7:32 AM, Andrew Hodgson wrote:
> My confusion relates to the virtual environment that I create. I am
> running from the dedicated MM3 user I created, and I am looking to
> expand the bundler from the user’s home directory in /home (for
> example). When I create the virtual environment, the files are all
> held in this directory, and I really want the MM3 to be installed
> system wide as this will be the only program running on this machine.
> Do I even need to create a virtual environment at all? Are there any
> other guides relating to setting up MM3 for a purely production
> environment with minimal dependencies?
I hit this same issue, as it were. In my case, I knew exactly what was
going on and why but, the problem arose when I needed other people to be
able to do mailman-related stuff on the machine and it feels *really*
weird to people to go into my home directory to restart mailman.
I think we should probably update the docs to suggest that you start by
making a directory where you'd like mailman installed, rather than the
way the guide is currently written where it sometimes surprises people
that they have a live mailman install in their home directory (as
opposed to the workflow people may be expecting which more like "I get a
staged copy of my source in my home directory and then I type make
install and it puts the executables and config files in expected places")
What would be a good default directory to have in the docs if I want to
update them to suggest you start somewhere other than your home directory?
is probably the most appropriate one according to the LSB.
Does anyone want to make another suggestion before I update the docs to
suggest that as a logical place to put your mailman stuff? (I'll leave
a note saying that if you're just trying stuff out then your home
directory is fine, too.)
Le lundi 14 décembre 2015 à 17:36:10+0100, Simon Hanna a écrit :
> On 12/14/2015 05:01 PM, Pierre-Elliott Bécue wrote:
> >One can find my work here : https://github.com/P-EB/mailman3-core
> >Small bump here, I'd appreciate if somebody finds the time to tell me two
> > * Is my config file enough for a start ?
> > * Is my systemd service good to have mailman started properly ?
> You seem to be missing a "start" at the end of ExecStart