*** ONE TIME OFFER: Because of the recent Internet worm, the ASF has installed new filters for the mail server. One of the victims is ZIP format, which is currently banned as a virus payload. JAR and TAR files are accepted. But we should also be able to accept patch and java files as attachments. There have been problems with some of those attachments, and I would like to resolve them. So please CC me just this one time when you send your attachments to the list. I want to check the raw MIME, and see why the server is filtering out the attachments.
Better idea, create an issue in JIRA and upload it as an attachment. :)
Serge wrote:We need to sort out releases quick... What's the next release we're planning? 2.2a17?
Should we be that fine-grained in JIRA, or should we targeting actual Release builds? I'm leaning towards the fine-grained approach, but that would result in a lot of versions. Consider how many we put put in 2003 alone.
We had 6-10 changes an alpha release, so I think it's fine. If we put out an emergency patch, then maybe not. But more releases the better in my mind.
This is done, but with a caveat. When we replace the faux short form with the full ASL v1.1 a year or so back, we "lost" original copyright dates. Similarly, all of the ASL v2.0 instances in the MAIN branch use 2000-2004. I am in the process of correcting the Mailet API to use 1999-2004 based upon the presence of internal dates within the files. More importantly, things such as FetchMail should be changed to 2003-2004, so that the copyright date is not EARLIER than the code.
I understand that this isn't really that big of a deal. There was some brief discussion (board or community?), and the conclusion was that copyright date didn't mean much... an archive to substantiate the date matters much more.
Danny and I agree on moving the date classes into the Mailet API as part of the merger. If we could, I think I would like to hide SimplifiedDateFormat and SynchronizedDateFormat, and expose just the three RFC related classes, but that isn't a critical issue.
Whatever with the dates is fine with me.
We also agree on leaving out the repository from the Mailet API in this next release.
+1
String getName(); void setName(String name); void setLastUpdated(Date date); Date getLastUpdated();
We could debate them, but with the exception of using getName for diagnostic purposes, these all relate to the repository interface, so what would be the point? Therefore, I believe that we can agree to leave these out of the Mailet API for this release.
+1
Danny and I just discussed if getName should be public, but in retrospect, I am reluctant to add getName as a public API. The reason is that "name" is probably not the best label for a unique ID/repository key, and also I am wondering if we should expose it as a Mail Attribute, even though the James implementation would special case that key rather than store it in the attributes set. At the least, if we are going to add it to the public API, we should give it a name we want to live with, and deprecate getName() internally.
Agreed.
Basically, I'd like to make as little change in the Mailet API as possible until after this Release.
Agreed.
The next round of enhancements that I believe should go into the release after this include:
- JNDI - enhanced version of SMTPACL - IMAP (between Jason's work and Maildir, Darrell and others should have a suitable persistent store - Sieve
Agreed.
We should create something as the next release (even if we just name it release "Next"), and mark this as fixed for that.
Is it possible to have a version called "sc" ("source control") or whatever, and then move issues to the actual release when we make one?
Sure, that's the basic idea of "next". The only reason I wouldn't is because if someone sees their issue as fixed "next," what does that tell them? Usually we will know the next version number.
I'd also like to start using JIRA to record (not to discuss) the Roadmap. But I also notice, as I am typing this in the car, how nice e-mail is when you are off-line. :-)
Yes, issue tracking is just tracking, not discussing. Some people used Bugzilla to make statements, but I don't like that practice.
right now JIRA is sending emails to each developer... should I change notices to instead go to the server-dev mailing list?
I would be in favor of that change, unless you can think of a reason otherwise.
Well, you just pushed me back on the other side of the fence. :)
If notices do not go to the mailing list, then someone has less motivation for posting arguments to the issue tracker.
-- Serge Knystautas President Lokitech >>> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
