Hi Stefano, Am Freitag, den 06.10.2006, 12:38 +0200 schrieb Stefano Bagnara:
> Now that Joachim is a James Committer and has write access to SVN > (Joachim: can you check your svn account works?) we have to decide what > to do. The account is there. Don't know whether the PMC has assigned me to James resources yet. I'll actually see, when trying to commit something. :-) > I think we should ask him to commit his work in server/sandbox/imap so > we can review it and eventually merge it to trunk. > Imho we can let him skip the packaging and the documentation he did in > past to post his work on JIRA, because he will do the work needed to > integrate (very small work) it in trunk and then it will be much more > easy for users that want to try IMAP as we'll bundle it in the default > distribution. I really would prefer committing it to sandbox instead of attaching to Jira. Jira is great for single files and patches. Attaching a big zip would be inconvenient for both sides. And maybe committers could incorporate their suggestions while discussing by adding new/modified interfaces to the API directly. Or add comments to the code where they have remarks. Or even fixing bugs! ;-) I love SVN. > I expect that it will be included but disabled by default and marked as > experimental in the next release due for 1st quarter 2007. I hope so. Early user feedback would bring us a lot of benefits. > Do we need Joachim to sign a Software Grant > (http://www.apache.org/licenses/software-grant.txt) for this? No, I don't think so. I never published it as a product somewhere else. There are no other persons involved that are not apache committers. And when I actually commit it my self into James-SVN it should be enough. To exclude all possibility of doubt I could additionally attach it to Jira doing a grant. ;-) > > Everything works quite well at the moment. I have unit tests for all > > basic operations. > > I know that past unit tests where tightly linked to maildir: I also saw > that you made steps since that time and now it seem you separated > generic tests from maildir tests from mstor tests. > We can't incldue javamaildir stuff in our repository: does including all > of the remaining things make sense? Is this already working? The new API doesn't require any JavaMail stuff, apart from MimeMessage and Flags. It's a 100% Torque/JDBC implementation. All additional required libs have actually ASL. There is no connection to javamailstore-mailrepository anymore. But I still plan using JavamailStore together with mstor or javamaildir as a an additional choice of backend. Another story is the possibility of creating a Javamailwrapper that would allow other apps to use our JDBC backend. > > My ideas to the roadmap topic: > > > > - after publishing API with prototype running together with imap in James > > I hope for some review. > > - maybe we are able to make some decisions then > > - we have to decide if/how to integrate the code > > - for integration everything (sandbox/branch/product/trunk) is imaginable, > > because it does not interfere with existing code. > I don't know if this roadmap is intended as a sorted list: in this case > I would change the order because I think that integration should be the > first task. Also it was a quick note, it was indeed a more "careful" approach. But I like your idea doing it more agile. > I think that we should use an agile approach to this task: > - commit it to sandbox (branch trunk, add your components, make > configuration changes) > - "official" review/test from us This would definitely lower the communication overhead. And lower the bounds for potential testers: checkout the branch from sandbox, build, run. It would give us a better overview before going live to trunk. > - when any "blocker" issue is solved merge it to trunk > - then I expect we can discuss and refactor it while a working version > is in trunk: maybe someone will start short-living branches to show his > ideas. An early merge to trunk will probably give us the most progress. As long as we are not doing substantial changes to other parts of James and keeping some kind of wrapper in between I see no risks for future releases. Maybe the ideal way would be developing the perfect API first and do the complete integration in all parts at once. Being pragmatical I think the API Imap uses, and the API rest of James uses, will come closer together step by step, until no wrapper is needed anymore. Joachim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
