You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2004/01/08 03:04:37 UTC

review of SpamAssassin incubator status file

OK, here's my review of our current Project Incubation Status file.

This has raised a number of questions, and is, of course, quite long ;)
Feel free to trim it down if you're answering a question.

Items known to be complete are tagged with "DONE".

> Identify the project to be incubated
> date 	item
> ....-..-.. 	Make sure that the requested project name does not already exist and check www.nameprotect.com to be sure that the name is not already trademarked for an existing software product.

DONE: Done, in that we are aware of the existing trademark.

> ....-..-.. 	If request from an existing Apache project to adopt an external package, then ask the Apache project for the cvs module and mail address names.

DONE: n/a

> ....-..-.. 	If request from outside Apache to enter an existing Apache project, then post a message to that project for them to decide on acceptance.

DONE: n/a

> ....-..-.. 	If request from anywhere to become a stand-alone PMC, then assess the fit with the ASF, and create the lists and modules under the incubator address/module names if accepted.

Partially complete.   We now have:

spamassassin-users: to take over from SpamAssassin-talk on sf.net;
spamassassin-dev: to take over from SpamAssassin-devel on sf.net;
spamassassin-cvs: to take over from SpamAssassin-commits on sf.net.

There's a few more -- -announce, -dev-de, and -dev-br. request in separate
mail.

> Interim responsibility
> date 	item
> ....-..-.. 	Identify all the Mentors for the incubation, by asking all that can be Mentors.
> ....-..-.. 	Subscribe all Mentors on the pmc and general lists.
> ....-..-.. 	Give all Mentors access to all incubator CVS modules. (to be done by PMC chair)
> ....-..-.. 	Tell Mentors to track progress in the file 'incubator/projects/{project.name}.cwiki'

Sander, I guess you take care of this section. ;)


> Copyright
> date 	item
> ....-..-.. 	Check and make sure that the papers that transfer rights to the ASF been received. It is only necessary to transfer rights for the package, the core code, and any new code produced by the project.

DONE: as far as I know, this is complete.

> ....-..-.. 	Check and make sure that the files that have been donated have been updated to reflect the new ASF copyright. 

Not yet complete.   Assuming this will also tag the files with the ASL
text, this also raises the question -- which version of the ASL are we to
use, 1.1 or 2.0?   if I recall correctly, this is an open question.

> Verify distribution rights
> date 	item
> ....-..-.. 	Check and make sure that for all code included with the distribution that is not under the Apache license, e have the right to combine with Apache-licensed code and redistribute.

DONE: Not applicable; there is no longer any code in the distribution
package that is not Apache licensed.   All distribution code in "trunk" is
covered by CLAs, and code in the older branches is not intended to be
released under the Apache.org aegis.

> ....-..-.. 	Check and make sure that all source code distributed by the project is covered by one or more of the following approved licenses: Apache, BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially the same terms.

DONE: see last comment

> Establish a list of active committers !
> date 	item
> ....-..-.. 	Check that all active committers have submitted a contributors agreement.

DONE: Done.

> ....-..-.. 	Add all active committers in the STATUS file.

Not yet complete; there are several who have not yet set up accounts.
See my previous mail to them.

I have a STATUS ready, based on what I've found in other project's
repositories and what looks plausible ;)   Once I get commit access
I'll chuck it in.

> ....-..-.. 	Ask root for the creation of committers' accounts on cvs.apache.org.

See prev.

> Infrastructure !
> date 	item
> ....-..-.. 	Ask infrastructure to create source repository modules and add thecommitters to the avail file.

DONE	seems to be working.

> ....-..-.. 	Ask infrastructure to set up and archive Mailing lists.

DONE	Both lists appear to be working.

> ....-..-.. 	Decide about and then ask infrastructure to setup an issuetracking system (Bugzilla, Scarab, Jira).

DONE	Will be sticking with our existing one due to enhancements.

> ....-..-.. 	Migrate the project to our infrastructure.

In progress.... ;)

> Project specific 
> Add project specific tasks here.

OK, here's some more components of our infrastructure we need to think
about migrating to Apache.org:

- The nightly-build packaging and signing scripts.

- The script to update a tag nightly (used by people running nightly
  "mass-check" tests for rule QA).

- The release packaging and signing scripts.

- The website-building scripts.   These use WebMake to build the website
  -- http://webmake.taint.org/ .  Do we have to migrate this to Forrest
  (which would be quite a lot of work, I think)?
  
  (BTW WebMake does not require any server-side code, it just generates
  static HTML files.)

- news.SpamAssassin.org, a Slash-type website for us and third parties to
  announce products, releases, services, news about SpamAssassin, and
  tools that work with SpamAssassin.   This is running on a donated
  server.

  Unsure what to do about this one, but I would suggest keeping it
  separate -- it provides a good forum for third parties to announce their
  plugins etc., so is useful, but I don't see anything like it in the
  existing Apache infrastructure.

  One option: we could always "downgrade" it's status so it becomes more
  of a "news about products that support SpamAssassin" third-party site,
  instead of an "official" news source as it is now.

