On Wed, 2004-01-21 at 04:13, Justin Mason wrote: > --BEGIN PGP SIGNED MESSAGE-- > Hash: SHA1 > > [resend, last one was misaddressed ;). Added some more text as well, > BTW, so previous mail can be ignored.] > > Sander -- here's our status report. Please feel free to take this and > mangle it into a suitable format for submission. > > There's a few items that may need a little work by you before > it's ready. ;)
*grin* > * is the STATUS file up to date? (also post link) > http://cvs.apache.org/viewcvs.cgi/*checkout*/incubator/site/projects/spamassass > in.cwiki > > Not quite -- the two 'Establish a list of active committers' items are not > up to date. All active committers are now signed up, so that can be > closed off. Nice. Will take care of that. > The second item is 'Add all active committers in the STATUS file.' > However, I'm now confused. Which is the canonical STATUS file -- > /incubator/spamassassin/trunk/STATUS, or > /incubator/site/projects/spamassassin.cwiki? Some signs seem to be > pointing to the latter... so, if the latter, some cut and paste from the > former to the latter is then required (and note, I don't think I > or anyone else on the SpamAssassin PPMC have write access to it). Correct. Like I said on a mail to spamassassin-dev@ earlier, you guys have been used as ginea pigs when it comes to user accounts. The consequence is that you can't do what other committers can. I'll request that full accounts be created for you. > I'm kind of taking the approach that the latter is the incubation > checklist, and the former is tracking our assets and people. That > may be wrong though ;) > > BTW the former is here: > http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/spamassassin/trunk/STATU > S?content-type=text%2Fplain&rev=6244&root=Apache-SVN > > Also, the two tasks under 'Verify distribution rights', should be > complete. All code in the trunk is covered by CLAs, and the non-covered > branches have README files noting their non-Apache status and presence for > historical purposes only. Good. You could consider deleting the branches that are at end of life. People will be able to access them by selecting a rev in which it existed. > However, perhaps this may need to be verified > by the ASF before the task can be marked as complete, I'm not sure. I'll try and get a round tuit. > * any legal, cross-project or personal issues > that still need to be addressed? > > Copyright and distribution rights still remain to be verified, although > all CLAs should now be in, assuming Matt Sergeant finally got around to it > ;) -- so it's up to ASF legal now. Matt's CLA isn't recorded as received (yet). > The trademark issue on the "SpamAssassin" name is still in progress; as > far as I know, NAI legal still need to provide some documentation to DW, > Jim Jagielski et al. We'll have to figure out what the status on this is. > * what has been done for incubation since the last report? > > Lots! > > - - all committer accounts are set up; > > - - source code is now running from the Apache Incubator SVN repository; > > - - all of the developer-oriented mailing lists are now at the Incubator - > although some user-oriented lists are still external, to avoid user > confusion; > > - - all code has been vetted for CLA coverage, and removed or clean-roomed > if a CLA could not be provided, and this is now awaiting verification by > the ASF; I'll go see if I can find some code-vetters... > - - and all major code or rules files in SVN are tagged with the ASL 1.1. > > > * plans and expectations for the next period? > > We need to transition more infrastructure, including our main website, > Wiki and Bugzilla. Bugzilla uses some custom code to track CLAs, which > would be nice to bring over. This could take some time. I wonder if you would consider Jira a viable alternative (given that Infra would take care of the conversion for you). You can view the Jira installation at http://issues.apache.org/jira/. Alternatively, leave it where it is until we can allocate the resources to move BZ over. > The Wiki is running on MoinMoin, so this fits nicely with wiki.apache.org. This should really be a breeze. > We also plan to finish up the legal situation, by getting the CLA coverage > verified by the ASF, then the trademark. > > Also we have several cron scripts that are used to perform distributed > rule QA, and a very large rsync server contain 2.7Gb of data, which will > need to be migrated. What to do with these is still a topic of > discussion, since they're *big* in terms of disk space usage, and > there may not be room at the ASF infrastructure for this! 2.7GB shouldn't be a problem. As for the cron scripts, we'd need to analyze those. It sounds like the QA system requires somekind of automated build systems. SA wouldn't be alone in requiring that and we are working on getting a dedicated location for that. > There's also a spamtrap server which almost definitely should *not* come > along -- it handles approx 1 Gbit of traffic per day (in spam reports) > and would be a waste of ASF hardware and bandwidth, IMO. I wouldn't worry about the latter too much. If it's part of the project, it's part of the project. If it can be viewed as an outside service, let's brand it like that and leave it where it is. > * any recommendations for how incubation could run > more smoothly for you? > > A little more introductory doco would be nice; I hadn't heard of > http://www.apache.org/dev/ until quite late in the process, and there were > a few other issues where I had to hop around the apache.org website to > figure out what things meant or what a given procedure was. I'm sorry about that. As I mentioned earlier, you were ginea pigs when it comes to SVN only accounts. When creating a unix account we send out a standard welcome mail, which includes this URL. We should have sent you a modified version. As for figuring things out by probing and searching the website (or asking people): I think that is good. Every TLP needs to know their way around the ASF on their own, and the more contact there is with other areas of the ASF, the better. > Also, one thing I'm concerned about is how many aspects of our > infrastructure will wind up with "incubator" in their URL or hostname; > as a mature project, it'd be much easier to transition with the minimum > of changes for the existing community, and this scoping of URLs > and hostnames as in incubation means an additional change once we > leave the incubator. As a result, it gives us a bit of an incentive > to *not* set things up (lists, etc.) until we leave. That's a fair assessment, which was recently raised elsewhere aswell. I think we are changing policy on that, with respect to leaving the project in its original location as long as possible, until it is close to graduation. Thanks for your report and feedback. Sander --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
