james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Re: Things to talk about at ApacheCon
Date Sun, 25 Jun 2006 23:37:27 GMT
Stefano Bagnara wrote:
> I won't be there, but I would appreciate if this topic could be 
> discussed there:
> 1) We have only 1 committer able to sign releases: imo this is *really 
> bad* to James. Is in our power (as PMC) to decide that only final 
> releases need to be signed with a trusted signature while at least 
> milestones, alphas (and I think even betas) could be released signed by 
> "untrusted" keys? I think that *MANY* apache projects currently have 
> untrusted official distributions so I don't think why James need to be 
> so "strict" in this regard.

if I am counting right, there are two keysigning party candidates in 
Dublin. would make it a 200% growth. :-)

> 2) Decision system analysis. <snipped/>
> 3) 2.3.0, 2.3.1, 2.4, 3.0, TNG and what else: I already said this, but I 
> would like to bring again this to your attention.
>  a. Imho we should keep working only on the trunk and eventually 
> backporting code to the branch.
>  b. I would keep only 2 channels (trunk/branch).
>  c. Code is always committed first to trunk (at least if we don't have 
> branch specific issues) and eventually backported.
>  d. After 2.3.0 will be released we keep working on trunk. If needed 
> 2.3.x releases we'll be created on the branch by backporting code from 
> trunk or just for mantenaince code (we'll decide this at that time)
>  e. At the end of september we'll evaluate what we have in trunk and how 
> good has been the 2.3.0 release and we'll decide wether we should try to 
> branch for 2.4 or keep working on trunk for a while, until 2.3.X is 
> stable enough to close its branch.

+1 (I thought we already mutually decided just this.)

> 4) Code issues: I want a "vote like" to apply this issues, then I would 
> like to start back with the CTR. Some of them already contains the code, 
> for the others I'll try to attach the code soon, otherwise please vote 
> if I can start working on the trunk for a Commit-Then-Review session of 
> the issue.
>  a. Cleanup/Refactor FetchMail code
>     http://issues.apache.org/jira/browse/JAMES-509
>     Code is there (not tested and not completed, but enough to be voted)
>  b. Create a RemoteDelivery service
>     http://issues.apache.org/jira/browse/JAMES-520
>     I already have code also related to SpoolManager refactorings that I 
> would like to commit in trunk and proceed with step-by-step refactorings 
> in order to experiment this and the JAMES-491 (see at the end) in 
> relation to the thoughts Noel reported to the list the past week about 
> the processor/spool manager/queue.
>  c. Mail/Spool/Message repositories refactoring
>     http://issues.apache.org/jira/browse/JAMES-521
>     Main goal is IMAP here: I would like to commit the code from Joachim 
> and start working on this refactoring.
>  d. Refactor James services to extract common code and isolate 
> cornerstone/excalibur dependencies
>     http://issues.apache.org/jira/browse/JAMES-516
>     Some code is already there, much more can be done, but it is a step 
> (the code I attached is not my last code, but I'm completely out of 
> synch due to this procedural problems).
>  e. Refactor the service methods to inject services via setters
>     http://issues.apache.org/jira/browse/JAMES-494
>  f. SpoolManager refactorings
>     http://issues.apache.org/jira/browse/JAMES-491

wow, there are cool things in the pipe. hope to see some on trunk soon!

> I also think that we should vote to decide wether I can work again on 
> the trunk with a CTR approach or not. I stopped my work on trunk in the 
> mean time. I want to understand why I cannot proceed with CTR, or my 
> codebase will be so different from james-trunk that I will be never able 
> to synchronize again with James. Incidentally I'm a lot more busy in 
> July and on holiday in August, so this is not an urgent issue, but I 
> really want this to be solved in a clear way as soon as possible.

We have a release branch now, so IMO there is no need for a trunk on hold.

> 5) JSPF: we need to release it. Norman wrote a message titled "jspf 
> release" (2006/06/06). I replied with a test build, a test website and 
> more informations. No one else replied.
> We voted to include Jspf in the James project: I would expect help 
> making the first release, but if you can't help, please at least reply 
> that you agree to make a release or anything else.

are the IP issues sorted out? if not, AFAIK, a release may not happen 
according to ASF rules.

> 6) Postage: it needs a JIRA project so we can separate Postage issues 
> from James issues. We should also make clear (at least to Bernd) what we 
> expect from him and what can we do for Postage. I can help with the 
> maven2 build/website once we decide how to publish the JSPF website and 
> the jpsf release.

Created sub-tasks of JAMES-442 for outstanding project management issues.
I started Wiki docs and am determined to proceed.

> 7) OSGi: I crossposted a message from the felix list about this. I would 
>  really like to be there to talk with felix authors and hear their 
> suggestion on how James should ideally be "built" (refactored) in the 
> felix world. The main issue I would like to submit to them for Ideas is 
> how to manage configurations and reloadable configurations for james 
> services (take also complex examples like processors, mailets and 
> mailets configurations). I think we are far from moving to another 
> container, but I would also love to be there and being able to talk to 
> some OSGi/Felix guru about this. Maybe in future I'll try to open a 
> mailing list thread on felix about this, but I wanted to bring this 
> point to your attention because they offered to help at the ApacheCon 
> and I think that it doesn't happen so often that 3-5 james committers 
> are able to directly talk about similar issues.



To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message