incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: [DISCUSS] Prototype ASF Mailing List Request form
Date Wed, 06 Jun 2012 04:05:16 GMT
Sam Ruby wrote:
> V3 of the interface:
> Key changes:
> 1) initially start out with two moderator input fields, both marked as required.
> 2) a paste of a list of (either comma or space separated) emails will
> be split across multiple input fields.
> 3) validation of podling, project, and emails.  This is the part where
> I would like the most feedback.  Apparently, people will want to use
> this before podlings and projects are set up elsewhere, and certainly
> not all emails are known in advance, so the way I am handling this is
> to ask for confirmation for each unrecognized value.  I also prevent
> requests for the creation of lists that already exist.
> At the present time, I'm not yet pulling from podlings.xml.  One thing
> I would like to discuss is whether it is possible for the following
> logic in be replaced by adding new attributes and/or
> elements to podlings.xml and pulling the data from there:
>   if k == "zetacomponents":
>     projects[k]['resourceNames'].append("zeta")
>   elif k == "beanvalidation":
>     projects[k]['resourceNames'].append("bval")
>   elif k == "":
>     projects[k]['resourceNames'].append("lucene-net")
>   elif k == "manifoldcf":
>     projects[k]['resourceNames'].append("connectors")
>   elif k == "":
>     projects[k]['resourceNames'].append("ooo")
>   elif k == "odftoolkit":
>     projects[k]['resourceNames'].append("odf")

When the podlings.xml file started i had hoped that we could use
its "resource" attribute to handle such alternate names.
Not sure what is the intention of that attribute.

There was an old conversation about this around 2011-10-10, e.g.
suggesting an optional "resourceAlias" attribute.

As explained there and in the clutch code, that "resourceNames" is plural
because we found some projects use two or three different names for their project
in different contexts.


> The ideal for me would be to have confirmation prompts be rare enough
> that when they do occur, people will actually read them.  The overall
> concern is that if it becomes too easy to create malling lists, the
> next problem will be requests to the infrastructure team to rename
> lists or moderator names when typos occur :-)
> For those who are interested, source is here:
> - Sam Ruby
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message