Proposal: interactive planning session for views/xhtml2/internals
(See also previous discussion in this thread.) Diwaker Gupta wrote: We need to be clear on what we are going to achieve and how *before* having a Forrest Tuesday event. To an extent. It is very hard to be clear beforehand. I agree. Besides, I think FT's provide a unique opportunity for people to collaboratively explore new directions. This is important, because even if we are clear on what we want to achieve, unexpected surprises might come up on the way (implementation details/limitations that we didn't think of earlier etc) so we need some kind of slack. No, having asynchronous discussion will sort out the issues. This is not noise, it is very important dicussion that is analysing the experimental work carried out on Forrest Tuesday. We have to find what is valuable about that approach and what is valuable about the alternative approaches that have not yet been worked on. It will sort out issues eventually. But I agree with Gavin that there seems to be a lot of confusion as to what was achieved and how valuable it was during the last FT. For me it was extremely valuable and am looking forward to the next one. I reckon that the confusion is mainly because we have a hard topic, and secondly because some things are hard to talk about in email. Personally, I think it was great -- well begun is half done, and I think after all those discussions on XHTML2 it was a good first step. True we might have wasted time, and we might end up implementing the same thing over and over again -- apart from the learning experience people had, I think this has value of its own in terms of understanding exactly what are the hard problems that we need to focus on. I wonder if we can gather together for an hour or two to just discuss in real time where we are going. Define some objectives. It could be an IRC session. For me the other day i found it difficult to hold multi-facetted discussion. Still worthwhile. It could be a Skype internet telephony session. That would also be difficult with a large number of people. It could work if we all allow space for other people to talk, only talk when we really need. Perhaps a round-robin where we take it in turns to add our pieces with the chair pulling up people that go on too long. This would be open to anyone to be involved. We would need to bring a summary back to the list. This is not something that we would do on a regular basis, but it seems that occasional sessions might help. I am reluctant to suggest it, because we all know that mailing list communication is the way to enable the whole community to be involved and not disadvantage any. Diwaker wrote: +1 for IRC. +0 for Skype. Weekends work best for me, I'll go with the majority. If there is no one against this idea, then we could define what we want to achieve and find a suitable time slot. WDYT? Lets do it! Addi said: I prefer IRC just because I am more familiar with it (never used Skype but am willing to try it out), although I agree about the misinterpretation being higher with written rather than spoken communication. I would mainly be listening anyway so whatever works best for others is fine with me. Thanks. Skype is easy - install it and try. Talk to the nice lady at the account 'echo123' use headphones to avoid feedback into internal mike. Well that is a few interested, but we are not going to do it unless the project is well-represented, with a majority of the people who are interested in the core views/xhtml/sitemaps issues. Remember, the proposal is not about making decisions or doing work. Looking for a suitable time. If it doesn't suit then propose another: http://www.timeanddate.com/worldclock/meetingtime.html?day=11month=9year=2005p1=136p2=48p3=176p4=240p5=224p6=213 1) Saturday, September 10, 2005 at 20:00:00 1) Sunday, September 11, 2005 at 19:00:00 So far the following people are interested. Please state if you have time or date restrictions: Ross Diwaker David - any time, any day, try Skype, IRC okay Addi
Re: [FT] 2005-09-06 Summary
Diwaker Gupta wrote: I live in San Diego :-) So I'm definitely going to be there (modulo certain unexpected events in my calendar). Hey, good to hear that. I didn't like the idea of being the only committer there at all. -- Ferdinand Soethe
Re: [FT] 2005-09-06 Summary
But I should warn you, so you're not shocked if you meet me, I'm actually a she. :) I think we are getting a little distracted from the real issues here: DO you brew good beer of don't you? And will you bring some to SD? But more seriously: This might be a good opportunity to have a Hackathon focused on getting the structure for our Forrest manual started? -- Ferdinand Soethe
[Fwd: Serious bug in tree processor]
Hi, I think that this bug would affect us, so I decided to upgrade to cocoon revision as for today. Let me know if you find any trouble... Cheers, cheche ---BeginMessage--- I just found a big bug in our treeprocessor (2.1.8-dev and 2.2 are effect, in 2.1.7 this works perfectly): if you have several pipeline sections in the sitemap using different pipeline implementations, always the first configured is used. For example: map:pipeline type=expires ... /map:pipeline map:pipeline type=noncaching map:match pattern=a ... /map:pipeline In the example above, the expires pipeline us even used if you request a. The problem is in the PipelineNode, line . The getProcessingPipeline() method is called to set the error handler in each encountered pipeline section. The InvokeContext checks in this method if a pipeline has already been instantiated and only creates one if not. I just checked in a quick fix which resets the processing pipeline in the inform() method of the InvokeContext, but I'm not sure if this is the best way. Imho we should only lookup the pipeline component if it is really used. Perhaps this is as well the cause of Reinhard's problem wrt caching. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ ---End Message---
Tedios work and revision number
Hi,
In order to save network traffic and history, I move our jars on the
lib/core instead of removing and adding a new version.
As you know there is this historical convention pre-SVN of having a date
in the name of the library if this library comes from a non-released copy.
Because of that, every time I have to upgrade cocoon to a newest
revision number I have to do these steps that are a bit tedious:
7a. For each cocoon-{name}-{cocoon.version}-{cocoon.revision}.jar:
svn mv cocoon-{name}-{cocoon.version}-{cocoon.OLDrevision}.jar
cocoon-{name}-{cocoon.version}-{cocoon.NEWrevision}.jar
svn ci -m prework for upgrade to {cocoon.NEWrevision}
I would like to simplify this for cocoon and other libraries (jtidy and jcs)
can anyone remember why has to be like that?
would it be enough to have it on the svn history?
Cheers,
cheche
Re: How to apply an update to 0.7
Ferdinand Soethe wrote: I would like to apply these two updates to 0.7 to fix bugs and make 0.7 usable in a project and a have some questions on procedure: - What is the procedure on doing that? Lazy consensus, just do it? Any changes that have been made to trunk can be also applied to the maintenance branch. Just do whatever. I already synchronised some. - How do I best apply these? My best guess is: co /forrest/branches/forrest_07_branch/ apply changes describes below ci changes I'm sure creating and applying a patch file would be smarter but I'm not sure on the exact steps to so that. I just copy the files in question from the trunk to the branch, then diff, commit. - QA Is anybody checking this branch for line ending probems etc before it is made available for download as a package? If not what is a foolproof test to check if my line endings are correct? No. But it can be done. It is not being released, so no download package. People can easily package it themselves, see the package instruction in etc/RELESE_PROCESS.txt (only need the packaging step). In the past, we have not done releases of a branch unless it has been specifically requested. The 0.5.1 was due to a cocoon issue. So if there are important issues then we can do a release. There have been a couple of important fixes already. How to check the line endings. There is a script in the ASF comitters repository at the tools directory. Also see the Cocoon page: http://cocoon.apache.org/community/committer.html If that doesn't work for you then i will check it. -David Thanks for your help, Ferdinand Author: ferdinand Date: Sat Jul 30 03:45:40 2005 New Revision: 226492 URL: http://svn.apache.org/viewcvs?rev=226492view=rev Log: Fixed problem of IMG with id-attributes disappearing. Modified: forrest/trunk/main/webapp/skins/common/xslt/html/document2html.xsl Modified: forrest/trunk/main/webapp/skins/common/xslt/html/document2html.xsl URL: http://svn.apache.org/viewcvs/forrest/trunk/main/webapp/skins/common/xslt/html/document2html.xsl?rev=226492r1=226491r2=226492view=diff == --- forrest/trunk/main/webapp/skins/common/xslt/html/document2html.xsl (original) +++ forrest/trunk/main/webapp/skins/common/xslt/html/document2html.xsl Sat Jul 30 03:45:40 2005 @@ -368,8 +368,13 @@ !-- End of toc mode templates -- xsl:template match=node()|@* priority=-1 +!-- id processing will create its own a-element so processing has to + happen outside the copied element +-- +xsl:apply-templates select=@id/ xsl:copy - xsl:apply-templates select=@*/ + xsl:apply-templates select=@*[name(.) != 'id']/ + xsl:copy-of select=@id/ xsl:apply-templates/ /xsl:copy /xsl:template Author: ferdinand Date: Mon Jul 25 10:59:13 2005 New Revision: 225159 URL: http://svn.apache.org/viewcvs?rev=225159view=rev Log: Fixed/added pass-through for id-attribute in several elements Modified: forrest/trunk/main/webapp/skins/common/xslt/html/document2html.xsl forrest/trunk/main/webapp/skins/pelt/xslt/html/document2html.xsl Modified: forrest/trunk/main/webapp/skins/common/xslt/html/document2html.xsl URL: http://svn.apache.org/viewcvs/forrest/trunk/main/webapp/skins/common/xslt/html/document2html.xsl?rev=225159r1=225158r2=225159view=diff == --- forrest/trunk/main/webapp/skins/common/xslt/html/document2html.xsl (original) +++ forrest/trunk/main/webapp/skins/common/xslt/html/document2html.xsl Mon Jul 25 10:59:13 2005 @@ -192,6 +192,7 @@ xsl:template match=[EMAIL PROTECTED]:space='preserve'] xsl:apply-templates select=@id/ div class=pre + xsl:copy-of select=@id/ xsl:apply-templates/ /div /xsl:template @@ -200,6 +201,7 @@ xsl:apply-templates select=@id/ pre class=code !-- Temporarily removed long-line-splitter ... gives out-of-memory problems -- + xsl:copy-of select=@id/ xsl:apply-templates/ !-- xsl:call-template name=format @@ -211,26 +213,33 @@ /xsl:template xsl:template match=anchor -a name=[EMAIL PROTECTED]/ +a name=[EMAIL PROTECTED] + xsl:copy-of select=@id/ +/a /xsl:template xsl:template match=icon xsl:apply-templates select=@id/ img class=icon -xsl:copy-of select=@height | @width | @src | @alt/ + xsl:copy-of select=@height | @width | @src | @alt | @id/ /img /xsl:template xsl:template match=code xsl:apply-templates select=@id/ -span class=codefragxsl:value-of select=.//span +span class=codefrag + xsl:copy-of select=@id/ + xsl:value-of select=./
Re: Tedios work and revision number
Juan Jose Pablos wrote:
Hi,
In order to save network traffic and history, I move our jars on the
lib/core instead of removing and adding a new version.
It would be better to do the 'svn remove; svn add'.
Why do we need history on these?
As you know there is this historical convention pre-SVN of having a date
in the name of the library if this library comes from a non-released copy.
Because of that, every time I have to upgrade cocoon to a newest
revision number I have to do these steps that are a bit tedious:
7a. For each cocoon-{name}-{cocoon.version}-{cocoon.revision}.jar:
svn mv cocoon-{name}-{cocoon.version}-{cocoon.OLDrevision}.jar
cocoon-{name}-{cocoon.version}-{cocoon.NEWrevision}.jar
svn ci -m prework for upgrade to {cocoon.NEWrevision}
Why not just remove and add?
I would like to simplify this for cocoon and other libraries (jtidy and jcs)
can anyone remember why has to be like that?
So that we know the exact version of Cocoon that
it came from. This enables people who use our
software to track any bugs in the supporting libaries.
Note that there is the validation block that is
not the same revision number as the other cocoon jars.
There could be a shell script to do that update.
would it be enough to have it on the svn history?
Only if committers remember to add the revision number
to the commit message, so probably not. Also the naming
convention means that users don't need to wade through
our SVN logs to find out which version.
-David
Re: Proposal: interactive planning session for views/xhtml2/internals
Gav wrote: At this stage, with me still learning a lot, I feel I would have not much to 'say' with using Skype at this stage, although I would certainly consider it in the future, I will not use it this time round. That said, I would feel comfortable using IRC again, being able to watch and learn and also ask where I get stuck. We are not doing anything, just talking, and some people will take notes. If IRC is used, those times are ok for me but I will be late joining the party as being in Perth they translate to 4am and 3am. I could be around from 6am tomorrow. The second time will be Monday morning and I would have to go to work after a couple of hours. We can change the time to suit. I chose that because i thought that you were east coast Australia and that fitted with the rest of the world. Not much time to get everyone together, but hope we get enough. It is not looking good, so proably need to wait another week. -David
Re: Proposal: interactive planning session for views/xhtml2/internals
Looking for a suitable time. If it doesn't suit then propose another: http://www.timeanddate.com/worldclock/meetingtime.html?day=11month=9year= 2005p1=136p2=48p3=176p4=240p5=224p6=213 1) Saturday, September 10, 2005 at 20:00:00 1) Sunday, September 11, 2005 at 19:00:00 Wow, that was kind of sudden! :-) Is it still happening? I assume the time's David mentioned are UTC? I have a busy weekend, but I'll still try to be online whenever its happening. Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpyDZYdSK3ch.pgp Description: PGP signature
Re: [FT] 2005-09-06 Summary
On Saturday September 10 2005 5:07 am, Ferdinand Soethe wrote: But I should warn you, so you're not shocked if you meet me, I'm actually a she. :) I think we are getting a little distracted from the real issues here: DO you brew good beer of don't you? And will you bring some to SD? Yes, back to the point, I do brew good beer, assuming that you like good, hearty ales of the IPA, bitter, stout variety and/or european wheat ales (I'm not a big fan of American Wheats). As for bringing some to SD that would depend on whether I am going and if I have any brew ready at the time. I normally just keg my beer and bypass the whole bottling mess, but an exception could be made to share with friends since I don't think a pressurized keg of beer is likely to go over well with the airlines. :) But more seriously: This might be a good opportunity to have a Hackathon focused on getting the structure for our Forrest manual started? You know, I find this very tempting. I would love to really be able to contribute more to the project and a face-to-face sit down would really get a manual off to a good start. I don't think I can afford to actually go to the conference itself (airfare, hotel AND the conference is a bit steep for me) but I may be able to come out for a few days and do a Social and Expo Pass if they offer it. I will be spending a decent chunk of money and leave time from work starting next weekend to go down to Texas to help with Katrina relief effort as a volunteer so I will have to assess the real possibility of SD once I return in October. Hopefully they will get the details about the conference posted relatively soon so I can more accurately assess what I can do. Diwaker: How is public transportation in SD? If I stay at some cheapy hotel not down by the water will I be able to get to the conference easily? -- Ferdinand Soethe
Re: [FT] 2005-09-06 Summary
Diwaker: How is public transportation in SD? If I stay at some cheapy hotel not down by the water will I be able to get to the conference easily? It sucks mostly. If you're living in the downtown area (where motels are likely to be not cheap), then you can get around on tram/bus. Anywhere off and you can't get by without a car. But I'm always happy to drive you around -- so keep that alternative in mind. -- Web/Blog/Gallery: floatingsun.net
Re: [jira] Closed: (INFRA-549) Please create a virtual list for forrest and lenya
On Sat, 2005-09-10 at 08:21 +0200, Roy T. Fielding (JIRA) wrote: [ http://issues.apache.org/jira/browse/INFRA-549?page=all ] Roy T. Fielding closed INFRA-549: - Resolution: Won't Fix As Nicola said: Basically it's an automatic and transparent cross-posting. It would not be easy to set up -- it would require disabling the subscriber-only posting for both lists and open them up for megaspam. Hmm, why do you think it requires disabling the subscriber only posting? Any poster that want to post to the list has to be subscribed too. He only do not get mail from it directly. People would have to subscribe to the list before posting but never receive mail only by subscribing to forrest-dev or lenya-dev, is that not possible? It is far easier to simply cross-post the few messages that are actually applicable to both groups. That should be done by this list to simplify the process. Is it not a simple foreword like in: cd /var/qmail/alias/ echo | /var/qmail/bin/forward lenya-dev forrest-dev.qmail-lefo That would exclude all subscriber. Mails only go to both lists. If one of the projects wants to set up a single lefo list (no need for two), then please request that as a new issue. People can then choose to subscribe to that list if they want to participate in the overlap. Can both projects request such a list or has it to be *one* of the projects? Can we then implement to forward all messages written to this list by only forwarding to both mailing lists instead of the subscriber? salu2 thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: How to apply an update to 0.7
David Crossley wrote: Ferdinand Soethe wrote: - QA Is anybody checking this branch for line ending probems etc before it is made available for download as a package? If not what is a foolproof test to check if my line endings are correct? No. But it can be done. It is not being released, so no download package. People can easily package it themselves, see the package instruction in etc/RELESE_PROCESS.txt (only need the packaging step). The main issue is described in that doc. If you are packaging for a client on a Windows platform, then do your svn checkout on Windows, otherwise do it on a unix machine. In the past, we have not done releases of a branch unless it has been specifically requested. The 0.5.1 was due to a cocoon issue. So if there are important issues then we can do a release. There have been a couple of important fixes already. How to check the line endings. There is a script in the ASF comitters repository at the tools directory. Also see the Cocoon page: http://cocoon.apache.org/community/committer.html If that doesn't work for you then i will check it. I just checked and all is well. -David
[jira] Updated: (FOR-655) Create sample document for XHTML2 subset
[ http://issues.apache.org/jira/browse/FOR-655?page=all ] Gavin updated FOR-655: -- Attachment: xhtml2_subset.xml.diff I have added all the rest of the sections mentioned in NKB's 'XHTML- lets do it!' mail. I have populated most of these new sections with content. There is still more content and more examples to come soon. I have added classes and id attributes, these need confirming or changing for the stylesheet. Create sample document for XHTML2 subset Key: FOR-655 URL: http://issues.apache.org/jira/browse/FOR-655 Project: Forrest Type: Sub-task Versions: 0.8-dev Reporter: Ross Gardler Fix For: 0.8-dev Attachments: xhtml2_subset.xml.diff Define the set of XHTML2 modules that will be used and document those by example. See discussion in thread: Re: XHTML2 - let's do it! http://marc.theaimsgroup.com/?t=11248949717 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
