Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project

[Rajeev S]

On Friday 30 May 2014 07:09 PM, Abhilash Raj wrote:

On Fri, 30 May 2014 18:12:18 +0530
Rajeev S  wrote:


I agree that an override for the confirmation message is necessary so that
the CLI
commands can be used in scripts and I would like to follow Barry's
suggestion of using
a `--yes` or `--force` switch. (Isn't --force more common than --yes, as in
`rm -f` ?)

No, as I think, `--yes` and `--force` or `-f` have different use cases.
For conformations `--yes` is used most of the times, it says 'hey I
know you are going to ask this question and my answer would be yes'.
While `--force` is to actually *force* any operation that cannot be
completed otherwise.



Ok. I will go with the --yes.


Good to hear that. Did you give TDD a try?


Not yet, I wrote a few test cases for the existing units using
python untitest.

I will try to focus on following TDD for the next set of units.

  

Also, I would like to ask how the tests should be triggered. Should
there be a `mmclient test` with a set of possible switches like `all`
,`domain`, `list`, `user` etc?
Or should the customary `python setup.py test` be used?

You can use `nose2` for that, like mailman does. It automatically
discovers all the tests in directories specified and runs them.


Ok.


What detail profile are you talking about? Apart from addresses and
name(optional) does mailman store any other data about a user? You can
show the lists he is subscribed to, but `describe user` may not be an
appropriate command for that. Maybe you can add it in users scope
itself like
   `mmclient user a...@b.org --list-subscriptions`
Others may have different thoughts though.



The following are the details that are available for a user

1.Addresses
2. Subscriptions
(3. Subscription list id's)
4.Preferences
5.Self link

@all
BTW I have pushed r55.

http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/55


___
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 2014] Mailman CLI Project

[Abhilash Raj]

On Fri, 30 May 2014 18:12:18 +0530
Rajeev S  wrote:

When you are not citing any context from previous posts, you should
start a new thread instead of re-posting on same old one. It makes it
difficult to find a specific post with this long thread.

-- 
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

Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project

[Abhilash Raj]

On Fri, 30 May 2014 18:12:18 +0530
Rajeev S  wrote:

> I agree that an override for the confirmation message is necessary so that
> the CLI
> commands can be used in scripts and I would like to follow Barry's
> suggestion of using
> a `--yes` or `--force` switch. (Isn't --force more common than --yes, as in
> `rm -f` ?)

No, as I think, `--yes` and `--force` or `-f` have different use cases.
For conformations `--yes` is used most of the times, it says 'hey I
know you are going to ask this question and my answer would be yes'.
While `--force` is to actually *force* any operation that cannot be
completed otherwise.

> About the create domain suggestion, Is the follow up question on `*create
> domain*`, upon missing domain,
> such a bad idea? A user already can `add a domain` by using the web
> interface. If that is not ambiguous,
> neither is this, right?
> 
> However I see this issue, if a newbie user types in an email address in
> place of the list name, probably
> on misreading the command format, he would end up creating a domain for his
> mail provider.
> 
> *$./mmclient create list --help*
> *Creates the list l...@domain.org *
>  *$./mmclient create list u...@gmail.com *
> *The domain gmail.com  does not exist.Create one?[y/n] y*
>  *$*
> 
> @Abhilash
> 
> I have written unittests for methods like connect and create, but have to
> refine them more.
> Hence the tests won't come up in this revision.

Good to hear that. Did you give TDD a try?
 
> Also, I would like to ask how the tests should be triggered. Should
> there be a `mmclient test` with a set of possible switches like `all`
> ,`domain`, `list`, `user` etc?
> Or should the customary `python setup.py test` be used?

You can use `nose2` for that, like mailman does. It automatically
discovers all the tests in directories specified and runs them.

> 
> I also propose to build a a *`describe user`* command that gives a detailed
> profile of the user.
> Verbose listing using tables is not so effective users as most of the
> attributes are lists.

What detail profile are you talking about? Apart from addresses and
name(optional) does mailman store any other data about a user? You can
show the lists he is subscribed to, but `describe user` may not be an
appropriate command for that. Maybe you can add it in users scope
itself like
  `mmclient user a...@b.org --list-subscriptions`
Others may have different thoughts though.

-- 
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

Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project

[Abhilash Raj]

On Thu, 29 May 2014 22:30:25 +0900
"Stephen J. Turnbull"  wrote:

>  > > Also maybe you can try making your tool a little more smart? Like lets
>  > > say I try to create a list abhil...@raj.com and there is no domain
>  > > raj.com in the database, so instead of just showing error maybe you can
>  > > ask the user:
>  > >
>  > > "The domain raj.com does not exist, Do you want to create one? [y/n]"
> 
> I'm not sure I like this approach.  Creating a domain should be a
> heavyweight operation, and eventually should include a bunch of sanity
> checks, like existence of domains and MX records.  I have visions
> (nightmares) of users coming to us saying
> 
> User: I said yes, but mail never arrives.
> Dev:    Oh, is there a proper entry in the DNS?
> User: Doesn't Mailman create the domain?

I agree to your point that it should be a heavyweight operation, I
guess i was not able to express myself. I don't know if this CLI client
can add domains to mailman(I mean add domain to mailman before and not
*create*), there could be a prompt saying "This mailman installation
is not configured to use this domain, do you want to do it now?" and
then maybe it will walk the user through the "usual" process of adding
a new domain? 

> 
>  > > Or maybe it could schedule a deletion after a pre-defined time with a
>  > > reasonable default lets say "1 Day"? And for an urgency(to delete) there
>  > > could be --force argument?
> 
> Deleting a list should be immediate, but I agree it should be confirmed.
> 



-- 
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

Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project

[Rajeev S]

Hi,

I have made more additions to the CLI, like the `delete` command and the
`user` scope.

Following is the list of changes brought about

1.Introduce User scope

Actions supported by User scope currently are create, show and delete.
show users, like other scopes, supports verbose and no-header flags. However
the detailed listing of users is not quite effective as most of the fields
are lists
rather than single valued attributes. The non detailed version prints one
of the
email ids of each user. The show list command takes an optional argument
list name that gives the users who are members of the list.


2.Introduce a cli/lib directory, to store procedures common across the
application.

The directory is to hold the procedures and classes that are reused among
scripts.
It currently holds a class that is used to colorize the output printed on
the terminal.

3.Updated and improved docs/using.txt. It was obsolete in r54.


4.Added delete action for all objects

The action is confirmed by a question to user, which can be overridden by a
--yes switch.

I will be committing and pushing r55 tonight (30/05/2014 around 16:30 UST,
I am away from
the computer right now).


As mentioned by Steve and agreed by Barry, I too believe that, in the
scenario of the CLI
multiple confirmations won't be necessary. In a situation in which such
multiple confirmations
come necessary, I believe that the commands will be better if the
confirmations are replaced
by switches.

I agree that an override for the confirmation message is necessary so that
the CLI
commands can be used in scripts and I would like to follow Barry's
suggestion of using
a `--yes` or `--force` switch. (Isn't --force more common than --yes, as in
`rm -f` ?)

About the create domain suggestion, Is the follow up question on `*create
domain*`, upon missing domain,
such a bad idea? A user already can `add a domain` by using the web
interface. If that is not ambiguous,
neither is this, right?

However I see this issue, if a newbie user types in an email address in
place of the list name, probably
on misreading the command format, he would end up creating a domain for his
mail provider.

*$./mmclient create list --help*
*Creates the list l...@domain.org *
 *$./mmclient create list u...@gmail.com *
*The domain gmail.com  does not exist.Create one?[y/n] y*
 *$*

@Abhilash

I have written unittests for methods like connect and create, but have to
refine them more.
Hence the tests won't come up in this revision.

Also, I would like to ask how the tests should be triggered. Should
there be a `mmclient test` with a set of possible switches like `all`
,`domain`, `list`, `user` etc?
Or should the customary `python setup.py test` be used?


I also propose to build a a *`describe user`* command that gives a detailed
profile of the user.
Verbose listing using tables is not so effective users as most of the
attributes are lists.

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 2014] Mailman CLI Project

[Patrick Ben Koetter]

* Stephen J. Turnbull :
> Patrick Ben Koetter writes:
> 
>  > I doubt anyone that igorant of e-mail and how it works will ever
>  > make it to the MM3 command line client, but yes, such cases do
>  > exist.
> 
> I think they're actually likely to be reasonably common.
> 
>  > However I think the use case "prepare Mailman to handle mail for a
>  > domain it doesn't handle mail for yet" exists and we should find a
>  > way to deal with it.
> 
> Indeed.  I'm suggesting that the routine could check the DNS and a few
> other things, and present the list operator with a TODO list.  Sortof
> like check_perms.

Where would you start with the TODO list? Where would you end?


>  > > Deleting a list should be immediate, but I agree it should be confirmed.
>  > 
>  > ... and it should be possible to pass the confirmation in the command to 
> make
>  > it useful in scripts.
> 
> Ooh, that is a very good point.  Bessides "possible," the syntax for
> doing that should be regular.


I'm hopping in on this and I certainly missed most of the discussion on the
command line client: Do we have interface guidelines for commands? Shortopts,
longopts, interaction, non-interactive behaviour/requirements?

> I wonder about distinguishing "yes to this prompt" and "yes to all"?

Me too. 

> Probably scripts should not be using commands that need multiple
> confirmations, though.

Hmmm, Unix: Do one thing. Do it well. ?
 

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
 
___
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 2014] Mailman CLI Project

[Barry Warsaw]

On May 30, 2014, at 03:41 AM, Stephen J. Turnbull wrote:

>Probably scripts should not be using commands that need multiple
>confirmations, though.

Agreed!
-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 2014] Mailman CLI Project

[Stephen J. Turnbull]

Patrick Ben Koetter writes:

 > I doubt anyone that igorant of e-mail and how it works will ever
 > make it to the MM3 command line client, but yes, such cases do
 > exist.

I think they're actually likely to be reasonably common.

 > However I think the use case "prepare Mailman to handle mail for a
 > domain it doesn't handle mail for yet" exists and we should find a
 > way to deal with it.

Indeed.  I'm suggesting that the routine could check the DNS and a few
other things, and present the list operator with a TODO list.  Sortof
like check_perms.

 > > Deleting a list should be immediate, but I agree it should be confirmed.
 > 
 > ... and it should be possible to pass the confirmation in the command to make
 > it useful in scripts.

Ooh, that is a very good point.  Bessides "possible," the syntax for
doing that should be regular.

I wonder about distinguishing "yes to this prompt" and "yes to all"?
Probably scripts should not be using commands that need multiple
confirmations, though.

___
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 2014] Mailman CLI Project

[Barry Warsaw]

On May 29, 2014, at 05:20 PM, Patrick Ben Koetter wrote:

>Deleting a list/domain requires an (internal) scheduler. Does Mailman have
>one? A broom job that can be called via cron?

Sort of, but the way these are handled currently are individual scripts that
each have to be added to cron.

>... and it should be possible to pass the confirmation in the command to make
>it useful in scripts.

Many such scripts have a --yes option to pre-confirm the action.

-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 2014] Mailman CLI Project

[Patrick Ben Koetter]

* Stephen J. Turnbull :
> Rajeev S writes:
> 
>  > > Also maybe you can try making your tool a little more smart? Like lets
>  > > say I try to create a list abhil...@raj.com and there is no domain
>  > > raj.com in the database, so instead of just showing error maybe you can
>  > > ask the user:
>  > >
>  > > "The domain raj.com does not exist, Do you want to create one? [y/n]"
> 
> I'm not sure I like this approach.  Creating a domain should be a
> heavyweight operation, and eventually should include a bunch of sanity
> checks, like existence of domains and MX records.  I have visions
> (nightmares) of users coming to us saying
> 
> User: I said yes, but mail never arrives.
> Dev:    Oh, is there a proper entry in the DNS?
> User: Doesn't Mailman create the domain?

I doubt anyone that igorant of e-mail and how it works will ever make it to
the MM3 command line client, but yes, such cases do exist. We should have
public pillory that receives name, mail and date, whenever someone confirms
the above question. ;)

However I think the use case "prepare Mailman to handle mail for a domain it
doesn't handle mail for yet" exists and we should find a way to deal with it.

Perhaps we could improve this, if we used better wording that doesn't lead the
operator to believe Mailman will connect a domain, setup DNS, do all the other
foo and finally configure it self to handle mailing lists for that domain?

>  > > Or maybe it could schedule a deletion after a pre-defined time with a
>  > > reasonable default lets say "1 Day"? And for an urgency(to delete) there

Deleting a list/domain requires an (internal) scheduler. Does Mailman have
one? A broom job that can be called via cron?


>  > > could be --force argument?
> 
> Deleting a list should be immediate, but I agree it should be confirmed.

... and it should be possible to pass the confirmation in the command to make
it useful in scripts.

p@rick


-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
 
___
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 2014] Mailman CLI Project

[Stephen J. Turnbull]

Rajeev S writes:

 > > Also maybe you can try making your tool a little more smart? Like lets
 > > say I try to create a list abhil...@raj.com and there is no domain
 > > raj.com in the database, so instead of just showing error maybe you can
 > > ask the user:
 > >
 > > "The domain raj.com does not exist, Do you want to create one? [y/n]"

I'm not sure I like this approach.  Creating a domain should be a
heavyweight operation, and eventually should include a bunch of sanity
checks, like existence of domains and MX records.  I have visions
(nightmares) of users coming to us saying

User: I said yes, but mail never arrives.
Dev:    Oh, is there a proper entry in the DNS?
User: Doesn't Mailman create the domain?

 > > Or maybe it could schedule a deletion after a pre-defined time with a
 > > reasonable default lets say "1 Day"? And for an urgency(to delete) there
 > > could be --force argument?

Deleting a list should be immediate, but I agree it should be confirmed.

___
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 2014] Mailman CLI Project

[Rajeev S]

Hi Barry,


Although I haven't had time to go through the code, I'm liking what I'm
> seeing
> here on the mailing list.  Just a quick comment.
> [...]
> Ideally, because this is a command line tool aimed and users, there should
> be
> a manpage for mmclient.  Fortunately, it's *really* easy to write manpages
> in reST with Sphinx.
>
>
Sure it is necessary. And writing the man page is mentioned in my proposal
as a project
deliverable.


http://sphinx-doc.org/builders.html#sphinx.builders.manpage.ManualPageBuilder
>
> And since examples never hurt:
>
> http://tinyurl.com/pwa2dfh
>
>
Thanks for the links.
___
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 2014] Mailman CLI Project

[Barry Warsaw]

On May 14, 2014, at 12:19 PM, Stephen J. Turnbull wrote:

>Barry Warsaw writes:
> > I just want it to be consistent, easily described, and easily understood by
> > users.  If it makes sense for the mmclient CLI to different from the
> > shell-access mailman command, then we at least need to be "translatable"
> > between the two.
>
>What do you mean by "shell-access mailman command"?
>src/mailman/bin/mailman.py?

Yes, as much as makes sense.  When installed into a virtual environment,
you'll have `/bin/mailman` with lots of subcommands, many of which are
similar to mmclient.  It may not be possible to give them identical
signatures, and that's fine, but it would be great if when someone learns the
commands for one, the other will not break their intuition, especially for
things that are "close".

Cheers,
-Barry


signature.asc
Description: 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 2014] Mailman CLI Project

[Barry Warsaw]

Although I haven't had time to go through the code, I'm liking what I'm seeing
here on the mailing list.  Just a quick comment.

On May 27, 2014, at 12:27 PM, Abhilash Raj wrote:

>Since this tool is meant for the users, you should write better
>documentation. Like in using.txt

Ideally, because this is a command line tool aimed and users, there should be
a manpage for mmclient.  Fortunately, it's *really* easy to write manpages
in reST with Sphinx.

http://sphinx-doc.org/builders.html#sphinx.builders.manpage.ManualPageBuilder

And since examples never hurt:

http://tinyurl.com/pwa2dfh

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 2014] Mailman CLI Project

[Rajeev S]

On Tuesday 27 May 2014 12:27 PM, Abhilash Raj wrote:

Rajeev S  wrote:


Both of these options looks clean to me as a user. So if I am right you
have completed

* Listing of domains
* Listing of mailing lists(filtered by domain also)
* Creating domains
* Creating mailing lists

Right?

Since this tool is meant for the users, you should write better
documentation. Like in using.txt#39 what does long listing mean? What
does `--verbose` do for listing a domain? Or even for listing all the
lists?

As I understand using.txt is more of a command reference than documentation?

Are there only these two options for lists and domains? What about
editing any list? Adding and removing user roles will be possible after
you have create the `user` scope but editing of other parameters can be
done?


No, there are more options for lists and domains, many of which
are dependent on the users. Some of the other options are list-members,
edit and export(to CSV)/import. Hence, these would be easier to build
after a basic user class is available.


Also maybe you can try making your tool a little more smart? Like lets
say I try to create a list abhil...@raj.com and there is no domain
raj.com in the database, so instead of just showing error maybe you can
ask the user:

"The domain raj.com does not exist, Do you want to create one? [y/n]"

Just adding all the options using argparse is really not a very tough
job (and with your pace, it is definitely not going to last more than
one month ;-). Try to put some more thought to how you can make this
tool more intuitive for the end user.
What I belive is that deleting a domain should not strightforward, any
destructive command should not be. Would it not be nice to prompt the
user once before deleting? as in

"There are 100 lists associated with this domain. Once deleted you
cannot undo it, Do you really want to delete x...@yyy.com?"[y/n]

Or maybe it could schedule a deletion after a pre-defined time with a
reasonable default lets say "1 Day"? And for an urgency(to delete) there
could be --force argument?

I roughly went through your code, and I have a few more points:

* You should write tests, before writing more code. Infact you should
   follow TDD (ofcourse if you are comfortable doing it) since the
   outcome of your commands is less likely to change, even though your
   code does.
* The commit messages should be written in a language that tells a
   reader "What this commit does?". Like "Adds documentation file
   using.txt". Instad of answering "What I have done in this commit?"
   Although it is my point of view, AFAIK it is also preferred by many
   other developers.(See commit messages of barry on lp:mailman)


Everything else seems fine. Will apply the necessary changes.


___
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 2014] Mailman CLI Project

[Abhilash Raj]

Rajeev S  wrote:

> As discussed, I have completed the r54, that does the following
> 
> 1. The arguments will be specified as positional arguments
> wherever necessary and possible. The ideal way to use
> positional arguments here is "if the argument to the command
> is the name of an instance the scope, use positional args else use
> optional args"
> 
> E.g,
> To filter mailing lists based on domains, do
> 
>   mmclient show list --domain domain.org
> 
> and not
> 
>mmclient show list domain.org
> 
> To create a list, do
> 
>mmclient create list l...@domain.org
> 
> instead of
> 
>mmclient create list --list list --domain domain.org

Both of these options looks clean to me as a user. So if I am right you
have completed

* Listing of domains
* Listing of mailing lists(filtered by domain also)
* Creating domains
* Creating mailing lists

Right?

Since this tool is meant for the users, you should write better
documentation. Like in using.txt#39 what does long listing mean? What
does `--verbose` do for listing a domain? Or even for listing all the
lists?

As I understand using.txt is more of a command reference than documentation?

Are there only these two options for lists and domains? What about
editing any list? Adding and removing user roles will be possible after
you have create the `user` scope but editing of other parameters can be
done?

Also maybe you can try making your tool a little more smart? Like lets
say I try to create a list abhil...@raj.com and there is no domain
raj.com in the database, so instead of just showing error maybe you can
ask the user:

"The domain raj.com does not exist, Do you want to create one? [y/n]"

Just adding all the options using argparse is really not a very tough
job (and with your pace, it is definitely not going to last more than
one month ;-). Try to put some more thought to how you can make this
tool more intuitive for the end user.

> 2. Added a no-header option to the detailed listing so
> that it becomes easier to pip the output.
> 
> I will be making the following changes for r55
> 
> 1.Delete
> 
> Quite a straightforward one.
> 
>delete list l...@domain.org
>delete domain domain.org

What I belive is that deleting a domain should not strightforward, any
destructive command should not be. Would it not be nice to prompt the
user once before deleting? as in

"There are 100 lists associated with this domain. Once deleted you
cannot undo it, Do you really want to delete x...@yyy.com?"[y/n]

Or maybe it could schedule a deletion after a pre-defined time with a
reasonable default lets say "1 Day"? And for an urgency(to delete) there
could be --force argument?

> 2. Begin the third `scope` user and add methods like create,
> delete and list.
> 
>create user f...@bar.com --password PASS --name NAME
>list user [--verbose] [--no-header]
> 
> The user class would be built and managed in the same way
> as other classes.
> 
> r55 would be an easy one. Once the above changes are approved,
> r55 can be completed in a day.

I roughly went through your code, and I have a few more points:

* You should write tests, before writing more code. Infact you should
  follow TDD (ofcourse if you are comfortable doing it) since the
  outcome of your commands is less likely to change, even though your
  code does. 
* The commit messages should be written in a language that tells a
  reader "What this commit does?". Like "Adds documentation file
  using.txt". Instad of answering "What I have done in this commit?"
  Although it is my point of view, AFAIK it is also preferred by many
  other developers.(See commit messages of barry on lp:mailman)
> ___
> 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/raj.abhilash1%40gmail.com
> 
> Security Policy: http://wiki.list.org/x/QIA9



-- 
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

Re: [Mailman-Developers] GSOC 2014: CI tool for the Mailman suite and postorius improvements

[varun sharma]

Sorry for being out of touch for so long, i was having exams during
community bonding period,so i couldn't spare time for discussions. But
after doing 3 irc meetings with my mentors,i have now pretty clear
understanding on how to proceed with my project but in order to get further
suggestions from community, i am posting all the details of my project:

1. CI tool for Mailman Suite (name yet to decide):
The first part that i will be doing for next 4 weeks is CI tool for Mailman
Suite. I have already started work on that and created a launchpad
repository at https://code.launchpad.net/~varun/mailman/ci_tool. I will try
to adhere to my timeline, so by the end of this week i'll be finishing with
all the unit tests of ci-tool. Right now i've written the rough
implementation of pull and test commands using python's optparse module
http://bazaar.launchpad.net/~varun/mailman/ci_tool/view/head:/ci-tool:

ci-tool -p all
(will pull all the projects which includes mailman, mailman.client,
postorius, postorius_standalone, hyperkitty and kittystore)

ci-tool -p hyperkitty
(for pulling a particular project)

ci-tool -t all
(will run all the unit tests from all the projects)

ci-tool -t postorius
(run tests specifically)

The tool is running fine but buildbot is unable to detect the failed tests
in case of running them from ci-tool, i guess i need to write plugin for
nose2 to fix this problem. Link to one of such build is
http://buildbot.sharmalabs.com/builders/runtests/builds/116
The basic commands that i think it should have are 'pull', 'test' and 'try'
but suggestions are welcomed for any new addition.

