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/10/20 18:59:22 UTC
Re: JAMES v2.4 Road Map (Status Update)
Slightly more than a month ago I wrote a roadmap, here is an update for
people that has not time for a day to day oversight.
Stefano Bagnara wrote:
> Norman Maurer wrote:
>> I agree with Stefano.. And i think we can push a 2.4 release in 6 Month
>> ( At least i hope so).
>>
>> So i think the next step must a roadmap! First we should dedicide which
>> jira issues should be moved to 2.4 before do anything else. Without a
>> roadmap we only make it more complicated.
>
> My proposal is:
> - everything we have in trunk now: now I can't see anything critical
> enough to be removed.
Well, this was already there ;-)
> - JAMES-426 - Make james use virtual user table domains for servernames
This is done.
> - JAMES-52 - 8bitmime capabilities missing
It seems that javamail 1.4.1ea fixed the problem and we reenabled the
support for it!
> - JAMES-487 - Refactor Bundled handlers to use the "HandlerChain" pattern
This is blocked by the handlerapi work in sandbox.
> - JAMES-577 - Switch default sendpartial to true for RemoteDelivery
Done.
> - JAMES-607 - Rewrite MBoxMailRepository to use mstor
We wrote the support for this: Joachim found 3 blocking bugs in mstor. 2
of them have been fixed, so as soon as mstor will fix the third and make
a release this will be fixed.
> - JAMES-611 - Remove finalizers and make sure we always call dispose
> when unreferencing objects
Done.
> - JAMES-461 - Javamail Store based MailRepository support (was: Maildir
> support)
Joachim contributed this. Applied.
> - JAMES-614 - Add more actions to FastFailHandlers
In progress: Norman is working on this.
> - JAMES-549 - Refactoring SMTPHandler to allow better integration of
> more the one class per command
Blocked by the new handlerapi in sandbox.
> - JAMES-599 - BeanShell Scripting in James
Code has been provided by Guillermo.
We should probably vote to decide wethere to include this or not.
I wrote a message in past to understand wether there was preference for
this BeanShell solution or on the BSF mailet: I would like to see the
BSF mailet code before deciding, but I can't find it.
> - JAMES-562 - Aliasmanagment should not depend on a user (see as
> VUT-UsersAliasingForwarding common interface and remove tightly
> dependencies between James and JamesUser)
Almost done.
> - JAMES-595 - Change names of release artifacts to use james-server
> instead of james.
Open (but easy to do).
That said, currenlty blocking issues are:
1) dnsjava 2.0.3 release (to support JSPF)
(we are currenlty including a snapshot of dnsjava trunk)
2) javamail 1.4.1 release (8bitmime bugs)
(we are currenlty including 1.4.1ea-SNAPSHOT from their m2 repository)
3) mstor release (to replace internal mbox management with mstor)
(2 of 3 bugs have been fixed in cvs, so we should be able soon to
include a working snapshot or the fixed release)
4) handlerapi v2.
(If I understood it right, Noel is almost ready with his work)
I think that if we can comlpete the handlerapi stuff soon we could
realistically consider branching for a release at the start of december
(almost a month before what was in the plans)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map (Status Update)
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus wrote:
> 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).
Thank you for remembering this!
I splitted this reply in 4 because we have too much things in the same
thread.
For virtual hosting and status file I "branched" the topic on
server-dev, while for maielt apis discussion I branched to the
mailet-api list!
http://mail-archives.apache.org/mod_mbox/james-mailet-api/
> On 10/24/06, Stefano Bagnara <ap...@bago.org> wrote:
>> 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'm not a fan of WIKIs, and the fact that there are already a lot of
outdated proposals there make me fear.
Btw I can live with WIKIs too, so if you think using wiki give us a
better workflow we can give it a try (as a sidenote I would prefer
confluence over the current wiki).
About Wiki I saw that felix, directory and geronimo projects started
using Confluence also for their website creation: they use confluence to
edit the structure and then export it statically to update the official
website. I think that if we want to "re-introduce" wiki in the james
project it would be cool to solve the "website updates" problems.
If I understood it there is also a maven2 plugin to include in the
website generation pages retrieved from confluence. Unfortunately there
is no such facility for MoinMoin.
>> 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.
Feel free to say this as many times as you can ;-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map (Status Update)
Posted by Stefano Bagnara <ap...@bago.org>.
Vincenzo Gianferrari Pini wrote:
> Danny Angus wrote:
>> On 10/24/06, Stefano Bagnara <ap...@bago.org> wrote:
>>
>>> 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 ;-)
>
> We just stressed the fact that life must be kept as much as possible
> easy for users when upgrading to new release, otherwise they may stay
> behind. Regarding configurations, this goal can be achieved either
> keeping as much as possible backward compatibility for existing
> features, either providing (safe and thoroughly tested) conversion
> tools. But we have to be aware that slowly adding small configuration
> incompatibilities can sum up to require complex conversion tools, that
> nobody would develop and would become a bottleneck when releasing a new
> version.
>
> Open Source Communities can create better and smarter software than
> Commercial Companies, but the latter normally care more of existing
> "dumb" users: we should always try to reach a good compromise ;-) .
>
> Vincenzo
Well, I won't write conversion tools, so I preferred to remember your
ideas/suggestions when I thought at the proposed roadmap.
I personally prefer a "new feature that break backward compatibility"
than "no new feature" but we have a lot of stuff that can be done
without breaking backward compatibility.
I simply pointed out that what Noel and Vincenzo proposed to release was
already breaking assembly.xml compatiblity so only could try to achieve
config.xml compatibility (and storage compatibility) and at least Norman
and I always think at this issue when we implement/test new features.
I'm sure most of you already know this, but I rewrite it again for
Danny: my idea was that storage compatibility would have been enough,
with no conversion tools (that's what we did with 2.2.0 to 2.3.0), but
we are a community and I'm not as fanatic as someone could think.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map (Status Update)
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Danny Angus wrote:
> On 10/24/06, Stefano Bagnara <ap...@bago.org> wrote:
>
>> 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 ;-)
>
>
We just stressed the fact that life must be kept as much as possible
easy for users when upgrading to new release, otherwise they may stay
behind. Regarding configurations, this goal can be achieved either
keeping as much as possible backward compatibility for existing
features, either providing (safe and thoroughly tested) conversion
tools. But we have to be aware that slowly adding small configuration
incompatibilities can sum up to require complex conversion tools, that
nobody would develop and would become a bottleneck when releasing a new
version.
Open Source Communities can create better and smarter software than
Commercial Companies, but the latter normally care more of existing
"dumb" users: we should always try to reach a good compromise ;-) .
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Status file (Was: JAMES v2.4 Road Map)
Posted by Danny Angus <da...@gmail.com>.
Stefano,
In many ways I agree with you, but I still believe that som summary
information reported in a status file, along with a record of the
decisions needed, made and outstanding, will help *you* to do the
things you want to without frightening everyone else ;-)
> If we can agree on a standard workflow/usage of JIRA I would prefer it
> over a status file to be committed in svn. Often I update JIRA when I
> have no other access than http and I can't commit so I use that spare
> time to update/reorganize JIRA.
I don't think the two things are really the same, and I don't think
you would be expected to replace your use of JIRA with the status
file, which is more (IMO) of a summary of what the plan is, than a
detailed record of every task.
> Briefly: I'm +1 to increase the usage of JIRA also for our
> roadmap/status tracking. -0 on the introduction of a status file in svn.
Ok, I'll take this on board.
d
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Status file (Was: JAMES v2.4 Road Map)
Posted by Stefano Bagnara <ap...@bago.org>.
Hi Danny,
I extracted the status file related sentences from the previous message.
I think that the "in-progress" issues in JIRA already have the
informations you would like to add to the status file:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10411&status=3
In fact I would prefer to use JIRA for tasks, for roadmaps, and for
tracking.
Furthermore I also use the "Assignment" also for issues I'm not
currently working on, but I think I should be contacted before anyone
else approach the same problem:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?assigneeSelect=specificuser&sorter/field=priority&mode=hide&reset=true&resolution=-1&assignee=bago&pid=10411&sorter/order=DESC
You can see that I have DSN support, memory efficient retrieval, remote
delivery service and more: I worked on all of this, I probably have
almost working code for each one, but I'm not ready to discuss about all
the complications of committing them to trunk.
If we can agree on a standard workflow/usage of JIRA I would prefer it
over a status file to be committed in svn. Often I update JIRA when I
have no other access than http and I can't commit so I use that spare
time to update/reorganize JIRA.
I would be happy to be able to have a more clear roadmap about the next
release and I could update the current trunk roadmap:
https://issues.apache.org/jira/browse/JAMES?report=com.atlassian.jira.plugin.system.project:roadmap-panel
to remove some of the "UNRESOLVED" issues that we already know won't be
part of the next release.
E.g: there is no effort on the IPV6 side, so we could remove the ipv6
issues from that roadmap.
I often asked people to review that list and to say what they think
should be removed, what they think is a must, what they think is an option.
Briefly: I'm +1 to increase the usage of JIRA also for our
roadmap/status tracking. -0 on the introduction of a status file in svn.
Stefano
Danny Angus wrote:
> Stefano Bagnara 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 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map (Status Update)
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus wrote:
> 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 just saw that you didn't partecipate to this thread 1 month ago. You
should read it and maybe add your comments:
http://www.mail-archive.com/search?l=server-dev%40james.apache.org&q=JAMES+v2.4+Road+Map
I say this because I see you're asking for roadmaps, for issue list, for
discussions about that. I think that if you read the whole thread you
will notice that I tried to do this already 1 month ago.
We saw 2 different approaches, they was not one against the other but
simply 2 road maps. You can find many messages from me with no
replies... It was clear that I, Norman and Bernd shared a common goal,
so we simply started working on this one.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: VirtualHosting and VirtualUsersTable (Was: JAMES v2.4 Road Map)
Posted by Danny Angus <da...@gmail.com>.
On 10/24/06, Stefano Bagnara <ap...@bago.org> wrote:
> I would ask you one important thing: as you talk english better than me
> and you know Noel much more than me try to discuss the vhosting issue
> with Noel and let's see if both of you can at least agree on a common
> roadmap on this issue. Once you have this we can then see if this
> roadmap is acceptable to me and Norman (as we are the one that put their
> hands in the code until now on this issue).
>
> I just have too much problems understanding and accepting Noel replies
> to all of my message, so if you feel you can contribute on this I would
> be happy.
Sorry, I started *another* thread on this issue. I think I understand
Noel's position, it is similar to mine. No doubt he can disagree with
me if he wants to.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
VirtualHosting and VirtualUsersTable (Was: JAMES v2.4 Road Map)
Posted by Stefano Bagnara <ap...@bago.org>.
I extracted things related to VHosting from the roadmap thread, and my
only reply is at the end of this message.
Danny Angus wrote:
> 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.
>
>> 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.
I would ask you one important thing: as you talk english better than me
and you know Noel much more than me try to discuss the vhosting issue
with Noel and let's see if both of you can at least agree on a common
roadmap on this issue. Once you have this we can then see if this
roadmap is acceptable to me and Norman (as we are the one that put their
hands in the code until now on this issue).
I just have too much problems understanding and accepting Noel replies
to all of my message, so if you feel you can contribute on this I would
be happy.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Mailet APIs refactoring (Was: JAMES v2.4 Road Map)
Posted by Danny Angus <da...@gmail.com>.
Yeah OK
On 10/24/06, Stefano Bagnara <ap...@bago.org> wrote:
> Danny Angus wrote:
> > On 10/24/06, Stefano Bagnara <ap...@bago.org> wrote:
> >> If you can give some ideas about the refactoring you have in mind for
> >> mailet apis we can try to understand wether the goal is shared between
> >> committers and wether it worth altering the Server schedule based on the
> >> mailet apis release schedule.
> >
> > Probably the easiest way to communicate it is to do the work locally
> > and let you see the javadocs, I'll try to get it done before the 31st
>
> Or even better you could use a folder in the svn-sandbox, so we can
> see/track changes much more easily!
>
> Stefano
>
>
Re: Mailet APIs refactoring (Was: JAMES v2.4 Road Map)
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus wrote:
> On 10/24/06, Stefano Bagnara <ap...@bago.org> wrote:
>> If you can give some ideas about the refactoring you have in mind for
>> mailet apis we can try to understand wether the goal is shared between
>> committers and wether it worth altering the Server schedule based on the
>> mailet apis release schedule.
>
> Probably the easiest way to communicate it is to do the work locally
> and let you see the javadocs, I'll try to get it done before the 31st
Or even better you could use a folder in the svn-sandbox, so we can
see/track changes much more easily!
Stefano
Re: Mailet APIs refactoring (Was: JAMES v2.4 Road Map)
Posted by Danny Angus <da...@gmail.com>.
On 10/24/06, Stefano Bagnara <ap...@bago.org> wrote:
> If you can give some ideas about the refactoring you have in mind for
> mailet apis we can try to understand wether the goal is shared between
> committers and wether it worth altering the Server schedule based on the
> mailet apis release schedule.
Probably the easiest way to communicate it is to do the work locally
and let you see the javadocs, I'll try to get it done before the 31st
Mailet APIs refactoring (Was: JAMES v2.4 Road Map)
Posted by Stefano Bagnara <ap...@bago.org>.
About Mailet APIs refactoring Danny Angus wrote:
> On 10/24/06, Stefano Bagnara <ap...@bago.org> wrote:
>> 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.
> [...]
>> 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.
If you can give some ideas about the refactoring you have in mind for
mailet apis we can try to understand wether the goal is shared between
committers and wether it worth altering the Server schedule based on the
mailet apis release schedule.
>> 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.
And I'm very *VERY* happy for this!
Stefano
Re: JAMES v2.4 Road Map (Status Update)
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Norman Maurer wrote:
> Vincenzo Gianferrari Pini schrieb:
>
>> Danny Angus wrote:
>>
>>> On 10/24/06, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>>
>>>> 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 ;-)
>>>
>>>
>>>
>> We just stressed the fact that life must be kept as much as possible
>> easy for users when upgrading to new release, otherwise they may stay
>> behind. Regarding configurations, this goal can be achieved either
>> keeping as much as possible backward compatibility for existing
>> features, either providing (safe and thoroughly tested) conversion
>> tools. But we have to be aware that slowly adding small configuration
>> incompatibilities can sum up to require complex conversion tools, that
>> nobody would develop and would become a bottleneck when releasing a
>> new version.
>>
>> Open Source Communities can create better and smarter software than
>> Commercial Companies, but the latter normally care more of existing
>> "dumb" users: we should always try to reach a good compromise ;-) .
>>
>> Vincenzo
>>
>
> Thats right but with no new features we will loose users and not get
> new.. I think we just need to document what to change in config.xml. I
> allready add an UPGRADING.txt to the 2.3 branch. If we add some new
> feature which need things the get changed in config.xml we just should
> document it in a UPGRADING.txt
>
The right thing to do would be to keep UPGRADING.txt up to date *as soon
as the related code change is done*, so the documentation is fresh and
rich. Doing it just before releasing would be less effective, because
things tend to be forgotten :-) .
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map (Status Update)
Posted by Norman Maurer <nm...@byteaction.de>.
Vincenzo Gianferrari Pini schrieb:
> Norman Maurer wrote:
>> Vincenzo Gianferrari Pini schrieb:
>>
>>> Danny Angus wrote:
>>>
>>>> On 10/24/06, Stefano Bagnara <ap...@bago.org> wrote:
>>>>
>>>>
>>>>> 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 ;-)
>>>>
>>>>
>>>>
>>> We just stressed the fact that life must be kept as much as possible
>>> easy for users when upgrading to new release, otherwise they may stay
>>> behind. Regarding configurations, this goal can be achieved either
>>> keeping as much as possible backward compatibility for existing
>>> features, either providing (safe and thoroughly tested) conversion
>>> tools. But we have to be aware that slowly adding small configuration
>>> incompatibilities can sum up to require complex conversion tools, that
>>> nobody would develop and would become a bottleneck when releasing a
>>> new version.
>>>
>>> Open Source Communities can create better and smarter software than
>>> Commercial Companies, but the latter normally care more of existing
>>> "dumb" users: we should always try to reach a good compromise ;-) .
>>>
>>> Vincenzo
>>>
>>
>> Thats right but with no new features we will loose users and not get
>> new.. I think we just need to document what to change in config.xml. I
>> allready add an UPGRADING.txt to the 2.3 branch. If we add some new
>> feature which need things the get changed in config.xml we just should
>> document it in a UPGRADING.txt
>>
> The right thing to do would be to keep UPGRADING.txt up to date *as
> soon as the related code change is done*, so the documentation is
> fresh and rich. Doing it just before releasing would be less
> effective, because things tend to be forgotten :-) .
>
> Vincenzo
>
+1
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map (Status Update)
Posted by Norman Maurer <nm...@byteaction.de>.
Vincenzo Gianferrari Pini schrieb:
> Danny Angus wrote:
>> On 10/24/06, Stefano Bagnara <ap...@bago.org> wrote:
>>
>>> 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 ;-)
>>
>>
> We just stressed the fact that life must be kept as much as possible
> easy for users when upgrading to new release, otherwise they may stay
> behind. Regarding configurations, this goal can be achieved either
> keeping as much as possible backward compatibility for existing
> features, either providing (safe and thoroughly tested) conversion
> tools. But we have to be aware that slowly adding small configuration
> incompatibilities can sum up to require complex conversion tools, that
> nobody would develop and would become a bottleneck when releasing a
> new version.
>
> Open Source Communities can create better and smarter software than
> Commercial Companies, but the latter normally care more of existing
> "dumb" users: we should always try to reach a good compromise ;-) .
>
> Vincenzo
Thats right but with no new features we will loose users and not get
new.. I think we just need to document what to change in config.xml. I
allready add an UPGRADING.txt to the 2.3 branch. If we add some new
feature which need things the get changed in config.xml we just should
document it in a UPGRADING.txt
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map (Status Update)
Posted by Danny Angus <da...@gmail.com>.
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 <ap...@bago.org> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map (Status Update)
Posted by Danny Angus <da...@gmail.com>.
Norman,
(I seem to have missed alot of mail, and got it all in one batch!)
I've replied about vhosting in a new thread,
> I think the most problems of people are that they fear to "break"
> james.. But why we should fear with new junit tests :-P
This is true, but it is also true that some proposals take longer and
have more impact, its not *just* about breaking James, but also about
blocking the project.
We have had some bad blocks in the past.
> > 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
Ok :-)
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map (Status Update)
Posted by Norman Maurer <nm...@byteaction.de>.
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 <ap...@bago.org> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map (Status Update)
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
>>> My proposal is:
>>> - everything we have in trunk now: now I can't see anything critical
>>> enough to be removed.
>
>> Well, this was already there ;-)
>
> Release planning by fiat? I think that we would have to be INSANE to
> release trunk as JAMES v2.4!
1) This was not a relase planning, it was a status update on what we did.
2) I don't mind being INSANE.
3) I never said we should release trunk as 2.4: I said we should branch
from trunk the release I called "next-major" and that we should start
working on stabilization for a release in the branch.
> More to come. And, no, I am not just reading this now. I have been reading
> it all every day, and getting angrier every day. Since I don't seem to be
> getting less angry about what I am reading, I might as well start replying.
>
> --- Noel
If you're angry for something concrete please write your concern, if
you're angry because something in my message was unclear give me more
details and I would be happy to provide more informations. If you're
angry because you didn't find slaves to work on your personal goals,
then I can't help with this ;-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: JAMES v2.4 Road Map (Status Update)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > My proposal is:
> > - everything we have in trunk now: now I can't see anything critical
> > enough to be removed.
> Well, this was already there ;-)
Release planning by fiat? I think that we would have to be INSANE to
release trunk as JAMES v2.4!
More to come. And, no, I am not just reading this now. I have been reading
it all every day, and getting angrier every day. Since I don't seem to be
getting less angry about what I am reading, I might as well start replying.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map (Status Update)
Posted by Bernd Fondermann <be...@googlemail.com>.
Hi guys,
so much words again for so few information, and not always fun to read.
anyway, a few very short takes from me to let you know what my preferences are:
Working on trunk towards 3.0: +1
Supporting old configuration in future versions: +1
Working on 2.4 by backporting stuff: +0
Using misleading mail subjects: -1
Using CAPS-LOCK when writing mail: -1
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map (Status Update)
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi Bernd,
this is *the best* Mail I read on this thread !!!
Kind regards
Juergen
Bernd Fondermann schrieb:
> Hi guys,
>
> so much words again for so few information, and not always fun to read.
>
> anyway, a few very short takes from me to let you know what my
> preferences are:
>
> Working on trunk towards 3.0: +1
> Supporting old configuration in future versions: +1
> Working on 2.4 by backporting stuff: +0
>
> Using misleading mail subjects: -1
> Using CAPS-LOCK when writing mail: -1
>
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
> !EXCUBATOR:1,454051c953079300313603!
RE: JAMES v2.4 Road Map (Status Update)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano wrote:
> Noel wrote:
>> Stefano Bagnara wrote:
>>> I don't agree with your version numbers, but if you can read my message
>>> you will find that I never talked about 2.4 or 3.0
>> See the subject header.
> Then now that I explained you that it was not related to 2.4 you can
> read it again and give your real reply.
Yes, that makes a very big difference. More later, but yes, this makes a
very big difference now that we are closer to being on the same page.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map (Status Update)
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
>> I don't know what's the problem with you.
>> And I don't know the meaning of "decision by message volume".
>
> See Steve Brewin's e-mail.
>
>> I don't agree with your version numbers, but if you can read my message
>> you will find that I never talked about 2.4 or 3.0
>
> See the subject header.
>
> --- Noel
Then now that I explained you that it was not related to 2.4 you can
read it again and give your real reply.
I replied to the message without changing the subject because we kept
that subject for a month and we already talked about every version
number we could think of. Of course feel free to change the subject if
you think you have a better one.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: JAMES v2.4 Road Map (Status Update)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I don't know what's the problem with you.
> And I don't know the meaning of "decision by message volume".
See Steve Brewin's e-mail.
> I don't agree with your version numbers, but if you can read my message
> you will find that I never talked about 2.4 or 3.0
See the subject header.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map (Status Update)
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
>> Slightly more than a month ago I wrote a roadmap, here is an update for
>> people that has not time for a day to day oversight.
>
> And I disagreed with you then, and so did others, and I am really getting
> tired of decision by message volume. I don't believe that I am alone in
> that sentiment.
I don't know what's the problem with you.
And I don't know the meaning of "decision by message volume".
My message was simply a status update on a set of features I proposed 1
month ago to be included in what I called "next-major" release. Active
committers did some progress so I decided to give an update.
I don't understand what exactly you "disagree".
> Trunk should be JAMES v3.0. No major concerns at the moment to discuss.
> JAMES v2.4 should be incremental changes to the newly released JAMES v2.3.
> We can even release concurrently, supporting JAMES v2 and JAMES v3 for as
> long as we need the need.
I don't agree with your version numbers, but if you can read my message
you will find that I never talked about 2.4 or 3.0, I simply updated a
list of issues I described in a previous post and I left the subject
unchanged.
I just started a vote to have a better overview on what we can do about
next-minor and next-major.
We'll vote for the numbers later.
> Ironically, to comment on an old claim, most of what I want to work on is
> for JAMES v3, but we still need to support our existing user base.
>
> --- Noel
As you proposed the "next-minor" (branch 2.3 and add backport few
features from 2.4) please feel free to write the same status update for
this goal.
I simply did my duties.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: JAMES v2.4 Road Map (Status Update)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Slightly more than a month ago I wrote a roadmap, here is an update for
> people that has not time for a day to day oversight.
And I disagreed with you then, and so did others, and I am really getting
tired of decision by message volume. I don't believe that I am alone in
that sentiment.
Trunk should be JAMES v3.0. No major concerns at the moment to discuss.
JAMES v2.4 should be incremental changes to the newly released JAMES v2.3.
We can even release concurrently, supporting JAMES v2 and JAMES v3 for as
long as we need the need.
Ironically, to comment on an old claim, most of what I want to work on is
for JAMES v3, but we still need to support our existing user base.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org