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 "Noel J. Bergman" <no...@devtech.com> on 2002/10/27 09:14:54 UTC
Release Plan v2.1
No, this is not the release plan. :-) Just a step in getting back to it.
Peter, would you please revise and post the 2.1 release plan? :-)
Previous:
http://www.mail-archive.com/james-dev@jakarta.apache.org/msg03743.html
As I understand it, and confirmed with Harmeet, so far we have (lazy)
consensus on the CVS commits.
- AuthService will stay gone unless resurrected
in the unlikely event of someone with a need.
- Harmeet will post up his Scheduler when ready,
but we're not holding up for it. I'll put in
the hooks to be ready (plus they clean up the
Server subclasses).
- I have a couple of matchers that I am working
on, but I don't see any reason to push them
into the build unless other folks want them
now. One is a regex matcher that loads the
regex patterns from a file specified in the
matcher config. I'm using it, but it is a
very simple thing, and doesn't have all of
the features I want to add.
So basically, I'm not aware of any reason not to declare the CVS feature
complete and move into the testing phase. It would be nice to update to
Phoenix 4.0.1, so that we have the correct log handling, plus they added a
fix for a thread pooling problem we reported.
I'm available for the coming week, then I'll rather unavailable while at
Software Summit (www.softwaresummit.com), so I'd like to contribute what I
can between now and then.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1
Posted by "Noel J. Bergman" <no...@devtech.com>.
Nico,
> I'm willing to help you setup the site using Forrest
> http://xml.apache.org/forrest/.
Thanks for the offer. :-)
As it happens, I just spent a week at Colorado Software Summit with a friend
from Australia, Dion Gillard, who is a Maven Committer. It appears to us
that perhaps the best solution, both technically and politically,
*post-release* might be to adopt a combination of Maven and Forrest.
Obviously, any change in the build process will require discussion and
consensus here on the james-dev mailing list, but as with Peter, I'd
certainly like to avoid the Build Tool Wars, so hopefully that sort of
approach would meet with everyone's approval. Danny seems to like Maven,
and from what Dion has said, it should address build related issues that
Peter has commented upon, as well as provide a nice end-user install
mechanism for optional packages (e.g., optional matcher/mailet sets) in the
James v3 timeframe.
> I will make a Forrest version of the site myself then with no
> time-constraint, and post here the link to the ongoing effort.
I look forward to seeing it. :-)
Dion has also offered to help the James project convert over to Maven
(again, post-release) *IF* that is what we decide to do, so hopefully the
two of you combined would be able to help us realize the best of both
worlds, again depending upon our project's consensus. Consensus and
collaboration are generally far more agreeable ways of doing things than the
alternatives.
In any event, I don't expect that there is really much to do about this now
other than discuss post-release options.
FYI, I am still on the road, so my connectivity will be spotty for another
few days.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Modifing timers and James delivery speed
Posted by Hontvari Jozsef <ho...@solware.com>.
As I remember there is no one minute delay normally. But I experienced the
same thing when I misconfigured James somehow. Maybe I wrote an email about
this, you may look for it.
It is vey easy to misconfigure james, actually it did happen all 4-5 cases
when I modified something, but the usual result is 100% processor usage not
delays.
----- Original Message -----
From: "Jason Webb" <jw...@inovem.com>
To: "'James Developers List'" <ja...@jakarta.apache.org>;
<ni...@apache.org>
Sent: Thursday, November 07, 2002 3:37 PM
Subject: Modifing timers and James delivery speed
> I'd like to change the time the spoolmanager runs at. At the moment it
> seems to be about once a minute. No matter what I changed in the
> james-config.xml file it seems to make no difference. The reason for
> doing this is to make James deliver mail faster, and I feel that
> tweaking the number of spool manager threads is less than ideal. Is
> there a particular config that was used to maximised throughput when the
> stress and load tests were being performed?
>
> What I'd ideally like to do is expose this in the config file so I can
> change it when I need to.
>
> Help?
>
> -- Jason
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Modifing timers and James delivery speed
Posted by Jason Webb <jw...@inovem.com>.
I'd like to change the time the spoolmanager runs at. At the moment it
seems to be about once a minute. No matter what I changed in the
james-config.xml file it seems to make no difference. The reason for
doing this is to make James deliver mail faster, and I feel that
tweaking the number of spool manager threads is less than ideal. Is
there a particular config that was used to maximised throughput when the
stress and load tests were being performed?
What I'd ideally like to do is expose this in the config file so I can
change it when I need to.
Help?
-- Jason
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release Plan v2.1
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter M. Goldstein wrote:
> Nicola,
>
> While I appreciate the offer, I don't think now is the time. The idea
> of being drawn into the web site creation tool argument that plagues the
> Avalon-dev list from time to time is a personal nightmare.
We are drawing now to a conclusion on this, by using Forrest (finally!).
> It would
> certainly kill any chance of meeting the proposed release schedule.
Hmmm, I wouldn't want it to happen.
> This rev will use the currently employed tool in the James build. I
> don't even know exactly what we're using, but whatever it is is what
> we'll be using through this release. Output documentation will be in
> the form of a few simple linked HTML pages.
I understand your concerns about making a new release, and as a James
user I can only agree (ie pleeeaseeee ;-)
I will make a Forrest version of the site myself then with no
time-constraint, and post here the link to the ongoing effort.
In the meantime, you all just work with just the release in mind, and
when time to evaluate the new system comes, it will come.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Nicola,
While I appreciate the offer, I don't think now is the time. The idea
of being drawn into the web site creation tool argument that plagues the
Avalon-dev list from time to time is a personal nightmare. It would
certainly kill any chance of meeting the proposed release schedule.
This rev will use the currently employed tool in the James build. I
don't even know exactly what we're using, but whatever it is is what
we'll be using through this release. Output documentation will be in
the form of a few simple linked HTML pages.
--Peter
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Monday, November 04, 2002 11:34 PM
> To: James Developers List
> Subject: Re: Release Plan v2.1
>
>
> Alan Gerhard wrote:
> >
> > -----Original Message-----
> >
> >>iv) Produce a consistent documentation package for the 2.1 version
that
> >>details the product services, as well as the basic steps of
installation
> >>and configuration.
> >
> >
> > what is the current state of this document package, I mean are we
> looking at
> > generating a whole new set and if so, based on a particular format
??
>
> I'm willing to help you setup the site using Forrest
> http://xml.apache.org/forrest/ .
>
> It gives you automatic PDFs for every page, it's skinnable (we're
almost
> ready to have a skin like the one used on the avalon site, thanks to
> Peter Donald) and you can now edit the pages and see the result in
> realtime in the browser since we include the Jetty server in the
distro.
>
> Examples:
>
> xml.apache.org/forrest
> incubator.apache.org
> xml.apache.org
>
> Coming soon:
>
> XIndice
> Cocoon
> FOP
> Apache Commons
> POI
> other xml.apache projects
> etc...
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail: <mailto:james-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release Plan v2.1
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Alan Gerhard wrote:
>
> -----Original Message-----
>
>>iv) Produce a consistent documentation package for the 2.1 version that
>>details the product services, as well as the basic steps of installation
>>and configuration.
>
>
> what is the current state of this document package, I mean are we looking at
> generating a whole new set and if so, based on a particular format ??
I'm willing to help you setup the site using Forrest
http://xml.apache.org/forrest/ .
It gives you automatic PDFs for every page, it's skinnable (we're almost
ready to have a skin like the one used on the avalon site, thanks to
Peter Donald) and you can now edit the pages and see the result in
realtime in the browser since we include the Jetty server in the distro.
Examples:
xml.apache.org/forrest
incubator.apache.org
xml.apache.org
Coming soon:
XIndice
Cocoon
FOP
Apache Commons
POI
other xml.apache projects
etc...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1
Posted by Alan Gerhard <al...@GerCom.Com>.
-----Original Message-----
> iv) Produce a consistent documentation package for the 2.1 version that
> details the product services, as well as the basic steps of installation
> and configuration.
what is the current state of this document package, I mean are we looking at
generating a whole new set and if so, based on a particular format ??
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release Plan v2.1
Posted by Serge Knystautas <se...@lokitech.com>.
Peter M. Goldstein wrote:
> iv) Produce a consistent documentation package for the 2.1 version that
> details the product services, as well as the basic steps of installation
> and configuration.
I'm pretty sure the LDAP user repository isn't working as I think we
changed the user repository a while ago and LDAP never really got
working with it. If that is the case, we should mark it as such across
the docs.
Looks great otherwise. I look forward to using the milestone build.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1
Posted by Danny Angus <da...@apache.org>.
> I'd love to. As I said in my earlier email, I don't have write access
> to the web site so I can't post a release candidate. Hoping to get
> Danny to do it...
Yeah I'll do it, tomorrow probably.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Noel,
> Two config file items:
>
> 1) Add Danny's patch to sqlResources.xml (and document it for
existing
> databases)
> 2) Increase number of max db connections
>
> I would certainly do #1. #2 already has a comment telling people to
> increase it, but I'd still consider increasing the default from 10 to
20,
> since 20 was able to support stress testing with 20 clients and 10
spool
> workers.
Agreed. Will roll in by EOD.
> I would immediately put out a milestone build for all parties willing
to
> act
> as test sites. Consider it a release candidate.
I'd love to. As I said in my earlier email, I don't have write access
to the web site so I can't post a release candidate. Hoping to get
Danny to do it...
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1
Posted by "Noel J. Bergman" <no...@devtech.com>.
Peter,
Two config file items:
1) Add Danny's patch to sqlResources.xml (and document it for existing
databases)
2) Increase number of max db connections
I would certainly do #1. #2 already has a comment telling people to
increase it, but I'd still consider increasing the default from 10 to 20,
since 20 was able to support stress testing with 20 clients and 10 spool
workers.
I would immediately put out a milestone build for all parties willing to act
as test sites. Consider it a release candidate.
--- Noel
-----Original Message-----
From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
Sent: Saturday, November 02, 2002 18:58
To: 'James Developers List'
Subject: RE: Release Plan v2.1
All,
Well, here's my suggested scheduler for release 2.1, given the
developments to this point. Let me first summarize what we've gotten
done, then what remains to be done before release, and then lay out the
schedule I think is realistic.
We have, at this point, achieved all the code specific goals discussed
in the release plan of September 28th. We have replaced the
ConnectionHandler infrastructure, addressed the TimeScheduler issue, and
closed all the code specific bugs in item #4 of the earlier release
plan. We have also made a number of substantial performance and memory
usage improvements over the last month, as well as bringing the NNTP
server into better agreement with the specification. We've upgraded our
distribution to Phoenix 4.0.1, resolving the logging bug. The javadocs
have also been brought up to speed. As far as I can tell, there are no
outstanding code items required for 2.1. So I'd like to declare code
freeze for this version.
Documentation and testing comprise the bulk of the remaining work. We
still need to carry out the following documentation tasks:
i) Document the configuration files in toto. Format the documentation
consistently, as well as vet it for correctness.
ii) Document the top 5 items on the TODO list
iii) Add FetchPOP documentation
iv) Produce a consistent documentation package for the 2.1 version that
details the product services, as well as the basic steps of installation
and configuration.
Build tasks:
i) Build a milestone build for testing.
ii) Adjust the CVS to allow future maintenance of the 2.1 branch while
permitting radical change for the 3.0 revision.
Testing tasks:
i) Run general tests on a variety of platforms. We've already done a
great deal of testing on both Windows and Linux platforms, but it would
be good to get a great deal more testing done before the official
release. We should look to our user base for potential testers.
ii) Test TLS support for POP3 and update the status from experimental to
stable.
Marketing tasks:
i) Produce a press release for distribution through channels announcing
both the release of 2.1 and inviting developers to participate in
version 3.0.
ii) Distribute this release through channels (i.e. Slashdot)
iii) Ensure that we are listed on common sites that provide lists of
available mail/news servers.
I'm working on items i, ii, and iv on the documentation task list, as
well as items i and iii on the marketing task list. Anyone who wants to
step up for any of the other items, please do. I'd like to ask Danny
specifically to address the milestone build issue, since he has write
access to the web site. If he can get me such write access, I'd be
happy to build and post the milestone build.
Here's my desired schedule:
November 4th, 2002 - Creation and posting of milestone build
November 4th-17th, 2002 - Testing period. Aggressive testing of James
under a variety of conditions.
November 8th, 2002 - Documentation freeze, which requires completion of
all documentation tasks.
November 15th, 2002 - Completion of press release, list of sites to
which the release needs to be distributed. Mail server info sites
should be updated with links at this point.
November 18th, 2002 - Release. Update of web site to reflect newly
released version. Distribution of press release to sites should be
completed immediately after release.
How does this sound to everyone? Danny, what are your thoughts on
making a milestone build?
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
One more item that I left off the list -
Build Tasks:
iii) Updating the changelog to reflect the changes in version 2.1
I'm taking care of this one as well.
--Peter
> -----Original Message-----
> From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
> Sent: Saturday, November 02, 2002 3:58 PM
> To: 'James Developers List'
> Subject: RE: Release Plan v2.1
>
>
> All,
>
> Well, here's my suggested scheduler for release 2.1, given the
> developments to this point. Let me first summarize what we've gotten
> done, then what remains to be done before release, and then lay out
the
> schedule I think is realistic.
>
> We have, at this point, achieved all the code specific goals discussed
> in the release plan of September 28th. We have replaced the
> ConnectionHandler infrastructure, addressed the TimeScheduler issue,
and
> closed all the code specific bugs in item #4 of the earlier release
> plan. We have also made a number of substantial performance and
memory
> usage improvements over the last month, as well as bringing the NNTP
> server into better agreement with the specification. We've upgraded
our
> distribution to Phoenix 4.0.1, resolving the logging bug. The
javadocs
> have also been brought up to speed. As far as I can tell, there are
no
> outstanding code items required for 2.1. So I'd like to declare code
> freeze for this version.
>
> Documentation and testing comprise the bulk of the remaining work. We
> still need to carry out the following documentation tasks:
>
> i) Document the configuration files in toto. Format the documentation
> consistently, as well as vet it for correctness.
>
> ii) Document the top 5 items on the TODO list
>
> iii) Add FetchPOP documentation
>
> iv) Produce a consistent documentation package for the 2.1 version
that
> details the product services, as well as the basic steps of
installation
> and configuration.
>
> Build tasks:
>
> i) Build a milestone build for testing.
>
> ii) Adjust the CVS to allow future maintenance of the 2.1 branch while
> permitting radical change for the 3.0 revision.
>
> Testing tasks:
>
> i) Run general tests on a variety of platforms. We've already done a
> great deal of testing on both Windows and Linux platforms, but it
would
> be good to get a great deal more testing done before the official
> release. We should look to our user base for potential testers.
>
> ii) Test TLS support for POP3 and update the status from experimental
to
> stable.
>
> Marketing tasks:
>
> i) Produce a press release for distribution through channels
announcing
> both the release of 2.1 and inviting developers to participate in
> version 3.0.
>
> ii) Distribute this release through channels (i.e. Slashdot)
>
> iii) Ensure that we are listed on common sites that provide lists of
> available mail/news servers.
>
> I'm working on items i, ii, and iv on the documentation task list, as
> well as items i and iii on the marketing task list. Anyone who wants
to
> step up for any of the other items, please do. I'd like to ask Danny
> specifically to address the milestone build issue, since he has write
> access to the web site. If he can get me such write access, I'd be
> happy to build and post the milestone build.
>
> Here's my desired schedule:
>
> November 4th, 2002 - Creation and posting of milestone build
>
> November 4th-17th, 2002 - Testing period. Aggressive testing of James
> under a variety of conditions.
>
> November 8th, 2002 - Documentation freeze, which requires completion
of
> all documentation tasks.
>
> November 15th, 2002 - Completion of press release, list of sites to
> which the release needs to be distributed. Mail server info sites
> should be updated with links at this point.
>
> November 18th, 2002 - Release. Update of web site to reflect newly
> released version. Distribution of press release to sites should be
> completed immediately after release.
>
> How does this sound to everyone? Danny, what are your thoughts on
> making a milestone build?
>
> --Peter
>
>
>
> --
> To unsubscribe, e-mail: <mailto:james-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1 (update)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Peter,
> > iii) Add FetchPOP documentation
> I'd really like someone to contribute on this one. Volunteers?
If Danny can't do it, I'll take a look. I'm not familiar with it, though,
so I'll have to go from the source code.
> ii) Adjust the CVS to allow future maintenance of the 2.1 branch while
> permitting radical change for the 3.0 revision.
Please review Charles Bennett's message from 13 October:
http://www.mail-archive.com/james-dev@jakarta.apache.org/msg03999.html. I'm
not a CVS guru, either. Charles understood the goal that we have, and
posted the way by which he said that we do it. Basically, we just have to
tag the release as we would normally do. After that, branching is deferred
until actually needed.
I'm going to merge my live configuration with the new distribution, and then
post it to my production server.
> iii) Ensure that we are listed on common sites that provide lists of
> available mail/news servers.
I think that we can all pitch in here, and we ought to ask our users if they
might help to spread the word post-release. I also think that our press
release should mention future plans, and invite interested developers to
contribute. If you want some help with the press release, let me know.
> I'm still not done with the segments of documentation I signed up for
> and no one else has picked up the remainder.
Other than FetchPOP, what's on the list?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release Plan v2.1 (update)
Posted by Serge Knystautas <se...@lokitech.com>.
Serge Knystautas wrote:
> For example...
> - build_2_1_rc_1 for James 2.1 RC1
> - then build_2_1_rc_2 for James 2.1 RC2
> - then build_2_1_fcs for James 2.1 (final)
> - then build_2_1_1_rc1 for James 2.1.1 RC1
> - then build_2_1_1_fcs for James 2.1.2
Doh!... build_2_1_1_fcs for James 2.1.1 (final)
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release Plan v2.1 (update)
Posted by Charles Benett <ch...@apache.org>.
(this might be a duplicate - apologies if it is)
I agree with Serge's suggestions. My only question would be whether
James needs point releases (ie James 2.1.1) or whether we major and
minor are sufficient.
Charles
(Who used to have an account on Daedalus but hasn't checked recently)
Serge Knystautas wrote:
> Noel J. Bergman wrote:
>
>> Serge,
>>
>> Never discussed, and Danny is probably the only one who has been
>> active and
>> CVS knowledgable enough to do it. I agree with you. I'd say I'm
>> sorry, but
>> I didn't even have commit rights until recently, and I still don't
>> know more
>> than just the basic CVS commands.
>>
>> Perhaps you, Charles and Danny could put together a brief
>> CVS-for-Committers
>> file? :-)
>>
>> --- Noel
>
>
> I would leave CVS guides to others more knowledgeable (there are three
> decent guides on http://jakarta.apache.org/site/library.html).
>
> But looking over our CVS repository, I would say we could benefit from
> standardizing on a tag/branching process. I would put forward this:
>
> 1. Tagging on publishing builds
>
> Aside from nightly builds, when we put a build on the website (an
> alpha, beta, release candidate, final release), we tag that in CVS
> using the naming convention
>
> build_<major>_<minor>[_<point>]_<level>[_<counter>]
>
> Possible levels include "alpha", "beta", "rc" (release candidate), and
> "fcs" (first customer ship, i.e., final release).
>
> For example...
> - build_2_1_rc_1 for James 2.1 RC1
> - then build_2_1_rc_2 for James 2.1 RC2
> - then build_2_1_fcs for James 2.1 (final)
> - then build_2_1_1_rc1 for James 2.1.1 RC1
> - then build_2_1_1_fcs for James 2.1.2
> etc...
>
> 2. Branching on these tags as needed
>
> If a release has been made public for some time, new development has
> proceeded on HEAD, and there is a need to apply patches to make a
> minor or dot release on an old version, we branch on that tag, using
> the following naming convention:
>
> branch_<major>_<minor>[_<point>]_<level>[_<counter>]
>
> For example, we had James 2.1 a1 out for a long time, so normally you
> wouldn't branch on an alpha release, but if we wanted to patch that
> version to make small releases while we were working out this current
> build, we could create a branch_2_1_a_1.
>
>
> Comments?
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1 (update)
Posted by Alan Gerhard <al...@GerCom.Com>.
eventually we will need/use point releases - at least that is the goal; not to
have point releases but to be a major player in the enterprise mail server
space; once there we will have indeed point releases, so, if it's not too much
to set up now and adhere to .. well, it might be better in the long run.
alan
-----Original Message-----
From: Serge Knystautas [mailto:sergek@lokitech.com]
Sent: Tuesday, November 26, 2002 3:46 PM
To: James Developers List
Subject: Re: Release Plan v2.1 (update)
Charles Benett wrote:
> I agree with Serge's suggestions. My only question would be whether
> James needs point releases (ie James 2.1.1) or whether we major and
> minor are sufficient.
>
> Charles
Yeah, good point.
I didn't mean to imply point releases or branching on alphas were
something we wanted to do very often. Normally I think we'd only do
either of those when we were focused on a new major/minor release, and
some security or other bug became so glaring that we wanted to make a
very minor bug fix release.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release Plan v2.1 (update)
Posted by Serge Knystautas <se...@lokitech.com>.
Charles Benett wrote:
> I agree with Serge's suggestions. My only question would be whether
> James needs point releases (ie James 2.1.1) or whether we major and
> minor are sufficient.
>
> Charles
Yeah, good point.
I didn't mean to imply point releases or branching on alphas were
something we wanted to do very often. Normally I think we'd only do
either of those when we were focused on a new major/minor release, and
some security or other bug became so glaring that we wanted to make a
very minor bug fix release.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release Plan v2.1 (update)
Posted by Charles Benett <ch...@apache.org>.
I agree with Serge's suggestions. My only question would be whether
James needs point releases (ie James 2.1.1) or whether we major and
minor are sufficient.
Charles
(Who used to have an account on Daedalus but hasn't checked recently)
Serge Knystautas wrote:
> Noel J. Bergman wrote:
>
>> Serge,
>>
>> Never discussed, and Danny is probably the only one who has been
>> active and
>> CVS knowledgable enough to do it. I agree with you. I'd say I'm
>> sorry, but
>> I didn't even have commit rights until recently, and I still don't
>> know more
>> than just the basic CVS commands.
>>
>> Perhaps you, Charles and Danny could put together a brief
>> CVS-for-Committers
>> file? :-)
>>
>> --- Noel
>
>
> I would leave CVS guides to others more knowledgeable (there are three
> decent guides on http://jakarta.apache.org/site/library.html).
>
> But looking over our CVS repository, I would say we could benefit from
> standardizing on a tag/branching process. I would put forward this:
>
> 1. Tagging on publishing builds
>
> Aside from nightly builds, when we put a build on the website (an
> alpha, beta, release candidate, final release), we tag that in CVS
> using the naming convention
>
> build_<major>_<minor>[_<point>]_<level>[_<counter>]
>
> Possible levels include "alpha", "beta", "rc" (release candidate), and
> "fcs" (first customer ship, i.e., final release).
>
> For example...
> - build_2_1_rc_1 for James 2.1 RC1
> - then build_2_1_rc_2 for James 2.1 RC2
> - then build_2_1_fcs for James 2.1 (final)
> - then build_2_1_1_rc1 for James 2.1.1 RC1
> - then build_2_1_1_fcs for James 2.1.2
> etc...
>
> 2. Branching on these tags as needed
>
> If a release has been made public for some time, new development has
> proceeded on HEAD, and there is a need to apply patches to make a
> minor or dot release on an old version, we branch on that tag, using
> the following naming convention:
>
> branch_<major>_<minor>[_<point>]_<level>[_<counter>]
>
> For example, we had James 2.1 a1 out for a long time, so normally you
> wouldn't branch on an alpha release, but if we wanted to patch that
> version to make small releases while we were working out this current
> build, we could create a branch_2_1_a_1.
>
>
> Comments?
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release Plan v2.1 (update)
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> Serge,
>
> Never discussed, and Danny is probably the only one who has been active and
> CVS knowledgable enough to do it. I agree with you. I'd say I'm sorry, but
> I didn't even have commit rights until recently, and I still don't know more
> than just the basic CVS commands.
>
> Perhaps you, Charles and Danny could put together a brief CVS-for-Committers
> file? :-)
>
> --- Noel
I would leave CVS guides to others more knowledgeable (there are three
decent guides on http://jakarta.apache.org/site/library.html).
But looking over our CVS repository, I would say we could benefit from
standardizing on a tag/branching process. I would put forward this:
1. Tagging on publishing builds
Aside from nightly builds, when we put a build on the website (an alpha,
beta, release candidate, final release), we tag that in CVS using the
naming convention
build_<major>_<minor>[_<point>]_<level>[_<counter>]
Possible levels include "alpha", "beta", "rc" (release candidate), and
"fcs" (first customer ship, i.e., final release).
For example...
- build_2_1_rc_1 for James 2.1 RC1
- then build_2_1_rc_2 for James 2.1 RC2
- then build_2_1_fcs for James 2.1 (final)
- then build_2_1_1_rc1 for James 2.1.1 RC1
- then build_2_1_1_fcs for James 2.1.2
etc...
2. Branching on these tags as needed
If a release has been made public for some time, new development has
proceeded on HEAD, and there is a need to apply patches to make a minor
or dot release on an old version, we branch on that tag, using the
following naming convention:
branch_<major>_<minor>[_<point>]_<level>[_<counter>]
For example, we had James 2.1 a1 out for a long time, so normally you
wouldn't branch on an alpha release, but if we wanted to patch that
version to make small releases while we were working out this current
build, we could create a branch_2_1_a_1.
Comments?
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1 (update)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
Never discussed, and Danny is probably the only one who has been active and
CVS knowledgable enough to do it. I agree with you. I'd say I'm sorry, but
I didn't even have commit rights until recently, and I still don't know more
than just the basic CVS commands.
Perhaps you, Charles and Danny could put together a brief CVS-for-Committers
file? :-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1 (update)
Posted by Danny Angus <da...@apache.org>.
no reason, I'll do that
> -----Original Message-----
> From: Serge Knystautas [mailto:sergek@lokitech.com]
> Sent: 23 November 2002 02:57
> To: James Developers List
> Subject: Re: Release Plan v2.1 (update)
>
>
> Danny Angus wrote:
> >>>ii) Adjust the CVS to allow future maintenance of the 2.1 branch while
> >>>permitting radical change for the 3.0 revision.
> >>
> >>I'd like a volunteer for this as well. I'm not CVS saavy, but I'll do
> >>it if I have to. Basically I'd suggest that we form a release/2.1
> >>directory off the base directory that contains all the necessary files
> >>to build a 2.1 release. This will allow bugfixing on that release.
> >
> >
> > I'll do this.
> > I'll tag 2.1 when the final code is checked out for the
> release, then if we need to mess around with it later we can
> branch CVS then (and only then)
>
> Was it discussed and/or is there a reason to not tag the release
> candidates as well? I like to see tags for any code that would be
> packaged and available to download. For instance, if I am trying to
> debug something in RC1, it's nice to be sure what code I'm testing.
>
> I agree about not branching until necessary, and really only on final
> releases.
>
> Serge Knystautas
> Loki Technologies
> http://www.lokitech.com/
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release Plan v2.1 (update)
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
>>>ii) Adjust the CVS to allow future maintenance of the 2.1 branch while
>>>permitting radical change for the 3.0 revision.
>>
>>I'd like a volunteer for this as well. I'm not CVS saavy, but I'll do
>>it if I have to. Basically I'd suggest that we form a release/2.1
>>directory off the base directory that contains all the necessary files
>>to build a 2.1 release. This will allow bugfixing on that release.
>
>
> I'll do this.
> I'll tag 2.1 when the final code is checked out for the release, then if we need to mess around with it later we can branch CVS then (and only then)
Was it discussed and/or is there a reason to not tag the release
candidates as well? I like to see tags for any code that would be
packaged and available to download. For instance, if I am trying to
debug something in RC1, it's nice to be sure what code I'm testing.
I agree about not branching until necessary, and really only on final
releases.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1 (update)
Posted by Danny Angus <da...@apache.org>.
> > iii) Add FetchPOP documentation
>
> I'd really like someone to contribute on this one. Volunteers?
You mean me don't yuo ;)
I'll do it.
> > i) Build a milestone build for testing.
We also need to test the source distribution to make sure it builds..
> > ii) Adjust the CVS to allow future maintenance of the 2.1 branch while
> > permitting radical change for the 3.0 revision.
>
> I'd like a volunteer for this as well. I'm not CVS saavy, but I'll do
> it if I have to. Basically I'd suggest that we form a release/2.1
> directory off the base directory that contains all the necessary files
> to build a 2.1 release. This will allow bugfixing on that release.
I'll do this.
I'll tag 2.1 when the final code is checked out for the release, then if we need to mess around with it later we can branch CVS then (and only then)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Release Plan v2.1 (update)
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
> Documentation and testing comprise the bulk of the remaining work. We
> still need to carry out the following documentation tasks:
>
> i) Document the configuration files in toto. Format the documentation
> consistently, as well as vet it for correctness.
In process. Assigned to me. I will be checking in some stuff tonight.
> ii) Document the top 5 items on the TODO list
In process. Assigned to me.
> iii) Add FetchPOP documentation
I'd really like someone to contribute on this one. Volunteers?
> iv) Produce a consistent documentation package for the 2.1 version
that
> details the product services, as well as the basic steps of
installation
> and configuration.
>
> Build tasks:
>
> i) Build a milestone build for testing.
Done. And posted.
> ii) Adjust the CVS to allow future maintenance of the 2.1 branch while
> permitting radical change for the 3.0 revision.
I'd like a volunteer for this as well. I'm not CVS saavy, but I'll do
it if I have to. Basically I'd suggest that we form a release/2.1
directory off the base directory that contains all the necessary files
to build a 2.1 release. This will allow bugfixing on that release.
> i) Run general tests on a variety of platforms. We've already done a
> great deal of testing on both Windows and Linux platforms, but it
would
> be good to get a great deal more testing done before the official
> release. We should look to our user base for potential testers.
The user base has started doing some testing. A request for feedback
has been posted on the web site. Not sure if anyone else wants to sign
up for more testing.
> ii) Test TLS support for POP3 and update the status from experimental
to
> stable.
Any volunteers?
> Marketing tasks:
>
> i) Produce a press release for distribution through channels
announcing
> both the release of 2.1 and inviting developers to participate in
> version 3.0.
In process. Assigned to me.
> ii) Distribute this release through channels (i.e. Slashdot)
In process. Assigned to me.
> iii) Ensure that we are listed on common sites that provide lists of
> available mail/news servers.
Any volunteers?
> I'm working on items i, ii, and iv on the documentation task list, as
> well as items i and iii on the marketing task list. Anyone who wants
to
> step up for any of the other items, please do. I'd like to ask Danny
> specifically to address the milestone build issue, since he has write
> access to the web site. If he can get me such write access, I'd be
> happy to build and post the milestone build.
I haven't really gotten any response from any of the
committers/contributors to this request for contributions. If we're
going to get this out the door, it's going to require some effort from a
number of interested parties. I know this stuff doesn't interest most
of us (it certainly doesn't interest me) but it's part and parcel of
putting out an enterprise class product.
> Here's my desired schedule:
>
> November 4th, 2002 - Creation and posting of milestone build
Completed November 13th, 2002.
> November 4th-17th, 2002 - Testing period. Aggressive testing of James
> under a variety of conditions.
Testing can be considered to be started November 13th, which would lead
to a close of this period on November 26th. There has been some testing
to date,
> November 8th, 2002 - Documentation freeze, which requires completion
of
> all documentation tasks.
We're way off on this one. :)
I'm still not done with the segments of documentation I signed up for,
and no one else has picked up the remainder. I'd like to set a nominal
freeze date of November 26th, but unless we get some contributions,
that's not going to happen.
> November 15th, 2002 - Completion of press release, list of sites to
> which the release needs to be distributed. Mail server info sites
> should be updated with links at this point.
I'd say this should be November 30th. But it depends on all the earlier
steps. And hence depends on people contributing.
> November 18th, 2002 - Release. Update of web site to reflect newly
> released version. Distribution of press release to sites should be
> completed immediately after release.
I'd say December 2nd for this. But again, this depends on everyone
stepping up and contributing.
Thoughts? Replies? Anyone? :)
--Peter
P.S.: I understand that Thanksgiving falls in the middle of this, but
there just isn't that much left to do. One last push should get us over
the edge.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan v2.1
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
Well, here's my suggested scheduler for release 2.1, given the
developments to this point. Let me first summarize what we've gotten
done, then what remains to be done before release, and then lay out the
schedule I think is realistic.
We have, at this point, achieved all the code specific goals discussed
in the release plan of September 28th. We have replaced the
ConnectionHandler infrastructure, addressed the TimeScheduler issue, and
closed all the code specific bugs in item #4 of the earlier release
plan. We have also made a number of substantial performance and memory
usage improvements over the last month, as well as bringing the NNTP
server into better agreement with the specification. We've upgraded our
distribution to Phoenix 4.0.1, resolving the logging bug. The javadocs
have also been brought up to speed. As far as I can tell, there are no
outstanding code items required for 2.1. So I'd like to declare code
freeze for this version.
Documentation and testing comprise the bulk of the remaining work. We
still need to carry out the following documentation tasks:
i) Document the configuration files in toto. Format the documentation
consistently, as well as vet it for correctness.
ii) Document the top 5 items on the TODO list
iii) Add FetchPOP documentation
iv) Produce a consistent documentation package for the 2.1 version that
details the product services, as well as the basic steps of installation
and configuration.
Build tasks:
i) Build a milestone build for testing.
ii) Adjust the CVS to allow future maintenance of the 2.1 branch while
permitting radical change for the 3.0 revision.
Testing tasks:
i) Run general tests on a variety of platforms. We've already done a
great deal of testing on both Windows and Linux platforms, but it would
be good to get a great deal more testing done before the official
release. We should look to our user base for potential testers.
ii) Test TLS support for POP3 and update the status from experimental to
stable.
Marketing tasks:
i) Produce a press release for distribution through channels announcing
both the release of 2.1 and inviting developers to participate in
version 3.0.
ii) Distribute this release through channels (i.e. Slashdot)
iii) Ensure that we are listed on common sites that provide lists of
available mail/news servers.
I'm working on items i, ii, and iv on the documentation task list, as
well as items i and iii on the marketing task list. Anyone who wants to
step up for any of the other items, please do. I'd like to ask Danny
specifically to address the milestone build issue, since he has write
access to the web site. If he can get me such write access, I'd be
happy to build and post the milestone build.
Here's my desired schedule:
November 4th, 2002 - Creation and posting of milestone build
November 4th-17th, 2002 - Testing period. Aggressive testing of James
under a variety of conditions.
November 8th, 2002 - Documentation freeze, which requires completion of
all documentation tasks.
November 15th, 2002 - Completion of press release, list of sites to
which the release needs to be distributed. Mail server info sites
should be updated with links at this point.
November 18th, 2002 - Release. Update of web site to reflect newly
released version. Distribution of press release to sites should be
completed immediately after release.
How does this sound to everyone? Danny, what are your thoughts on
making a milestone build?
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>