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.
+1
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
