Getting code in? (was: Storm based MemberAdaptor for Mailman)
On Sat, Aug 8, 2009 at 1:25 AM, Malveeka Tewari<malveeka@gmail.com> wrote:
I am working on writing a storm based member adaptor for mailman so that the mailman membership data can be stored in a database instead of .pck files. The reason for choosing storm is that it provides an abstraction to use any underlying db language- either mysql, postgresql or sqllite.
Hi, I'm one of the GSOC mentors for Systers, all of whose students are working on Mailman enhancements. Some of these (Like Malveeka's) would be suitable for merging upstream, but the review and acceptance process is not clear.
- Do people on this list regularly provide review of proposed enhancement patches?
- Is there a set of people who explicitly ACK or NAK all proposed patches?
- Once reviewed, merging is via LP merge requests, right? Or does one do the merge request and *then* get reviewed?
- More fundamentally, is Mailman currently accepting patches from external contributors?
We have code to contribute. It's not perfect yet but we will make it better. We need some Official Mailman participation or our improvements will never make it out of our branch. Even a response of "we're not interested in X, thanks" would be much superior to no response at all.
Thanks -- Regards -- Andy
On Aug 9, 2009, at 3:35 PM, Andrew Grover wrote:
Hi, I'm one of the GSOC mentors for Systers, all of whose students are working on Mailman enhancements. Some of these (Like Malveeka's) would be suitable for merging upstream, but the review and acceptance process is not clear.
Very cool to hear about your work! Let's see if I can clarify
things. Eventually this ought to make it into the wiki.
- Do people on this list regularly provide review of proposed enhancement patches?
- Is there a set of people who explicitly ACK or NAK all proposed
patches?- Once reviewed, merging is via LP merge requests, right? Or does one do the merge request and *then* get reviewed?
I think the process should generally work like this:
A developer has an idea for an enhancement. They describe it here
and we can discuss general design issues, coding suggestions,
decomposition of work into branches, etc. For higher bandwidth
discussions we can use irc.If the idea or approach isn't something the Mailman community thinks
is worthwhile, we'll leave official participation at that. Of course,
this being open source and bzr being a DVCS, you're free to do
whatever you want.If the idea is appropriate for Mailman, we must get copyright
assignments from the developer. Let's do this early, since it can
take some time to get all the paperwork to the FSF.Branches should be as small as possible and still be self- contained. They must include documentation, a NEWS entry, and for
Mailman 3 they must include tests. Ideally, there would be one bug
for every branch you work on. The smaller the branch the easier it is
to review. For Launchpad, we have a strict 800 line diff limit on
branches. I'm not sure if that's appropriate or not for Mailman, but
please understand that anything over 1000 lines of diff gets very
difficult and time consuming to review.When a branch is ready for review, create a merge proposal for it
and email us here.One of us will review the code. For Mailman 2.x, it will most
likely be Mark. For Mailman 3 it will be me.Once we've approved the branch, either Mark or I will merge it into
the official trunks. Currently only a few of us have write permission
to the official branches. I do hope more people become developers and
reviewers!
- More fundamentally, is Mailman currently accepting patches from external contributors?
Yes. It's tough though, and I apologize in advance, but both Mark and
I are very busy. I've tried to shed load by concentrating only on
Mailman 3 and that seems to work for me (and hopefully MM3, which is
making good progress).
We have code to contribute. It's not perfect yet but we will make it better. We need some Official Mailman participation or our improvements will never make it out of our branch. Even a response of "we're not interested in X, thanks" would be much superior to no response at all.
Completely agreed! Let's talk about your ideas and see which might be
appropriate for inclusion. I will really work at being more responsive.
-Barry
On Sun, Aug 9, 2009 at 7:31 PM, Barry Warsaw<barry@python.org> wrote:
Hi, I'm one of the GSOC mentors for Systers, all of whose students are working on Mailman enhancements. Some of these (Like Malveeka's) would be suitable for merging upstream, but the review and acceptance process is not clear.
Very cool to hear about your work! Let's see if I can clarify things. Eventually this ought to make it into the wiki.
Hi Barry, thanks for your lengthy response. I've tried to be helpful by updating the wiki with the content from your email (http://wiki.list.org/display/DEV/Home). You really clarified a lot for us, and hopefully other potential contributors :)
So the next question for Mark and everyone is: do you want a StormDB-backed MembershipAdaptor for Mailman 2.x?
There are some further questions the Systers org needs to settle before proceeding, about the ownership status of GSOC-produced code, as well as if copyright assignment to FSF is acceptable, but it is moot if the feature is only interesting to us.
Thanks -- Regards -- Andy
Andrew Grover wrote:
So the next question for Mark and everyone is: do you want a StormDB-backed MembershipAdaptor for Mailman 2.x?
There are some further questions the Systers org needs to settle before proceeding, about the ownership status of GSOC-produced code, as well as if copyright assignment to FSF is acceptable, but it is moot if the feature is only interesting to us.
I'm interested. It is not a high priority for me because it is something that Barry is doing for MM 3 anyway.
My concern is to not create additional 2.1 -> 2.2 -> 3 migration headaches. If this is something that could ease the migration to MM 3 by providing a 'stepwise' path, that would be great. However, if it is viewed as something that will be done for MM 2.2 and then totally redone for MM 3, I'm afraid it will just encourage people to skip MM 2.2 and wait for MM 3.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Aug 10, 2009, at 12:38 PM, Mark Sapiro wrote:
My concern is to not create additional 2.1 -> 2.2 -> 3 migration headaches. If this is something that could ease the migration to MM 3 by providing a 'stepwise' path, that would be great. However, if it is viewed as something that will be done for MM 2.2 and then totally redone for MM 3, I'm afraid it will just encourage people to skip MM 2.2 and wait for MM 3.
The Storm based MemberAdapter is definitely a MM2-only thing. The
schema is so different in MM3 I don't see it as being a possible
stepping stone.
-Barry
On Mon, Aug 10, 2009 at 10:57 AM, Barry Warsaw<barry@python.org> wrote:
On Aug 10, 2009, at 12:38 PM, Mark Sapiro wrote:
My concern is to not create additional 2.1 -> 2.2 -> 3 migration headaches. If this is something that could ease the migration to MM 3 by providing a 'stepwise' path, that would be great. However, if it is viewed as something that will be done for MM 2.2 and then totally redone for MM 3, I'm afraid it will just encourage people to skip MM 2.2 and wait for MM 3.
The Storm based MemberAdapter is definitely a MM2-only thing. The schema is so different in MM3 I don't see it as being a possible stepping stone.
One (bad) option would be to use a MM3-compatible schema for the new 2.2 code. This sounds bad for a few reasons: MM3 schema could change, and an incomplete implementation of the (large) schema in our 2.2 Adaptor could increase the complexity and fragility of the upgrade process.
Have you given any thought yet to the upgrade process? I'm assuming there will be some utility to convert a MM2.2 installation to a MM3 one? One thought I had was that this utility would likely use the Membership adaptor classes to pull data (as opposed to reading .pck files directly) in which case the data source of the member data should be opaque[1]?
Thanks -- Regards -- Andy
[1] of course if database or table names overlap, it goes boom
On Aug 10, 2009, at 3:07 PM, Andrew Grover wrote:
On Mon, Aug 10, 2009 at 10:57 AM, Barry Warsaw<barry@python.org>
wrote:On Aug 10, 2009, at 12:38 PM, Mark Sapiro wrote:
My concern is to not create additional 2.1 -> 2.2 -> 3 migration headaches. If this is something that could ease the migration to
MM 3 by providing a 'stepwise' path, that would be great. However, if
it is viewed as something that will be done for MM 2.2 and then totally redone for MM 3, I'm afraid it will just encourage people to skip MM 2.2 and wait for MM 3.The Storm based MemberAdapter is definitely a MM2-only thing. The
schema is so different in MM3 I don't see it as being a possible stepping
stone.One (bad) option would be to use a MM3-compatible schema for the new 2.2 code. This sounds bad for a few reasons: MM3 schema could change, and an incomplete implementation of the (large) schema in our 2.2 Adaptor could increase the complexity and fragility of the upgrade process.
I'm not in favor of this because one of the whole points of having a
MM2.2 was to keep the data model unchanged from 2.1, but to fix and
improve other aspects of the system, such as the web interface, some
of the defaults, etc. Really fixing the data model should only happen
in MM3.
Of course, I welcome all participation in that effort :).
Have you given any thought yet to the upgrade process? I'm assuming there will be some utility to convert a MM2.2 installation to a MM3 one? One thought I had was that this utility would likely use the Membership adaptor classes to pull data (as opposed to reading .pck files directly) in which case the data source of the member data should be opaque[1]?
Thanks -- Regards -- Andy
[1] of course if database or table names overlap, it goes boom
I have thought about this, and done some preliminary work on this, but
it could definitely use some more attention. It's absolutely critical
that we have an easy migration mechanism before MM3 final can be
released. My current thinking has been to use a flat file format
somewhat like what bin/export produces and have an import script in
MM3 that collates and updates its data. That's just a general
direction though so lots of details need to be worked out.
Another thing I have not been good at is tracking the MM2.2 changes
and 2.1 bug fixes. At some point I'll have to do an audit of this,
but it's too disruptive of my current flow to do that now. :(
-Barry
participants (3)
-
Andrew Grover -
Barry Warsaw -
Mark Sapiro