I request all the creative (and non-creative) members of the community to
suggest some cool names for the ci-tool :)


2. The UI Testing Framework for Postorius:
I have also started working on UI framework and after discussing the
possible testing frameworks that we can use in that, we decided to go with
selenium. I wrote 5 basis tests for testing the ui of postorius with
selenium webdriver (
http://bazaar.launchpad.net/~varun/mailman/ci_tool/view/head:/test_postorius.py)
and the i am yet to expand it to hyperkitty. The idea is to include this
framework into ci-tool as an optional feature.

I will be very happy to hear the feedback from the community, so that i'll
be able to make changes to my project accordingly and at right time.
Many thanks to my mentors Florian, Steve and Sneha for helping me in making
this project feasible.

@abhilsh: Sorry, i was really busy during that time,so couldn't replay
accordingly and i'll keep that in mind for future discussions.
@barry: Thanks barry, I'll make sure the test suite works fine with all the
major MTAs, DBMSs and *nix platforms.


Thanks
Varun
___
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 2014] Mailman CLI Project

[Rajeev S]

As discussed, I have completed the r54, that does the following

1. The arguments will be specified as positional arguments
wherever necessary and possible. The ideal way to use
positional arguments here is "if the argument to the command
is the name of an instance the scope, use positional args else use
optional args"

E.g,
To filter mailing lists based on domains, do

 mmclient show list --domain domain.org

and not

  mmclient show list domain.org

To create a list, do

  mmclient create list l...@domain.org

instead of

  mmclient create list --list list --domain domain.org

2. Added a no-header option to the detailed listing so
that it becomes easier to pip the output.

I will be making the following changes for r55

1.Delete

Quite a straightforward one.

  delete list l...@domain.org
  delete domain domain.org

2. Begin the third `scope` user and add methods like create,
delete and list.

  create user f...@bar.com --password PASS --name NAME
  list user [--verbose] [--no-header]

The user class would be built and managed in the same way
as other classes.

r55 would be an easy one. Once the above changes are approved,
r55 can be completed in a day.
___
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 2014] Mailman CLI Project

[Rajeev S]

Hi,

I have pushed the revision 53, that has the following changes.

1. Refactoring as mentioned in the comments by Steve
2. Grouping of options and sub commands using subparsers
3. Changed the format of the command from *mmclient  *
to *mmclient  *
4. Replaced ambiguous action *list* with *show*


The change mentioned in point 2 solves many/most of the problems
raised during the recent discussions.

The options are now paired with their corresponding sub commands.
The implications of this change is that the extra options/arguments
raise command syntax errors, which were ignored earlier. Further,
an great extent of leniency can be allowed in the command format.
To be specific, the parser can support the commands

*mmclient create list --list list1 --domain domain.org*

and

*mmclient set --key "foo" --value "bar"*

at the same time. Note that the second command has not specified a
scope.(PS: scope as in list, domain, user etc, and not site-wide, domain 
etc).


The change also prevents argparse from generating a dictionary
with all possible options (which may be huge).

The agreed change to add a positional argument for the *name*
(commands of the form *mmclient create list l...@domain.org*)
has been postponed to the next revision, as this revision mostly
contains code refactoring.

http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/53


___
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 2014] Mailman CLI Project

[Rajeev S]

On Tuesday 13 May 2014 07:12 PM, Barry Warsaw wrote:

On May 13, 2014, at 03:27 PM, Rajeev S wrote:

Would --list be implied by seeing a `--listname=l...@example.com`?  E.g. would
this be just as useful, and a little shorter:

mmclient show --listname=l...@example.com --domain=example.org

?


In the command *mmclient  * , the scope denotes
the class name and the action denotes the class method to be invoked.

The following format suggested by you,

mmclient show --listname=l...@example.com --domain=example.org

From the developer point of view, its difficult to map an action to a 
class

by using this format. For eg, the above command can be associated
with the class domain or list, as the order of the arguments is 
insignificant.


Further, the commands do not offer much advantage to the user in terms
of usability. Most of the current (frequent) commands are quite 
straightforward
and similar to the ones to be used in the shell, for eg, *create list 
l...@domain.org*

compared to *create --listname="l...@domain.org"*.

Some commands like *add-role* are less intuitive in this format,yet provide
a tolerable level of understandability.


which makes the outcome dependent on the order in which the
if-else's are written. This is a serious bug when actions like `delete`
are being used.

Destructive actions should probably be more constrained in what they allow, so
that there's no possibility of ambiguity on either the part of the user or the
code.  "In the face of ambiguity, refuse the temptation to guess."


Got a bit confused with the use of *scope* in this context.
Anyways, if the scope is not specified, apply the setting on a
default *scope*, `default=site-wide` makes sense, while others
do not.

Hmm.  If scope is optional (because it has a default), then it's not a
required positional argument, right?  So shouldn't a --switch should be used?



A switch would work best when the number of possible choices are
very few. Here we have the following choices for the scope, site-wide, 
domain

and list. It seems OK to use a switch here.

However, using switches limits the extendibility of the scopes. If a new 
scope
is to be added some day (something server-wide?), integrating new 
switches is not an easy task, when

compared to the addition of a new choice for scope in current approach.


And as the final word, I am ready to change the command style,

mmclient   

if there is some serious disagreement with it.

I just want it to be consistent, easily described, and easily understood by
users.  If it makes sense for the mmclient CLI to different from the
shell-access mailman command, then we at least need to be "translatable"
between the two.


The current format of commands,mmclientis
directly translatable to the shell. In fact, they are almost similar, 
except for the `--`

in the commands.

___
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 2014] Mailman CLI Project

[Stephen J. Turnbull]

Barry Warsaw writes:

 > Would --list be implied by seeing a `--listname=l...@example.com`?
 > E.g. would this be just as useful, and a little shorter:
 > 
 > mmclient show --listname=l...@example.com --domain=example.org

Are you thinking that this is equivalent to 

mmclient show --list --listname=l...@example.com
mmclient show --domain=example.org

which would display the set of subscribers for l...@example.com and
the set of lists for example.org?  I can see that as a minor
convenience, but it doesn't seem useful enough to allow.

 > "In the face of ambiguity, refuse the temptation to guess."

Rajeev, do you know about the Zen of Python?  If not yet, try
"python -m this".  :-)

 > I just want it to be consistent, easily described, and easily understood by
 > users.  If it makes sense for the mmclient CLI to different from the
 > shell-access mailman command, then we at least need to be "translatable"
 > between the two.

What do you mean by "shell-access mailman command"?
src/mailman/bin/mailman.py?

___
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 2014] Mailman CLI Project

[Stephen J. Turnbull]

BTW, unless specifically mentioned that I'm speaking as mentor, I'm
speaking as an ordinary developer, and you should feel free to argue
with me, or agree with me, or reserve comment until you feel
comfortable discussing issues.  Also, I apologize if I end up talking
"down" to you.  I don't know you very well yet, so feel free to let me
know you already understand what I'm talking about.

Rajeev S writes:

 > Positional arguments *can be made* optional, also be supplied
 > with a default value, in case the argument was not specified.

Sure, I'm just saying that argparse "likes" to associate "positional"
with "required", and keyword-like with "optional".  We should consider
carefully whether we want to deviate from that practice because
there's probably good reason for it.

 > In my opinion, I don't like the `one level of sub command`

That's fine by me, and as your mentor I advise that you continue to
discuss this with Barry.  I hope that you and he will come to
agreement on this point.  In the end, however, Barry is The Client,
and if you don't come to a meeting of minds the default is to do it
his way.  OK?

Taking my mentor hat off, now.

 > Further there is a possibility of the user specifying multiple scopes,
 > 
 > mmclient show --list --listname "l...@domain.org" --domain

I think this is a syntax error, and should be reported that way.

 > > In the model Rajeev has shown so far, the "scope" argument (list,
 > > domain, user) hasn't been optional.
 > 
 > I assumed this model was OK since I had received no comments
 > against that part, since the beginning. I strongly believe that it
 > is quite effective to mention the scope this way.

I agree with that.  Note, however, that it has been suggested that in
the shell it should be possible to

   >>> set scope list=foo-l...@domain.org

so that after that only list-scope commands are allowed and only
foo-list will be affected.

 > Sorry about the horse :). As I said, I assumed it was OK, and It
 > was a mistake from my part not to discuss the command syntax before
 > working on it.

Again speaking as mentor, I would not call it a "mistake" in your
case, but rather say it is up to your personal preference.  You have
demonstrated that you do write code that can be refactored and that
you refactor spontaneously.  It's acceptable for developers to "write
code for discussion" to the extent that they are comfortable with such
refactoring.  Many clients will find that a great convenience (it's a
simple form of "prototype").

Conversely it's unacceptable for you to respond to The Client's
requirements by saying "I've already written the code and it doesn't
do that."  (Except, of course, if the existing code was written to a
specification accepted by the client and he's changing his mind.  Then
both sides have a responsibility to negotiate.)

 > Also, the above is still possible with the current version. The
 > *scope* positional argument can be made to default to a *scope*
 > that has no solid structure, `settings` for example. More
 > generally, it could be defaulted to a `general` scope, managed by a
 > `General` class, that inherits from multiple classes like
 > `Settings`, `Backup/restore` etc.

Wearing my developer hat, I don't much like an implicit default
scope.  The user should either specify the scope in each command, or
explicitly specify a default scope.

Regards,
Steve
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project

[Barry Warsaw]

On May 13, 2014, at 03:27 PM, Rajeev S wrote:

>Further there is a possibility of the user specifying multiple scopes,
>
>mmclient show --list --listname "l...@domain.org" --domain

Would --list be implied by seeing a `--listname=l...@example.com`?  E.g. would
this be just as useful, and a little shorter:

mmclient show --listname=l...@example.com --domain=example.org

?

>which makes the outcome dependent on the order in which the
>if-else's are written. This is a serious bug when actions like `delete`
>are being used.

Destructive actions should probably be more constrained in what they allow, so
that there's no possibility of ambiguity on either the part of the user or the
code.  "In the face of ambiguity, refuse the temptation to guess."

>Got a bit confused with the use of *scope* in this context.
>Anyways, if the scope is not specified, apply the setting on a
>default *scope*, `default=site-wide` makes sense, while others
>do not.

Hmm.  If scope is optional (because it has a default), then it's not a
required positional argument, right?  So shouldn't a --switch should be used?

>Sorry about the horse :). As I said, I assumed it was OK, and It was a
>mistake from my part not to discuss the command syntax before working on it.
>
>Also, the above is still possible with the current version. The *scope*
>positional argument can be made to default to a *scope* that has no solid
>structure, `settings` for example. More generally, it could be defaulted to a
>`general` scope, managed by a `General` class, that inherits from multiple
>classes like `Settings`, `Backup/restore` etc.
>
>And as the final word, I am ready to change the command style,
>
>mmclient   
>
>if there is some serious disagreement with it.

I just want it to be consistent, easily described, and easily understood by
users.  If it makes sense for the mmclient CLI to different from the
shell-access mailman command, then we at least need to be "translatable"
between the two.

-Barry


signature.asc
Description: 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 2014] Mailman CLI Project

[Barry Warsaw]

On May 13, 2014, at 01:45 AM, Stephen J. Turnbull wrote:

>In the model Rajeev has shown so far, the "scope" argument (list,
>domain, user) hasn't been optional.

If it's truly non-optional in the sense that there's no default, and the scope
is required, then maybe it's okay.  It just doesn't look "normal" to me.

> > mmclient set --key  --value 
>
>This seems unnecessarily verbose on the one hand, and to not actually
>correspond to an actual use case, on the other: there's no scope
>mentioned.  I feel the scope should be mandatory, even if it's
>sitewide:
>
>mmclient set --site-wide --key CAN_PERSONALIZE --value No
>mmclient set --domain=python.org --key CAN_PERSONALIZE --value Yes

This seems different than what Rajeev wrote, where he mentions that the
'setting' argument is the scope:

On May 11, 2014, at 10:37 PM, Rajeev S wrote:

>*Preferences/settings*
>
>Settings would form a new `scope`, commands for which can be implemented
>in a fairly straightforward way.
>
>mmclient set setting  --value 

On May 13, 2014, at 01:45 AM, Stephen J. Turnbull wrote:

>(after the first one, the second would be an error, I guess, but in
>other cases a site-wide setting would be interpreted as a default).
>
>I guess this horse has already bolted the barn, but I wonder about a
>syntax like
>
>mmclient set --site-wide --key PERSONALIZE --value Permitted
>mmclient set --domain=python.org --key PERSONALIZE --value Permitted
>mmclient set --list=mailman-us...@python.org --key PERSONALIZE --value No

I think that would be fine (probably --site is sufficient, and a bit
shorter).  Also I would suggest allowing either List-ID or posting address as
an argument to --list, e.g. --list=mailman-users.python.org would also be
acceptable.  Usually there will be no difference, but lists can be renamed and
the List-ID will never change.

Cheers,
-Barry


signature.asc
Description: 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 2014] Mailman CLI Project

[Rajeev S]

On Monday 12 May 2014 09:12 PM, Barry Warsaw wrote:

A better name might be `show` since the term "list" is so overloaded in this
context.  Here's it's being used as a verb and a noun to refer to different
concepts, and I think that's confusing.


Yes, its confusing. In fact, I was looking for a replacement for that. 
Thanks.



Also as a general rule, I think we want just one level of subcommand, so that
`mmclient show --list` would be the template.  (That's open to discussion.)

...

Yuck.  Sorry but I'd like to discourage the use of made up or concatenated
words.  It's okay for some options to be multi-word separated by dashes,
e.g. --affect-bar or --change-foo.

I don't have a good alternative atm.


Will do.


E.g.

mmclient set --key  --value 


I have answered this part and the `one level subcommand` part in the 
reply to Steve's mail.

___
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 2014] Mailman CLI Project

[Rajeev S]

On Monday 12 May 2014 10:15 PM, Stephen J. Turnbull wrote:

Barry Warsaw writes:

  > Also as a general rule, I think we want just one level of
  > subcommand, so that `mmclient show --list` would be the template.
  > (That's open to discussion.)

I wonder about this in the context of argparse and the command line,
because argparse makes a strong distinction (and corresponding
associations) between *required positional* arguments and *optional*
keyword-like arguments (ie, any argument with leading dashes).


Positional arguments *can be made* optional, also be supplied
with a default value, in case the argument was not specified.

In my opinion, I don't like the `one level of sub command` as
neither the user nor the developer is benefited of such a design.
The user ends up typing the same strings as before plus an extra
`--` followed by the same set of arguments.

And from the angle of implementation, each of the *scope* name
would require a different optional argument, followed by a set of
if-else's to land at the right *scope* to manage.

Further there is a possibility of the user specifying multiple scopes,

mmclient show --list --listname "l...@domain.org" --domain

which makes the outcome dependent on the order in which the
if-else's are written. This is a serious bug when actions like `delete`
are being used.


In the model Rajeev has shown so far, the "scope" argument (list,
domain, user) hasn't been optional.


I assumed this model was OK since I had received no comments
against that part, since the beginning. I strongly believe that it is quite
effective to mention the scope this way.


  > mmclient set --key  --value 

This seems unnecessarily verbose on the one hand, and to not actually
correspond to an actual use case, on the other: there's no scope
mentioned.  I feel the scope should be mandatory, even if it's
sitewide:

 mmclient set --site-wide --key CAN_PERSONALIZE --value No
 mmclient set --domain=python.org --key CAN_PERSONALIZE --value Yes

(after the first one, the second would be an error, I guess, but in
other cases a site-wide setting would be interpreted as a default).


Got a bit confused with the use of *scope* in this context.
Anyways, if the scope is not specified, apply the setting on a
default *scope*, `default=site-wide` makes sense, while others
do not.


I guess this horse has already bolted the barn, but I wonder about a
syntax like

 mmclient set --site-wide --key PERSONALIZE --value Permitted
 mmclient set --domain=python.org --key PERSONALIZE --value Permitted
 mmclient set --list=mailman-us...@python.org --key PERSONALIZE --value No

for resource constraining settings.  (Permitted could probably be an
alias for False.)



Sorry about the horse :). As I said, I assumed it was OK, and It was a
mistake from my part not to discuss the command syntax before
working on it.

Also, the above is still possible with the current version. The *scope* 
positional argument can

be made to default to a *scope* that has no solid structure, `settings` for
example. More generally, it could be defaulted to a `general` scope, managed
by a `General` class, that inherits from multiple classes like `Settings`,
`Backup/restore` etc.

And as the final word, I am ready to change the command style,

mmclient   

if there is some serious disagreement with it.


Steve




___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project

[Stephen J. Turnbull]

Barry Warsaw writes:

 > Also as a general rule, I think we want just one level of
 > subcommand, so that `mmclient show --list` would be the template.
 > (That's open to discussion.)

I wonder about this in the context of argparse and the command line,
because argparse makes a strong distinction (and corresponding
associations) between *required positional* arguments and *optional*
keyword-like arguments (ie, any argument with leading dashes).

In the model Rajeev has shown so far, the "scope" argument (list,
domain, user) hasn't been optional.

 > mmclient set --key  --value 

This seems unnecessarily verbose on the one hand, and to not actually
correspond to an actual use case, on the other: there's no scope
mentioned.  I feel the scope should be mandatory, even if it's
sitewide:

mmclient set --site-wide --key CAN_PERSONALIZE --value No
mmclient set --domain=python.org --key CAN_PERSONALIZE --value Yes

(after the first one, the second would be an error, I guess, but in
other cases a site-wide setting would be interpreted as a default).

I guess this horse has already bolted the barn, but I wonder about a
syntax like

mmclient set --site-wide --key PERSONALIZE --value Permitted
mmclient set --domain=python.org --key PERSONALIZE --value Permitted
mmclient set --list=mailman-us...@python.org --key PERSONALIZE --value No

for resource constraining settings.  (Permitted could probably be an
alias for False.)

Steve



___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project

[Barry Warsaw]

On May 11, 2014, at 10:37 PM, Rajeev S wrote:

>I have modified the CLI to use English like commands and hence will
>use them hereafter.
>
>*list*
>
>The command lists the entities and should be available for users,mailing
>lists and domains.
>
>mmclient list list [l...@domain.org] [-v for verbose]
>mmclient list user [l...@domain.org] [-v for verbose] [--role ROLE]
>mmclient list domain [domain.org] [-v for verbose]

A better name might be `show` since the term "list" is so overloaded in this
context.  Here's it's being used as a verb and a noun to refer to different
concepts, and I think that's confusing.

Also as a general rule, I think we want just one level of subcommand, so that
`mmclient show --list` would be the template.  (That's open to discussion.)

>*Role management*
>
>User roles can be managed by two actions, addrole and
>removerole, rather than 6 separate actions for subscribe, unsubscribe,
>addowner, addmoderator, removeowner, removemoderator

Yuck.  Sorry but I'd like to discourage the use of made up or concatenated
words.  It's okay for some options to be multi-word separated by dashes,
e.g. --affect-bar or --change-foo.

I don't have a good alternative atm.

>*Preferences/settings*
>
>Settings would form a new `scope`, commands for which can be implemented
>in a fairly straightforward way.
>
>mmclient set setting  --value 

E.g.

mmclient set --key  --value 

-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 2014] Mailman CLI Project

[Barry Warsaw]

On May 11, 2014, at 10:37 PM, Rajeev S wrote:

>I doubt the usability of a common option `name`. As per the above snippet,
>you have used a `in-domain` to specify the domain name. There are many such
>instances where you would have to use more than one `name`, for instance
>adding moderators for a list. In such cases, options like `domainname`,
>`listname` and `username` would be more intuitive than using options like
>`in-domain`.

You'll want to take a cue from the `mailman create` command, and as a general
rule, I think the shell-cli should be as similar as possible to the rest-cli.
I'm open to modifying the former in order to better align them, as long as we
have a consistent view of commands and options across both tools.  Let's not
go down the accretion-without-design path of git. :)

-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 2014] Mailman CLI Project

[Rajeev S]

Hi,

I have elaborated the implementation and the motivations behind the 
current approach in the following blog post, in case it might help 
reviewing the code better.


http://myfossblog.blogspot.in/2014/05/lets-talk-over-cup-of-code.html


___
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 2014] Mailman CLI Project

[Rajeev S]

Stephen J. Turnbull wrote:

Ah, OK, I see what you're getting at now.

I think this is out of scope for the CLI project, although it's
possible that providing some kind of scriptable interface (even a
simple way to store a sequence of commands acting on the "current"
list should suffice, where "current list" is a concept his proposal
already includes) would allow it to be implemented relatively easily.
I'll discuss that with Rajeev later.

Still, I would expect that the "right" place to expose a "list style"
capability is in Postorius.  Most list admins are not even going to
have access to the CLI, most likely, because we have *no* security
model for it yet, except shell access to the list host.  The CLI is
going to be a "power user's" and sysadmin feature more than "the" way
to manage lists for most people, AIUI.  (Again, this is negotiable
with the student.)

Adding a list style attribute would be simple to implement, as Barry
had mentioned.

Also, list "styles" probably should be "stored" in the Mailman core so
they can be accessed from any client (which is what takes it right out
of the scope of this GSoC IMO, although that's negotiable, again
according to Rajeev's interest).

I have not concentrated much on the mailman core as it has
least to do with my proposal. All I have done with the mailman
core is to go through the table schema as it might be useful for
the command shell. However, I will give it a try.


HTH,
Steve



___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project

[Tom Browder]

On Sat, May 3, 2014 at 12:21 PM, Barry Warsaw  wrote:
> On May 03, 2014, at 09:59 AM, Tom Browder wrote:
...
>>Then, for other styles, we could use something like (pardon my pseudo code):
>>
>>  test_one = example.create_list('test-one', style='read-only')
...
> The CLI (i.e. `mailman create` command) does not yet accept a --style
> argument, but that would be pretty trivial to add.
>
> Note that currently only the legacy-default and legacy-announce styles are
> defined by default.

Great, the 'legacy-announce' style sounds like a 'read-only'/'news'
list!  I hope so because that's just what I'm looking for.

Best,

-Tom
___
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 2014] Mailman CLI Project

[Barry Warsaw]

On May 03, 2014, at 09:59 AM, Tom Browder wrote:

>Using the latest cli commands as shown in Rajeev's
>/src/mailmanclient/cli/docs/using.txt would be for the "default" list
>style:
>
>  test_one = example.create_list('test-one')
>
>Then, for other styles, we could use something like (pardon my pseudo code):
>
>  test_one = example.create_list('test-one', style='read-only')
>
>Looking briefly at the cli code I see nothing about the list
>attributes Barry mentioned in last year's thread referenced above, so
>I'm not sure how this would all fit together, but I think it needs to
>be considered.

Using MM3's internal API:

from mailman.app.lifecycle import create_list
mylist = create_list('t...@example.com', style='legacy-announce')

