Hi Danny, something to say ..
Danny Angus schrieb: > 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. We can test it but i aspect not much of it.. Anyway i will be happy if im wrong. > >> 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 lookin forward to this... Please go ahead. > >> 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. We should just find a good solution to lookup Services without bundle the mailets to tight to james. If i understand it right then the mailets should work without james.. > > >> >> Maybe someone receiving less vetoes to proposals ;-) will be more likely >> to do this step. > > Ha! :-D :-D Maybe i should try .. I'm everyones most loved guy :-P > > > >> 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). Im happy to hear. > > >> 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. I think thats a very good solution and should also fix noels -1 . > > >> 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. I think thats cool.. but i don't see so many user cases. I prefer the "normal" vhosting like vpopmail etc do it > > >> 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. +1 for isolating > > >> 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. > +1 >> >> 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? I think the most problems of people are that they fear to "break" james.. But why we should fear with new junit tests :-P > > >> 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. :-D :-D > >> 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 ;-). Go ahead > > >> 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. > Agree.. bye Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
