Hi Stefano, Thanks for your detailed reply, I hope my comments below will reassure you that I'm not proposing anything radical, just a slightly more visible planning process, and some small refactorings. I also hope that we're beginning to reach a common understanding of what James project is lacking and how to take the next step from having tactical (I don't want to pretend you are stupid, but I know that English is not everyone's best language, tactical means short term) decision making towards strategic (means long term).
On 10/24/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I'm happy enough with what JIRA roadmaps give us. I don't know what exactly you mean with "status file" but I would not like having more pieces to mantain.
the STATUS file is a mechanism used by Apache projects to record what work is planned and who is doing it. It allows the project cope with both a rapid cycle of defect fixes and minor enhancements, and with a longer cycle of major refactorings.
It is already boring enough to manually update the changelog in our website at each release.
Yes that is a painful task, but this is not the same thing, it isn't about what has changed but about everyone being able to record what they are working on and what state it is in. It can make planning releases much easier.
I've added this point because Noel and Vincenzo brought this as an important point in the 2.4 roadmap discussion. I personally don't care of config.xml compatibility: I was just reporting what I understood was important (and feasible) to the PMC.
Fair enough, in that case I direct my point to Noel and Vincezo ;-)
Well, don't take me wrong: I never intended to stop you from working on this. If you have the time and will to do that then feel free to start some proposal (either with code or discussion as you prefer). I just would avoid starting discussions on things that have no "champion" to do the concrete work at the end because I'm running short in time and I prefer to concentrate on things that I already thought in past.
Oh no! I wasn't suggesting that anyone other than me do this, and yes I'll propose it in more detail first. The problem is that it results in a major release (because the API changes) and this can mess up the schedule of defect and minor enhancement releases.
I admit I didn't think to mailet apis too much but I did this in past and I wrote something (also in the mailet-api list) and it seems we (all) have really different ideas about the next mailet apis, so I decided to avoid the topic to concentrate on something simpler.
OK, I agree that we have different ideas, I would hope to show that mine is just a normalising refactoring and doesn't conflict with any API enhancements others may have in mind.
Maybe someone receiving less vetoes to proposals ;-) will be more likely to do this step.
Ha! :-D :-D
As I said we probably don't agree on the future of the mailet apis ;-) Beside joking, I believe that now that we are here we should wait to find a good solution to services to be provided to "handlers plugins" and maybe the same patterns could be used in the next mailet.
+1 I agree, I'm not suggesting that the mailet changes be released quickly, just that work could start soon.
I simply thought at this roadmap because I thought it was convenient: unfortunately the time is really much less than what I would like to do on James.
I know, I'm just using this opportunity to put my cards on the table again.
Btw you shouldn't fear me: I rerely use vetoes and always prefer an average/partial solution to no solution. And I would be really happy to see some new concrete effort by "less active" committers!
I've been very busy for a long time now, but I'm finding more opportunities now, and I'm keen to re-start where I left off, which was looking at vhosting and a mailet API SDK (which requires some small chages to the API as an enabler).
Ok, so if we let pop3 users to have the "@domain" and we add to the pop3server a configuration for a default domain to be used when no domain is passed would solve both issues, right?
Right.
Now if we want to bind the pop3server to multiple IPs we have to declare multiple <pop3server> blocks anyway: is this right?
Right. All we need to do is to allow the <pop3server> blocks to take the repository as a config param. and to let the local delivery mailet do the same thing.
Well, ToMultiRepository try first to retrieve the user inbox via MailServer.getUserInbox method. IIRC it shouldn't be so hard to isolate also this method in the new services we added lately.
Agree.
I'll try to remember this the next time I'll review the code about this issue.
Thanks
> Well thats true to some extent. but only if you accept that your > proposal is enough and as far as we'd want to go. I accept this ;-)
:-D :-D.
>> You can read more at the end of this comment: >> https://issues.apache.org/jira/browse/JAMES-414#action_12322582 > > Problem accessing this just now :-( Now it should work again.
I agree with that. Looks good.
Well, as you can see the goals I proposed (and that at least Norman agreed) was listed on that topic and we have took them seriously enough. I think that I can't do anything more than proposing a list, finding a "working crew" sharing the same goals and get things done ;-).
I'm not disagreeing with this at all, just saying that I think we should consider recording what we're doing, and what we're planning at a high level in the status file, so that we have one single list we can use to plan releases. This is about unblocking the big changes which we know we want but can't agree when or how to do them.
I tried for more than an year to do some bigger planning and bigger changes but I failed.
I know, and I think that the problem for some people was that the proposals involved a lot of change, and the discussions went into a lot of detail and moved very quickly. I'm suggesting that one way to get these things agreed may be to record the proposals (on the wiki?) discuss them here and revise them then vote them into the status file where they are "officially recorded", rather than record discuss and vote all in one mail thread. IIRC Many of your high level proposals were rejected because whilst people agreed with the high level, and many aspects of the detail it was only one or two aspects of the detail which put people off. Separating the high level proposal from the detailed design of its implementation might allow more things to be agreed in principle, and then we can delay arguing over details until we are ready to implement the details, by which time we may be clearer about what is required and what is achievable. Do you see what I mean?
Even small changes have been vetoed, so I won't loose much more time on big goals if there is a chance to be vetoed at the first step. I can leave this task to someone with more social talent than me with this.
(see above) I hope that this is one thing that I *can* contribute ;-) not only do I have years of experience of annoying people @apache, but getting groups to reach consensus based decisions is also one of the skills I use in my day job.
Feel free to do some proposal, but remember that in not paid open source it is hard to write timetable for others.
I think I'm even more aware of this than you are, it is exactly why I can't spend the time on James that I used to.
I think that Norman and I did exactly a proper plan and almost a proper timetable because we put on the table tasks that we was willing to do.
Right, and thats the right thing to do. If everyone adds their own thing to a list (the status file?) we can see what everyone is capable of achieving, and outline the contents of planned releases without having to comit to dates. Releases need to be roughly planned for major and minor cycles to prevent major changes from blocking defect fixes.
I would be happy to start discussing a bigger/better roadmap: anyone should start writing what they will be willing to work on and when. THen we can see how to solve the puzzle (and what can be part of James and what not).
I think I will propose the use of the status file, and we can see what we think once we've tried it, unless it gets shot down by the veto brigade ;-).
I personally don't have a fixed roadmap: it depends on my mood and sometimes on what features my clients are willing to pay me for ;-) but I always try to keep trunk consistent and to commit things only when I know I can finish it.
Thats the right approach, and (if you don't mind me saying so) one of several reasons that your contributions have been such a sucess, which in turn has encouraged others to become more involved. d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
