Am Freitag, den 23.06.2006, 01:30 +0200 schrieb Stefano Bagnara: > 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
8)SMTPServer: Discuss what will be the best "method" for support a plugable SMTPHandler api like we did for mailets. Also discuss howto support fastfail etc. bye Norman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