- the spamtraps server; this is a dedicated server which receives about
  100Mbytes of spam per day, and reports it to various blocklists and
  network services.   I don't think this should be brought over in any
  way, as it eats a killer amount of CPU time and bandwidth, is not
  required when building SpamAssassin releases, and is a donation from our
  friendly ISP pals at sonic.net. ;)


So those are the bits and pieces that need a bit of thought.

--j.

Re: review of SpamAssassin incubator status file

Posted by Sander Striker <st...@apache.org>.
On Thu, 2004-01-08 at 03:04, Justin Mason wrote:
> OK, here's my review of our current Project Incubation Status file.
> 
> This has raised a number of questions, and is, of course, quite long ;)
> Feel free to trim it down if you're answering a question.
> 
> Items known to be complete are tagged with "DONE".
> 
> > Identify the project to be incubated
> > date 	item
> > ....-..-.. 	Make sure that the requested project name does not already exist
> > and check www.nameprotect.com to be sure that the name is not already
> > trademarked for an existing software product.
> 
> DONE: Done, in that we are aware of the existing trademark.

And what is the status of that trademark?  Is it in the process of being
signed over to the ASF? 

[...]
> > ....-..-.. 	If request from anywhere to become a stand-alone PMC, then assess
> > the fit with the ASF, and create the lists and modules under the incubator
> > address/module names if accepted.
>
> Partially complete.

I'd mark this as DONE.  The assessment of a fit was previously made.
And resources have and will be created under the incubator namespace.

> We now have:
> 
> spamassassin-users: to take over from SpamAssassin-talk on sf.net;
> spamassassin-dev: to take over from SpamAssassin-devel on sf.net;
> spamassassin-cvs: to take over from SpamAssassin-commits on sf.net.
> 
> There's a few more -- -announce, -dev-de, and -dev-br. request in separate
> mail.

Just add them to the list below* when completed.

> > Interim responsibility
> > date 	item
> > ....-..-.. 	Identify all the Mentors for the incubation, by asking all that can be Mentors.

Done.

> > ....-..-.. 	Subscribe all Mentors on the pmc and general lists.

Done.

> > ....-..-.. 	Give all Mentors access to all incubator CVS modules. (to be done by PMC chair)

Done (as in, I already had access ;).

> > ....-..-.. 	Tell Mentors to track progress in the file 'incubator/projects/{project.name}.cwiki'

Done.

> Sander, I guess you take care of this section. ;)

Done.

> > Copyright
> > date 	item
> > ....-..-.. 	Check and make sure that the papers that transfer rights to the ASF been received. It
> > is only necessary to transfer rights for the package, the core code, and any new code produced by
> > the project.
> 
> DONE: as far as I know, this is complete.

Before marking this as DONE, I want to be 100% sure.  I still need to
see at least one CLA be marked as received for instance.

> > ....-..-.. 	Check and make sure that the files that have been donated have been updated to
> > reflect the new ASF copyright. 
> 
> Not yet complete.   Assuming this will also tag the files with the ASL
> text, this also raises the question -- which version of the ASL are we to
> use, 1.1 or 2.0?   if I recall correctly, this is an open question.

Use 1.1.  2.0 is still pending approval.

> > Verify distribution rights
> > date 	item
> > ....-..-.. 	Check and make sure that for all code included with the distribution that is not under
> > the Apache license, e have the right to combine with Apache-licensed code and redistribute.
> 
> DONE: Not applicable; there is no longer any code in the distribution
> package that is not Apache licensed.   All distribution code in "trunk" is
> covered by CLAs, and code in the older branches is not intended to be
> released under the Apache.org aegis.

The latter is indeed important.  For code history purposes, I'd say that
the code may be there, but releases may absolutely not be made under
the ASF banner from that code.

> > ....-..-.. 	Check and make sure that all source code distributed by the project is covered by one
> > or more of the following approved licenses: Apache, BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or
> > something with essentially the same terms.
> 
> DONE: see last comment

I'd rather wait with marking as done until all license texts are applied
and every single needed CLA is on record.

> > Establish a list of active committers !
> > date 	item
> > ....-..-.. 	Check that all active committers have submitted a contributors agreement.
> 
> DONE: Done.

Can't mark this as done when not all CLAs are marked as received.  This
one is a bit of a pain, but I need a list of all the people for whom
we require to have a CLA on file (== the people you asked to send
one in).  I can then check the entire list against what we have on
file.  FWIW, at least one is not recorded, although there was a comment
on a list that one was faxed in.  And, we have to take a delay into
account; our secretary usually processes faxes weekly.