Using the REST API

http://pythonhosted.org//mailman/src/mailman/rest/docs/lists.html#apply-a-style-at-list-creation-time

The CLI (i.e. `mailman create` command) does not yet accept a --style
argument, but that would be pretty trivial to add.

Note that currently only the legacy-default and legacy-announce styles are
defined by default.

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 2014] Mailman CLI Project

[Stephen J. Turnbull]

Tom Browder writes:

 > I think this GSoC project might be the place to at least start with
 > the option of choosing a list "style" such as a defined  "read-only"
 > mailing list.

Ah, OK, I see what you're getting at now.

I think this is out of scope for the CLI project, although it's
possible that providing some kind of scriptable interface (even a
simple way to store a sequence of commands acting on the "current"
list should suffice, where "current list" is a concept his proposal
already includes) would allow it to be implemented relatively easily.
I'll discuss that with Rajeev later.

Still, I would expect that the "right" place to expose a "list style"
capability is in Postorius.  Most list admins are not even going to
have access to the CLI, most likely, because we have *no* security
model for it yet, except shell access to the list host.  The CLI is
going to be a "power user's" and sysadmin feature more than "the" way
to manage lists for most people, AIUI.  (Again, this is negotiable
with the student.)

Also, list "styles" probably should be "stored" in the Mailman core so
they can be accessed from any client (which is what takes it right out
of the scope of this GSoC IMO, although that's negotiable, again
according to Rajeev's interest).

HTH,
Steve
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project

[Tom Browder]

On Sat, May 3, 2014 at 8:44 AM, Stephen J. Turnbull  wrote:
> Tom Browder writes:
>
>  > I haven't watched this entire thread, but I hope someone is
>  > considering setting appropriate defaults for at least two mailing list
>  > types such as:
>  >
>  >   read-only (news)
>  >   read-post (moderated or not)
>
> Not in that terminology, no.  What do you hope to type, and what
> effect do you want it to have?

We had a little discussion last year about list styles.  See this thread:

  http://www.mail-archive.com/mailman-developers%40python.org/msg13369.html

I think this GSoC project might be the place to at least start with
the option of choosing a list "style" such as a defined  "read-only"
mailing list.

Using the latest cli commands as shown in Rajeev's
/src/mailmanclient/cli/docs/using.txt would be for the "default" list
style:

  test_one = example.create_list('test-one')

Then, for other styles, we could use something like (pardon my pseudo code):

  test_one = example.create_list('test-one', style='read-only')

Looking briefly at the cli code I see nothing about the list
attributes Barry mentioned in last year's thread referenced above, so
I'm not sure how this would all fit together, but I think it needs to
be considered.

I hope this makes some sense from a very interested user.

Best regards,

-Tom
___
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 2014] Mailman CLI Project

[Stephen J. Turnbull]

Tom Browder writes:

 > I haven't watched this entire thread, but I hope someone is
 > considering setting appropriate defaults for at least two mailing list
 > types such as:
 > 
 >   read-only (news)
 >   read-post (moderated or not)

Not in that terminology, no.  What do you hope to type, and what
effect do you want it to have?

___
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 2014] Mailman CLI Project

[Stephen J. Turnbull]

Rajeev S writes:
 > Hi,
 > 
 > I have added two more methods, *create domain* and *list mailing lists*.
 > The listing feature is performed using the `tabulate` module, which I have
 > added to the install_requires.
 > 
 > Also, the usage of the CLI is explained in the cli/docs/using.txt.

Great!

I have $DAYJOB stuff that will prevent me from reviewing until at
least Monday evening (Japan time), but thank you for posting and
keeping all of us updated.
___
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 2014] Mailman CLI Project

[Tom Browder]

On Sat, May 3, 2014 at 2:49 AM, Rajeev S  wrote:
> Hi,
>
> I have added two more methods, *create domain* and *list mailing lists*.

I haven't watched this entire thread, but I hope someone is
considering setting appropriate defaults for at least two mailing list
types such as:

  read-only (news)
  read-post (moderated or not)

Excuse my imprecise terminology.

Best regards,

-Tom
___
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 2014] Mailman CLI Project

[Rajeev S]

Hi,

I have added two more methods, *create domain* and *list mailing lists*.
The listing feature is performed using the `tabulate` module, which I have
added to the install_requires.

Also, the usage of the CLI is explained in the cli/docs/using.txt.


*Regards,Rajeev S*
*Government Engineering College,Thrissur*
*http://rajeevs.tk *


On Fri, May 2, 2014 at 9:06 PM, Rajeev S  wrote:

> Hi,
>
> I have added the licensing blocks to the files and pushed the code.
>
>
> *Regards,Rajeev S*
> *Government Engineering College,Thrissur*
> *http://rajeevs.tk *
>
>
> On Fri, May 2, 2014 at 7:13 AM, Barry Warsaw  wrote:
>
>> On May 02, 2014, at 06:36 AM, Rajeev S wrote:
>>
>> >3.The code has been verified with pep8 *and* flake8 tools. It also passes
>> >most of the guidelines mentioned in Barry's styleguide. Some of the
>> >guidelines are yet to be met, like the licensing block
>> >and stuff like __all__. Also the ^L at major sections are also not
>> >added.(Is it still necessary?)
>>
>> Files should definitely all have licensing blocks.  ^Ls are not required.
>>  I
>> find them useful for Emacs navigation, but I understand they may be
>> distracting for other folks in other editors.  I really need to update the
>> style guide for Python 3 and not-quite-Python-3-yet.
>>
>> -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/rajeevs1992%40gmail.com
>>
>> 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 2014] Mailman CLI Project

[Rajeev S]

Hi,

I have added the licensing blocks to the files and pushed the code.


*Regards,Rajeev S*
*Government Engineering College,Thrissur*
*http://rajeevs.tk *


On Fri, May 2, 2014 at 7:13 AM, Barry Warsaw  wrote:

> On May 02, 2014, at 06:36 AM, Rajeev S wrote:
>
> >3.The code has been verified with pep8 *and* flake8 tools. It also passes
> >most of the guidelines mentioned in Barry's styleguide. Some of the
> >guidelines are yet to be met, like the licensing block
> >and stuff like __all__. Also the ^L at major sections are also not
> >added.(Is it still necessary?)
>
> Files should definitely all have licensing blocks.  ^Ls are not required.
>  I
> find them useful for Emacs navigation, but I understand they may be
> distracting for other folks in other editors.  I really need to update the
> style guide for Python 3 and not-quite-Python-3-yet.
>
> -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/rajeevs1992%40gmail.com
>
> 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 2014] Mailman CLI Project

[Barry Warsaw]

On May 02, 2014, at 06:36 AM, Rajeev S wrote:

>3.The code has been verified with pep8 *and* flake8 tools. It also passes
>most of the guidelines mentioned in Barry's styleguide. Some of the
>guidelines are yet to be met, like the licensing block
>and stuff like __all__. Also the ^L at major sections are also not
>added.(Is it still necessary?)

Files should definitely all have licensing blocks.  ^Ls are not required.  I
find them useful for Emacs navigation, but I understand they may be
distracting for other folks in other editors.  I really need to update the
style guide for Python 3 and not-quite-Python-3-yet.

-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 2014: CI tool for the Mailman suite and postorius improvements

[Barry Warsaw]

On May 01, 2014, at 06:25 AM, Tanstaafl wrote:

>? Not fully supporting the most popular (mysql/mariadb)?

Contributions welcome!

the-obvious-response-ly y'rs,
-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 2014: CI tool for the Mailman suite and postorius improvements

[Tanstaafl]

On 4/30/2014 10:11 AM, Barry Warsaw  wrote:

Thanks for giving me opportunity to work with mailman community this
summer. I'm an undergraduate student from Manipal Institute Of Technology,
India and i'll be working on project "CI tool for the Mailman suite and
postorius improvements".
I would love to get feedback and suggestions from the community regarding
my project which involves:
1. CI tool for Mailman Suite (mailman core, postorius, hyperkitty)
2. The UI Testing Framework for Postorius
I am in process of discussing the best possible implementation for this
project with my mentors and advice from the community for the same will be
very helpful.



One of the things I think is critical for the core, is testing it against
supported the two supported db backends, SQLite and PostgreSQL.


? Not fully supporting the most popular (mysql/mariadb)?
___
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 2014: CI tool for the Mailman suite and postorius improvements

[Barry Warsaw]

Hi Varun, welcome to Mailman GSoC!

On Apr 30, 2014, at 12:24 PM, varun sharma wrote:

>Thanks for giving me opportunity to work with mailman community this
>summer. I'm an undergraduate student from Manipal Institute Of Technology,
>India and i'll be working on project "CI tool for the Mailman suite and
>postorius improvements".
>I would love to get feedback and suggestions from the community regarding
>my project which involves:
>1. CI tool for Mailman Suite (mailman core, postorius, hyperkitty)
>2. The UI Testing Framework for Postorius
>I am in process of discussing the best possible implementation for this
>project with my mentors and advice from the community for the same will be
>very helpful.

One of the things I think is critical for the core, is testing it against
supported the two supported db backends, SQLite and PostgreSQL.  Eventually
others if/when we get some contributions.  I'd also love to see some testing
against the major MTAs, and on other *nix platforms other than Ubuntu and
Debian.

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 2014: CI tool for the Mailman suite and postorius improvements

[Abhilash Raj]

Hi Varun,

Welcome to mailman community, we look forward to a great summer with you.


On Wed, Apr 30, 2014 at 12:24 PM, varun sharma wrote:

> Hi everyone,
> Thanks for giving me opportunity to work with mailman community this
> summer. I'm an undergraduate student from Manipal Institute Of Technology,
> India and i'll be working on project "CI tool for the Mailman suite and
> postorius improvements".
> I would love to get feedback and suggestions from the community regarding
> my project which involves:
> 1. CI tool for Mailman Suite (mailman core, postorius, hyperkitty)
> 2. The UI Testing Framework for Postorius
>

I think you should give something more to comment on rather than just asking
to give suggestions and feedback. I can't tell you each and every step of
your
project only based on above two points. Maybe you can be more specific on
ideas
that you want suggestions on?

Also not everyone on this list has read your proposal, so if you want to
discuss
on whether your proposal is enough to go though the summer or you need more
details
lined out(which I am sure you do ;-), it would be best if you either blog
about
your proposal(which I guess PSF wants you to do before coding period starts)
or post about your proposal here in mm-dev and then ask for suggestions or
feedback based on that.

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 2014 : Proposal for the Mailman CLI project

[Stephen J. Turnbull]

Tanstaafl writes:
 > On 4/27/2014 11:03 AM, Stephen J. Turnbull  wrote:

 > > When you get ~250 wanted mails (many of them list, of
 > > course) and ~1000 spams (that get past the 6-sigma "if this filter
 > > thinks it's spam, throw it away!" filter) a day, automatic processing
 > > is really important.
 > 
 > ?
 > 
 > Anyone who gets ~1000 spams per day that actually make it through 
 > whatever anti-spam tools you are employing,

I didn't say that I actually see them, I said I get 1000 that can't be
rejected/discarded as spam with 6-sigma accuracy.  Dealing with the
1-in-100 Type II errors and the 2-in-100 Type I errors in the 1000 is
what much of the "automatic processing" is for.

 > then you need different/better anti-spam tools.

Suggestions are welcome.  Most of the problematic mail is in Japanese
or Chinese however, and I don't know any tools (including GMail which
throws up false positives in my spam folder about once a week) that
get 2- or 3-sigma performance on those languages, at least not in my
multilingual context.  So I quarantine, and do a lot of tweaking of
packaged tools and postprocessing myself.

At least some commercial tools for Japanese are really horrible --
about once a week I get mail from a colleague that is marked as "spam"
or "suspected spam" by my *employer*'s filters, and traffic on this
list gets marked that way about as often. :-(


___
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 2014 : Proposal for the Mailman CLI project

[Mark Sapiro]

On 04/27/2014 08:03 AM, Stephen J. Turnbull wrote:
> 
> Unfortunately I don't have a copy of your original, but what may be
> happening is not at GMail, but rather that the mailing list tries
> pretty hard to avoid HTML mail, throwing away the text/html part if
> there's a text/plain alternative, and otherwise running it through an
> HTML-to-text converter (probably Lynx with output to a file).
> 
> It could also just be my local MUA, which I have set up to try to
> minimize the HTML mail that I see.
> 
> Mark can probably say with some confidence.


This list's content filtering removes all text/html parts from list posts.

This, combined with the fact that web based MUAs such as Gmail and Yahoo
typically default to 'rich text' composition and allow things like bold,
underline and italic, can create issues.

When you send such an email, the MUA typically creates a
multipart/alternative message with text/plain and text/html
alternatives. The text/html alternative will generally render very much
like what you saw in the composition window, at least in MUAs that
understand MIME and render HTML. The text/plain alternative is more
problematic. Yahoo's is frankly terrible, at least if you view the raw
text. Gmail's is better, but it uses the more or less standard star,
underscore and slash convention for *bold*, _underlined_ and /italic/ text.

On most (ed. comment - intelligent) discussion lists, you will only
receive the text/plain part. If the poster has cut/pasted things,
instead of seeing *some bold text*, you may see *bold **some text* or
similar anomalies.

The bottom line message is use plain text composition to begin with if
it is an option.

Confidently yours,
-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
___
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 2014 : Proposal for the Mailman CLI project

[Tanstaafl]

On 4/27/2014 11:03 AM, Stephen J. Turnbull  wrote:

When you get ~250 wanted mails (many of them list, of
course) and ~1000 spams (that get past the 6-sigma "if this filter
thinks it's spam, throw it away!" filter) a day, automatic processing
is really important.


?

Anyone who gets ~1000 spams per day that actually make it through 
whatever anti-spam tools you are employing, then you need 
different/better anti-spam tools.

___
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 2014 : Proposal for the Mailman CLI project

[Stephen J. Turnbull]

Rajeev S writes:

 > You do a *heroku login *from your shell and you can run commands on
 > the remote server of your application from your shell.This would be
 > an interesting project and would hugely benefit usability of the
 > current project.

Sure, under the hood this is just an ssh login, most likely.  However,
I wouldn't bet on it being "hugely useful", as these days most Mailman
list owners share a Mailman site using cPanel or similar, and don't
have shell access at all.  *Very* useful in beta test, though.

 > That seems like a funny GMail bug. All I did was to reorder the terms of
 > the phrase which was in boldface, using cut and paste. Anyway, I will
 > remember not to do this again.

Aargh.  HTML mail is a tool of the devil.  It is not a hacker's
friend, it makes life annoying for filtering and automatic mail
processing.  When you get ~250 wanted mails (many of them list, of
course) and ~1000 spams (that get past the 6-sigma "if this filter
thinks it's spam, throw it away!" filter) a day, automatic processing
is really important.

Unfortunately I don't have a copy of your original, but what may be
happening is not at GMail, but rather that the mailing list tries
pretty hard to avoid HTML mail, throwing away the text/html part if
there's a text/plain alternative, and otherwise running it through an
HTML-to-text converter (probably Lynx with output to a file).

It could also just be my local MUA, which I have set up to try to
minimize the HTML mail that I see.

Mark can probably say with some confidence.

___
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 2014 : Proposal for the Mailman CLI project

[Rajeev S]

>
> Please don't top-post.  It's very helpful to readers to keep the
> "subthreads" about particular issues separate, while at the same time
> bundling them together for ease of mail-handling.
>
> Why not?  The CLI tools will have access to the user database, so in
> theory you could authenticate.  In *practice*, this may be outside of
> the scope of your project because there's no provision for
> authentication in the current RESTful interface; you end up
> restricting to connections from localhost.
>

I have given this some thought and yes, you can authenticate and authorize
in both shell and tools interface. Authn/authz in shell is quite
straightforward as Abhilash mentioned and with the CLI tools, it can be
achieved, in a not so easy way. SSH keys can be used to register your shell
with the server which can be used as a token for authn/authz for the shell
user, just like the interface provided by cloud services like heroku.You do
a *heroku login *from your shell and you can run commands on the remote
server of your application from your shell.This would be an interesting
project and would hugely benefit usability of the current project.


> But by the same token, past projects have decided to connect to
> Postorius rather than Mailman itself precisely because Postorious
> *does* maintain roles and credentials for users.  Again, probably
> beyond the scope of your project, but for precisely this reason it has
> been proposed a few times that the authn/authz part of Postorius be
> broken out into a separate module.
>
> I agree with your logic here.
>
> But I find the text very difficult to read.  There should be at least
> one space after a sentence-ending period ("Yes.Users" looks like a
> class attribute!)  And I have no idea what the semantics of "*" is
> intended to be.



That seems like a funny GMail bug. All I did was to reorder the terms of
the phrase which was in boldface, using cut and paste. Anyway, I will
remember not to do this again.


> Despite the current thread on python-dev, I
> strongly recommend the pep8.py tool (available on PyPI as well as
> upstream: https://github.com/jcrocholl/pep8/).  pyflakes, pylint, and
> pychecker are also good tools, but their orientation is a bit
> different, and you may or may not find them useful (and in particular
> you may find after a while that you *never* get warnings from them).
>
> I have used pychecker before. Barry's 
> guide followed
by a PEP8 verifier would do good.
___
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 2014 : Proposal for the Mailman CLI project

[Abhilash Raj]

Hi Rajeev,

On Sat, Apr 26, 2014 at 1:27 PM, Rajeev S  wrote:

> Hi Abhilash,
>
> I did not quite get the user role part.A command line utility runs on the
> server on which a software instance runs, just like a MySQL command line
> utility.You will need physical access to the system or atleast the shell.I
> believe you cannot expect every moderator of the list to have that kind of
> access. From my point of view, the tool will be used by the list owner or
> the server admin, just like the MySQL shell,which can be used only if you
> have access to system shell.However, User/Role management can be imposed by
> including a login for the shell,if necessary.Again,that's not possible for
> the command tools.
>

The working of mysql client and this project are very different. As Steve
pointed
a lot of things might be out of scope for your project but it would be nice
if you
could discuss about the complete working of it and at-least document it so
that
if not you, someone else can leverage this discussion and help improve your
project after you are done with it.

There is usually never a physical access to a server so that is out of
question
but still applications do exist with user roles, don't they? Even in mysql
you
have users. What if on a host I run mailman as 'maxking' and on the same
host 'rajeev' and 'steve' are two other users whom I have granted owner
roles(as
an admin) to two different lists do whatever the CLI will do. Who said only
one
person can have access to a host?
___
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 2014 : Proposal for the Mailman CLI project

[Stephen J. Turnbull]

Rajeev S writes:
 > Hi Abhilash,

Please don't top-post.  It's very helpful to readers to keep the
"subthreads" about particular issues separate, while at the same time
bundling them together for ease of mail-handling.

 > I did not quite get the user role part.A command line utility runs on the
 > server on which a software instance runs, just like a MySQL command line
 > utility.You will need physical access to the system or atleast the shell.I
 > believe you cannot expect every moderator of the list to have that kind of
 > access. From my point of view, the tool will be used by the list owner or
 > the server admin, just like the MySQL shell,which can be used only if you
 > have access to system shell.However, User/Role management can be imposed by
 > including a login for the shell,if necessary.Again,that's not possible for
 > the command tools.

Why not?  The CLI tools will have access to the user database, so in
theory you could authenticate.  In *practice*, this may be outside of
the scope of your project because there's no provision for
authentication in the current RESTful interface; you end up
restricting to connections from localhost.

But by the same token, past projects have decided to connect to
Postorius rather than Mailman itself precisely because Postorious
*does* maintain roles and credentials for users.  Again, probably
beyond the scope of your project, but for precisely this reason it has
been proposed a few times that the authn/authz part of Postorius be
broken out into a separate module.

 > And Yes.Users will be a part of this. I prefer to build the other two
 > first.Many methods that can come under User class is better suited under
 > the other two.For eg, for adding a moderator to the list, you can do, *list
 > --addmoderator user_id , *which should be under the List class*. *But the
 > same from user point of view, would  be a complicated and less intuitive
 > command, *user **user_id **--addmoderator **--list list_id *. So, after the
 > list and domain functions are built, It will be more clear what the user
 > class must do.

I agree with your logic here.

But I find the text very difficult to read.  There should be at least
one space after a sentence-ending period ("Yes.Users" looks like a
class attribute!)  And I have no idea what the semantics of "*" is
intended to be.

 > About optparse, I actually meant argparse,sorry about that :). And thanks
 > for the style guide tip.

Despite the current thread on python-dev, I
strongly recommend the pep8.py tool (available on PyPI as well as
upstream: https://github.com/jcrocholl/pep8/).  pyflakes, pylint, and
pychecker are also good tools, but their orientation is a bit
different, and you may or may not find them useful (and in particular
you may find after a while that you *never* get warnings from them).



___
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 2014 : Proposal for the Mailman CLI project

[Rajeev S]

Hi Abhilash,

I did not quite get the user role part.A command line utility runs on the
server on which a software instance runs, just like a MySQL command line
utility.You will need physical access to the system or atleast the shell.I
believe you cannot expect every moderator of the list to have that kind of
access. From my point of view, the tool will be used by the list owner or
the server admin, just like the MySQL shell,which can be used only if you
have access to system shell.However, User/Role management can be imposed by
including a login for the shell,if necessary.Again,that's not possible for
the command tools.

And Yes.Users will be a part of this. I prefer to build the other two
first.Many methods that can come under User class is better suited under
the other two.For eg, for adding a moderator to the list, you can do, *list
--addmoderator user_id , *which should be under the List class*. *But the
same from user point of view, would  be a complicated and less intuitive
command, *user **user_id **--addmoderator **--list list_id *. So, after the
list and domain functions are built, It will be more clear what the user
class must do.

About optparse, I actually meant argparse,sorry about that :). And thanks
for the style guide tip.


*Regards,Rajeev S*
*Government Engineering College,Thrissur*
*http://rajeevs.tk *


On Sat, Apr 26, 2014 at 10:42 AM, Abhilash Raj wrote:

> On Fri, Apr 25, 2014 at 6:14 PM, Rajeev S  wrote:
>
>> Hi Stephen,
>>
>> The CLI project would be a sub module for the mailman.client project.
>>
>
>> Since bzr does not have the submodule feature, I must be doing it either
>> by using a new repository or as a new branch to mailman.client .The latter
>> would be better as it would be easier to integrate the code into the
>> mailman.client project when this project is completed.
>>
>
> Why do you want it to be a submodule in the first place? If you want to
> extend
> mailman.client they why not simply branch it?
>
>>
>> Now about the implementation part.As described in the project timeline,
>> the first phase would be to build the command tools. I would be building
>> two classes List and Domain, and identify the various methods that are to
>> be given to them. Many of the methods are identified in my GSoC proposal.
>> The command parsing would be handled by the python Optparse library.
>>
> Are users not going to be a part of this? Or you have thought of something
> else
> for managing users?
>
> Also in your proposal I don't find any mention of user roles. How will you
> manage
> user roles? Is the command line tool that you want to build will only be
> accessible
> by the supersuser/admin? Or moderators and assigned list owners can also
> use it
> to do whatever it does? Also if you allow moderators and owners then you
> probably
> have to think of something about permissions to restrict everyone to use
> the features
> only specific to there role.
>
> From my point of view this project would (someday) be an command line
> alternative to postorius for admin roles. Not that you have to do
> everything in this summer, but it
> should be kept in mind while you work on it.
>
> Also may I suggest you to use argparse instead of optparse -- it is now
> depricated
> since py2.7.
>
>>
>>
> I would like to start building the Version 0, but not to throw away, but
>> will be refining it further as per the feedback. If all this is OK I would
>> start building the version and push it to the mailman.client project.
>>
>>
> You probably should figure out everything before you jump on to coding.
> The time till
> 19th May is allotted for community bonding and there is a reason for that.
> Try to
> understand how new features are discussed in here(mailman community) before
> becoming python statements.
>
> I don't know if you already have, but try to read the source code and
> understand the
> coding style Barry prefers. There is a style guide for mailman, find it
> out.
>
>  And forget about the git vs bzr part. I am OK with using bzr :).
>>
>> Great.
>
> 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

Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project

[Abhilash Raj]

On Fri, Apr 25, 2014 at 6:14 PM, Rajeev S  wrote:

> Hi Stephen,
>
> The CLI project would be a sub module for the mailman.client project.
>

> Since bzr does not have the submodule feature, I must be doing it either
> by using a new repository or as a new branch to mailman.client .The latter
> would be better as it would be easier to integrate the code into the
> mailman.client project when this project is completed.
>

Why do you want it to be a submodule in the first place? If you want to
extend
mailman.client they why not simply branch it?

>
> Now about the implementation part.As described in the project timeline,
> the first phase would be to build the command tools. I would be building
> two classes List and Domain, and identify the various methods that are to
> be given to them. Many of the methods are identified in my GSoC proposal.
> The command parsing would be handled by the python Optparse library.
>
Are users not going to be a part of this? Or you have thought of something
else
for managing users?

Also in your proposal I don't find any mention of user roles. How will you
manage
user roles? Is the command line tool that you want to build will only be
accessible
by the supersuser/admin? Or moderators and assigned list owners can also
use it
to do whatever it does? Also if you allow moderators and owners then you
probably
have to think of something about permissions to restrict everyone to use
the features
only specific to there role.

>From my point of view this project would (someday) be an command line
alternative to postorius for admin roles. Not that you have to do
everything in this summer, but it
should be kept in mind while you work on it.

Also may I suggest you to use argparse instead of optparse -- it is now
depricated
since py2.7.

>
>
I would like to start building the Version 0, but not to throw away, but
> will be refining it further as per the feedback. If all this is OK I would
> start building the version and push it to the mailman.client project.
>
>
You probably should figure out everything before you jump on to coding. The
time till
19th May is allotted for community bonding and there is a reason for that.
Try to
understand how new features are discussed in here(mailman community) before
becoming python statements.

I don't know if you already have, but try to read the source code and
understand the
coding style Barry prefers. There is a style guide for mailman, find it
out.

And forget about the git vs bzr part. I am OK with using bzr :).
>
> Great.

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

Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project

[Rajeev S]

Hi Stephen,

The CLI project would be a sub module for the mailman.client project.

Since bzr does not have the submodule feature, I must be doing it either by
using a new repository or as a new branch to mailman.client .The latter
would be better as it would be easier to integrate the code into the
mailman.client project when this project is completed.

Now about the implementation part.As described in the project timeline, the
first phase would be to build the command tools. I would be building two
classes List and Domain, and identify the various methods that are to be
given to them. Many of the methods are identified in my GSoC proposal. The
command parsing would be handled by the python Optparse library.

I would like to start building the Version 0, but not to throw away, but
will be refining it further as per the feedback. If all this is OK I would
start building the version and push it to the mailman.client project.

And forget about the git vs bzr part. I am OK with using bzr :).




