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 Bernd Fondermann <be...@googlemail.com> on 2006/12/16 08:50:35 UTC
Re: Roadmap again
Hi,
On 12/14/06, Norman <nm...@spam-box.de> wrote:
> Hi commiters,
>
> its now about 4 weeks ago when Stefano and me posted a roadmap proposal
> to the mailling list. Nothing concrete happen since this posting. I
> really whould like to get this odd roadmap stuff done now to focus on
> working on the next release. Without the roadmap it is impossible for me
> to help the project and work on concrete things.
> So what the stuff other people want to see in next release ? Is the
> proposed stuff ok ?
For the next release I would like to
+ have basic (whatever than means) IMAP stable, perfoming and
functional, and well integrated with the rest of James architecture.
+ have more online management and monitoring features done
+ have a Spring distribution besides the other packages
> I whould also like to focus on a branch date. Maybe branch in 2/2007 ?
I would rather not call for a "branch date", but focus on "feature
freeze" and "release" dates.
Branching is just a technical thing which can be completely omitted if
we release from trunk.
And I would like to have us release from trunk, because it keeps us
focused on testing and finalizing.
Would a release target date end of Q2/Y07 be OK?
> I hope this start no new "war". I just want to work on something
> concrete. So please help me and james ;-)
HTH :-)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Roadmap again
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin wrote:
> JAMES is a complex, mature application but now contains many youthful
> components. perhaps these new components would benefit from a quicker
> release cycle than the main application.
>
> perhaps it might be worth considering decoupling the spring support
> from the normal james release cycle for at least a little while. this
> would allow the spring component to be released more regularly with
> the normal james release picking up and bundling the latest release of
> the component.
>
> perhaps this may be approach may be worth considering as well for
> other developing capabilities such as IMAP and OpenPGP/SMIME support.
Hi Robert,
I don't think this would help James. If we have an updated spring
support or an advanced IMAP or OpenPGP/SMIME support we think deserve a
release we can should not fear making a new full release.
That said, on the other side, I would be in favor of a multi-module
factoring using maven2: this would be a first step to have different
lifecycles for components.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Roadmap again
Posted by robert burrell donkin <ro...@gmail.com>.
On 12/16/06, Norman <nm...@spam-box.de> wrote:
<snip>
> >> + have a Spring distribution besides the other packages
> >>
> >
> > Let's do it! :-)
> >
> >
>
> If im not wrong then there is allready a sandbox on which joachim is workin.
JAMES is a complex, mature application but now contains many youthful
components. perhaps these new components would benefit from a quicker
release cycle than the main application.
perhaps it might be worth considering decoupling the spring support
from the normal james release cycle for at least a little while. this
would allow the spring component to be released more regularly with
the normal james release picking up and bundling the latest release of
the component.
perhaps this may be approach may be worth considering as well for
other developing capabilities such as IMAP and OpenPGP/SMIME support.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Roadmap again
Posted by Norman <nm...@spam-box.de>.
Hi guys,
Joachim Draeger schrieb:
> Hi Bernd,
>
> Am Samstag, den 16.12.2006, 08:50 +0100 schrieb Bernd Fondermann:
>
>
>>> its now about 4 weeks ago when Stefano and me posted a roadmap proposal
>>> to the mailling list. Nothing concrete happen since this posting. I
>>> really whould like to get this odd roadmap stuff done now to focus on
>>> working on the next release. Without the roadmap it is impossible for me
>>> to help the project and work on concrete things.
>>> So what the stuff other people want to see in next release ? Is the
>>> proposed stuff ok ?
>>>
>> For the next release I would like to
>> + have basic (whatever than means) IMAP stable, perfoming and
>> functional, and well integrated with the rest of James architecture.
>>
>
> That would introduce probably some incompatibility. I'm fine with this
> if there is a majority.
> I always try to let the new stuff run beside the old one without
> changing anything. I work this way only because I see it as problematic
> in this project to introduce big changes.
>
>
>> + have more online management and monitoring features done
>>
>
> Yes, that is very important and will broaden significantly the target
> group.
> Be transparent and less cryptic.
>
>
+1
>> + have a Spring distribution besides the other packages
>>
>
> Let's do it! :-)
>
>
If im not wrong then there is allready a sandbox on which joachim is workin.
>>> I whould also like to focus on a branch date. Maybe branch in 2/2007 ?
>>>
>> I would rather not call for a "branch date", but focus on "feature
>> freeze" and "release" dates.
>> Branching is just a technical thing which can be completely omitted if
>> we release from trunk.
>>
>
> There seemed to be a consensus that the next release should be
> config/storage compatible. This compatibility limits the introducing of
> new features.
> If we want to have a compatible release we IMO need the branch to be
> able to work on non compatible features in trunk while stabilizing the
> branch.
> You seem to favor a non-compatible release. (So do I and some others
> that saw the compatible one as a compromise)
> In this case I agree with you that we should continue working in trunk
> and decide later whether a branch is needed or not.
>
I agree with you.. But if we want to break compatibility we should do
it carefully so no further compatibilily changes have to be done in near
future.
> Well, as the last approach has been beaten down that unkind, (which
> still makes me very sad) we need possibly a new vote for a direction.
>
> James often makes the impression to me to be headless and indecisive.
> That makes me feel unsure and uncomfortable if this is the right place
> for my open source work. Too much energy gets wasted. For me this is
> some kind of a last chance before I will draw the conclusions.
>
> I appeal to the James community and to the PMC to make again all
> assiduous efforts to come out of this mess. Something has to change
> right now.
>
I agree. We have to change something... The first things we have to do
now is:
* Define if the next release should be compatible or not
* Define a clear roadmap
* Define a version number ( not so importent for me , but it seems its
importent for others)
* Define feature freeze date/ branch date / release date
After that i hope we all can focus and work on concrete stuff.
>
>> And I would like to have us release from trunk, because it keeps us
>> focused on testing and finalizing.
>>
>> Would a release target date end of Q2/Y07 be OK?
>>
>
> This is one of the options I can agree on. Because it's quite a long
> period we could maybe introduce milestones. We are all voluntaries, no
> one will force us to meet deadlines.
> But clear targets are important for humans. So yes, define a release
> date, and maybe dates for alpha and beta releases. We are free to change
> them whenever we think it's reasonable.
>
+1
> Joachim
>
>
>
>
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Roadmap again
Posted by Joachim Draeger <jd...@joachim-draeger.de>.
Hi Bernd,
Am Samstag, den 16.12.2006, 08:50 +0100 schrieb Bernd Fondermann:
> > its now about 4 weeks ago when Stefano and me posted a roadmap proposal
> > to the mailling list. Nothing concrete happen since this posting. I
> > really whould like to get this odd roadmap stuff done now to focus on
> > working on the next release. Without the roadmap it is impossible for me
> > to help the project and work on concrete things.
> > So what the stuff other people want to see in next release ? Is the
> > proposed stuff ok ?
>
> For the next release I would like to
> + have basic (whatever than means) IMAP stable, perfoming and
> functional, and well integrated with the rest of James architecture.
That would introduce probably some incompatibility. I'm fine with this
if there is a majority.
I always try to let the new stuff run beside the old one without
changing anything. I work this way only because I see it as problematic
in this project to introduce big changes.
> + have more online management and monitoring features done
Yes, that is very important and will broaden significantly the target
group.
Be transparent and less cryptic.
> + have a Spring distribution besides the other packages
Let's do it! :-)
> > I whould also like to focus on a branch date. Maybe branch in 2/2007 ?
>
> I would rather not call for a "branch date", but focus on "feature
> freeze" and "release" dates.
> Branching is just a technical thing which can be completely omitted if
> we release from trunk.
There seemed to be a consensus that the next release should be
config/storage compatible. This compatibility limits the introducing of
new features.
If we want to have a compatible release we IMO need the branch to be
able to work on non compatible features in trunk while stabilizing the
branch.
You seem to favor a non-compatible release. (So do I and some others
that saw the compatible one as a compromise)
In this case I agree with you that we should continue working in trunk
and decide later whether a branch is needed or not.
Well, as the last approach has been beaten down that unkind, (which
still makes me very sad) we need possibly a new vote for a direction.
James often makes the impression to me to be headless and indecisive.
That makes me feel unsure and uncomfortable if this is the right place
for my open source work. Too much energy gets wasted. For me this is
some kind of a last chance before I will draw the conclusions.
I appeal to the James community and to the PMC to make again all
assiduous efforts to come out of this mess. Something has to change
right now.
> And I would like to have us release from trunk, because it keeps us
> focused on testing and finalizing.
>
> Would a release target date end of Q2/Y07 be OK?
This is one of the options I can agree on. Because it's quite a long
period we could maybe introduce milestones. We are all voluntaries, no
one will force us to meet deadlines.
But clear targets are important for humans. So yes, define a release
date, and maybe dates for alpha and beta releases. We are free to change
them whenever we think it's reasonable.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Roadmap again
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
> For the next release I would like to
> + have basic (whatever than means) IMAP stable, perfoming and
> functional, and well integrated with the rest of James architecture.
> + have more online management and monitoring features done
> + have a Spring distribution besides the other packages
>
>> I whould also like to focus on a branch date. Maybe branch in 2/2007 ?
>
> I would rather not call for a "branch date", but focus on "feature
> freeze" and "release" dates.
I admit I considered "branch date" = "feature freeze date".
> Branching is just a technical thing which can be completely omitted if
> we release from trunk.
> And I would like to have us release from trunk, because it keeps us
> focused on testing and finalizing.
-1: people would start head sandboxes and this is not better than having
a release branch. v2.3 proved us that working on new features on trunk
we found a lot of bugs that was in v2.3 (waiting or avoid work on other
folders does not make a codebase more solid).
> Would a release target date end of Q2/Y07 be OK?
When do you propose to feature freeze to achieve the Q2 release date?
----
And here was the long one for people with more time:
Unfortunately we can only tune the branch date because we control this
event, but we have not the same degree of control on the release date:
imho we can define when we branch, bug reports, bug investigation, bug
resolutions will instead define the real release date. We can try to
estimate it but it is much more easy to speak about branch (feature
freeze) dates.
And yes, when I say "branch for release" I mean feature freezing. New
features will go in trunk, and we branched to consolidate. Imho when we
declare feature freezing we HAVE TO branch. We have 2 options:
consolidate the feature freezed code in the branch, or switch "head"
development to another branch to be merged once released. I prefer the
first. I'm sorry I took this as a fact because I saw we did this way in
past. If we want to change I'm not completely against the second option.
I'm instead against feature freezing without branching, because this
would mean completely stop any other parallel activity while
consolidating trunk (waste of contributor time).
Back on topic: What plan do you propose to try to release by end Q2?
When to feature freeeze? What kind of backward compatibility? What
"major" features to include? E.g: Would you accept a new mailet api
inside this release? Would you include a big spoolmanager change? Would
you include major refactorings?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org