+1
Upayavira wrote:
Carsten Ziegeler wrote:
The release is built and I'll announce everything tomorrow. This means
we should update the website (and docs) tomorrow as well. Can someone
please do this?
A request, from a marketing perspective. Could we write a special
announcement for
Jorg Heymans wrote:
I think this release in particular has shown that cocoon in its current
monolithic form is detriment to our release cycle. Let's keep that first
2.2 release in clear sight !
Jorg
Good point. I think it would be a good idea to schedule a date for
2.1.9 and 2.2-M1 now.
hepabolu wrote:
Carsten Ziegeler wrote:
hepabolu wrote:
Ok, I just committed your changes - and I think everything should be ok
-perhaps you can please verify? There are some display problems at
least with IE, e.g. in the AppCoplet tab.
I just ran the site in cocoon zones and noticed a
hepabolu wrote:
Carsten Ziegeler wrote:
hepabolu wrote:
Ok, I just committed your changes - and I think everything should be ok
-perhaps you can please verify? There are some display problems at
least with IE, e.g. in the AppCoplet tab.
I just ran the site in cocoon zones and noticed a
hepabolu wrote:
Just a quick change, might need some polishing. Replace the portal.css
in files with the one attached and add the gif to files.
Have fun. ;-)
Bye, Helma
Very nice.
Ralph
Carsten Ziegeler wrote:
This is another try to get 2.1.8 finally out:
Please cast your votes for releasing 2.1.8 tomorrow, 8th of November.
Carsten
+1
Ralph
On second thought, why are these not sent to the doc list?
Ralph Goers wrote:
Is this an effort to get our message traffic numbers even higher?
Sorry, but these messages are now filtered straight to the trash.
[EMAIL PROTECTED] wrote:
Automated build for cocoon-site FAILED
Log attached
Carsten Ziegeler wrote:
Ralph Goers wrote:
OK. I took a more comprehensive approach and believe I have fixed
this. Please give it a whirl and let me know if you have any problems.
I haven't had a chance to look into your latest changes on trunk. I'll
take a look at them and see
At once an hour I'd bet I'm not the only one who is sending them to the
bit bucket. When gump fails it isn't quite so annoying.
David Crossley wrote:
Reinhard Poetz wrote:
Ralph Goers wrote:
On second thought, why are these not sent to the doc list?
Yes please
Is this an effort to get our message traffic numbers even higher?
Sorry, but these messages are now filtered straight to the trash.
[EMAIL PROTECTED] wrote:
Automated build for cocoon-site FAILED
Log attached.
--
Forrestbot run ended at 06 November 07:10 AM
Using Forrest 0.7
Just as well. I'm still trying to get the portal full screen working
properly. If I can't get it working tomorrow I'll have to back the
change out as I'll be away next week.
Ralph
Carsten Ziegeler wrote:
To be honest I'm not really happy about this vote: I counted only four
votes! I'm
Carsten Ziegeler wrote:
Ralph Goers wrote:
And what about the case that I added support for - full screen with all
the navigation still present?
Actually, your changes broke the full screen feature if no tab is
available. If you look at the current portal demo, full screen does
Carsten Ziegeler wrote:
Ralph Goers wrote:
And what about the case that I added support for - full screen with all
the navigation still present?
Actually, your changes broke the full screen feature if no tab is
available. If you look at the current portal demo, full screen does
Jorg Heymans wrote:
What if there is no real need for an api block? Do we still add it and
define for example the cocoon-core dependency there or do we leave it
out alltogether ?
I would lead it out altogether. Leaving it in kind of implies that
there should be an api and will probably
Sylvain Wallez wrote:
About the logo, however, I really prefer the current one, which is way
more readable and is also well-known.
Sylvain
I prefer the current one as well, but I have to be honest. I've always
wondered why the logo isn't a cocoon?
Ralph
The portal requires that the IncludingHTMLSerializer be used to generate
the content of any JSR-168 portlets. This works fine for portlets which
generate HTML. However, our sites are required to generate only XHTML.
So I have a few questions.
1. HTMLSerializer sets the output format to
Joerg Heinicke wrote:
On 02.11.2005 15:42, Ralph Goers wrote:
I've always wondered why the logo isn't a cocoon?
Aren't there 3 o's each cocooning a dot?
Jörg
Yes, there are 3 o's each containing a dot. In what strange world does
that make them into cocoon's?
These look more like
Jorg Heymans wrote:
I won't argue marketing tactics here. If this is the general feeling
then I have no problem with this :)
FWIW, my suggestion was inspired by the maven project, compare [1] with
[2]. (ok their first logo wasn't really a logo, but still)
Jorg
[1]
[EMAIL PROTECTED] wrote:
Author: cziegeler
Date: Wed Nov 2 11:50:24 2005
New Revision: 330329
URL: http://svn.apache.org/viewcvs?rev=330329view=rev
Log:
Start suppport for static layouts
So, you decided to do this. Do you have a plan to keep it from killing
performance?
Ralph
Carsten Ziegeler wrote:
Please cast your votes for releasing 2.1.8 on friday, 4th of November.
(if we vote to not release on friday, I can do the release on any day in
the next week).
Carsten
+1
Carsten Ziegeler wrote:
Ralph Goers wrote:
So, you decided to do this.
Yes :)
Do you have a plan to keep it from killing
performance?
Yepp, the information will be stored as a temporary attribute on a
layout. FOr example for full-screen, the full-screen coplet layout
[ http://issues.apache.org/jira/browse/COCOON-1666?page=all ]
Ralph Goers updated COCOON-1666:
Assign To: Ralph Goers
The test was with page labels and marshalling enabled. I missed one
configuration item - uncommenting the parameter-name
[ http://issues.apache.org/jira/browse/COCOON-1666?page=all ]
Ralph Goers closed COCOON-1666:
---
Resolution: Invalid
Saving of JSR-168 preferences does not appear to be working
Reinhard Poetz wrote:
Bertrand, your comment makes me think why we don't use Daisy as Wiki
too? Any reasons for this? It would also make it much simpler to move
over docs from a wiki zone into our official documentation.
Well, I'm +1 but this raises a significant issue. There was a
Reinhard Poetz wrote:
Bertrand, your comment makes me think why we don't use Daisy as Wiki
too? Any reasons for this? It would also make it much simpler to move
over docs from a wiki zone into our official documentation.
Well, here is another option. Geronimo was proposing to use
Joerg Heinicke wrote:
On 25.10.2005 09:06, Bart Molenkamp wrote:
(Can it be discussed here, or do I need to add them as comments to
the issue too?)
Of course.
I don't totally agree with your latest comment. The CacheValidity
won't solve the problem, IMO it's a problem with the ID being
Carsten Ziegeler wrote:
We had some feedback in the last days wrt to the 2.1.8 release.
As I'm having access to a unix system tomorrow and next friday (but not
inbetween), I can do the release either tomorrow or we can use another
week to fix some possible issues and release next friday.
So
Saving of JSR-168 preferences does not appear to be working.
Carsten Ziegeler wrote:
We had some feedback in the last days wrt to the 2.1.8 release.
As I'm having access to a unix system tomorrow and next friday (but not
inbetween), I can do the release either tomorrow or we can use another
Unless I have screwed something up, it appears the
ConvertableEventAspect is not doing its job. I can't test any more
tonight. It is very late.
Ralph
Ralph Goers wrote:
Saving of JSR-168 preferences does not appear to be working.
Carsten Ziegeler wrote:
We had some feedback in the last
Daisy isn't really appropriate for this. Users should be able to update
the matrix too.
Ralph
Ross Gardler wrote:
Bertrand Delacretaz wrote:
Le 27 oct. 05, à 09:14, Ralph Goers a écrit :
...it would be great if we had a testing matrix of JVMs, Servlet
Containers and operating systems
and different Tomcat versions
--
Key: COCOON-1665
URL: http://issues.apache.org/jira/browse/COCOON-1665
Project: Cocoon
Type: Task
Versions: 2.1.8-dev (Current SVN)
Reporter: Ralph Goers
Priority: Minor
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Now the problem comes from the property search order, which follows the
exact same path, meaning the most generic properties (in
WEB-INF/properties) hide any overriding in specific properties (user
settings, system properties).
I reverted
Daniel Fagerstrom wrote:
Don't wait on that, I'm not clear about it my self ;)
The idea is that I would assume that when we test a block it is best
to do it in an environment that is as close as possible to the
environment it will be used in. For an OSGi bundle this means that it
will get
hepabolu wrote:
Berin Loritsch wrote:
In the period of about 12 hours there has been over 120 messages
generated by JIRA. All to do with opening and closing issues, etc.
While it is to be expected that the introduction of the new tool is
going to require some rampup time, Its hard to see
Pier Fumagalli wrote:
On 25 Oct 2005, at 15:23, Berin Loritsch wrote:
Thanks.
Is it still possible to have digest emails sent to the dev list
instead of one
per alteration? I think that is the most sensible option to
minimize the
signal to noise ratio on the list.
Once all this
Torsten Curdt wrote:
Gang,
there are a few things regarding the current flow machinery that
are bugging me for quite a while now. In order to support flow
serialization they need to be addressed.
1. Class vs Interface
The WebContinuation is currently a class. IMO it makes much more
sense to
I want to create a portal component and move the portal issues into
that. How can I accomplish that? I don't see a way to change the
component an issue is assigned to or a way to create a new component.
Ralph
Pier Fumagalli wrote:
On 24 Oct 2005, at 16:23, Ralph Goers wrote:
I want to create a portal component and move the portal issues into
that. How can I accomplish that? I don't see a way to change the
component an issue is assigned to or a way to create a new component
Pier Fumagalli wrote:
There are already two components: The Portal Block and the
deprecated Portal-FW block...
Pier
The table below is what I see (Sorry for the html). I don't see the
portal block.
Reinhard Poetz wrote:
Ralph Goers wrote:
Pier Fumagalli wrote:
There are already two components: The Portal Block and the
deprecated Portal-FW block...
Pier
The table below is what I see (Sorry for the html). I don't see the
portal block.
You can't see the component Portal
[ http://issues.apache.org/jira/browse/COCOON-1474?page=all ]
Ralph Goers updated COCOON-1474:
Bugzilla Id: (was: 34025)
Component: * Cocoon Core
(was: Blocks: (Undefined))
Description:
I have reproduced this in both
[ http://issues.apache.org/jira/browse/COCOON-1523?page=all ]
Ralph Goers updated COCOON-1523:
Bugzilla Id: (was: 35228)
Component: Blocks: XSP
(was: Blocks: (Undefined))
Description:
In [1] in we discussed an XSP
[ http://issues.apache.org/jira/browse/COCOON-1557?page=all ]
Ralph Goers updated COCOON-1557:
Bugzilla Id: (was: 35672)
Component: Blocks: Java Flow
(was: Blocks: (Undefined))
Description:
The attached patch changes
[ http://issues.apache.org/jira/browse/COCOON-1391?page=all ]
Ralph Goers updated COCOON-1391:
Bugzilla Id: (was: 32935)
Component: Blocks: XSP
(was: Blocks: (Undefined))
Description:
Whilst the cache of compiled XSPs
[ http://issues.apache.org/jira/browse/COCOON-1286?page=all ]
Ralph Goers updated COCOON-1286:
Bugzilla Id: (was: 31564)
Component: Blocks: XSP
(was: Blocks: (Undefined))
Description:
Are you using the jpath logicsheet
[ http://issues.apache.org/jira/browse/COCOON-1280?page=all ]
Ralph Goers updated COCOON-1280:
Bugzilla Id: (was: 31493)
Component: Blocks: XSP
(was: Blocks: (Undefined))
Description:
The xsp logix sheet jpath.xsl
[ http://issues.apache.org/jira/browse/COCOON-1251?page=all ]
Ralph Goers updated COCOON-1251:
Bugzilla Id: (was: 30971)
Component: Blocks: XSP
(was: Blocks: (Undefined))
Description:
I am trying to use the new JDK1.5
[ http://issues.apache.org/jira/browse/COCOON-1196?page=all ]
Ralph Goers updated COCOON-1196:
Bugzilla Id: (was: 29864)
Component: Blocks: XSP
(was: Blocks: (Undefined))
Description:
If an input module namespace
[ http://issues.apache.org/jira/browse/COCOON-1450?page=all ]
Ralph Goers updated COCOON-1450:
Bugzilla Id: (was: 33637)
Component: * Cocoon Core
(was: Blocks: (Undefined))
Description:
I've tried using i18n tags
[ http://issues.apache.org/jira/browse/COCOON-1639?page=all ]
Ralph Goers updated COCOON-1639:
Bugzilla Id: (was: 37023)
Component: Blocks: HTML
(was: Blocks: (Undefined))
Description:
The html block contains
[ http://issues.apache.org/jira/browse/COCOON-1608?page=all ]
Ralph Goers updated COCOON-1608:
Bugzilla Id: (was: 36736)
Component: Blocks: WebDAV
(was: Blocks: (Undefined))
Description:
Trace Back:
[exec
[ http://issues.apache.org/jira/browse/COCOON-1600?page=all ]
Ralph Goers updated COCOON-1600:
Bugzilla Id: (was: 36686)
Component: Blocks: XML-DB
(was: Blocks: (Undefined))
Description:
There is currently no way
[ http://issues.apache.org/jira/browse/COCOON-1584?page=all ]
Ralph Goers updated COCOON-1584:
Bugzilla Id: (was: 36371)
Component: Blocks: WebDAV
(was: Blocks: (Undefined))
Description:
When WebDAVSource fails
[ http://issues.apache.org/jira/browse/COCOON-1578?page=all ]
Ralph Goers updated COCOON-1578:
Bugzilla Id: (was: 36299)
Component: Blocks: Proxy
(was: Blocks: (Undefined))
Description:
http://localhost:/samples
[ http://issues.apache.org/jira/browse/COCOON-1574?page=all ]
Ralph Goers updated COCOON-1574:
Bugzilla Id: (was: 36162)
Component: * Cocoon Core
(was: Blocks: (Undefined))
Description:
I'm currently looking
[ http://issues.apache.org/jira/browse/COCOON-1547?page=all ]
Ralph Goers updated COCOON-1547:
Bugzilla Id: (was: 35575)
Component: Blocks: XML-DB
(was: Blocks: (Undefined))
Description:
In some rare circumstances
[ http://issues.apache.org/jira/browse/COCOON-1549?page=all ]
Ralph Goers updated COCOON-1549:
Bugzilla Id: (was: 35578)
Component: Blocks: Batik
(was: Blocks: (Undefined))
Description:
A bug has been filed at Batik
[ http://issues.apache.org/jira/browse/COCOON-1536?page=all ]
Ralph Goers updated COCOON-1536:
Bugzilla Id: (was: 35444)
Component: Blocks: STX
(was: Blocks: (Undefined))
Description:
Cocoon ships with an old version
[ http://issues.apache.org/jira/browse/COCOON-1351?page=all ]
Ralph Goers updated COCOON-1351:
Bugzilla Id: (was: 32289)
Component: * Cocoon Core
(was: Blocks: (Undefined))
Description:
The fragment id generated
[ http://issues.apache.org/jira/browse/COCOON-1339?page=all ]
Ralph Goers updated COCOON-1339:
Bugzilla Id: (was: 32199)
Component: Blocks: Portal
(was: Blocks: (Undefined))
Description:
Hi!
I've found a bug in the new
[ http://issues.apache.org/jira/browse/COCOON-1148?page=all ]
Ralph Goers updated COCOON-1148:
Bugzilla Id: (was: 28724)
Component: * Cocoon Core
(was: Blocks: (Undefined))
Description:
From the code it is not a caching
[ http://issues.apache.org/jira/browse/COCOON-1320?page=all ]
Ralph Goers updated COCOON-1320:
Bugzilla Id: (was: 32011)
Component: Blocks: Databases
(was: Blocks: (Undefined))
Description:
The buildList method
[ http://issues.apache.org/jira/browse/COCOON-1316?page=all ]
Ralph Goers updated COCOON-1316:
Bugzilla Id: (was: 31889)
Component: * Cocoon Core
(was: Blocks: (Undefined))
Description:
The i18nTransformer cannot format
[ http://issues.apache.org/jira/browse/COCOON-1259?page=all ]
Ralph Goers updated COCOON-1259:
Bugzilla Id: (was: 31064)
Component: Blocks: XML-DB
(was: Blocks: (Undefined))
Description:
This patch allows a user
[ http://issues.apache.org/jira/browse/COCOON-1256?page=all ]
Ralph Goers updated COCOON-1256:
Bugzilla Id: (was: 31011)
Component: Blocks: XML-DB
(was: Blocks: (Undefined))
Description:
this patch allow to set user
[ http://issues.apache.org/jira/browse/COCOON-1249?page=all ]
Ralph Goers updated COCOON-1249:
Bugzilla Id: (was: 30928)
Component: Blocks: XML-DB
(was: Blocks: (Undefined))
Description:
It should be possible to have
[ http://issues.apache.org/jira/browse/COCOON-1248?page=all ]
Ralph Goers updated COCOON-1248:
Bugzilla Id: (was: 30924)
Component: Blocks: XML-DB
(was: Blocks: (Undefined))
Description:
The method getInputStream() does
[ http://issues.apache.org/jira/browse/COCOON-1243?page=all ]
Ralph Goers updated COCOON-1243:
Bugzilla Id: (was: 30849)
Component: Blocks: XML-DB
(was: Blocks: (Undefined))
Description:
The code assumes
[ http://issues.apache.org/jira/browse/COCOON-1165?page=all ]
Ralph Goers updated COCOON-1165:
Bugzilla Id: (was: 29061)
Component: Blocks: XML-DB
(was: Blocks: (Undefined))
Description
[ http://issues.apache.org/jira/browse/COCOON-1182?page=all ]
Ralph Goers updated COCOON-1182:
Bugzilla Id: (was: 29524)
Component: Blocks: XML-DB
(was: Blocks: (Undefined))
Description:
Hi,
I was trying to write
[ http://issues.apache.org/jira/browse/COCOON-1116?page=all ]
Ralph Goers updated COCOON-1116:
Bugzilla Id: (was: 28189)
Component: Blocks: WebDAV
(was: Blocks: (Undefined))
Description:
Fixes an obvious copy n paste
[ http://issues.apache.org/jira/browse/COCOON-1123?page=all ]
Ralph Goers updated COCOON-1123:
Bugzilla Id: (was: 28311)
Component: Blocks: WebDAV
(was: Blocks: (Undefined))
Description:
This patch integrates a new
[ http://issues.apache.org/jira/browse/COCOON-806?page=all ]
Ralph Goers updated COCOON-806:
---
Bugzilla Id: (was: 23002)
Component: Blocks: POI
(was: Blocks: (Undefined))
Description:
The gmr:PrintInformation element
[ http://issues.apache.org/jira/browse/COCOON-1066?page=all ]
Ralph Goers updated COCOON-1066:
Bugzilla Id: (was: 27279)
Component: Blocks: Naming
(was: Blocks: (Undefined))
Description:
This patch addresses 2 issues
Jorg Heymans wrote:
Hi,
How do people feel about moving sample content and source from a block
out of the block directory into its own location ?
Carsten already did that for the portal, although not with either of the
directory structures you list below. Ultimately this needs to be
Jorg Heymans wrote:
Ralph Goers wrote:
I don't like this structure much. I prefer
/src
/blocks
/cforms
/api
pom.xml
/impl
pom/xml
/samples
pom.xml
Joerg Heinicke wrote:
On 23.10.2005 13:40, Upayavira wrote:
Sorry, I'm afraid I don't understand what you are saying!
No problem, let me try a second time:
Ralph made a proposal [1] where exactly one block (= directory) per
block (= block in the narrower sense) exists, but with many
Daniel Fagerstrom wrote:
* M2 stable enough (2.0 is out so this should be fullfilled)
* Reasonably fast (don't need to be as fast as Ant, but not several
times slower)
For me, this isn't an issue.
* Easy configuration of what blocks to compile (like blocks.properties
and maybe even
Daniel Fagerstrom wrote:
Joerg Heinicke wrote:
...
Ralph made a proposal [1] where exactly one block (= directory) per
block (= block in the narrower sense) exists, but with many modules
(in the maven sense) in them:
/src
/blocks
/cforms
/api
Jorg Heymans wrote:
Ralph Goers wrote:
/src
/blocks
/cforms
/api
pom.xml
/impl
pom/xml
/samples
pom.xml
/test
pom.xml
Andrew Savory wrote:
* We really need to get rid of obsolete stuff. Must really every
single block go to 2.2? Are there some oneman shows that better
could be returned to their creator and driven on source forge or
Cocoon-dev?
Hmm. I'm not convinced of this. The problem is that we
Upayavira wrote:
Basically, we relegate blocks not by removing or reducing them, but my
lifting others. We will have a background of many blocks, many one man
shows, half maintained ones, etc. However, we will also have lists
saying these are the cool ones, the ones that really work and are
Out of curiosity, when exactly does tonight begin?
Ralph
Carsten Ziegeler wrote:
The code freeze for the 2.1.8 release starts tonight and ends next
friday (hopefully) with the release of 2.1.8.
The usual committing rules for a code freeze apply.
Thanks
Carsten
Sylvain Wallez wrote:
Sylvain Wallez wrote:
snip/
Activating this second feature requires to change the XSLTProcessor
implementation to o.a.c.c.xslt.XSLTProcessorImpl
Damn! While porting to the 2.1 branch, I realized that this conflict
with the same class that exists in the deprecated
Sylvain Wallez wrote:
Ralph Goers wrote:
Sylvain Wallez wrote:
Sylvain Wallez wrote:
snip/
Activating this second feature requires to change the XSLTProcessor
implementation to o.a.c.c.xslt.XSLTProcessorImpl
Damn! While porting to the 2.1 branch, I realized that this conflict
Carsten Ziegeler wrote:
Ok, I think it's safer to just vote on this as well - again the majority
wins. We already agreed on using just HTML for the docs.
Please cast your votes for:
a) Include the docs in the distribution
b) Provide a separate docs package to download
The docs will be the
In looking this over and it occured to me that if you are going to make
all events be convertable that:
a) we won't need the marshall events flag anymore,
b) It should end up that only the events needed to process the current
request will end up in the decode list of the DefaultEventConverter.
Apologies to the list. This thread was started off-list but really
belongs here.
Carsten Ziegeler wrote:
Hi Ralph,
Ralph Goers wrote:
OK. I did notice that you got rid of the fullscreen event yesterday.
That was a good thing.
Yepp, I'm trying to clean up the mess we created
Carsten Ziegeler wrote:
Yepp, that's exactly the idea. And this was how we implement it in the
first place. Now imagine that you have a hugh tree of layouts and down
the tree there is one layout/coplet that is now maximized. When you
start rendering the whole portal, you first have to crawl
Carsten Ziegeler wrote:
Ralph Goers wrote:
I have a concern over the hascode that is used in the
DefaultEventConverter. Although it may not be likely, hash algorithms
can return duplicate values so this is not guaranteed to always work.
Yes, you can configure a mapping on the event
Carsten Ziegeler wrote:
Bart Molenkamp wrote:
And I thought that people here rather move away from Avalon's
interfaces. Then why introduce another dependency on it, when
configuration can do the same?
Yes, I tend to agree with you. So let's forget about the new interface
and use the
Carsten Ziegeler wrote:
I want to deprecate the AbstractUserProfileManager and the
AuthenticationProfileManager in the portal in 2.1.8 (and remove them in
2.2).
The newer GroupBasedProfileManager provides the same functionality in a
much cleaner way. With deprecating the old stuff, we can get
Sylvain Wallez wrote:
And actually 3 resolvers, as we also have the one in setup() of
sitemap components :-)
Here's another suggestion that doesn't need a new component.
First of all, when a component is setup (i.e. Avalon lifecycle
interfaces), the relative path must *always* be the one
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
It seems that most major problems have been solved and we can release.
To give everyone some more days time to finish/polish everything, I
propose to start the code freeze on friday, 21st of October, and I will
do the release one week later on
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Isn't 1999-2005 enough?
Well, actually yes, and to be honest 1999 is wrong anyway as the code
has been written later...but I don't want to touch the old values, I'm
just adding the year of the latest change (which is actually not really
Bertrand Delacretaz wrote:
Le 17 oct. 05, à 12:00, Upayavira a écrit :
...2. HTML Files.
PDF can go on website. Otherwise it adds 5Mb to the download..
Same here, and I think the PDF of that release should not be
overwritten with the next release, it should stay archived. Which
means
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
+1.
And as we decided to have fixed releases, what about planning 2.1.9
right now?
Let's say that code freeze for 2.1.9 starts on 20th January (3rd friday)
and release happens on 27th.
Hmm, do we need fixed dates for a maintenance
Carsten Ziegeler wrote:
Starting with 2.2 we want to have different release cycles etc. for each
block so I think it's time to split up the status.xml file and create a
file for each block.
This status file will only contain the changes (no committers list) for
this block.
I think splitting
Carsten Ziegeler wrote:
It seems that most major problems have been solved and we can release.
To give everyone some more days time to finish/polish everything, I
propose to start the code freeze on friday, 21st of October, and I will
do the release one week later on 28th of October.
WDYT?
Carsten Ziegeler wrote:
Ralph Goers wrote:
2. It seems a little wierd to have the developer's initials on status
items without that being defined anywhere in the file. changes.xml is
similar to status.xml in that each action has a dev attribute with the
developer's id which refers back
501 - 600 of 1276 matches
Mail list logo