*Regards,Rajeev S*
*Government Engineering College,Thrissur*
*http://rajeevs.tk *


On Tue, Apr 22, 2014 at 9:01 PM, Stephen J. Turnbull wrote:

> Just to follow up quickly (I've got problems I need to deal with
> elsewhere over the next couple days).
>
> Abhilash Raj writes:
>
> Hey, thanks for jumping in, maxking!
>
>  > Hi Rajeev,
>  >
>  > Congratulations! We look forward to a great summer with you.
>
> Definitely!
>
>  >> I would like to thank the Mailman community and mentors for
>  >> their extensive > support during my application process,
>
> You're very welcome.
>
>  >> Also I have a few questions as part of the community bonding
>  >> process.
>  >>
>  >> 1.Is the project to be developed as an independent project or as a
>  >> part/branch of the Mailman Core repository
>  >
>  > That is supposed to be an implementation detail of your
>  > proposal. What do you think would be the best?
>
> I agree with Abhilash.  You make a proposal, we'll criticize it
> (contructively; "criticism" is not necessarily negative, just as with
> literary critics we may give a positive review -- you should know when
> you're doing things right).
>
>  >> 2.If it is an Independent project, Is it OK to use the >
>  >> git+gitorious/savannah or should I stick to bzr+launchpad? I have
>  >> used git extensively,naturally more comfortable with git.
>  >> However, I can pick up bzr if necessary.
>
>  > Even if it is an independent project we strongly encourage you to
>  > use bzr, as integration and code review might become a problem in
>  > later stages of your project( I am speaking from personal
>  > experience). Learning bzr and launchpad is not at all difficult if
>  > you know git.
>
> The CLI won't be *that* independent.  It really needs to be on
> Launchpad.
>
> Note: It may be possible to use git-bzr to fetch and push from
> Launchpad.
>
>  >> 3.Is it necessary for me to hangout in the IRC?If yes, when?
>  >
>  > It is not *necessary* for you to hangout on IRC. You just need to
>  > keep your mentors updated about what are you doing all the time. If
>  > you prefer email, I don't think that would be a problem. Your only
>  > responsibility is to deliver the project you proposed on time.
>
> It's generally a good idea to have interaction (brainstorming) when
> working on design.  I can generally be available on IRC from about
> 01:00 UTC to 15:00 UTC.  As Abhilash knows :-) I can often be
> convinced to stay around until about 17:00 UTC.  yaseppochi @ freenode
>
>  >> 4.Can I start coding right away?
>  >
>  > You can, but first be sure you know what you want to code. Your
>  > proposal does have a detailed description on working of the tool,
>  > however there is little mention about the details of implementation
>  > and design. It would be best if you first consult with your mentors
>  > and decide on something so that you don't waste time writing code
>  > that is not needed.
>
> Read Fred Brooks' /The Mythical Man-Month/, especially the essay
> "Build One to Throw Away".  Then think about whether you really
> believe him. :-)
>
> Regards and looking forward to working with you!
>
> Steve
>
>
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project

[Stephen J. Turnbull]

Just to follow up quickly (I've got problems I need to deal with
elsewhere over the next couple days).

Abhilash Raj writes:

Hey, thanks for jumping in, maxking!

 > Hi Rajeev,
 > 
 > Congratulations! We look forward to a great summer with you.

Definitely!

 >> I would like to thank the Mailman community and mentors for
 >> their extensive > support during my application process,

You're very welcome.

 >> Also I have a few questions as part of the community bonding
 >> process.
 >>
 >> 1.Is the project to be developed as an independent project or as a
 >> part/branch of the Mailman Core repository
 > 
 > That is supposed to be an implementation detail of your
 > proposal. What do you think would be the best?

I agree with Abhilash.  You make a proposal, we'll criticize it
(contructively; "criticism" is not necessarily negative, just as with
literary critics we may give a positive review -- you should know when
you're doing things right).

 >> 2.If it is an Independent project, Is it OK to use the >
 >> git+gitorious/savannah or should I stick to bzr+launchpad? I have
 >> used git extensively,naturally more comfortable with git.
 >> However, I can pick up bzr if necessary.

 > Even if it is an independent project we strongly encourage you to
 > use bzr, as integration and code review might become a problem in
 > later stages of your project( I am speaking from personal
 > experience). Learning bzr and launchpad is not at all difficult if
 > you know git.

The CLI won't be *that* independent.  It really needs to be on
Launchpad.

Note: It may be possible to use git-bzr to fetch and push from
Launchpad.

 >> 3.Is it necessary for me to hangout in the IRC?If yes, when?
 > 
 > It is not *necessary* for you to hangout on IRC. You just need to
 > keep your mentors updated about what are you doing all the time. If
 > you prefer email, I don't think that would be a problem. Your only
 > responsibility is to deliver the project you proposed on time.

It's generally a good idea to have interaction (brainstorming) when
working on design.  I can generally be available on IRC from about
01:00 UTC to 15:00 UTC.  As Abhilash knows :-) I can often be
convinced to stay around until about 17:00 UTC.  yaseppochi @ freenode

 >> 4.Can I start coding right away?
 > 
 > You can, but first be sure you know what you want to code. Your
 > proposal does have a detailed description on working of the tool,
 > however there is little mention about the details of implementation
 > and design. It would be best if you first consult with your mentors
 > and decide on something so that you don't waste time writing code
 > that is not needed.

Read Fred Brooks' /The Mythical Man-Month/, especially the essay
"Build One to Throw Away".  Then think about whether you really
believe him. :-)

Regards and looking forward to working with you!

Steve

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project

[Rajeev S]

Hi Abhilash,

Thank you for the reply.

I will post a write up describing the implementation details of the
project.All other issues stand resolved.I will be using bzr+launchpad,and I
prefer mail to IRC.




*Regards,Rajeev S*
*Government Engineering College,Thrissur*
*http://rajeevs.tk *


On Tue, Apr 22, 2014 at 7:42 PM, Abhilash Raj wrote:

> Hi Rajeev,
>
> Congratulations! We look forward to a great summer with you.
>
> On Tue, Apr 22, 2014 at 3:47 PM, Rajeev S  wrote:
>
>> Hi,
>>
>> My proposal has been successfully accepted into the GSoC 2014 program.I
>> would like to thank the Mailman community and mentors for their extensive
>> support during my application process,especially Mr. Stephen Turnbull.
>>
>> Also I have a few questions as part of the community bonding process.
>>
>> 1.Is the project to be developed as an independent project or as a
>> part/branch of the Mailman Core repository
>>
>
> That is supposed to be an implementation detail of your proposal. What do
> you
> think would be the best?
>
>
>> 2.If it is an Independent project, Is it OK to use the
>> git+gitorious/savannah or should I stick to bzr+launchpad? I have used git
>> extensively,naturally more comfortable with git.However, I can pick up bzr
>> if necessary.
>>
>
> Even if it is an independent project we strongly encourage you to use bzr,
> as
> integration and code review might become a problem in later stages of your
> project( I am speaking from personal experience). Learning bzr and
> launchpad
> is not at all difficult if you know git.
>
>
>> 3.Is it necessary for me to hangout in the IRC?If yes, when?
>>
>
> It is not *necessary* for you to hangout on IRC. You just need to keep
> your mentors updated about what are you doing all the time. If you prefer
> email, I don't think that would be a problem. Your only responsibility
> is to deliver the project you proposed on time.
>
> 4.Can I start coding right away?
>>
>
> You can, but first be sure you know what you want to code. Your proposal
> does have a detailed description on working of the tool, however there is
> little mention about the details of implementation and design. It would
> be best if you first consult with your mentors and decide on something so
> that you don't waste time writing code that is not needed.
>
>>
>> Thank you once again!
>>
>>
>> *Regards,Rajeev S*
>> *Government Engineering College,Thrissur*
>> *http://rajeevs.tk *
>>
>>
>> On Thu, Mar 20, 2014 at 6:50 PM, Rajeev S  wrote:
>>
>> > Hi,
>> >
>> > Made a minor edit upon Meflin's comment, asking to change project title.
>> >
>> > http://myfossblog.blogspot.in/2014/03/yet-another-change.html
>> >
>> >
>> > *Regards,Rajeev S*
>> > *Government Engineering College,Thrissur*
>> > *http://rajeevs.tk *
>>
>> >
>> >
>> > On Fri, Mar 14, 2014 at 3:50 PM, Rajeev S 
>> wrote:
>> >
>> >> Hi,
>> >>
>> >> I have submitted a proposal for the Mailman CLI project through
>> >> melange.You can find it here
>> >>
>> >>
>> >>
>> https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/rajeevs1992/5629499534213120
>> >>
>> >> (Organisation view only)
>> >>
>> >> I have gone through the suggestions by Stephen as comments to the
>> >> proposal and revised the proposal accordingly.
>> >>
>> >>
>> http://myfossblog.blogspot.in/2014/03/gsoc-proposal-to-gnu-mailman.html
>> >>
>> >>
>> >>
>> >> *Regards,Rajeev S*
>> >> *Government Engineering College,Thrissur*
>> >> *http://rajeevs.tk *
>> >>
>> >
>> >
>> ___
>> 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/raj.abhilash1%40gmail.com
>>
>> Security Policy: http://wiki.list.org/x/QIA9
>>
>
>
>
> --
> 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

Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project

[Abhilash Raj]

Hi Rajeev,

Congratulations! We look forward to a great summer with you.

On Tue, Apr 22, 2014 at 3:47 PM, Rajeev S  wrote:

> Hi,
>
> My proposal has been successfully accepted into the GSoC 2014 program.I
> would like to thank the Mailman community and mentors for their extensive
> support during my application process,especially Mr. Stephen Turnbull.
>
> Also I have a few questions as part of the community bonding process.
>
> 1.Is the project to be developed as an independent project or as a
> part/branch of the Mailman Core repository
>

That is supposed to be an implementation detail of your proposal. What do
you
think would be the best?


> 2.If it is an Independent project, Is it OK to use the
> git+gitorious/savannah or should I stick to bzr+launchpad? I have used git
> extensively,naturally more comfortable with git.However, I can pick up bzr
> if necessary.
>

Even if it is an independent project we strongly encourage you to use bzr,
as
integration and code review might become a problem in later stages of your
project( I am speaking from personal experience). Learning bzr and launchpad
is not at all difficult if you know git.


> 3.Is it necessary for me to hangout in the IRC?If yes, when?
>

It is not *necessary* for you to hangout on IRC. You just need to keep
your mentors updated about what are you doing all the time. If you prefer
email, I don't think that would be a problem. Your only responsibility
is to deliver the project you proposed on time.

4.Can I start coding right away?
>

You can, but first be sure you know what you want to code. Your proposal
does have a detailed description on working of the tool, however there is
little mention about the details of implementation and design. It would
be best if you first consult with your mentors and decide on something so
that you don't waste time writing code that is not needed.

>
> Thank you once again!
>
>
> *Regards,Rajeev S*
> *Government Engineering College,Thrissur*
> *http://rajeevs.tk *
>
>
> On Thu, Mar 20, 2014 at 6:50 PM, Rajeev S  wrote:
>
> > Hi,
> >
> > Made a minor edit upon Meflin's comment, asking to change project title.
> >
> > http://myfossblog.blogspot.in/2014/03/yet-another-change.html
> >
> >
> > *Regards,Rajeev S*
> > *Government Engineering College,Thrissur*
> > *http://rajeevs.tk *
> >
> >
> > On Fri, Mar 14, 2014 at 3:50 PM, Rajeev S  wrote:
> >
> >> Hi,
> >>
> >> I have submitted a proposal for the Mailman CLI project through
> >> melange.You can find it here
> >>
> >>
> >>
> https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/rajeevs1992/5629499534213120
> >>
> >> (Organisation view only)
> >>
> >> I have gone through the suggestions by Stephen as comments to the
> >> proposal and revised the proposal accordingly.
> >>
> >> http://myfossblog.blogspot.in/2014/03/gsoc-proposal-to-gnu-mailman.html
> >>
> >>
> >>
> >> *Regards,Rajeev S*
> >> *Government Engineering College,Thrissur*
> >> *http://rajeevs.tk *
> >>
> >
> >
> ___
> 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/raj.abhilash1%40gmail.com
>
> Security Policy: http://wiki.list.org/x/QIA9
>



-- 
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

Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project

[Rajeev S]

Hi,

My proposal has been successfully accepted into the GSoC 2014 program.I
would like to thank the Mailman community and mentors for their extensive
support during my application process,especially Mr. Stephen Turnbull.

Also I have a few questions as part of the community bonding process.

1.Is the project to be developed as an independent project or as a
part/branch of the Mailman Core repository
2.If it is an Independent project, Is it OK to use the
git+gitorious/savannah or should I stick to bzr+launchpad? I have used git
extensively,naturally more comfortable with git.However, I can pick up bzr
if necessary.
3.Is it necessary for me to hangout in the IRC?If yes, when?
4.Can I start coding right away?

Thank you once again!


*Regards,Rajeev S*
*Government Engineering College,Thrissur*
*http://rajeevs.tk *


On Thu, Mar 20, 2014 at 6:50 PM, Rajeev S  wrote:

> Hi,
>
> Made a minor edit upon Meflin's comment, asking to change project title.
>
> http://myfossblog.blogspot.in/2014/03/yet-another-change.html
>
>
> *Regards,Rajeev S*
> *Government Engineering College,Thrissur*
> *http://rajeevs.tk *
>
>
> On Fri, Mar 14, 2014 at 3:50 PM, Rajeev S  wrote:
>
>> Hi,
>>
>> I have submitted a proposal for the Mailman CLI project through
>> melange.You can find it here
>>
>>
>> https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/rajeevs1992/5629499534213120
>>
>> (Organisation view only)
>>
>> I have gone through the suggestions by Stephen as comments to the
>> proposal and revised the proposal accordingly.
>>
>> http://myfossblog.blogspot.in/2014/03/gsoc-proposal-to-gnu-mailman.html
>>
>>
>>
>> *Regards,Rajeev S*
>> *Government Engineering College,Thrissur*
>> *http://rajeevs.tk *
>>
>
>
___
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 2014 : Proposal for the Mailman CLI project

[Rajeev S]

Hi,

Made a minor edit upon Meflin's comment, asking to change project title.

http://myfossblog.blogspot.in/2014/03/yet-another-change.html


*Regards,Rajeev S*
*Government Engineering College,Thrissur*
*http://rajeevs.tk *


On Fri, Mar 14, 2014 at 3:50 PM, Rajeev S  wrote:

> Hi,
>
> I have submitted a proposal for the Mailman CLI project through
> melange.You can find it here
>
>
> https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/rajeevs1992/5629499534213120
>
> (Organisation view only)
>
> I have gone through the suggestions by Stephen as comments to the proposal
> and revised the proposal accordingly.
>
> http://myfossblog.blogspot.in/2014/03/gsoc-proposal-to-gnu-mailman.html
>
>
>
> *Regards,Rajeev S*
> *Government Engineering College,Thrissur*
> *http://rajeevs.tk *
>
___
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 2014

[Abhilash Raj]

Hi Milap,

Thanks for choosing Mailman. You should get started by reading
documentation online here[1] and then trying to setup your own mailman
installation. If you have any problems in it you are free to ask any
questions here or at #mailman on freenode irc for quick replies.

About the projects you are interested in, I would suggest you to choose
one project out of the two you mentioned as get started on your proposal
asap. There are other students interested in your project as well and
you should check archives of this mailing list and go through the
discussions.

On Friday 14 March 2014 01:14 AM, Milap Bhojak wrote:
> Hello,
> 
> I'm Milap Bhojak. I'm looking for Gsoc this year. PSF is the one of my
> favorite organization (Of course) for every Py dev. :). i'm Contributor at
> VideoLAN (VLC Media Player). i'm interested in Continuous integration tool
> for the Mailman suite and  Mailman command line client projects could any
> one guide me ?
> 


[1]: http://pythonhosted.org/mailman/src/mailman/docs/START.html
[2]: http://www.mail-archive.com/mailman-developers%40python.org/

thanks,
Abhilash Raj



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 2014] Cordova/Android App for GNU Mailman Admin Interface

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 03/13/2014 05:41 AM, Bhargav Golla wrote:
> Regarding your second comment, I indeed took Terri's suggestion
> about Intel XDK and am evaluating it while I am writing the
> proposal. And I have missed out Postorius responsive UI project
> idea. Thanks for pointing it out.

The two project ideas ("Cordova app" vs. "Postorius responsive") are
similar to some extend, but with significant differences. Let me
highlight some of them:

