Giacomo Pati wrote:
But first we need to come to a consensus about which build
infrastructure we would support to use:
1) Ant
in this case we can use the current build system and tune it to the
needs we have for the 2.2 and maybe add some ruper task to get rid
of jars in
On Thu, 25 Sep 2003, Stefano Mazzocchi wrote:
On Thursday, Sep 25, 2003, at 10:47 Europe/Rome, Giacomo Pati wrote:
On Wed, 24 Sep 2003, Berin Loritsch wrote:
snippeddiscussion on build infrastructure/snipped
We tried to have a unified build system with ANT, and all excalibur
projects
On Thu, 25 Sep 2003, Berin Loritsch wrote:
Stefano Mazzocchi wrote:
Contrast that with the parts that were ported over to use Maven, or
the GUIApp
project (http://d-haven.org). A world of difference. No longer is
there any
question about what is needed where. No longer is there a
Giacomo Pati dijo:
But first we need to come to a consensus about which build
infrastructure we would support to use:
1) Ant
in this case we can use the current build system and tune it to the
needs we have for the 2.2 and maybe add some ruper task to get rid
of jars in our repository
On Sun, 28 Sep 2003, Antonio Gallardo wrote:
Giacomo Pati dijo:
But first we need to come to a consensus about which build
infrastructure we would support to use:
1) Ant
in this case we can use the current build system and tune it to the
needs we have for the 2.2 and maybe add
Giacomo Pati dijo:
On Sun, 28 Sep 2003, Antonio Gallardo wrote:
Then Ant can be present in the 3 options presented. I share with you
the need to move to a better project management. In that case I think
the question is related to Centiped vs. Maven.
Well, all three infrastructure mentioned
Le Mercredi, 24 sep 2003, à 23:08 Europe/Zurich, Stefano Mazzocchi a
écrit :
On Wednesday, Sep 24, 2003, at 20:34 Europe/Rome, Timothy Larson wrote:
lots-of-snips cause=agree/
The above suggests one simple, but really important thing:
the block 'health' metadata should *NOT* be included in the
On Wednesday, September 24, 2003, at 04:29 PM, Reinhard Poetz wrote:
From: Stefano Mazzocchi
On Tuesday, Sep 23, 2003, at 22:38 Europe/Rome, Berin Loritsch wrote:
I would highly recommend steering away from the use of the word
certified
unless you intend to establish a standards body to oversee
On Wed, 24 Sep 2003, Berin Loritsch wrote:
Stefano Mazzocchi wrote:
- have multiple sub project in the repository which will be build all
the same way with only one project.xml descriptor for name, version,
etc. per sub project (this is Maven specific).
h
I would
On Wednesday, September 24, 2003, at 08:46 PM, Timothy Larson wrote:
Which solution should I select : Woody or JXForms? FOP or iText? Just
look
at the activity to determine the health of a module/block.
Exactly. Of course, no measure is going to be perfect, but something
like
this could help.
On Thursday, Sep 25, 2003, at 10:47 Europe/Rome, Giacomo Pati wrote:
On Wed, 24 Sep 2003, Berin Loritsch wrote:
Stefano Mazzocchi wrote:
- have multiple sub project in the repository which will be build
all
the same way with only one project.xml descriptor for name,
version,
etc.
On Thursday, Sep 25, 2003, at 08:51 Europe/Rome, Bertrand Delacretaz
wrote:
Le Mercredi, 24 sep 2003, à 23:08 Europe/Zurich, Stefano Mazzocchi a
écrit :
On Wednesday, Sep 24, 2003, at 20:34 Europe/Rome, Timothy Larson
wrote:
lots-of-snips cause=agree/
The above suggests one simple, but really
Stefano Mazzocchi wrote:
Contrast that with the parts that were ported over to use Maven, or
the GUIApp
project (http://d-haven.org). A world of difference. No longer is
there any
question about what is needed where. No longer is there a need to
have JARs
locally in the repository. No
I was doing wiring and sleeping during part of this discussion, but please
let me jump in again. We could say something like this about a module:
Code Stability: alpha/beta/final
API/Contract Stability: alpha/beta/final
Support Level: contributed/supported/deprecated
Community Info:
Le Jeudi, 25 sep 2003, à 12:45 Europe/Zurich, Stefano Mazzocchi a écrit
:
...I think that contributed and experimental are somewhat
orthogonal, in fact, linotype can be considered both contributed and
experimental
Agreed.
...So:
contributed - no broad community support
supported -
On Tuesday, Sep 23, 2003, at 22:38 Europe/Rome, Berin Loritsch wrote:
I would highly recommend steering away from the use of the word
certified
unless you intend to establish a standards body to oversee an official
certification process.
Good point. Supported sounds less marketing intrusive.
On Tuesday, Sep 23, 2003, at 19:41 Europe/Rome, Giacomo Pati wrote:
On Tue, 23 Sep 2003, Stefano Mazzocchi wrote:
On Monday, Sep 22, 2003, at 16:23 Europe/Rome, Giacomo Pati wrote:
SNIP/
I agree with you that even a 'naked cocoon' (a cocoon with no
functional blocks) can be further
Le Mercredi, 24 sep 2003, à 12:44 Europe/Zurich, Stefano Mazzocchi a
écrit :
..Good point. Supported sounds less marketing intrusive.
I like it too - supported vs. unsupported is very clear.
-Bertrand
--- Stefano Mazzocchi [EMAIL PROTECTED] wrote:
Good point. Supported sounds less marketing intrusive.
comments?
Yes, supported matches the concept better. It says someone
still cares about the block, that the community has not moved
on and left it behind.
--Tim Larson
Timothy Larson wrote:
--- Stefano Mazzocchi [EMAIL PROTECTED] wrote:
Good point. Supported sounds less marketing intrusive.
comments?
Yes, supported matches the concept better. It says someone
still cares about the block, that the community has not moved
on and left it behind.
+1
--
Nicola
On Wed, 24 Sep 2003, Stefano Mazzocchi wrote:
On Tuesday, Sep 23, 2003, at 22:38 Europe/Rome, Berin Loritsch wrote:
I would highly recommend steering away from the use of the word
certified
unless you intend to establish a standards body to oversee an official
certification process.
Giacomo Pati wrote:
...
The main part for me is
...
- have multiple sub project in the repository which will be build all
the same way with only one project.xml descriptor for name, version,
etc. per sub project (this is Maven specific).
Not really. Centipede uses the Gump descriptor for
On Wednesday, Sep 24, 2003, at 15:41 Europe/Rome, Giacomo Pati wrote:
On Wed, 24 Sep 2003, Stefano Mazzocchi wrote:
On Tuesday, Sep 23, 2003, at 19:41 Europe/Rome, Giacomo Pati wrote:
On Tue, 23 Sep 2003, Stefano Mazzocchi wrote:
On Monday, Sep 22, 2003, at 16:23 Europe/Rome, Giacomo Pati
Stefano Mazzocchi wrote:
...
- no need to have any jars in the CVS repository anymore or at least
only some exotic ones that are not distributed over the web (today
more than 40% of the cocoon cvs space is needed by jars and this is
even more in our zipped distributions)
this is a
Stefano Mazzocchi wrote:
- no need to have any jars in the CVS repository anymore or at least
only some exotic ones that are not distributed over the web (today
more than 40% of the cocoon cvs space is needed by jars and this is
even more in our zipped distributions)
this is a good
Stefano Mazzocchi wrote:
- have multiple sub project in the repository which will be build all
the same way with only one project.xml descriptor for name, version,
etc. per sub project (this is Maven specific).
h
I would strongly suggest to wait to refactor the build system
Geoff Howard wrote:
Stefano Mazzocchi wrote:
- no need to have any jars in the CVS repository anymore or at least
only some exotic ones that are not distributed over the web (today
more than 40% of the cocoon cvs space is needed by jars and this is
even more in our zipped
From: Stefano Mazzocchi
On Tuesday, Sep 23, 2003, at 22:38 Europe/Rome, Berin Loritsch wrote:
I would highly recommend steering away from the use of the word
certified
unless you intend to establish a standards body to oversee
an official
certification process.
Good point.
Berin Loritsch wrote:
Geoff Howard wrote:
Stefano Mazzocchi wrote:
- no need to have any jars in the CVS repository anymore or at least
only some exotic ones that are not distributed over the web (today
more than 40% of the cocoon cvs space is needed by jars and this is
even more
On Wednesday, September 24, 2003, at 02:09 PM, Giacomo Pati wrote:
On Wed, 24 Sep 2003, Stefano Mazzocchi wrote:
On Tuesday, Sep 23, 2003, at 22:38 Europe/Rome, Berin Loritsch wrote:
I would highly recommend steering away from the use of the word
certified
unless you intend to establish a
On Wednesday, Sep 24, 2003, at 17:29 Europe/Rome, Reinhard Poetz wrote:
From: Stefano Mazzocchi
On Tuesday, Sep 23, 2003, at 22:38 Europe/Rome, Berin Loritsch wrote:
I would highly recommend steering away from the use of the word
certified
unless you intend to establish a standards body to
From: Stefano Mazzocchi
On Wednesday, Sep 24, 2003, at 17:29 Europe/Rome, Reinhard
Poetz wrote:
From: Stefano Mazzocchi
On Tuesday, Sep 23, 2003, at 22:38 Europe/Rome, Berin
Loritsch wrote:
I would highly recommend steering away from the use of the word
certified unless
Geoff Howard wrote:
Berin Loritsch wrote:
Geoff Howard wrote:
Stefano Mazzocchi wrote:
- no need to have any jars in the CVS repository anymore or at
least
only some exotic ones that are not distributed over the web
(today
more than 40% of the cocoon cvs space is needed by jars
Upayavira wrote:
Geoff Howard wrote:
Berin Loritsch wrote:
Geoff Howard wrote:
Stefano Mazzocchi wrote:
- no need to have any jars in the CVS repository anymore or at
least
only some exotic ones that are not distributed over the web
(today
more than 40% of the cocoon cvs space is
Upayavira wrote:
Do bear in mind that Maven downloads a number of things itself the first
time you use it. Avalon (Framework) has very few dependencies itself
Does it then cache that locally, so that next time it needs it, it has it?
Absolutely. There are two things to note:
* If you
From: Berin Loritsch [mailto:[EMAIL PROTECTED]
* If you want to bypass that feature add the -e parameter
to tell Maven not to expect a network connection. It won't try
to download anything.
Correction: -o not -e
/LS
Leo Sutic wrote:
From: Berin Loritsch [mailto:[EMAIL PROTECTED]
* If you want to bypass that feature add the -e parameter
to tell Maven not to expect a network connection. It won't try
to download anything.
Correction: -o not -e
Thanks.
--
They that give up essential liberty to obtain
Maybe we are having a hard time finding the right word because we are
mixing concerns. I can think of roughly four separate things the user
of a module would want to know:
(1) Is the module stable?
(i.e. is it considered to generally work properly with no critical bugs?)
(2) Will code
Timothy Larson wrote:
Maybe we are having a hard time finding the right word because we are
mixing concerns. I can think of roughly four separate things the user
of a module would want to know:
(1) Is the module stable?
(i.e. is it considered to generally work properly with no critical
- Original Message -
From: Timothy Larson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 24, 2003 8:34 PM
Subject: Re: on better release and version management
snip/
side-note
Eventually it would be helpful for the source website to include the
static
meta-info
See below...
What happens if we find out that a certain block is not supported any
more (technology outdated, we have a better block, any active
developers) *after* we marked it as supported. The first question I had
was how long does supported mean? The former proposed *certified*
On Wednesday, Sep 24, 2003, at 20:34 Europe/Rome, Timothy Larson wrote:
Maybe we are having a hard time finding the right word because we are
mixing concerns.
I came to the same conclusion.
I can think of roughly four separate things the user
of a module would want to know:
(1) Is the module
Stefano Mazzocchi wrote:
On Sunday, Sep 21, 2003, at 12:39 Europe/Rome, Upayavira wrote:
Steven Noels wrote:
Joerg Heinicke wrote:
IMO this is difficult to maintain. If someone wants to look on the
code base of a block he has to search for its dependencies first or
search for the code at
On Tuesday, Sep 23, 2003, at 08:38 Europe/Rome, Nicola Ken Barozzi
wrote:
Stefano Mazzocchi wrote:
I fear one-man-shows.
May I guess where this fear comes from... Avalon? ;-)
yeah
I have the same fear.
At the same time, we need 'sort-of incubation' practices for blocks,
as it is impractical
.
all SitemapComponents etc.)
- A Block implementation
Each block implementation will be a IRU of course. It has for
sure it's own development cycle.
This of course are my personal oppinios about a better version
management, release management and resource management. It'll break
apart
Stefano Mazzocchi wrote:
...
Instead of associating 'maturity levels' to the actual location of a
block, I would state that as a 'label' attached to it, a label that the
block deployer reacts to and prompt the user for action in case the
block is not considered final by the community.
And maybe
Le Mardi, 23 sep 2003, à 14:26 Europe/Zurich, Nicola Ken Barozzi a
écrit :
...And maybe also use a low-tech way of adding a
WARNING_BETA_BLOCK.txt or WARNING_SCRATCHPAD_BLOCK.txt file in the
block source dir to make it clear to CVS browsers and coders of the
status of the code.
Or rather an
Le Mardi, 23 sep 2003, à 14:33 Europe/Zurich, Nicola Ken Barozzi a
écrit :
Bertrand Delacretaz wrote:
Le Mardi, 23 sep 2003, à 14:26 Europe/Zurich, Nicola Ken Barozzi a
écrit :
...And maybe also use a low-tech way of adding a
WARNING_BETA_BLOCK.txt or WARNING_SCRATCHPAD_BLOCK.txt file in the
Stefano Mazzocchi [EMAIL PROTECTED] writes:
snip
Instead of associating 'maturity levels' to the actual location of a
block, I would state that as a 'label' attached to it, a
label that the
block deployer reacts to and prompt the user for action in case the
block is not considered final
On Tuesday, Sep 23, 2003, at 14:46 Europe/Rome, Bertrand Delacretaz
wrote:
Le Mardi, 23 sep 2003, à 14:33 Europe/Zurich, Nicola Ken Barozzi a
écrit :
Bertrand Delacretaz wrote:
Le Mardi, 23 sep 2003, à 14:26 Europe/Zurich, Nicola Ken Barozzi a
écrit :
...And maybe also use a low-tech way of
On Tuesday, Sep 23, 2003, at 16:05 Europe/Rome, Hunsberger, Peter wrote:
Stefano Mazzocchi [EMAIL PROTECTED] writes:
snip
Instead of associating 'maturity levels' to the actual location of a
block, I would state that as a 'label' attached to it, a
label that the
block deployer reacts to and
--- Stefano Mazzocchi [EMAIL PROTECTED] wrote:
...
I propose a much simpler scheme. A block can be:
1) certified
2) not certified
A certified block is said to be guaranteed by the certifier (not only
the Apache Cocoon project, but any organization willing to certify
their blocks)
Le Mardi, 23 sep 2003, à 16:31 Europe/Zurich, Stefano Mazzocchi a écrit
:
...The system I outlined above seems really nice, but, IMO, has a few
serious drawbacks:
1) it requires a central authorithy of certification
2) it creates an incredible amount of friction..
Right. Nightmares in the
On Tuesday, Sep 23, 2003, at 17:27 Europe/Rome, Bertrand Delacretaz
wrote:
Le Mardi, 23 sep 2003, à 16:31 Europe/Zurich, Stefano Mazzocchi a
écrit :
...The system I outlined above seems really nice, but, IMO, has a few
serious drawbacks:
1) it requires a central authorithy of certification
On Tue, 23 Sep 2003, Stefano Mazzocchi wrote:
On Monday, Sep 22, 2003, at 16:23 Europe/Rome, Giacomo Pati wrote:
SNIP/
I agree with you that even a 'naked cocoon' (a cocoon with no
functional blocks) can be further modularized, even if I personally
don't resonate with the modularization
Giacomo Pati wrote:
On Tue, 23 Sep 2003, Stefano Mazzocchi wrote:
On Monday, Sep 22, 2003, at 16:23 Europe/Rome, Giacomo Pati wrote:
SNIP/
I agree with you that even a 'naked cocoon' (a cocoon with no
functional blocks) can be further modularized, even if I personally
don't resonate with
Stefano Mazzocchi wrote:
Certification, more than anything is a stamp on trust.
When installing something, the question a user poses wants answered: can
I trust this? can I build my software on this?
Certification provides an answer to this simple (yet vital!) question,
expecially in an
personal oppinios about a better version
management, release management and resource management. It'll break
apart the monilitic release process we have today and allows much more
flexibility and also more compact composition of a Cocoon System.
The drawback is that we need another system to compose
Giacomo Pati wrote:
2 - copying all blocks to the 2.2 repo is not wanted since not all
blocks will evolve in the 2.2
I think we have to clean up the build process from bottom again (see
below).
In the long run, I believe yes (see below)
3 - the real blocks may require some
Stefano Mazzocchi wrote:
Joerg Heinicke wrote:
IMO this is difficult to maintain. If someone wants to look on the
code base of a block he has to search for its dependencies first or
search for the code at different places. Can't we extract the blocks
from 2.1 as they are at the moment and
Joerg Heinicke wrote:
IMO this is difficult to maintain. If someone wants to look on the code
base of a block he has to search for its dependencies first or search
for the code at different places. Can't we extract the blocks from 2.1
as they are at the moment and move them to cocoon-blocks
Steven Noels wrote:
Joerg Heinicke wrote:
IMO this is difficult to maintain. If someone wants to look on the
code base of a block he has to search for its dependencies first or
search for the code at different places. Can't we extract the blocks
from 2.1 as they are at the moment and move
On Sunday, Sep 21, 2003, at 01:40 Europe/Rome, Joerg Heinicke wrote:
Stefano Mazzocchi wrote:
OTOH if it is the case, then we're back to needing an uninhibited
way to experiment with them, and the block.xml and the whole block
content may need to be duplicated in 2.2 until cocoon-blocks is
On Sunday, Sep 21, 2003, at 12:39 Europe/Rome, Upayavira wrote:
Steven Noels wrote:
Joerg Heinicke wrote:
IMO this is difficult to maintain. If someone wants to look on the
code base of a block he has to search for its dependencies first or
search for the code at different places. Can't we
Stefano Mazzocchi wrote:
OTOH if it is the case, then we're back to needing an uninhibited way
to experiment with them, and the block.xml and the whole block content
may need to be duplicated in 2.2 until cocoon-blocks is worked out.
yes. if the fop block, for example, requires dependencies on
Steven Noels wrote:
Hi folks,
forgive me for putting on my BOFH hat, while making the following
observations...
1) We suck at freezing and stabilizing the codebase prior to releases.
I would suggest that, from now on, the Release Manager puts forward a
release date after discussion
Carsten Ziegeler wrote:
snip type=happy agreement/
I tried to address this issue several times in the last weeks, well,
without much success.
One thing I want to stress again: *if* we would make a new repository
for 2.2 and duplicate all code, this would include the blocks as well.
So we would
Le Vendredi, 19 sep 2003, à 11:25 Europe/Zurich, Carsten Ziegeler a
écrit :
...Now to the docs:
Yes, looking back it was a very stupid idea to reorganize the docs. I
didn't thought about links pointing to the old docs. I'm very sorry
for that!
I don't think it was a stupid idea - after so much
Le Vendredi, 19 sep 2003, à 14:47 Europe/Zurich, Sylvain Wallez a écrit
:
...So what about the following (somewhat already expressed, BTW) :
- start a 2.2 repo with only the Cocoon core (i.e. src/java)
- copy blocks in the 2.2 repo only if they require substantial changes
that would break the
Sylvain Wallez wrote:
Steven Noels wrote:
Carsten Ziegeler wrote:
snip type=happy agreement/
I tried to address this issue several times in the last weeks, well,
without much success.
...
So, whatever we decide, I'm -1 on duplicating the block code.
My problem with the blocks code is that
On Friday, Sep 19, 2003, at 11:39 Europe/Rome, Steven Noels wrote:
Carsten Ziegeler wrote:
snip type=happy agreement/
I tried to address this issue several times in the last weeks, well,
without much success.
One thing I want to stress again: *if* we would make a new repository
for 2.2 and
Geoff Howard wrote:
+1 let's give it a shot. This is probably what Carsten was picturing
all along. :)
Yeah. That's one of my qualities/defaults (depending on the context) : I
hear all opinions, make a synthesis and sometimes claim that it's my own
idea ;-)
Sylvain
--
Sylvain Wallez
On Friday, Sep 19, 2003, at 15:05 Europe/Rome, Geoff Howard wrote:
Sylvain Wallez wrote:
Steven Noels wrote:
Carsten Ziegeler wrote:
snip type=happy agreement/
I tried to address this issue several times in the last weeks,
well, without much success.
...
So, whatever we decide, I'm -1 on
--- Stefano Mazzocchi [EMAIL PROTECTED] wrote:
After a little more thinking, I think that we should avoid placing
block code in cocoon-2.2 alltogether because we need to start talking
about the 'community process' of accepting new blocks, where they fit,
how they get 'certified' and all
Stefano Mazzocchi wrote:
A few points:
1) there is no *block* code in cocoon 2.1, everything is done by the
builder.
Hey, I knew that already! ;-)
2) blocks in 2.1 and blocks in 2.2 are a single block.xml file away.
Given all this stuff of block-specific classloading and much more
technical
Sylvain Wallez wrote:
Yeah. That's one of my qualities/defaults (depending on the context) : I
hear all opinions, make a synthesis and sometimes claim that it's my own
idea ;-)
Ha. :-)
You couldn't get away with it this time! :-D
/Steven
--
Steven Noels
Stefano Mazzocchi wrote:
SNIP/
+1 let's give it a shot. This is probably what Carsten was picturing
all along. :)
+1 as well. the magic build script that gets missing blocks from 2.1
would simply be a cvs checkout, followed with a few file copy
operations.
Yes, I thought of that,
On Friday, Sep 19, 2003, at 15:54 Europe/Rome, Geoff Howard wrote:
Hmmm... I've been assuming that the way a block actually gets coded
may need to change in order to interact with other real blocks, etc.
If this is not the case, then the whole issue of back-compatibility of
blocks goes away
Bertrand Delacretaz [EMAIL PROTECTED] wrote:
Le Mercredi, 10 sep 2003, à 11:26 Europe/Zurich, Reinhard Poetz a
écrit
...Would it be enough to extend our Anteater scripts (see Guido's
mail) and
add Anteater to our codebase and include it automatically to our
build system? ...
certainly a
On Wed, 2003-09-10 at 11:26, Reinhard Poetz wrote:
From: Steven Noels
snip/
2) We need to break from the impasse of 2.1.1 vs 2.2
I suggested yesterday night that the reshuffling of docs that Carsten
started really seems more apt for a 2.2 release. Also, the switch to
Fortress and
Le Jeudi, 11 sep 2003, à 11:33 Europe/Zurich, Bruno Dumon a écrit :
I'd rather see the entire repository duplicated, and
move all development effort to the 2.2 repository. Only bugfixes should
be applied to the 2.1 repository, and occasional backports of new
functionality if anyone wants
From: Bruno Dumon
Carsten made a good proposal how we can continue having 3
repositories
and how this can be done with only little code duplicating:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106076740711234w=2
I'm +1 with his proposal - the reason is simple: Some people
Reinhard Poetz dijo:
From: Bruno Dumon
Carsten made a good proposal how we can continue having 3
repositories
and how this can be done with only little code duplicating:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106076740711234w=2
I'm +1 with his proposal - the reason is
From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
Reinhard Poetz dijo:
From: Bruno Dumon
Carsten made a good proposal how we can continue having 3
repositories
and how this can be done with only little code duplicating:
On Thu, 2003-09-11 at 12:02, Reinhard Poetz wrote:
From: Bruno Dumon
Carsten made a good proposal how we can continue having 3
repositories
and how this can be done with only little code duplicating:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106076740711234w=2
I'm +1
Reinhard Poetz wrote:
I expect this and that's the reason why I think that a stable 2.2
release will take some time (I think that's not a matter of a few months
but much more) and why I like Carsten's proposal.
Grmbl. Bruno and I were just trying to argumentize against each other
about both
Reinhard Poetz wrote:
From: Bruno Dumon
Carsten made a good proposal how we can continue having 3
repositories
and how this can be done with only little code duplicating:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106076740711234w=2
I'm +1 with his proposal - the reason is simple: Some
Geoff Howard wrote:
I am undecided but something occurred to me in the shower this AM which
made me wonder whether Carsten's proposal will work. As blocks evolve
into real blocks, the changes will need to happen right in the
src/blocks. Can we guarantee (or will it be too painful to ensure)
: on better release and version management
Reinhard Poetz wrote:
I expect this and that's the reason why I think that a stable 2.2
release will take some time (I think that's not a matter of a few
months but much more) and why I like Carsten's proposal.
Grmbl. Bruno and I were just
From: Bruno Dumon [mailto:[EMAIL PROTECTED]
snip/
I expect Woody to also take another year or so before it can
be considered stable (in terms of interfaces, not code).
... that long? I expected it to be stable sooner (end of this year).
What's open? (I already added this discussion point
Reinhard Poetz wrote:
From: Bruno Dumon [mailto:[EMAIL PROTECTED]
snip/
I expect Woody to also take another year or so before it can
be considered stable (in terms of interfaces, not code).
... that long? I expected it to be stable sooner (end of this year).
What's open? (I already added
On Thu, 2003-09-11 at 14:19, Reinhard Poetz wrote:
From: Bruno Dumon [mailto:[EMAIL PROTECTED]
snip/
I expect Woody to also take another year or so before it can
be considered stable (in terms of interfaces, not code).
... that long? I expected it to be stable sooner (end of this
From: Bruno Dumon
On Thu, 2003-09-11 at 14:19, Reinhard Poetz wrote:
From: Bruno Dumon [mailto:[EMAIL PROTECTED]
snip/
I expect Woody to also take another year or so before it can
be considered stable (in terms of interfaces, not code).
... that long? I expected it to be
On Thu, 2003-09-11 at 19:47, Reinhard Poetz wrote:
snip/
What do you think?
I think we're almost there. Lets wait a few more days to give
others a chance to comment, and then launch a vote.
fine, go ahead when you think it's time for it.
ok. I'm not here though next week, so if it
Hi folks,
forgive me for putting on my BOFH hat, while making the following
observations...
1) We suck at freezing and stabilizing the codebase prior to releases.
I would suggest that, from now on, the Release Manager puts forward a
release date after discussion on the dev list, and that
From: Steven Noels
Hi folks,
forgive me for putting on my BOFH hat, while making the following
observations...
1) We suck at freezing and stabilizing the codebase prior to releases.
I would suggest that, from now on, the Release Manager puts forward a
release date after discussion
Le Mercredi, 10 sep 2003, à 11:26 Europe/Zurich, Reinhard Poetz a écrit
:
...Would it be enough to extend our Anteater scripts (see Guido's
mail) and
add Anteater to our codebase and include it automatically to our build
system? ...
certainly a Good Thing it tests are not too hard to write -
Steven Noels [EMAIL PROTECTED] wrote:
3) Given the breakage in the Rhino stuff, and the lack of serious
testing on the 2.1.1 release, I would refrain from announcing 2.1.1
How about putting a hotfix on the dist site like Tomcat is doing
http://nagoya.apache.org/mirror/jakarta/tomcat-4/binaries/
Steven Noels wrote:
Hi folks,
forgive me for putting on my BOFH hat, while making the following
observations...
1) We suck at freezing and stabilizing the codebase prior to releases.
I would suggest that, from now on, the Release Manager puts forward a
release date after discussion on the dev
99 matches
Mail list logo