> > ....-..-.. 	Add all active committers in the STATUS file.
> 
> Not yet complete; there are several who have not yet set up accounts.
> See my previous mail to them.
> 
> I have a STATUS ready, based on what I've found in other project's
> repositories and what looks plausible ;)   Once I get commit access
> I'll chuck it in.

I've seen the STATUS file; nice!

> > ....-..-.. 	Ask root for the creation of committers' accounts on cvs.apache.org.
> 
> See prev.
> 
> > Infrastructure !
> > date 	item
> > ....-..-.. 	Ask infrastructure to create source repository modules and add thecommitters to the avail file.
> 
> DONE	seems to be working.

I'll rephrase that sentence and mark it as done.

> > ....-..-.. 	Ask infrastructure to set up and archive Mailing lists.
> 
> DONE	Both lists appear to be working.
> 
> > ....-..-.. 	Decide about and then ask infrastructure to setup an issuetracking system (Bugzilla, Scarab, Jira).
> 
> DONE	Will be sticking with our existing one due to enhancements.

Hmmm... :)  Need to think about that one.  We pretty much discourage
using non-ASF controlled resources.  That said, we'd prolly be
able to get the customized things in our BZ install, since what
you have done is not limited to SA (the CLA field).  The bug you
encountered (and disabled server push for) seems to be fixed in our
install if IIRC.

> > ....-..-.. 	Migrate the project to our infrastructure.
> 
> In progress.... ;)
> 
> > Project specific 
> > Add project specific tasks here.
> 
> OK, here's some more components of our infrastructure we need to think
> about migrating to Apache.org:
> 
> - The nightly-build packaging and signing scripts.

We have a mechanism in place for nightly code snapshots which might be
something to look into.  Automatic signing?  Sounds something that
could be fragile, or at least be viewed as less secure than one would
like.

> - The script to update a tag nightly (used by people running nightly
>   "mass-check" tests for rule QA).

I need some more details on this one to understand.

> - The release packaging and signing scripts.

*nod*

> - The website-building scripts.   These use WebMake to build the website
>   -- http://webmake.taint.org/ .  Do we have to migrate this to Forrest
>   (which would be quite a lot of work, I think)?

You certainly are not required to use Forrest.  The requirement is that
the site source and generated content have to be kept under version
control (to keep things easy for infrastructure).  And ofcourse the
generated content has to reproducable from source.  Adding ASF tools
is a bonus, but not a requirement.

There are some things with respect to content.  The home page should
reflect that this is an ASF project.  There should be links to the
main http://www.apache.org/ page.  Furthermore, while in incubation,
it has to be noted on the site that the project is in incubation.
I believe someone was working on an incubation logo to make this
a bit easier (by just including the image on the page).
Anyway, just browse around the ASF site and see what other projects have
done.

Another note: the final site destination will be
http://spamassassin.apache.org.  We can certainly keep
www.spamassassin.org and simply redirect it there.  Given that
DNS moves over anyway... ;)

>   (BTW WebMake does not require any server-side code, it just generates
>   static HTML files.)

Ah, yes, server-side would be something that would have to be proposed
to Infrastructure, assessed, voted on, etc.  Glad it's N/A  ;).

> - news.SpamAssassin.org, a Slash-type website for us and third parties to
>   announce products, releases, services, news about SpamAssassin, and
>   tools that work with SpamAssassin.   This is running on a donated
>   server.

Where is this server located?  Is the hardware a solid donation, or is
it a 'lend-for-use' box?  Is the bandwidth donated?  Do you have full
control over the machine?

>   Unsure what to do about this one, but I would suggest keeping it
>   separate -- it provides a good forum for third parties to announce their
>   plugins etc., so is useful, but I don't see anything like it in the
>   existing Apache infrastructure.

That's because we don't let third parties announce on our sites.

>   One option: we could always "downgrade" it's status so it becomes more
>   of a "news about products that support SpamAssassin" third-party site,
>   instead of an "official" news source as it is now.

What I think is that we should just bring this up for discussion.  Let's
see how we can fit things in.

> - the spamtraps server; this is a dedicated server which receives about
>   100Mbytes of spam per day, and reports it to various blocklists and
>   network services.   I don't think this should be brought over in any
>   way, as it eats a killer amount of CPU time and bandwidth, is not
>   required when building SpamAssassin releases, and is a donation from our
>   friendly ISP pals at sonic.net. ;)

Ok, we're gonna need some details here.  Basically the same questions
as above.  And add: How much bandwidth? to that list.

> 
> So those are the bits and pieces that need a bit of thought.

Yep :).  Thanks for taking the time to do this.

I'll add:

 - transfer of spamassassin.org to ASF
 - transfer of DNS to ASF Infrastructure
 - ...

There's probably more to think about, but I think we have enough to
keep us busy for a bit.

Sander