Both projects will make you write a good amount HTML/CSS/JS code, as
Cordova also uses these technologies for the user interface. Ideally
(if both projects are implemented - which isn't very likely) the UI
should not be much different - no matter if you open Postorius on a
phone's browser or use the native Cordova app.

1. Postorius responsive
The Postorius responsive project builds on an existing (Django)
back-end that is ready to be used. You might need to implement *some*
backend features, but (in contrast to the Cordova project) especially
the authentication/authorization part is something you will not have
to worry about because the framework already takes care of this. You
can concentrate on the interesting UI parts and make everything work
nicely on a variety of different devices. Oh, but please don't
underestimate the amount of (really very interesting) work you can put
into making a site really usable with either keyboard, mouse and fingers.

2. Cordova app
The Cordova project is different in that it doesn't build on an
existing underlying back-end, which means you will have to take care
of the communication with the core, as well as of authorization.
Mailman's REST API is mainly built for local use, giving you
wide-ranging permissions by default (meaning: if your credentials are
ok, you can do everything). It's definitely not advisable to expose it
directly to a phone app and then let this app manage the permissions
(because that way all users could make themselves admins by
manipulating the app's source code). So what's needed is a layer in
between (and controlled by the site, not the app). This could be
implemented as part of Postorius, but it could theoretically also be
something else on top of the core's REST API. Which one would first
have to be discussed (there are good arguments to be made for both
scenarios). So, in the end, the Cordova project will not be a pure app
project.

Hope that helps.

Cheers
Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTIhdvAAoJEEceGbPdavl7LwAH/2tCr/NgpaD1PbygPEV1LVVP
9PGybptYEFX95eBZoZ6ZXGdOM5y1emBiNhvnoiQT8ciGYnnfqFo9yG+vlHUBbvnp
HEDvzERoYPmZs7uHTLslvqXxpoPeFNbB8Zqk9bWKZdnCa8IRNmwCj87XzKYzMCYC
PyMmpSx3/ypjYJOoyGDsDtJkSmKKX+ZyzETHL+A/N1rA/06Ic2xNhWlyqe64GDu/
N2D+wo2Qw0+DQa80733HXdHoJn/7Us4w0ed1TU58PAbRBMBhfPi69yTOH4LRgWeS
Kq7EmyaEpKOl0n12sOQv65BOxC6Y5Oryka2wkefgTsSzzTIQo8jx8BHKXXXWJww=
=eMLU
-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 2014] Cordova/Android App for GNU Mailman Admin Interface

[Stephen J. Turnbull]

Bhargav Golla writes:

 > guess the culture varies from organization to organization

Thank you for pointing this out.  Indeed it does.  ASF (and the PSF
for that matter) have a lot more applicants, and at least the PSF is
using a generic channel -- core-mentorship -- for GSoC and OPW
interns.  In those cases it makes a lot of sense to clearly indicate
what the post is for, and who.

In Mailman it happens to be the case that this list, although it is
the generic developers list, is relatively low traffic, except at GSoC
time.  So we know what you're going to talk about. :-)

 > and I should have been wary of this or should have followed usual
 > email etiquette. It was wrong on my part

I certainly wouldn't say "wrong", as you apparently are already well-
aware of the etiquette issues.  You did your best.  We can't ask for
more than that given varying culture and needs.  (Heck, I myself
didn't clean up the headers)

Steve


___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] [GSoC 2014] Cordova/Android App for GNU Mailman Admin Interface

[Bhargav Golla]

Hi Stephen

Thanks for your feedback. I sincerely apologize for CC'ing people in the
mail who weren't mentors. But, during my experience with work at ASF, I was
asked to mention the project head in all mails when there is no mentor
assigned on an idea. That is solely the reason why I included Terri and
Barry (who are on the list of mentors and also responded to my doubts). I
guess the culture varies from organization to organization and I should
have been wary of this or should have followed usual email etiquette. It
was wrong on my part and I am sure this was a learning experience and I
would ensure that this wouldn't happen another time.

Regarding your second comment, I indeed took Terri's suggestion about Intel
XDK and am evaluating it while I am writing the proposal. And I have missed
out Postorius responsive UI project idea. Thanks for pointing it out.

And regarding login screens, I meant them to be like the settings page of
apps where we provide our username and password and it will be saved until
a user wants to revoke it. That way, the user won't be asked for username
and password every time he wants to use the app.

But, taking your suggestions, I think I shouldn't hold back on my proposal
but should send it in and take feedback on it on the whole without asking
individual questions. I will turn it in once I complete it and am sure
there would be much more feedback I can expect from the likes of you.

Thanks


On Wed, Mar 12, 2014 at 9:48 PM, Stephen J. Turnbull wrote:

> Bhargav Golla writes:
>
>  > I hope my mail hasn't missed your attention. I would be very much
>  > obliged if someone could answer this question so that I can go
>  > ahead and write proposal.
>
> First, it's impolite to send mail to specific people just because
> they're answered you before, unless they are specifically interested
> in mentoring your project or have requested personal mail.  I don't
> think either is true (according to the wiki, there are no prospective
> mentors for this project -- I'm sure there are some, but they're not
> identified).  Everybody reads this list, and by addressing them
> specifically you may be sending them duplicates.  Note: no harm done
> this time, but you will be a much more valuable developer if you
> become sensitive to these "marginal" "people skills".
>
> Second, you yourself have not responded to a somewhat detailed comment
> from Terri about using HTML5.  I for one have been waiting for that.
> See also the "Postorius Responsive UI" project.
>
> Third, "there's not much here to comment on" is all I really have to
> say.  From the Subject I can see that you're interested in a handheld
> interface.  From the text you quote, I see you have a *very* basic
> grasp of the requirements of web protocols for this application.  You
> probably know a heck of a lot more -- but that's all I can confirm
> from your posts.
>
> The way you ask is problematic.  On the one hand, a GSoC proposal is
> not a homework for school.  There are no "right" answers, only good
> ones and better ones.  And you don't have to give a superior answer
> immediately to qualify, only show promise of heading in the right
> direction.  (Of course, there are more students than slots, so you
> also have to show more promise than others.  But you have another week
> or so to improve, and the delta can be in your favor.)  On the other,
> it's not *one* question.  Rather, it has a strong whiff of "please
> write half my proposal (the hard half) for me".
>
> So just write your proposal so there's something to actually comment
> on.
>
> All that said, "login screens" are way clunky for modern handheld
> apps.  Users expect a smooth convenient experience.  Second, that
> experience does not include entering passwords on a frequent basis.
> You should look into including TLS authentication.  These need not be
> present in the initial design, and maybe they won't even be in your
> delivered product.  But you should think in terms of a design that
> allows easy upgrades to the UI.
>
> Steve
>
>  >
>  > Thanks
>  >
>  >
>  > On Mon, Mar 10, 2014 at 9:23 AM, Bhargav Golla 
> wrote:
>  >
>  > > Hello
>  > >
>  > > I have gone through the Admin interface and all functions that can be
>  > > achieved with the REST API. I intend to have a login screen where a
> user
>  > > can enter URL for the REST API endpoint, REST Username and password.
> We
>  > > will use this to subsequent authenticate all requests made to fetch
>  > > subscribers list, domains list, etc.
>  > >
>  > > I was wondering if I could get some feedback on this. I will start
> writing
>  > > my proposal based on this starting point and list out what all I would
>  > > features I would be implementing during the period of GSoC.
>  > >
>  > > Regards
>  > >
>  > >
>  > > On Wed, Mar 5, 2014 at 10:32 AM, Bhargav Golla  >wrote:
>  > >
>  > >> Thanks. I would have probably missed it out the first time. I will go
>  > >> through the web UI and also the documentation of REST 

Re: [Mailman-Developers] [GSoC 2014] Cordova/Android App for GNU Mailman Admin Interface

[Stephen J. Turnbull]

Bhargav Golla writes:

 > I hope my mail hasn't missed your attention. I would be very much
 > obliged if someone could answer this question so that I can go
 > ahead and write proposal.

First, it's impolite to send mail to specific people just because
they're answered you before, unless they are specifically interested
in mentoring your project or have requested personal mail.  I don't
think either is true (according to the wiki, there are no prospective
mentors for this project -- I'm sure there are some, but they're not
identified).  Everybody reads this list, and by addressing them
specifically you may be sending them duplicates.  Note: no harm done
this time, but you will be a much more valuable developer if you
become sensitive to these "marginal" "people skills".

Second, you yourself have not responded to a somewhat detailed comment
from Terri about using HTML5.  I for one have been waiting for that.
See also the "Postorius Responsive UI" project.

Third, "there's not much here to comment on" is all I really have to
say.  From the Subject I can see that you're interested in a handheld
interface.  From the text you quote, I see you have a *very* basic
grasp of the requirements of web protocols for this application.  You
probably know a heck of a lot more -- but that's all I can confirm
from your posts.

The way you ask is problematic.  On the one hand, a GSoC proposal is
not a homework for school.  There are no "right" answers, only good
ones and better ones.  And you don't have to give a superior answer
immediately to qualify, only show promise of heading in the right
direction.  (Of course, there are more students than slots, so you
also have to show more promise than others.  But you have another week
or so to improve, and the delta can be in your favor.)  On the other,
it's not *one* question.  Rather, it has a strong whiff of "please
write half my proposal (the hard half) for me".

So just write your proposal so there's something to actually comment
on.

All that said, "login screens" are way clunky for modern handheld
apps.  Users expect a smooth convenient experience.  Second, that
experience does not include entering passwords on a frequent basis.
You should look into including TLS authentication.  These need not be
present in the initial design, and maybe they won't even be in your
delivered product.  But you should think in terms of a design that
allows easy upgrades to the UI.

Steve

 > 
 > Thanks
 > 
 > 
 > On Mon, Mar 10, 2014 at 9:23 AM, Bhargav Golla  wrote:
 > 
 > > Hello
 > >
 > > I have gone through the Admin interface and all functions that can be
 > > achieved with the REST API. I intend to have a login screen where a user
 > > can enter URL for the REST API endpoint, REST Username and password. We
 > > will use this to subsequent authenticate all requests made to fetch
 > > subscribers list, domains list, etc.
 > >
 > > I was wondering if I could get some feedback on this. I will start writing
 > > my proposal based on this starting point and list out what all I would
 > > features I would be implementing during the period of GSoC.
 > >
 > > Regards
 > >
 > >
 > > On Wed, Mar 5, 2014 at 10:32 AM, Bhargav Golla wrote:
 > >
 > >> Thanks. I would have probably missed it out the first time. I will go
 > >> through the web UI and also the documentation of REST API to understand
 > >> what all functions need to be implemented in the admin interface for a 
 > >> user.
 > >>
 > >> Regards
 > >>
 > >>
 > >> On Wed, Mar 5, 2014 at 10:25 AM, Rajeev S  wrote:
 > >>
 > >>> Hi,
 > >>>
 > >>> You will be asked for the create user prompt only the first time you run
 > >>> syncdb.That's why you don't see it now.
 > >>>
 > >>> Once the DB is created, only new tables, specified via django models,
 > >>> get added to DB during the syncdb.
 > >>>
 > >>>
 > >>> *Regards,Rajeev S*
 > >>> *Government Engineering College,Thrissur*
 > >>> *http://rajeevs.tk *
 > >>>
 > >>>
 > >>> On Wed, Mar 5, 2014 at 8:47 PM, Bhargav Golla 
 > >>> wrote:
 > >>>
 >  Hi Rajeev
 > 
 >  I wasn't asked if I wanted to create a super user when I executed
 >  python manage.py syncdb. This was the output I got with syncdb:
 >  Creating tables...
 >  Installing Custome SQL...
 >  Installing indexes...
 >  Installed 0 object(s) from 0 fixture(s)
 > 
 >  I tried python manage.py createsuperuser and was able to login with
 >  details I provided there.
 > 
 >  Thanks for your help.
 > 
 >  Regards
 > 
 > 
 >  On Wed, Mar 5, 2014 at 10:00 AM, Rajeev S wrote:
 > 
 > > Hi Bhargav,
 > >
 > > You will be asked whether to *add a superuser* during *syncdb*. If
 > > you answered no to that, do *python manage.py createsuperuser * and
 > > use that username and password to login.
 > >
 > >
 > > *Regards,Rajeev S*
 > > *Government Engineering College,Thrissur*
 > > *http://rajeevs.tk *
 > >

Re: [Mailman-Developers] [GSoC 2014] Cordova/Android App for GNU Mailman Admin Interface

[Bhargav Golla]

Hi

I hope my mail hasn't missed your attention. I would be very much obliged
if someone could answer this question so that I can go ahead and write
proposal.

Thanks


On Mon, Mar 10, 2014 at 9:23 AM, Bhargav Golla  wrote:

> Hello
>
> I have gone through the Admin interface and all functions that can be
> achieved with the REST API. I intend to have a login screen where a user
> can enter URL for the REST API endpoint, REST Username and password. We
> will use this to subsequent authenticate all requests made to fetch
> subscribers list, domains list, etc.
>
> I was wondering if I could get some feedback on this. I will start writing
> my proposal based on this starting point and list out what all I would
> features I would be implementing during the period of GSoC.
>
> Regards
>
>
> On Wed, Mar 5, 2014 at 10:32 AM, Bhargav Golla wrote:
>
>> Thanks. I would have probably missed it out the first time. I will go
>> through the web UI and also the documentation of REST API to understand
>> what all functions need to be implemented in the admin interface for a user.
>>
>> Regards
>>
>>
>> On Wed, Mar 5, 2014 at 10:25 AM, Rajeev S  wrote:
>>
>>> Hi,
>>>
>>> You will be asked for the create user prompt only the first time you run
>>> syncdb.That's why you don't see it now.
>>>
>>> Once the DB is created, only new tables, specified via django models,
>>> get added to DB during the syncdb.
>>>
>>>
>>> *Regards,Rajeev S*
>>> *Government Engineering College,Thrissur*
>>> *http://rajeevs.tk *
>>>
>>>
>>> On Wed, Mar 5, 2014 at 8:47 PM, Bhargav Golla wrote:
>>>
 Hi Rajeev

 I wasn't asked if I wanted to create a super user when I executed
 python manage.py syncdb. This was the output I got with syncdb:
 Creating tables...
 Installing Custome SQL...
 Installing indexes...
 Installed 0 object(s) from 0 fixture(s)

 I tried python manage.py createsuperuser and was able to login with
 details I provided there.

 Thanks for your help.

 Regards


 On Wed, Mar 5, 2014 at 10:00 AM, Rajeev S wrote:

> Hi Bhargav,
>
> You will be asked whether to *add a superuser* during *syncdb*. If
> you answered no to that, do *python manage.py createsuperuser * and
> use that username and password to login.
>
>
> *Regards,Rajeev S*
> *Government Engineering College,Thrissur*
> *http://rajeevs.tk *
>
>
> On Wed, Mar 5, 2014 at 8:05 PM, Bhargav Golla wrote:
>
>> Hi Abhilash
>>
>> If you mean the last step of installation where we do cd
>> postorius_standalone;python manage.py syncdb, I wasn't asked for any
>> username/password. I checked the settings.py and it doesn't have any
>> specific default username/password.
>>
>> And the http://localhost:8001/3.0 worked for me.
>>
>>
>> On Wed, Mar 5, 2014 at 9:22 AM, Abhilash Raj > >wrote:
>>
>> > Hi Bhargav,
>> >
>> > On Wednesday 05 March 2014 07:36 PM, Bhargav Golla wrote:
>> > > Thanks for that change Rajeev. I was able to get the Web UI up and
>> > running.
>> > > I was trying to find out the default Username and password for
>> this but
>> > was
>> > > unable to. When I was exploring docs in mailman.client and some
>> config
>> > > files in mailman, I found that the default username and password
>> for
>> > admin
>> > > is restadmin and restpass. Tried that and was out of luck there
>> too.
>> > Could
>> > > you help me with the default username and password details?
>> >
>> > While setting up Postorius(the web UI) when you do 'python manage.py
>> > syncdb' for the first time, it asks you to create admin. You can
>> log in
>> > using those credentials. 'restadmin' and 'restpass' are the
>> credentials
>> > for the mailman rest server.
>> >
>> > > Also, there is a using.txt doc in mailman.client which says we
>> can make
>> > the
>> > > REST requests by connecting to http://localhost:9001/3.0 using
>> username
>> > and
>> > > password. Should the URL be http://localhost:9000/3.0 for this
>> example
>> > or
>> > > would it be any different?
>> >
>> > AFAIK it is 'http://localhost:8001/3.0'. (Try it once. If I am
>> wrong
>> > please someone correct me)
>> >
>> > >
>> > > Thanks
>> > >
>> > >
>> > > On Mon, Mar 3, 2014 at 1:38 PM, Rajeev S 
>> wrote:
>> > >
>> > >> Hi Bhargav,
>> > >>
>> > >> Just do *mailman start*, without the bin.
>> > >>
>> > >> I have edited the wiki.
>> > >>
>> > >>
>> > >> *Regards, Rajeev S*
>> > >> *Government Engineering College,Thrissur*
>> > >> *http://rajeevs.tk *
>> > >>
>> > >>
>> > >> On Mon, Mar 3, 2014 at 10:37 PM, Bhargav Golla <
>> bgo...@g.clemson.edu
>> > >wrote:
>> > >>
>

Re: [Mailman-Developers] [GSoC 2014] Cordova/Android App for GNU Mailman Admin Interface

[Bhargav Golla]

Hello

I have gone through the Admin interface and all functions that can be
achieved with the REST API. I intend to have a login screen where a user
can enter URL for the REST API endpoint, REST Username and password. We
will use this to subsequent authenticate all requests made to fetch
subscribers list, domains list, etc.

I was wondering if I could get some feedback on this. I will start writing
my proposal based on this starting point and list out what all I would
features I would be implementing during the period of GSoC.

Regards


On Wed, Mar 5, 2014 at 10:32 AM, Bhargav Golla  wrote:

> Thanks. I would have probably missed it out the first time. I will go
> through the web UI and also the documentation of REST API to understand
> what all functions need to be implemented in the admin interface for a user.
>
> Regards
>
>
> On Wed, Mar 5, 2014 at 10:25 AM, Rajeev S  wrote:
>
>> Hi,
>>
>> You will be asked for the create user prompt only the first time you run
>> syncdb.That's why you don't see it now.
>>
>> Once the DB is created, only new tables, specified via django models, get
>> added to DB during the syncdb.
>>
>>
>> *Regards,Rajeev S*
>> *Government Engineering College,Thrissur*
>> *http://rajeevs.tk *
>>
>>
>> On Wed, Mar 5, 2014 at 8:47 PM, Bhargav Golla wrote:
>>
>>> Hi Rajeev
>>>
>>> I wasn't asked if I wanted to create a super user when I executed python
>>> manage.py syncdb. This was the output I got with syncdb:
>>> Creating tables...
>>> Installing Custome SQL...
>>> Installing indexes...
>>> Installed 0 object(s) from 0 fixture(s)
>>>
>>> I tried python manage.py createsuperuser and was able to login with
>>> details I provided there.
>>>
>>> Thanks for your help.
>>>
>>> Regards
>>>
>>>
>>> On Wed, Mar 5, 2014 at 10:00 AM, Rajeev S  wrote:
>>>
 Hi Bhargav,

 You will be asked whether to *add a superuser* during *syncdb*. If you
 answered no to that, do *python manage.py createsuperuser * and use
 that username and password to login.


 *Regards,Rajeev S*
 *Government Engineering College,Thrissur*
 *http://rajeevs.tk *


 On Wed, Mar 5, 2014 at 8:05 PM, Bhargav Golla wrote:

> Hi Abhilash
>
> If you mean the last step of installation where we do cd
> postorius_standalone;python manage.py syncdb, I wasn't asked for any
> username/password. I checked the settings.py and it doesn't have any
> specific default username/password.
>
> And the http://localhost:8001/3.0 worked for me.
>
>
> On Wed, Mar 5, 2014 at 9:22 AM, Abhilash Raj  >wrote:
>
> > Hi Bhargav,
> >
> > On Wednesday 05 March 2014 07:36 PM, Bhargav Golla wrote:
> > > Thanks for that change Rajeev. I was able to get the Web UI up and
> > running.
> > > I was trying to find out the default Username and password for
> this but
> > was
> > > unable to. When I was exploring docs in mailman.client and some
> config
> > > files in mailman, I found that the default username and password
> for
> > admin
> > > is restadmin and restpass. Tried that and was out of luck there
> too.
> > Could
> > > you help me with the default username and password details?
> >
> > While setting up Postorius(the web UI) when you do 'python manage.py
> > syncdb' for the first time, it asks you to create admin. You can log
> in
> > using those credentials. 'restadmin' and 'restpass' are the
> credentials
> > for the mailman rest server.
> >
> > > Also, there is a using.txt doc in mailman.client which says we can
> make
> > the
> > > REST requests by connecting to http://localhost:9001/3.0 using
> username
> > and
> > > password. Should the URL be http://localhost:9000/3.0 for this
> example
> > or
> > > would it be any different?
> >
> > AFAIK it is 'http://localhost:8001/3.0'. (Try it once. If I am wrong
> > please someone correct me)
> >
> > >
> > > Thanks
> > >
> > >
> > > On Mon, Mar 3, 2014 at 1:38 PM, Rajeev S 
> wrote:
> > >
> > >> Hi Bhargav,
> > >>
> > >> Just do *mailman start*, without the bin.
> > >>
> > >> I have edited the wiki.
> > >>
> > >>
> > >> *Regards, Rajeev S*
> > >> *Government Engineering College,Thrissur*
> > >> *http://rajeevs.tk *
> > >>
> > >>
> > >> On Mon, Mar 3, 2014 at 10:37 PM, Bhargav Golla <
> bgo...@g.clemson.edu
> > >wrote:
> > >>
> > >>> Thanks Barry and Terri for your feedback.
> > >>> I was trying to install Postorius locally and analyze what all
> would be
> > >>> required in a mobile app for Admin. Doing the same, I have hit a
> > >>> roadblock.
> > >>> I am using the wiki provided here[1]. I tried to install mailman
> using
> > >>> "set
> > >>> up sources" part of the wiki. 

Re: [Mailman-Developers] [GSoC 2014] Command line Client

[Stephen J. Turnbull]

Florian Fuchs writes:

 > One is the one-off command (with options) that outputs a result,
 > either on stdout or saved to a file. This could make for an
 > interesting project, but I think then it would really make more sense
 > (like Steve said) to extend the existing `mailman` command instead of
 > writing a new one.

Ah, I see.  I think that what you're talking about, then, is deciding
how much state to keep in configuration of the client, how much to
require the user to enter, and whether to save state changes made
during an interactive session.

For "stateless" commands like "status" (it reports the state, but
issuing it is the same regardless of current state), or simple state-
dependence (a "list lists on domain" command might be "mmclient list
lists domain=python.org) you could do it as a shell command.  For more
complicated, state-dependent commands:

$ mmclient
mm> status
all qrunners running
mm> set domain python.org
mm> set list mailman-users
mm> list members from list.org
ba...@list.org
mm>

;-)

Then set of questions might be "should mmclient automatically save the
settings for 'domain' and 'list'?  Or should there be a 'save current
settings' command?  Or a special 'configure settings' command?  Or
should the user edit mmclient.ini?"

Is that the kind of thing you mean by layout?

___
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 2014] Command line Client

[Rajeev S]

Thanks Florian. Things are much more clearer now.

I have built a basic command line version for the mailman.client, that will
currently print the domain list and mailing list lists.

This is, as Steve mentioned, like the git interface

You can find it here

  https://github.com/rajeevs1992/mailman-cli/blob/master/client

*Usage:*

To list the registered domains in your server, do

   - ./client domain --list

To list the registered mailing lists in your server, do

   - ./client list --list

For help with options available, do

   - ./client -h




*Regards,Rajeev S*
*Government Engineering College,Thrissur*
*http://rajeevs.tk *


