You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2006/06/23 01:30:56 UTC
Things to talk about at ApacheCon
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.
2) Decision system analysis. IMO James PMC have BIG problems in managing
the project. Most of the few developer/architect time we have at hand is
lost because we have not been able to be *agile* in our decisions. We
loose weeks in design discussions that *rarely* (or better never) ends
up in operative plans. Most times the discussion is stalled and 1, 2
years ago, when someone find the time to work on the topic it is hard to
understand what has been decided and most time things are no more up to
date because the world has moved forward in the mean time.
I think we need to find a procedural solution to this problem, and here
are a few proposals:
a. Define macro goals and related priorities (IMAP support, Container
change, repository refactoring, and so on). Priorities are not a way to
sort operations, but way to how much the feature is important. If I work
on a primary goal I'm more allowed to create incompatibilities, if I
work on minor things now, and so on.
b. Leave at the developer or group of developers design and
implementation of this features working this way: if the change is
simple, short in time, and isolated just apply it and the we review it
(CTR), if the change is bigger the developer that understand this
automatically create a shortliving branch to commit, work, and show us
the work in progress. I would avoid at all costs long living branches.
c. I would leave to the developer the option to discuss implementation
(or even design) details before coding. Either way each PMC member can
cast a veto and the developer have the responsibility to revert the code
that has been vetoed. (Of course vetoes needs explanations as per Apache
rules)
d. We should definitely avoid to start design discussions if we don't
have the time to finish them, or at least make clear in the message that
it is only a stone thrown in the lake to count how many jumps we can make.
As an example I would like to bring the last talk about James
configurations. I created a JIRA issue (JAMES-495), everyone have been
excited by an "UML" word in a message.. we had a good hi level approach
proposed Steve (2006/05/27). I spent my time to understand the proposal
and make an analysis on our code and I saw possible flaws in the
hi-level design so I wrote asking for more details (2006/05/28). 4 weeks
later no one replied to my message and we have *Yet Another Unfinished
Proposal*. This is just an example. We all loose time if we don't take
the responsibility to finish what we started.
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.
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
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.
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.
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.
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.
I hope that at least some of this issues will be evaluated at ApacheCon
and that you can at least find an agreement on this issue (to my
proposals or alternative proposals) so we can vote and finally solve
them soon.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Things to talk about at ApacheCon
Posted by Bernd Fondermann <bf...@brainlounge.de>.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Things to talk about at ApacheCon
Posted by Stefano Bagnara <ap...@bago.org>.
Vincenzo Gianferrari Pini wrote:
> Just a small "Italian vs. English" language clarification :-) , to help
> non Italians understand.
>
> "Eventualmente" in Italian means "in case of ..., if need arises ... if
> a decision is made ... if it is appropriate to do so ..."; "eventually"
> in English means "finally ... to surely happen at the end ...". It's a
> very common misunderstanding arising when an Italian writes in English.
Thank you very much: I appreciate your help!! I asways make this mistate :-(
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Things to talk about at ApacheCon
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Just a small "Italian vs. English" language clarification :-) , to help
non Italians understand.
"Eventualmente" in Italian means "in case of ..., if need arises ... if
a decision is made ... if it is appropriate to do so ..."; "eventually"
in English means "finally ... to surely happen at the end ...". It's a
very common misunderstanding arising when an Italian writes in English.
So:
Stefano Bagnara wrote:
........
> 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.
means: "Imho we should keep working only on the trunk and end up
backporting code to the branch in case it is appropriate/decided to do so".
.......
> c. Code is always committed first to trunk (at least if we don't have
> branch specific issues) and eventually backported.
means: Code is always committed first to trunk (at least if we don't
have branch specific issues) and backported in case it is
appropriate/decided to do so".
.......
Just a small "I18N" contribution :-)
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Things to talk about at ApacheCon
Posted by Stefano Bagnara <ap...@bago.org>.
Noel, Roger Fullerton just sent the FAX.
Is there a need of a Fax from me and Norman?
We always worked on jSPF as part of a James feature proposal and we
didn't work in James subversion because Norman had no account yet (even
if he already had his CLA signed).
Post to JIRA and the whole SVN import are proofs for this.
BTW if we need to send/sign a FAX please help us with what is the
document to fill and how to fill it (what to write apart our signature).
Stefano
Bernd Fondermann wrote:
> the clearance process Noel probably was referring to is described here:
> http://incubator.apache.org/ip-clearance/index.html
>
> Bernd
>
> Stefano Bagnara wrote:
>> Bernd Fondermann wrote:
>>
>>> IP = "intellectual property"
>>>
>>> I am referring to a mail from Noel dating from May 26:
>>> http://www.mail-archive.com/server-dev@james.apache.org/msg07455.html
>>
>>
>> I've described in the PMC list what we have in jspf sourcecode. What
>> we wrote from scratch, what we imported from other projects.
>>
>> If someone can help determining what are our duties now, this would be
>> useful.
>>
>> Stefano
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Things to talk about at ApacheCon
Posted by Bernd Fondermann <bf...@brainlounge.de>.
the clearance process Noel probably was referring to is described here:
http://incubator.apache.org/ip-clearance/index.html
Bernd
Stefano Bagnara wrote:
> Bernd Fondermann wrote:
>
>> IP = "intellectual property"
>>
>> I am referring to a mail from Noel dating from May 26:
>> http://www.mail-archive.com/server-dev@james.apache.org/msg07455.html
>
>
> I've described in the PMC list what we have in jspf sourcecode. What we
> wrote from scratch, what we imported from other projects.
>
> If someone can help determining what are our duties now, this would be
> useful.
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Things to talk about at ApacheCon
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
> IP = "intellectual property"
>
> I am referring to a mail from Noel dating from May 26:
> http://www.mail-archive.com/server-dev@james.apache.org/msg07455.html
I've described in the PMC list what we have in jspf sourcecode. What we
wrote from scratch, what we imported from other projects.
If someone can help determining what are our duties now, this would be
useful.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Things to talk about at ApacheCon
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Norman Maurer wrote:
>>>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.
>
>
> What you mean with "IP issues" ? I cant follow..
sorry, the context of my question wasn't clear.
IP = "intellectual property"
I am referring to a mail from Noel dating from May 26:
http://www.mail-archive.com/server-dev@james.apache.org/msg07455.html
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Things to talk about at ApacheCon
Posted by Norman Maurer <nm...@byteaction.de>.
> > 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.
What you mean with "IP issues" ? I cant follow..
bye
Norman