On Wed, Mar 5, 2014 at 3:37 PM, Florian Fuchs  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 03/04/2014 10:49 AM, Stephen J. Turnbull wrote:
> > Rajeev S writes:
> >> Also, I did not quite get the "*coming up with a **great layout
> >> *" part. Do you mean to build a custom shell for mailman? If yes,
> >> what extra functionality should it provide than the standard
> >> command line tools?
> >
> > I think that probably is what he means, but I personally don't
> > think that's appropriate.  If people want a "CLI with layout"
> > (which I agree is plausible), what's wrong with Postorius via Lynx?
> > (Florian?)
>
> No, that's not what I meant (using the term "layout" was obviously
> confusing - sorry for that!). I think we're talking about two
> possible, but very different concepts of a client here:
>
> One is the one-off command (with options) that outputs a result,
> either on stdout or saved to a file. This could make for an
> interesting project, but I think then it would really make more sense
> (like Steve said) to extend the existing `mailman` command instead of
> writing a new one.
>
> The other (and the one I had in mind) is a tool you invoke with a
> commando which then offers a interface a little different from that of
> your standard terminal shell (bash or else). Just like you invoke the
> mysql/sqlite3 client (with a db name or file as option). What I meant
> by "layout" is really the question what happens after one starts the
> tool by typing something like `$ mmclient --list=f...@bar.id`" or `$
> mmclient --domain=python.org`", not the actual visual representation.
>
>
> Does that make more sense?
>
> Florian
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTFvdqAAoJEEceGbPdavl76KIIAKLIsZEux/TPCSNV9sEQGJt1
> s5gkIT298wZPPQfG+b2kllMO9o6uObQ0K10Ynk4yzLi1YngTyR1kC52Ty6uZ1pws
> YvD87o7DCeoZWDMss77+zvJkpkG+zFn4Ts3taeWW/9A1N9fJP22izgtm9aki+RLn
> 8nWn4jfTmnE3TvU8ptr/5uK0LPApfjMZz0mGCc6jgExdsJhVw11LU0Wzoxtw9424
> 1ygW2zWPcvdHTqykluvf62u24oTna641vNxE60LB9e4SF6LhS0Pi+F/w+m8zjNAT
> q3xY76yNlhZVI/N2cR4jinuUbagX61DSu7mgC4Kk08oyN6TgkS9kknlYrGupQ3c=
> =ufWT
> -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 2014] Cordova/Android App for GNU Mailman Admin Interface

[Bhargav Golla]

Thanks. I would have probably missed it out the first time. I will go
through the web UI and also the documentation of REST API to understand
what all functions need to be implemented in the admin interface for a user.

Regards


On Wed, Mar 5, 2014 at 10:25 AM, Rajeev S  wrote:

> Hi,
>
> You will be asked for the create user prompt only the first time you run
> syncdb.That's why you don't see it now.
>
> Once the DB is created, only new tables, specified via django models, get
> added to DB during the syncdb.
>
>
> *Regards,Rajeev S*
> *Government Engineering College,Thrissur*
> *http://rajeevs.tk *
>
>
> On Wed, Mar 5, 2014 at 8:47 PM, Bhargav Golla wrote:
>
>> Hi Rajeev
>>
>> I wasn't asked if I wanted to create a super user when I executed python
>> manage.py syncdb. This was the output I got with syncdb:
>> Creating tables...
>> Installing Custome SQL...
>> Installing indexes...
>> Installed 0 object(s) from 0 fixture(s)
>>
>> I tried python manage.py createsuperuser and was able to login with
>> details I provided there.
>>
>> Thanks for your help.
>>
>> Regards
>>
>>
>> On Wed, Mar 5, 2014 at 10:00 AM, Rajeev S  wrote:
>>
>>> Hi Bhargav,
>>>
>>> You will be asked whether to *add a superuser* during *syncdb*. If you
>>> answered no to that, do *python manage.py createsuperuser * and use
>>> that username and password to login.
>>>
>>>
>>> *Regards,Rajeev S*
>>> *Government Engineering College,Thrissur*
>>> *http://rajeevs.tk *
>>>
>>>
>>> On Wed, Mar 5, 2014 at 8:05 PM, Bhargav Golla wrote:
>>>
 Hi Abhilash

 If you mean the last step of installation where we do cd
 postorius_standalone;python manage.py syncdb, I wasn't asked for any
 username/password. I checked the settings.py and it doesn't have any
 specific default username/password.

 And the http://localhost:8001/3.0 worked for me.


 On Wed, Mar 5, 2014 at 9:22 AM, Abhilash Raj >>> >wrote:

 > Hi Bhargav,
 >
 > On Wednesday 05 March 2014 07:36 PM, Bhargav Golla wrote:
 > > Thanks for that change Rajeev. I was able to get the Web UI up and
 > running.
 > > I was trying to find out the default Username and password for this
 but
 > was
 > > unable to. When I was exploring docs in mailman.client and some
 config
 > > files in mailman, I found that the default username and password for
 > admin
 > > is restadmin and restpass. Tried that and was out of luck there too.
 > Could
 > > you help me with the default username and password details?
 >
 > While setting up Postorius(the web UI) when you do 'python manage.py
 > syncdb' for the first time, it asks you to create admin. You can log
 in
 > using those credentials. 'restadmin' and 'restpass' are the
 credentials
 > for the mailman rest server.
 >
 > > Also, there is a using.txt doc in mailman.client which says we can
 make
 > the
 > > REST requests by connecting to http://localhost:9001/3.0 using
 username
 > and
 > > password. Should the URL be http://localhost:9000/3.0 for this
 example
 > or
 > > would it be any different?
 >
 > AFAIK it is 'http://localhost:8001/3.0'. (Try it once. If I am wrong
 > please someone correct me)
 >
 > >
 > > Thanks
 > >
 > >
 > > On Mon, Mar 3, 2014 at 1:38 PM, Rajeev S 
 wrote:
 > >
 > >> Hi Bhargav,
 > >>
 > >> Just do *mailman start*, without the bin.
 > >>
 > >> I have edited the wiki.
 > >>
 > >>
 > >> *Regards, Rajeev S*
 > >> *Government Engineering College,Thrissur*
 > >> *http://rajeevs.tk *
 > >>
 > >>
 > >> On Mon, Mar 3, 2014 at 10:37 PM, Bhargav Golla <
 bgo...@g.clemson.edu
 > >wrote:
 > >>
 > >>> Thanks Barry and Terri for your feedback.
 > >>> I was trying to install Postorius locally and analyze what all
 would be
 > >>> required in a mobile app for Admin. Doing the same, I have hit a
 > >>> roadblock.
 > >>> I am using the wiki provided here[1]. I tried to install mailman
 using
 > >>> "set
 > >>> up sources" part of the wiki. Though python setup.py install
 executes
 > >>> without any errors, I am unable to see the folder bin/ in the same
 > >>> directory. So, even though I proceed with further setup, I am
 getting a
 > >>> "Mailman REST API not available. Please start mailman core" on my
 > >>> localhost:8000 webpage. Could anyone help me here?
 > >>>
 > >>> [1]
 > >>>
 > >>>
 >
 http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running
 > >>>
 > >>> Thanks
 > >>>
 > >>>
 > >>> On Sun, Mar 2, 2014 at 1:18 AM, Terri Oda 
 wrote:
 > >>>
 > 
 >  On 2014-02-28, 7:36 AM, Bhargav Golla wrote:
 > 
 > > I have a few questions regarding this idea

Re: [Mailman-Developers] [GSoC 2014] Cordova/Android App for GNU Mailman Admin Interface

[Rajeev S]

Hi,

You will be asked for the create user prompt only the first time you run
syncdb.That's why you don't see it now.

Once the DB is created, only new tables, specified via django models, get
added to DB during the syncdb.


*Regards,Rajeev S*
*Government Engineering College,Thrissur*
*http://rajeevs.tk *


On Wed, Mar 5, 2014 at 8:47 PM, Bhargav Golla  wrote:

> Hi Rajeev
>
> I wasn't asked if I wanted to create a super user when I executed python
> manage.py syncdb. This was the output I got with syncdb:
> Creating tables...
> Installing Custome SQL...
> Installing indexes...
> Installed 0 object(s) from 0 fixture(s)
>
> I tried python manage.py createsuperuser and was able to login with
> details I provided there.
>
> Thanks for your help.
>
> Regards
>
>
> On Wed, Mar 5, 2014 at 10:00 AM, Rajeev S  wrote:
>
>> Hi Bhargav,
>>
>> You will be asked whether to *add a superuser* during *syncdb*. If you
>> answered no to that, do *python manage.py createsuperuser * and use that
>> username and password to login.
>>
>>
>> *Regards,Rajeev S*
>> *Government Engineering College,Thrissur*
>> *http://rajeevs.tk *
>>
>>
>> On Wed, Mar 5, 2014 at 8:05 PM, Bhargav Golla wrote:
>>
>>> Hi Abhilash
>>>
>>> If you mean the last step of installation where we do cd
>>> postorius_standalone;python manage.py syncdb, I wasn't asked for any
>>> username/password. I checked the settings.py and it doesn't have any
>>> specific default username/password.
>>>
>>> And the http://localhost:8001/3.0 worked for me.
>>>
>>>
>>> On Wed, Mar 5, 2014 at 9:22 AM, Abhilash Raj >> >wrote:
>>>
>>> > Hi Bhargav,
>>> >
>>> > On Wednesday 05 March 2014 07:36 PM, Bhargav Golla wrote:
>>> > > Thanks for that change Rajeev. I was able to get the Web UI up and
>>> > running.
>>> > > I was trying to find out the default Username and password for this
>>> but
>>> > was
>>> > > unable to. When I was exploring docs in mailman.client and some
>>> config
>>> > > files in mailman, I found that the default username and password for
>>> > admin
>>> > > is restadmin and restpass. Tried that and was out of luck there too.
>>> > Could
>>> > > you help me with the default username and password details?
>>> >
>>> > While setting up Postorius(the web UI) when you do 'python manage.py
>>> > syncdb' for the first time, it asks you to create admin. You can log in
>>> > using those credentials. 'restadmin' and 'restpass' are the credentials
>>> > for the mailman rest server.
>>> >
>>> > > Also, there is a using.txt doc in mailman.client which says we can
>>> make
>>> > the
>>> > > REST requests by connecting to http://localhost:9001/3.0 using
>>> username
>>> > and
>>> > > password. Should the URL be http://localhost:9000/3.0 for this
>>> example
>>> > or
>>> > > would it be any different?
>>> >
>>> > AFAIK it is 'http://localhost:8001/3.0'. (Try it once. If I am wrong
>>> > please someone correct me)
>>> >
>>> > >
>>> > > Thanks
>>> > >
>>> > >
>>> > > On Mon, Mar 3, 2014 at 1:38 PM, Rajeev S 
>>> wrote:
>>> > >
>>> > >> Hi Bhargav,
>>> > >>
>>> > >> Just do *mailman start*, without the bin.
>>> > >>
>>> > >> I have edited the wiki.
>>> > >>
>>> > >>
>>> > >> *Regards, Rajeev S*
>>> > >> *Government Engineering College,Thrissur*
>>> > >> *http://rajeevs.tk *
>>> > >>
>>> > >>
>>> > >> On Mon, Mar 3, 2014 at 10:37 PM, Bhargav Golla <
>>> bgo...@g.clemson.edu
>>> > >wrote:
>>> > >>
>>> > >>> Thanks Barry and Terri for your feedback.
>>> > >>> I was trying to install Postorius locally and analyze what all
>>> would be
>>> > >>> required in a mobile app for Admin. Doing the same, I have hit a
>>> > >>> roadblock.
>>> > >>> I am using the wiki provided here[1]. I tried to install mailman
>>> using
>>> > >>> "set
>>> > >>> up sources" part of the wiki. Though python setup.py install
>>> executes
>>> > >>> without any errors, I am unable to see the folder bin/ in the same
>>> > >>> directory. So, even though I proceed with further setup, I am
>>> getting a
>>> > >>> "Mailman REST API not available. Please start mailman core" on my
>>> > >>> localhost:8000 webpage. Could anyone help me here?
>>> > >>>
>>> > >>> [1]
>>> > >>>
>>> > >>>
>>> >
>>> http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running
>>> > >>>
>>> > >>> Thanks
>>> > >>>
>>> > >>>
>>> > >>> On Sun, Mar 2, 2014 at 1:18 AM, Terri Oda  wrote:
>>> > >>>
>>> > 
>>> >  On 2014-02-28, 7:36 AM, Bhargav Golla wrote:
>>> > 
>>> > > I have a few questions regarding this idea.
>>> > > 1. I intend to develop it on Cordova since it will help in
>>> porting
>>> > the
>>> > >>> app
>>> > > easily to multiple platforms. Were there any ideas in this
>>> directions
>>> > > regarding going native or hybrid?
>>> > >
>>> > 
>>> >  Personally, I'd prefer if we went hybrid and had an html5 webapp
>>> that
>>> >  could be used straight over the web for mobile users who don't
>>> want to
>>> >  install a

Re: [Mailman-Developers] [GSoC 2014] Cordova/Android App for GNU Mailman Admin Interface

[Bhargav Golla]

Hi Rajeev

I wasn't asked if I wanted to create a super user when I executed python
manage.py syncdb. This was the output I got with syncdb:
Creating tables...
Installing Custome SQL...
Installing indexes...
Installed 0 object(s) from 0 fixture(s)

I tried python manage.py createsuperuser and was able to login with details
I provided there.

Thanks for your help.

Regards


On Wed, Mar 5, 2014 at 10:00 AM, Rajeev S  wrote:

> Hi Bhargav,
>
> You will be asked whether to *add a superuser* during *syncdb*. If you
> answered no to that, do *python manage.py createsuperuser * and use that
> username and password to login.
>
>
> *Regards,Rajeev S*
> *Government Engineering College,Thrissur*
> *http://rajeevs.tk *
>
>
> On Wed, Mar 5, 2014 at 8:05 PM, Bhargav Golla wrote:
>
>> Hi Abhilash
>>
>> If you mean the last step of installation where we do cd
>> postorius_standalone;python manage.py syncdb, I wasn't asked for any
>> username/password. I checked the settings.py and it doesn't have any
>> specific default username/password.
>>
>> And the http://localhost:8001/3.0 worked for me.
>>
>>
>> On Wed, Mar 5, 2014 at 9:22 AM, Abhilash Raj > >wrote:
>>
>> > Hi Bhargav,
>> >
>> > On Wednesday 05 March 2014 07:36 PM, Bhargav Golla wrote:
>> > > Thanks for that change Rajeev. I was able to get the Web UI up and
>> > running.
>> > > I was trying to find out the default Username and password for this
>> but
>> > was
>> > > unable to. When I was exploring docs in mailman.client and some config
>> > > files in mailman, I found that the default username and password for
>> > admin
>> > > is restadmin and restpass. Tried that and was out of luck there too.
>> > Could
>> > > you help me with the default username and password details?
>> >
>> > While setting up Postorius(the web UI) when you do 'python manage.py
>> > syncdb' for the first time, it asks you to create admin. You can log in
>> > using those credentials. 'restadmin' and 'restpass' are the credentials
>> > for the mailman rest server.
>> >
>> > > Also, there is a using.txt doc in mailman.client which says we can
>> make
>> > the
>> > > REST requests by connecting to http://localhost:9001/3.0 using
>> username
>> > and
>> > > password. Should the URL be http://localhost:9000/3.0 for this
>> example
>> > or
>> > > would it be any different?
>> >
>> > AFAIK it is 'http://localhost:8001/3.0'. (Try it once. If I am wrong
>> > please someone correct me)
>> >
>> > >
>> > > Thanks
>> > >
>> > >
>> > > On Mon, Mar 3, 2014 at 1:38 PM, Rajeev S 
>> wrote:
>> > >
>> > >> Hi Bhargav,
>> > >>
>> > >> Just do *mailman start*, without the bin.
>> > >>
>> > >> I have edited the wiki.
>> > >>
>> > >>
>> > >> *Regards, Rajeev S*
>> > >> *Government Engineering College,Thrissur*
>> > >> *http://rajeevs.tk *
>> > >>
>> > >>
>> > >> On Mon, Mar 3, 2014 at 10:37 PM, Bhargav Golla > > >wrote:
>> > >>
>> > >>> Thanks Barry and Terri for your feedback.
>> > >>> I was trying to install Postorius locally and analyze what all
>> would be
>> > >>> required in a mobile app for Admin. Doing the same, I have hit a
>> > >>> roadblock.
>> > >>> I am using the wiki provided here[1]. I tried to install mailman
>> using
>> > >>> "set
>> > >>> up sources" part of the wiki. Though python setup.py install
>> executes
>> > >>> without any errors, I am unable to see the folder bin/ in the same
>> > >>> directory. So, even though I proceed with further setup, I am
>> getting a
>> > >>> "Mailman REST API not available. Please start mailman core" on my
>> > >>> localhost:8000 webpage. Could anyone help me here?
>> > >>>
>> > >>> [1]
>> > >>>
>> > >>>
>> >
>> http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running
>> > >>>
>> > >>> Thanks
>> > >>>
>> > >>>
>> > >>> On Sun, Mar 2, 2014 at 1:18 AM, Terri Oda  wrote:
>> > >>>
>> > 
>> >  On 2014-02-28, 7:36 AM, Bhargav Golla wrote:
>> > 
>> > > I have a few questions regarding this idea.
>> > > 1. I intend to develop it on Cordova since it will help in porting
>> > the
>> > >>> app
>> > > easily to multiple platforms. Were there any ideas in this
>> directions
>> > > regarding going native or hybrid?
>> > >
>> > 
>> >  Personally, I'd prefer if we went hybrid and had an html5 webapp
>> that
>> >  could be used straight over the web for mobile users who don't
>> want to
>> >  install an app, with Cordova used to build the individual platform
>> > >>> apps.  I
>> >  may not be the mentor on this one, though, so I'm happy to defer to
>> > >>> whoever
>> >  the final mentor is on this front.
>> > 
>> >  Incidentally, I've been using Intel's XDK for building Cordova apps
>> > >>> lately
>> >  and highly recommend it for quick testing on various platforms and
>> > >>> screen
>> >  sizes.  I've found it a very useful tool, and not just because I
>> work
>> > >>> for
>> >  Intel now!
>> > 
>> >   2. Can I assume that all ma

Re: [Mailman-Developers] [GSoC 2014] Cordova/Android App for GNU Mailman Admin Interface

[Rajeev S]

Hi Bhargav,

You will be asked whether to *add a superuser* during *syncdb*. If you
answered no to that, do *python manage.py createsuperuser * and use that
username and password to login.


*Regards,Rajeev S*
*Government Engineering College,Thrissur*
*http://rajeevs.tk *


On Wed, Mar 5, 2014 at 8:05 PM, Bhargav Golla  wrote:

> Hi Abhilash
>
> If you mean the last step of installation where we do cd
> postorius_standalone;python manage.py syncdb, I wasn't asked for any
> username/password. I checked the settings.py and it doesn't have any
> specific default username/password.
>
> And the http://localhost:8001/3.0 worked for me.
>
>
> On Wed, Mar 5, 2014 at 9:22 AM, Abhilash Raj  >wrote:
>
> > Hi Bhargav,
> >
> > On Wednesday 05 March 2014 07:36 PM, Bhargav Golla wrote:
> > > Thanks for that change Rajeev. I was able to get the Web UI up and
> > running.
> > > I was trying to find out the default Username and password for this but
> > was
> > > unable to. When I was exploring docs in mailman.client and some config
> > > files in mailman, I found that the default username and password for
> > admin
> > > is restadmin and restpass. Tried that and was out of luck there too.
> > Could
> > > you help me with the default username and password details?
> >
> > While setting up Postorius(the web UI) when you do 'python manage.py
> > syncdb' for the first time, it asks you to create admin. You can log in
> > using those credentials. 'restadmin' and 'restpass' are the credentials
> > for the mailman rest server.
> >
> > > Also, there is a using.txt doc in mailman.client which says we can make
> > the
> > > REST requests by connecting to http://localhost:9001/3.0 using
> username
> > and
> > > password. Should the URL be http://localhost:9000/3.0 for this example
> > or
> > > would it be any different?
> >
> > AFAIK it is 'http://localhost:8001/3.0'. (Try it once. If I am wrong
> > please someone correct me)
> >
> > >
> > > Thanks
> > >
> > >
> > > On Mon, Mar 3, 2014 at 1:38 PM, Rajeev S 
> wrote:
> > >
> > >> Hi Bhargav,
> > >>
> > >> Just do *mailman start*, without the bin.
> > >>
> > >> I have edited the wiki.
> > >>
> > >>
> > >> *Regards, Rajeev S*
> > >> *Government Engineering College,Thrissur*
> > >> *http://rajeevs.tk *
> > >>
> > >>
> > >> On Mon, Mar 3, 2014 at 10:37 PM, Bhargav Golla  > >wrote:
> > >>
> > >>> Thanks Barry and Terri for your feedback.
> > >>> I was trying to install Postorius locally and analyze what all would
> be
> > >>> required in a mobile app for Admin. Doing the same, I have hit a
> > >>> roadblock.
> > >>> I am using the wiki provided here[1]. I tried to install mailman
> using
> > >>> "set
> > >>> up sources" part of the wiki. Though python setup.py install executes
> > >>> without any errors, I am unable to see the folder bin/ in the same
> > >>> directory. So, even though I proceed with further setup, I am
> getting a
> > >>> "Mailman REST API not available. Please start mailman core" on my
> > >>> localhost:8000 webpage. Could anyone help me here?
> > >>>
> > >>> [1]
> > >>>
> > >>>
> >
> http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running
> > >>>
> > >>> Thanks
> > >>>
> > >>>
> > >>> On Sun, Mar 2, 2014 at 1:18 AM, Terri Oda  wrote:
> > >>>
> > 
> >  On 2014-02-28, 7:36 AM, Bhargav Golla wrote:
> > 
> > > I have a few questions regarding this idea.
> > > 1. I intend to develop it on Cordova since it will help in porting
> > the
> > >>> app
> > > easily to multiple platforms. Were there any ideas in this
> directions
> > > regarding going native or hybrid?
> > >
> > 
> >  Personally, I'd prefer if we went hybrid and had an html5 webapp
> that
> >  could be used straight over the web for mobile users who don't want
> to
> >  install an app, with Cordova used to build the individual platform
> > >>> apps.  I
> >  may not be the mentor on this one, though, so I'm happy to defer to
> > >>> whoever
> >  the final mentor is on this front.
> > 
> >  Incidentally, I've been using Intel's XDK for building Cordova apps
> > >>> lately
> >  and highly recommend it for quick testing on various platforms and
> > >>> screen
> >  sizes.  I've found it a very useful tool, and not just because I
> work
> > >>> for
> >  Intel now!
> > 
> >   2. Can I assume that all mailing lists built by Mailman support the
> > >>> REST
> > > interface? Also, I have tried to see if I can get JSON responses
> and
> > I
> > >>> am
> > > unable to by adding a HTTP Accept Header to take
> "application/json".
> > >>> Am I
> > > doing anything wrong or is JSON not implemented?
> > >
> > 
> >  I don't know the answer to this off the top of my head: Barry?
> > 
> > 
> >   3. As a starter, could I ignore internationalization for GSoC, but
> > > implement interface in such a way as to be able to internationalize
> > it
> > >

Re: [Mailman-Developers] [GSoC 2014] Cordova/Android App for GNU Mailman Admin Interface

[Barry Warsaw]

On Mar 05, 2014, at 09:06 AM, Bhargav Golla wrote:

>files in mailman, I found that the default username and password for admin
>is restadmin and restpass. Tried that and was out of luck there too. Could
>you help me with the default username and password details?

That's only the default username and password for the privileged admin REST
API in the core.  The web ui uses that to speak to the core, but if you're
connecting to the web ui, that username and password won't be exposed.

-Barry


signature.asc
Description: 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 2014] Cordova/Android App for GNU Mailman Admin Interface

[Bhargav Golla]

Hi Abhilash

If you mean the last step of installation where we do cd
postorius_standalone;python manage.py syncdb, I wasn't asked for any
username/password. I checked the settings.py and it doesn't have any
specific default username/password.

And the http://localhost:8001/3.0 worked for me.


On Wed, Mar 5, 2014 at 9:22 AM, Abhilash Raj wrote:

> Hi Bhargav,
>
> On Wednesday 05 March 2014 07:36 PM, Bhargav Golla wrote:
> > Thanks for that change Rajeev. I was able to get the Web UI up and
> running.
> > I was trying to find out the default Username and password for this but
> was
> > unable to. When I was exploring docs in mailman.client and some config
> > files in mailman, I found that the default username and password for
> admin
> > is restadmin and restpass. Tried that and was out of luck there too.
> Could
> > you help me with the default username and password details?
>
> While setting up Postorius(the web UI) when you do 'python manage.py
> syncdb' for the first time, it asks you to create admin. You can log in
> using those credentials. 'restadmin' and 'restpass' are the credentials
> for the mailman rest server.
>
> > Also, there is a using.txt doc in mailman.client which says we can make
> the
> > REST requests by connecting to http://localhost:9001/3.0 using username
> and
> > password. Should the URL be http://localhost:9000/3.0 for this example
> or
> > would it be any different?
>
> AFAIK it is 'http://localhost:8001/3.0'. (Try it once. If I am wrong
> please someone correct me)
>
> >
> > Thanks
> >
> >
> > On Mon, Mar 3, 2014 at 1:38 PM, Rajeev S  wrote:
> >
> >> Hi Bhargav,
> >>
> >> Just do *mailman start*, without the bin.
> >>
> >> I have edited the wiki.
> >>
> >>
> >> *Regards, Rajeev S*
> >> *Government Engineering College,Thrissur*
> >> *http://rajeevs.tk *
> >>
> >>
> >> On Mon, Mar 3, 2014 at 10:37 PM, Bhargav Golla  >wrote:
> >>
> >>> Thanks Barry and Terri for your feedback.
> >>> I was trying to install Postorius locally and analyze what all would be
> >>> required in a mobile app for Admin. Doing the same, I have hit a
> >>> roadblock.
> >>> I am using the wiki provided here[1]. I tried to install mailman using
> >>> "set
> >>> up sources" part of the wiki. Though python setup.py install executes
> >>> without any errors, I am unable to see the folder bin/ in the same
> >>> directory. So, even though I proceed with further setup, I am getting a
> >>> "Mailman REST API not available. Please start mailman core" on my
> >>> localhost:8000 webpage. Could anyone help me here?
> >>>
> >>> [1]
> >>>
> >>>
> http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running
> >>>
> >>> Thanks
> >>>
> >>>
> >>> On Sun, Mar 2, 2014 at 1:18 AM, Terri Oda  wrote:
> >>>
> 
>  On 2014-02-28, 7:36 AM, Bhargav Golla wrote:
> 
> > I have a few questions regarding this idea.
> > 1. I intend to develop it on Cordova since it will help in porting
> the
> >>> app
> > easily to multiple platforms. Were there any ideas in this directions
> > regarding going native or hybrid?
> >
> 
>  Personally, I'd prefer if we went hybrid and had an html5 webapp that
>  could be used straight over the web for mobile users who don't want to
>  install an app, with Cordova used to build the individual platform
> >>> apps.  I
>  may not be the mentor on this one, though, so I'm happy to defer to
> >>> whoever
>  the final mentor is on this front.
> 
>  Incidentally, I've been using Intel's XDK for building Cordova apps
> >>> lately
>  and highly recommend it for quick testing on various platforms and
> >>> screen
>  sizes.  I've found it a very useful tool, and not just because I work
> >>> for
>  Intel now!
> 
>   2. Can I assume that all mailing lists built by Mailman support the
> >>> REST
> > interface? Also, I have tried to see if I can get JSON responses and
> I
> >>> am
> > unable to by adding a HTTP Accept Header to take "application/json".
> >>> Am I
> > doing anything wrong or is JSON not implemented?
> >
> 
>  I don't know the answer to this off the top of my head: Barry?
> 
> 
>   3. As a starter, could I ignore internationalization for GSoC, but
> > implement interface in such a way as to be able to internationalize
> it
> > easily?
> >
> 
>  We don't expect you to actually translate anything, don't worry. :)
> But
>  you should definitely build as much as possible so that
>  internationalization will be easy: make sure there's a quick way to
> get
> >>> a
>  list of strings that need translation, at least.  Some of the strings
> >>> may
>  be already translated in other components of Mailman, so you may be
> >>> able to
>  get some translations to use to test if you have time at the end of
> the
>  summer for internationalization.
> 
>   Terri
> 
> 
> >>>
> >>>
> >>> --
> >>> Bhargav Goll

Re: [Mailman-Developers] [GSoC 2014] Cordova/Android App for GNU Mailman Admin Interface

[Bhargav Golla]

Thanks for that change Rajeev. I was able to get the Web UI up and running.
I was trying to find out the default Username and password for this but was
unable to. When I was exploring docs in mailman.client and some config
files in mailman, I found that the default username and password for admin
is restadmin and restpass. Tried that and was out of luck there too. Could
you help me with the default username and password details?

Also, there is a using.txt doc in mailman.client which says we can make the
REST requests by connecting to http://localhost:9001/3.0 using username and
password. Should the URL be http://localhost:9000/3.0 for this example or
would it be any different?


Thanks


On Mon, Mar 3, 2014 at 1:38 PM, Rajeev S  wrote:

> Hi Bhargav,
>
> Just do *mailman start*, without the bin.
>
> I have edited the wiki.
>
>
> *Regards, Rajeev S*
> *Government Engineering College,Thrissur*
> *http://rajeevs.tk *
>
>
> On Mon, Mar 3, 2014 at 10:37 PM, Bhargav Golla wrote:
>
>> Thanks Barry and Terri for your feedback.
>> I was trying to install Postorius locally and analyze what all would be
>> required in a mobile app for Admin. Doing the same, I have hit a
>> roadblock.
>> I am using the wiki provided here[1]. I tried to install mailman using
>> "set
>> up sources" part of the wiki. Though python setup.py install executes
>> without any errors, I am unable to see the folder bin/ in the same
>> directory. So, even though I proceed with further setup, I am getting a
>> "Mailman REST API not available. Please start mailman core" on my
>> localhost:8000 webpage. Could anyone help me here?
>>
>> [1]
>>
>> http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running
>>
>> Thanks
>>
>>
>> On Sun, Mar 2, 2014 at 1:18 AM, Terri Oda  wrote:
>>
>> >
>> > On 2014-02-28, 7:36 AM, Bhargav Golla wrote:
>> >
>> >> I have a few questions regarding this idea.
>> >> 1. I intend to develop it on Cordova since it will help in porting the
>> app
>> >> easily to multiple platforms. Were there any ideas in this directions
>> >> regarding going native or hybrid?
>> >>
>> >
>> > Personally, I'd prefer if we went hybrid and had an html5 webapp that
>> > could be used straight over the web for mobile users who don't want to
>> > install an app, with Cordova used to build the individual platform
>> apps.  I
>> > may not be the mentor on this one, though, so I'm happy to defer to
>> whoever
>> > the final mentor is on this front.
>> >
>> > Incidentally, I've been using Intel's XDK for building Cordova apps
>> lately
>> > and highly recommend it for quick testing on various platforms and
>> screen
>> > sizes.  I've found it a very useful tool, and not just because I work
>> for
>> > Intel now!
>> >
>> >  2. Can I assume that all mailing lists built by Mailman support the
>> REST
>> >> interface? Also, I have tried to see if I can get JSON responses and I
>> am
>> >> unable to by adding a HTTP Accept Header to take "application/json".
>> Am I
>> >> doing anything wrong or is JSON not implemented?
>> >>
>> >
>> > I don't know the answer to this off the top of my head: Barry?
>> >
>> >
>> >  3. As a starter, could I ignore internationalization for GSoC, but
>> >> implement interface in such a way as to be able to internationalize it
>> >> easily?
>> >>
>> >
>> > We don't expect you to actually translate anything, don't worry. :) But
>> > you should definitely build as much as possible so that
>> > internationalization will be easy: make sure there's a quick way to get
>> a
>> > list of strings that need translation, at least.  Some of the strings
>> may
>> > be already translated in other components of Mailman, so you may be
>> able to
>> > get some translations to use to test if you have time at the end of the
>> > summer for internationalization.
>> >
>> >  Terri
>> >
>> >
>>
>>
>> --
>> Bhargav Golla
>> M.S Computer Science
>> Github  |
>> LinkedIN
>>  | Website 
>> ___
>> 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/rajeevs1992%40gmail.com
>>
>> Security Policy: http://wiki.list.org/x/QIA9
>>
>
>


-- 
Bhargav Golla
M.S Computer Science
Github  |
LinkedIN
 | Website 
___
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

Re: [Mailman-Developers] [GSoC 2014] Command line Client

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 03/04/2014 10:49 AM, Stephen J. Turnbull wrote:
> Rajeev S writes:
>> Also, I did not quite get the "*coming up with a **great layout
>> *" part. Do you mean to build a custom shell for mailman? If yes,
>> what extra functionality should it provide than the standard
>> command line tools?
> 
> I think that probably is what he means, but I personally don't
> think that's appropriate.  If people want a "CLI with layout"
> (which I agree is plausible), what's wrong with Postorius via Lynx?
> (Florian?)

No, that's not what I meant (using the term "layout" was obviously
confusing - sorry for that!). I think we're talking about two
possible, but very different concepts of a client here:

One is the one-off command (with options) that outputs a result,
either on stdout or saved to a file. This could make for an
interesting project, but I think then it would really make more sense
(like Steve said) to extend the existing `mailman` command instead of
writing a new one.

The other (and the one I had in mind) is a tool you invoke with a
commando which then offers a interface a little different from that of
your standard terminal shell (bash or else). Just like you invoke the
mysql/sqlite3 client (with a db name or file as option). What I meant
by "layout" is really the question what happens after one starts the
tool by typing something like `$ mmclient --list=f...@bar.id`" or `$
mmclient --domain=python.org`", not the actual visual representation.


Does that make more sense?

Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTFvdqAAoJEEceGbPdavl76KIIAKLIsZEux/TPCSNV9sEQGJt1
s5gkIT298wZPPQfG+b2kllMO9o6uObQ0K10Ynk4yzLi1YngTyR1kC52Ty6uZ1pws
YvD87o7DCeoZWDMss77+zvJkpkG+zFn4Ts3taeWW/9A1N9fJP22izgtm9aki+RLn
8nWn4jfTmnE3TvU8ptr/5uK0LPApfjMZz0mGCc6jgExdsJhVw11LU0Wzoxtw9424
1ygW2zWPcvdHTqykluvf62u24oTna641vNxE60LB9e4SF6LhS0Pi+F/w+m8zjNAT
q3xY76yNlhZVI/N2cR4jinuUbagX61DSu7mgC4Kk08oyN6TgkS9kknlYrGupQ3c=
=ufWT
-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 2014] Command line Client

[Stephen J. Turnbull]

Rajeev S writes:

 > The deliverables of the project would be, at the least,
 > 
 >- Command line tools to perform tasks in the mailman client docs

I think there should be one tool with multiple commands.  These can be
implemented by separate commands in a directory off the normal PATH if
you like, or with annoyingly long names (a la git's scripting interface).

 >- Any Extra useful functionalities that can be identified, such as
 >  export, backup
 >- Other Useful tools like backup and restore.
 >- Man Page entries for the new commands

These look good to me.  Also, a help command to display the man pages
from the new tool.

 > Also, I did not quite get the "*coming up with a **great layout *"
 > part. Do you mean to build a custom shell for mailman? If yes, what
 > extra functionality should it provide than the standard command
 > line tools?

I think that probably is what he means, but I personally don't think
that's appropriate.  If people want a "CLI with layout" (which I agree
is plausible), what's wrong with Postorius via Lynx?  (Florian?)

I suggest you should concentrate on the syntax of the command line,
possibly building on the existing mailmanctl tool.  (But let's check
with Barry on that before you put in much effort!)

Steve

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] [GSoC 2014] Command line Client

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 03/03/2014 03:11 PM, Rajeev S wrote:
> Hi Florian,
> 
> I had discussed about the full anonymization project with Stephen
> and I had found that I had quite misunderstood the use case of that
> project.
> 
> So I have decided to go forward with applying for the mailman
> command line client project.
> 
> The deliverables of the project would be, at the least,
> 
> * Command line tools to perform tasks in the mailman client docs *
> Any Extra useful functionalities that can be identified, such as 
> export, backup * Other Useful tools like backup and restore. * Man
> Page entries for the new commands

Sounds good! But make sure to mark steps 2 to 4 as optional.

> Also, I did not quite get the "/coming up with a //great layout /"
> part. Do you mean to build a custom shell for mailman? If yes, what
> extra functionality should it provide than the standard command
> line tools?

I don't know if I would call it a shell, but something like that, yes.
I talked about it with Patrick Koetter a while ago (who is also a
possible mentor for this project), and we had something *a little*
similar to the mysql/sqlite3 client in mind. Similar meaning: You
start the client (possibly providing some context option, like the
database used) and then perform operations on a given context/object
(in our case: lists, users, addresses, preferences) using predefined
commands.

Ideally, the application makes all operations pretty easy, by using
auto-completion, a good help function etc.

This is just a rough idea though, maybe you can come up with a better
one... ;-)


Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTFYUaAAoJEEceGbPdavl7jEEIAKJa5XMXRXp9HxJsQgyurZi+
YHqbJlGGNPG0eXOkHS2gdkNXp36cwSLgtKZM/1Xj9pvgnj5+MKlMg8528iGUNqDU
WUdQlIcWLsVovy0m3ANI77k8I5TBFCl8vX4X0NuR05H6RmqwjtlWs9ZnFXlPnrtd
atMCXm7JkEwubTcI+m6I5utLDNzmNLzPwRekFX9umcMR1DXmIDm5v8cE16+DWLmj
ZO5Fj83OH8pA6sUvucfR6YddbDlgRsVfC6K88j2yHFl+0GUeYwIoKPHFXu49/zj+
ThcnNkhx4nMiJlKh41urxA27ysvCavbhgjGvehwWp6eDHBQT29lJtBPEWKRRryM=
=AY/u
-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 2014] Cordova/Android App for GNU Mailman Admin Interface

[Rajeev S]

Hi Bhargav,

Just do *mailman start*, without the bin.

I have edited the wiki.


*Regards,Rajeev S*
*Government Engineering College,Thrissur*
*http://rajeevs.tk *


On Mon, Mar 3, 2014 at 10:37 PM, Bhargav Golla  wrote:

> Thanks Barry and Terri for your feedback.
> I was trying to install Postorius locally and analyze what all would be
> required in a mobile app for Admin. Doing the same, I have hit a roadblock.
> I am using the wiki provided here[1]. I tried to install mailman using "set
> up sources" part of the wiki. Though python setup.py install executes
> without any errors, I am unable to see the folder bin/ in the same
> directory. So, even though I proceed with further setup, I am getting a
> "Mailman REST API not available. Please start mailman core" on my
> localhost:8000 webpage. Could anyone help me here?
>
> [1]
>
> http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running
>
> Thanks
>
>
> On Sun, Mar 2, 2014 at 1:18 AM, Terri Oda  wrote:
>
> >
> > On 2014-02-28, 7:36 AM, Bhargav Golla wrote:
> >
> >> I have a few questions regarding this idea.
> >> 1. I intend to develop it on Cordova since it will help in porting the
> app
> >> easily to multiple platforms. Were there any ideas in this directions
> >> regarding going native or hybrid?
> >>
> >
> > Personally, I'd prefer if we went hybrid and had an html5 webapp that
> > could be used straight over the web for mobile users who don't want to
> > install an app, with Cordova used to build the individual platform apps.
>  I
> > may not be the mentor on this one, though, so I'm happy to defer to
> whoever
> > the final mentor is on this front.
> >
> > Incidentally, I've been using Intel's XDK for building Cordova apps
> lately
> > and highly recommend it for quick testing on various platforms and screen
> > sizes.  I've found it a very useful tool, and not just because I work for
> > Intel now!
> >
> >  2. Can I assume that all mailing lists built by Mailman support the REST
> >> interface? Also, I have tried to see if I can get JSON responses and I
> am
> >> unable to by adding a HTTP Accept Header to take "application/json". Am
> I
> >> doing anything wrong or is JSON not implemented?
> >>
> >
> > I don't know the answer to this off the top of my head: Barry?
> >
> >
> >  3. As a starter, could I ignore internationalization for GSoC, but
> >> implement interface in such a way as to be able to internationalize it
> >> easily?
> >>
> >
> > We don't expect you to actually translate anything, don't worry. :) But
> > you should definitely build as much as possible so that
> > internationalization will be easy: make sure there's a quick way to get a
> > list of strings that need translation, at least.  Some of the strings may
> > be already translated in other components of Mailman, so you may be able
> to
> > get some translations to use to test if you have time at the end of the
> > summer for internationalization.
> >
> >  Terri
> >
> >
>
>
> --
> Bhargav Golla
> M.S Computer Science
> Github  |
> LinkedIN
>  | Website 
> ___
> 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/rajeevs1992%40gmail.com
>
> 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 2014] Cordova/Android App for GNU Mailman Admin Interface

[Bhargav Golla]

Thanks Barry and Terri for your feedback.
I was trying to install Postorius locally and analyze what all would be
required in a mobile app for Admin. Doing the same, I have hit a roadblock.
I am using the wiki provided here[1]. I tried to install mailman using "set
up sources" part of the wiki. Though python setup.py install executes
without any errors, I am unable to see the folder bin/ in the same
directory. So, even though I proceed with further setup, I am getting a
"Mailman REST API not available. Please start mailman core" on my
localhost:8000 webpage. Could anyone help me here?

[1]
http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running

Thanks


On Sun, Mar 2, 2014 at 1:18 AM, Terri Oda  wrote:

>
> On 2014-02-28, 7:36 AM, Bhargav Golla wrote:
>
>> I have a few questions regarding this idea.
>> 1. I intend to develop it on Cordova since it will help in porting the app
>> easily to multiple platforms. Were there any ideas in this directions
>> regarding going native or hybrid?
>>
>
> Personally, I'd prefer if we went hybrid and had an html5 webapp that
> could be used straight over the web for mobile users who don't want to
> install an app, with Cordova used to build the individual platform apps.  I
> may not be the mentor on this one, though, so I'm happy to defer to whoever
> the final mentor is on this front.
>
> Incidentally, I've been using Intel's XDK for building Cordova apps lately
> and highly recommend it for quick testing on various platforms and screen
> sizes.  I've found it a very useful tool, and not just because I work for
> Intel now!
>
>  2. Can I assume that all mailing lists built by Mailman support the REST
>> interface? Also, I have tried to see if I can get JSON responses and I am
>> unable to by adding a HTTP Accept Header to take "application/json". Am I
>> doing anything wrong or is JSON not implemented?
>>
>
> I don't know the answer to this off the top of my head: Barry?
>
>
>  3. As a starter, could I ignore internationalization for GSoC, but
>> implement interface in such a way as to be able to internationalize it
>> easily?
>>
>
> We don't expect you to actually translate anything, don't worry. :) But
> you should definitely build as much as possible so that
> internationalization will be easy: make sure there's a quick way to get a
> list of strings that need translation, at least.  Some of the strings may
> be already translated in other components of Mailman, so you may be able to
> get some translations to use to test if you have time at the end of the
> summer for internationalization.
>
>  Terri
>
>


-- 
Bhargav Golla
M.S Computer Science
Github  |
LinkedIN
 | Website 
___
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 2014] Command line Client

[Rajeev S]

Hi Florian,

I had discussed about the full anonymization project with Stephen and I had
found that I had quite misunderstood the use case of that project.

So I have decided to go forward with applying for the mailman command line
client project.

The deliverables of the project would be, at the least,

   - Command line tools to perform tasks in the mailman client docs
   - Any Extra useful functionalities that can be identified, such as
   export, backup
   - Other Useful tools like backup and restore.
   - Man Page entries for the new commands

Also, I did not quite get the "*coming up with a **great layout *" part. Do
you mean to build a custom shell for mailman? If yes, what extra
functionality should it provide than the standard command line tools?




*Regards,Rajeev S*
*Government Engineering College,Thrissur*
*http://rajeevs.tk *


On Mon, Mar 3, 2014 at 4:35 PM, Florian Fuchs  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 02/25/2014 03:17 AM, Rajeev S wrote:
> > Hi,
> >
> > I am Rajeev S , A CSE Undergrad from India. I would like to work
> > with the Command Line client project listed in the GSoC ideas
> > page.
> >
> > I have been working on the Postorious package lately and have
> > managed to make some tweaks in it, like the add users by file
> > upload and an improved email validator.
> >
> > As a part of the project, I would like to build,at the minimum,
> > the functionalities listed at the
> > mailmain.client/src/mailmanclient/docs/using.txt
> >
> > Can the mentor of this project elaborate upon the requirements of
> > the project?
>
> I think the functionalities listed in the mailman.client docs are a
> good orientation point, because those represent almost everything the
> core REST API currently exposes. It also makes sense to use
> mailman.client instead of writing new code that handles the HTTP stuff
> and object binding.
>
> I guess the most difficult part of this project is coming up with a
> great "layout", possibly borrowing stuff from other well-known command
> line clients (mutt, mysql/sqlite3, the ipython shell, lynx etc.).
>
> Of course there are bonus points for all kinds of stuff, like
> exporting data to files/stdout, making the tool extensible etc. But I
> really think designing the right interface and implementing most or
> all of what mailman.client can do will take a good amount time.
>
> > Also I have thought of an approach for the full anonymization
> > project.Is it possible that I can work on both of these as a single
> > project?(I have a feeling that the CLI is a small project, am I
> > right?)
>
> You should definitely pick one project and come up with good ideas for
> that.
>
>
> Cheers
> Florian
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTFGH3AAoJEEceGbPdavl7ZYIH+gJVB27H6G5LXd+0+vytx1gC
> sZiQCy/vYEr8jtCbe8BdoLvk+jyBNRaUzaxDuL/9Pb3g8HCwuJQ+HzEQm25ewZ0X
> vlvWZ7dW07sEYr5q7cRatkqO/GQc2n6B6IgGd3oTkihQUO4iZQTu/ddytMghvCP0
> MYtuQyuecjZm8JBlCn6AU0KQWxNx/Kt7CsuPfk6FcCOmA15ZEnZ4kxZFY0khVY5a
> NLetoDDY7fQAf5fFlea8SfIN8PFB1i4qv5DdjDaX17Yg/S+X5S0nZx18uvqX7Up8
> RlGLTCSA8s3qsYItaI9NWpXRdo/Z1p8MN/hQOOot85e3SVernKn9oq1TSI/7lww=
> =pozr
> -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/rajeevs1992%40gmail.com
>
> 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 2014] Command line Client

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 02/25/2014 03:17 AM, Rajeev S wrote:
> Hi,
> 
> I am Rajeev S , A CSE Undergrad from India. I would like to work
> with the Command Line client project listed in the GSoC ideas
> page.
> 
> I have been working on the Postorious package lately and have
> managed to make some tweaks in it, like the add users by file
> upload and an improved email validator.
> 
> As a part of the project, I would like to build,at the minimum,
> the functionalities listed at the 
> mailmain.client/src/mailmanclient/docs/using.txt
> 
> Can the mentor of this project elaborate upon the requirements of
> the project?

I think the functionalities listed in the mailman.client docs are a
good orientation point, because those represent almost everything the
core REST API currently exposes. It also makes sense to use
mailman.client instead of writing new code that handles the HTTP stuff
and object binding.

I guess the most difficult part of this project is coming up with a
great "layout", possibly borrowing stuff from other well-known command
line clients (mutt, mysql/sqlite3, the ipython shell, lynx etc.).

Of course there are bonus points for all kinds of stuff, like
exporting data to files/stdout, making the tool extensible etc. But I
really think designing the right interface and implementing most or
all of what mailman.client can do will take a good amount time.

> Also I have thought of an approach for the full anonymization
> project.Is it possible that I can work on both of these as a single
> project?(I have a feeling that the CLI is a small project, am I
> right?)

You should definitely pick one project and come up with good ideas for
that.


Cheers
Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTFGH3AAoJEEceGbPdavl7ZYIH+gJVB27H6G5LXd+0+vytx1gC
sZiQCy/vYEr8jtCbe8BdoLvk+jyBNRaUzaxDuL/9Pb3g8HCwuJQ+HzEQm25ewZ0X
vlvWZ7dW07sEYr5q7cRatkqO/GQc2n6B6IgGd3oTkihQUO4iZQTu/ddytMghvCP0
MYtuQyuecjZm8JBlCn6AU0KQWxNx/Kt7CsuPfk6FcCOmA15ZEnZ4kxZFY0khVY5a
NLetoDDY7fQAf5fFlea8SfIN8PFB1i4qv5DdjDaX17Yg/S+X5S0nZx18uvqX7Up8
RlGLTCSA8s3qsYItaI9NWpXRdo/Z1p8MN/hQOOot85e3SVernKn9oq1TSI/7lww=
=pozr
-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 2014] Cordova/Android App for GNU Mailman Admin Interface

[Barry Warsaw]

On Feb 28, 2014, at 10:36 AM, Bhargav Golla wrote:

>2. Can I assume that all mailing lists built by Mailman support the REST
>interface? Also, I have tried to see if I can get JSON responses and I am
>unable to by adding a HTTP Accept Header to take "application/json". Am I
>doing anything wrong or is JSON not implemented?

I'm not sure this question makes sense. ;)  Mailman 3 does expose a REST API,
but in the core, it's a protected (e.g. localhost only by default) admin
interface.  It's not per-mailing list, although there are mailing list
specific resources.  JSON is the only response format currently supported.
See http://tinyurl.com/kzmcwf5 for details.

Cheers,
-Barry


signature.asc
Description: 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 2014] Cordova/Android App for GNU Mailman Admin Interface

[Terri Oda]

On 2014-02-28, 7:36 AM, Bhargav Golla wrote:

I have a few questions regarding this idea.
1. I intend to develop it on Cordova since it will help in porting the app
easily to multiple platforms. Were there any ideas in this directions
regarding going native or hybrid?


Personally, I'd prefer if we went hybrid and had an html5 webapp that 
could be used straight over the web for mobile users who don't want to 
install an app, with Cordova used to build the individual platform 
apps.  I may not be the mentor on this one, though, so I'm happy to 
defer to whoever the final mentor is on this front.


Incidentally, I've been using Intel's XDK for building Cordova apps 
lately and highly recommend it for quick testing on various platforms 
and screen sizes.  I've found it a very useful tool, and not just 
because I work for Intel now!

2. Can I assume that all mailing lists built by Mailman support the REST
interface? Also, I have tried to see if I can get JSON responses and I am
unable to by adding a HTTP Accept Header to take "application/json". Am I
doing anything wrong or is JSON not implemented?


I don't know the answer to this off the top of my head: Barry?


3. As a starter, could I ignore internationalization for GSoC, but
implement interface in such a way as to be able to internationalize it
easily?


We don't expect you to actually translate anything, don't worry. :) But 
you should definitely build as much as possible so that 
internationalization will be easy: make sure there's a quick way to get 
a list of strings that need translation, at least.  Some of the strings 
may be already translated in other components of Mailman, so you may be 
able to get some translations to use to test if you have time at the end 
of the summer for internationalization.


 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 2014]Approach towards the Full anonymization project

[Rajeev S]

Hi,

I have written and deployed an App that generates and decodes anonymous
emails,as I had mentioned.

Find the application here

http://anongen.herokuapp.com/

Source here

https://github.com/rajeevs1992/anongen



*Regards,Rajeev S*
*Government Engineering College,Thrissur*
*http://rajeevs.tk *


On Tue, Feb 25, 2014 at 8:18 AM, Rajeev S  wrote:

> Hi,
>
> As mentioned, here is my approach towards the full anonymization project.
>
>
>- Introduce a new model EmailMapper with attributes
>   - ForeginKey to Address / User
>   - seed, A 40 bit hash,unique
>   - nuses, number of times this hash is used,max 5 or 10
>- The approach is to encrypt the seed nuses times, with encryption
>algorithms like AES, each time the email ID is displayed.
>- The email ID is displayed as 
>- The email is decrypted nuses times to find the parent seed and
>thereby point to the exact email address.
>- A new seed should be generated for the user after a fixed number of
>attempts,say 5 or 10,as the repeated encryption routines can slow down the
>system.
>
> The outcomes
>
>
>- Everytime the user sends a message,his from address changes.
>- At the same time, each of the from addresses point to the same user.
>- The sender can use any stored address he has,like in the mail
>contacts,repeatedly, to contact with a user,as it has nuses attached with
>it.
>
> If this approach seems viable or if I am missing something
> important,please let me know.If this is fine, I would build an app that can
> demonstrate this functionality, before building my application.
>
>
> *Regards,Rajeev S*
> *Government Engineering College,Thrissur*
> *http://rajeevs.tk *
>
___
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 2014

[Terri Oda]

On 2/24/2014, 3:18 PM, Stephen J. Turnbull wrote:

@Florian, Terri: is there going to be a "why some orgs get in and
some don't" session again this year?  (Sorry, I've had no time at all
to follow the process this year. :-( )
Yes, it's on Friday 28 February at 16:00 UTC.  As usual, it's an IRC 
meeting on #gsoc on freenode.  Worth attending, although I expect the 
answer will be similar to last year: more good applicants than there are 
slots.  Maybe next 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

Re: [Mailman-Developers] GSoC 2014

[Stephen J. Turnbull]

Barry Warsaw writes:
 > On Feb 24, 2014, at 09:54 PM, Florian Fuchs wrote:
 > 
 > >The good news: The Python Software Foundation was more successful
 > >(congrats to Terri!), so we'll be able to participate under their
 > >umbrella again. \o/
 > 
 > Much thanks to Terri and all involved.  Looking forward to some great GSoC
 > students again this year.

Yes, many thanks to Florian and Terri!

@Florian, Terri: is there going to be a "why some orgs get in and
some don't" session again this year?  (Sorry, I've had no time at all
to follow the process this year. :-( )

Steve


___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC 2014

[Barry Warsaw]

On Feb 24, 2014, at 09:54 PM, Florian Fuchs wrote:

>The good news: The Python Software Foundation was more successful
>(congrats to Terri!), so we'll be able to participate under their
>umbrella again. \o/

Much thanks to Terri and all involved.  Looking forward to some great GSoC
students again this year.

-Barry


signature.asc
Description: 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 2014 ideas list

[Patrick Ben Koetter]

* Florian Fuchs :
> 
> 
> On 02/07/2014 10:22 PM, Patrick Ben Koetter wrote:
> > Dunno, if this is there yet, but a command line client for admins
> > that allows to create lists, configure them via list templates,
> > backup configs etc. would be a nice thing to have.
> 
> +1!
> 
> Maybe starting with a "local" version first (meaning: running on the
> same host as Mailman, with unrestricted REST API access -- I guess it
> might be enough work for one GSoC project to build a nice CL interface
> for the most important functionality). But with an option to add
> remote access with more advanced authentication/authorization at a
> later time.

ACK

> 
> > Personally I would also like to see SNMP support to monitor mailman
> > in larger installations.
> 
> I'm adding it to the ideas page. Would you like to provide a short
> description of what you have in mind, so I can add that too?

Unfortunately I am short on time. Here's a brief description:

The idea is to add SNMP capabilities to MM. The SNMP interface should follow
the FCAPS model . What exactly that means
for an MLM and MM in specific is something I'd expect the project to layout
and implement (in parts).

I would, for example, like to know how many mailing lists there are, how many
people subscribed to each mailinglist, how many non-subscribed senders send to
the mailinglist etc. pp.

I can come up with a list of items to examine and count if this becomes a
project.

p@rick

-- 
[*] sys4 AG
 
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
 
___
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 2014 ideas list

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 02/07/2014 10:22 PM, Patrick Ben Koetter wrote:
> Dunno, if this is there yet, but a command line client for admins
> that allows to create lists, configure them via list templates,
> backup configs etc. would be a nice thing to have.

+1!

Maybe starting with a "local" version first (meaning: running on the
same host as Mailman, with unrestricted REST API access -- I guess it
might be enough work for one GSoC project to build a nice CL interface
for the most important functionality). But with an option to add
remote access with more advanced authentication/authorization at a
later time.

> Personally I would also like to see SNMP support to monitor mailman
> in larger installations.

I'm adding it to the ideas page. Would you like to provide a short
description of what you have in mind, so I can add that too?

Cheers
Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS9+9jAAoJEEceGbPdavl7ACQIAKToWKOZpVu73XyGRgLKTD1b
892v/2xfli2HUUjU/Pb4JfGAZGen0GcPNtsjahy8THcRHy0RIJ+3RrrTrfCErZ9Y
THkyu0uILaZLqOrr9TMvyUkmF0DQXZF0IdgzeYel/WZVL/EC5NHxFldHv4LnnNX8
25cMhxlOW8VJzrUoeP3qBhrwhXe4kMB9PUa8onxgWlvT47P1zNcCLeyb3LBPcphO
0P3iZOgT+nlVn1ZFFrqOT7d3+r2MFYRQz7ltMu3RSwwkXKC0Cq2nfIbtYYtPue2h
az6JPfStGZChq/sQCa5Nqz4JwNc1XW+fo7Qx6YKEuHZxXP4HyGG/c5yI0MuLFwU=
=83sc
-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 2014 ideas list

[Patrick Ben Koetter]

* Florian Fuchs :
> 
> 
> On 02/06/2014 08:21 PM, Barry Warsaw wrote:
> >> 2. A responsive ui for Postorius
> > 
> > Very much +1.  Another thought would be to support an app that you
> > could install on Android or iOS (or Ubuntu Touch? :) to more
> > directly control a Postorius server.
> 
> Also a great idea! I think using Apache Cordova for that would be an
> interesting option. It's a native app container around a HTML/JS
> engine, so one can build native apps with HTML/CSS/JS. Supports
> Android, iOS and, yes, Ubuntu, plus a few others. I heard a lot of
> good things about it from a friend who has used it recently.

Dunno, if this is there yet, but a command line client for admins that allows
to create lists, configure them via list templates, backup configs etc. would
be a nice thing to have.

Personally I would also like to see SNMP support to monitor mailman in larger
installations.

p@rick

-- 
[*] sys4 AG
 
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
 
___
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 2014 ideas list

[Stephen J. Turnbull]

Máirín Duffy writes:

 > By UX design I don't mean simply surface aesthetics, but designing the 
 > interactions and workflows for new features and cleaning up what's 
 > there, scoping out new features (e.g., right now Karen and I are working 
 > out whether or not users should be able to follow categories in 
 > Hyperkitty like they can follow tags, walking through what a user might 
 > want to do based on how mailing lists may be set up, and the mechanisms 
 > we could add to allow the feature.)

The implementation of "workflows" such as "following categories like
tags" and "mechanisms" sounds good to me.  "New features" are
generally what Google is interested in sponsoring.

 > So she is doing some CSS yeah, but also javascript and she's modifying 
 > stuff in django too for the Bootstrap upgrade.

AIUI, the javascript and Django work sounds like it would be enough to
qualify for the "Code" in "Google Summer of Code".

 > Testing how well it works across various mobile formats.

Testing in the sense of running the program on different devices
doesn't qualify, and ISTR discussion on the Google lists to the effect
that even writing regression tests doesn't qualify by itself if they
basically amount to scripts to mimic a human thumbing on an iPhone. :-)
There's also a prejudice against declarative languages like HTML and
CSS.[1]

Google recognizes the value of CSS and regression tests, of course.
There has been discussion of extending GSoC (eg, Google Code-In for
high school students allows tasks defined by those activities, and
documentation as well), or having a separate intern program for them.
But GSoC is designed and funded for the purpose of supporting coding.

So from the point of view of GSoC proposals, the students should be
focusing on the Javascript and Python to be written to implement the
features in Django.

Overall it sounds to me like the project your student would propose is
very similar in content to what Shanu did, and the main thing is to
emphasize the Django/Python and Javascript coding, and make sure it
looks like a summer's worth of work in the proposal.

I would say at this point it's certainly worth writing up a
preliminary design proposal to see if it's worth putting in the work
to write up schedules and precise descriptions of deliverables.

Also, note that I can't speak *for* the Google administrators.

Footnotes: 
[1]  I mention that because I find these distinctions somewhat
specious, myself, but the language bias clearly exists among the
Google administrators.

___
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 2014 ideas list

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 02/06/2014 08:21 PM, Barry Warsaw wrote:
>> 2. A responsive ui for Postorius
> 
> Very much +1.  Another thought would be to support an app that you
> could install on Android or iOS (or Ubuntu Touch? :) to more
> directly control a Postorius server.

Also a great idea! I think using Apache Cordova for that would be an
interesting option. It's a native app container around a HTML/JS
engine, so one can build native apps with HTML/CSS/JS. Supports
Android, iOS and, yes, Ubuntu, plus a few others. I heard a lot of
good things about it from a friend who has used it recently.

We would need to get the public API working though...


Cheers
Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS9TwbAAoJEEceGbPdavl7hrUH/jOPOcLl5f0i/PtC+dmxA1E3
lHyYN8pEF5gSYZ4LQfTYIdjBy5yFxVT3kmhNSm8q9TcRB0yYXYsaDBam2GBcrJyU
5utrP5fqtKXDWRe7yZ2k4316tdG8x0ljTwRDeth1IFiEAIqEs1S9ph7xdReA/mry
PVTo1VRjoSXGOryilxDR4RQ151xILooN+R0zw8KoAEcBhSU9oi7ZF8LBop7E1+1a
87/scF7qNTm+4H+0G2/2f5JO+/Cpi2iQvChN2Y6w0OHzhuF1270InN1yz308Qcmp
7TJpkvtQ4DGYV+7C0LbOT5IKKvlOtPvE7nmvPCeBeBdqCUAWEuROL6E2HYb3oSM=
=+I6D
-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 2014 ideas list

[Máirín Duffy]

On 02/06/2014 09:17 PM, Stephen J. Turnbull wrote:

Hi, Máirín!  Good to see you here!


Thanks :) Long time lurker :)


I'm not sure what you mean by "design".  Something like graphic design
via CSS alone doesn't fly.  It has to come with an implementation that
is aimed to be of high enough quality to be integrated.


By UX design I don't mean simply surface aesthetics, but designing the 
interactions and workflows for new features and cleaning up what's 
there, scoping out new features (e.g., right now Karen and I are working 
out whether or not users should be able to follow categories in 
Hyperkitty like they can follow tags, walking through what a user might 
want to do based on how mailing lists may be set up, and the mechanisms 
we could add to allow the feature.)


So I was actually envisioning an internship similar to what my current 
Hyperkitty OPW program intern is doing some UX design work (as described 
above) but also creating static HTML pages of the new pages, modifying 
existing screens to mobile friendly / responsive by upgrading it to the 
latest Bootstrap and making it more Bootstrap-compliant (it was a little 
messy before she fixed it up.)


So she is doing some CSS yeah, but also javascript and she's modifying 
stuff in django too for the Bootstrap upgrade. Testing how well it works 
across various mobile formats. In addition to creating UX mockups, etc.



If what you mean is the kind of stuff that is involved in Postorius
and Shanu Salunke's "Mailman Interface" (a GSoC project for Systers
last year), yes, that passes muster.


While I've used Postorius and am familiar with it, I'm not familiar with 
Shanu's internship work. How do you think what I'm proposing above compares?


~m
___
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 2014 ideas list

[Stephen J. Turnbull]

Hi, Máirín!  Good to see you here!

Máirín Duffy writes:

 > Do you know if Summer of Code students can do interaction design / UX 
 > stuff? Because I'd be willing to mentor for that.

I'm not sure what you mean by "design".  Something like graphic design
via CSS alone doesn't fly.  It has to come with an implementation that
is aimed to be of high enough quality to be integrated.

If the project misses implementation quality by end of summer,
nobody's going to complain if we pass the student based on reasonable
effort and significant progress.  But what Google is paying for is the
time and effort spent on designing and writing code to implement
processes, not the UX design.

Eg, doing CSS work that makes a screen pretty and easy to hide
uninteresting information and changes simple text fields to more
structured widgets (eg for date input) is out.  Writing JavaScript
that sanity-checks user input is OK.

If what you mean is the kind of stuff that is involved in Postorius
and Shanu Salunke's "Mailman Interface" (a GSoC project for Systers
last year), yes, that passes muster.
___
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 2014 ideas list

[Barry Warsaw]

On Feb 06, 2014, at 07:11 PM, Florian Fuchs wrote:

>1. A continuous integration tool for the Mailman suite.

Very much +1.

I like the development model where we have a gatekeeper against merges to the
trunk better than post-merge buildbot-style validations.  That way, we know
that only merges that pass the test suite will land on trunk, so it should
always be releaseable.

The downside to that is that the gatekeeper is usually one exact setup (e.g. a
specific version of the OS, a specific choice for backend database, a specific
Python version, etc.)  buildbots/jenkins, etc. then augment that to make sure
that we haven't regressed on supporting PostgreSQL, MySQL, PythonX.Y, etc.

>2. A responsive ui for Postorius

Very much +1.  Another thought would be to support an app that you could
install on Android or iOS (or Ubuntu Touch? :) to more directly control a
Postorius server.

>3. Various Python 3 ports

Very much +1.  More on this later.

>4. Postorius: Improve the test suite

+1

>- - Migration Scripts from MM 2.1 to MM 3

abompard has a merge proposal that I've been slowly working through here.

>- - Design interface "themes" for specific types of list

Styles, yes, this would be nice and very doable for GSoC.

>- - Enhance List Style Capabilities
>- - Full anonymization (obfuscating sender addresses)
>- - No-logging mode
>- - Log monitor
>
>
>Any comments or (even better) more ideas?
>
>
>I am planning to complete the ideas page by the end of the week
>(probably over the weekend), so I can submit our GSoC application on
>Monday or Tuesday... Of course we can theoretically add more after the
>deadline, but since the ideas page is the most important ingredient of
>the application, it would be *a lot* better if we had all projects on
>it before Friday 14.

Thanks for doing this Florian and to Terri for getting the ball rolling.

-Barry


signature.asc
Description: 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 2014 ideas list

[Nicolas Karageuzian]

Le 06/02/14 19:22, Máirín Duffy a écrit :
> On 01/09/2014 02:28 AM, Terri Oda wrote:
>> I've had prospective Google Summer of Code students emailing me since,
>> uh, September or so... so I guess it's time to talk ideas!
>>
>> I've set up a wiki page, as usual:
>>
>> http://wiki.list.org/display/DEV/Google+Summer+of+Code+2014
>>
>> But let's start with here: what small projects would you like to see us
>> sponsor this year?  I think we'll need to be more selective about the
>> final list, but let's start with some brainstorming!
> 
> Do you know if Summer of Code students can do interaction design / UX
> stuff? Because I'd be willing to mentor for that.

And what about this idea (already posted i think) about :
- plug-in support for hyperkitty ( for plugs to other tools like
redmine, etherpad, poll systems, and as an opening for semantic
integration (index/search) )


> 
> ~m
> ___
> 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/nicolas%40karageuzian.com
> 
> 
> Security Policy: http://wiki.list.org/x/QIA9



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 2014 ideas list

[Florian Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 02/06/2014 07:22 PM, Máirín Duffy wrote:
> Do you know if Summer of Code students can do interaction design /
> UX stuff? Because I'd be willing to mentor for that.

Oh, that would be great!

I'm not a 100% sure about the exact criteria. I vaguely remember a
discussion on the GSoC mentors list about CSS which eventually turned
into an argument about Turing completeness and what constitutes "real"
programming.

So I don't know if a pure design/CSS project would qualify. But I
think any UX work on Postorius/Hyperkitty will involve at least a
little bit of Django and/or JavaScript work. I'll scan the mentors
list archives if I can find something - or ask that question again,
just to be on the save side.

Florian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS89zRAAoJEEceGbPdavl7vrAH/0rru3C6TtS5RP66h3onx6te
v+9ODFthhH4X4igbElIaI5THa2p8W9d3ukabN9JtvUPhdSSCzWxCn4JsFNJhhqa7
nxQ36cTeR/QPXs49MBBMVTtQPXN7vAC11OgIgOLmkYRrI0hFOQnOOliXflYy7ho6
RSxzHPpsUw48ASYryODfWOSBE1F0yk+fc4p4fWoQZsvGnR56U3y7PV39FLJdWAvq
vdXTqHzX/rzHJyd1njfLO36SFQ0p+rDQNHZXrQJ/Ul5r3le2m1yrxD65WIjn1HAb
frFD4V8RI+CHAP+PSbpJ3E8hBi5/CUVUKqnoZD9ShZ948wpQEIxYRIzXKUImPcE=
=auR2
-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 2014 ideas list

[Máirín Duffy]

On 01/09/2014 02:28 AM, Terri Oda wrote:

I've had prospective Google Summer of Code students emailing me since,
uh, September or so... so I guess it's time to talk ideas!

I've set up a wiki page, as usual:

http://wiki.list.org/display/DEV/Google+Summer+of+Code+2014

But let's start with here: what small projects would you like to see us
sponsor this year?  I think we'll need to be more selective about the
final list, but let's start with some brainstorming!


Do you know if Summer of Code students can do interaction design / UX 
stuff? Because I'd be willing to mentor for that.


~m
___
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