cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@indexgeo.com.au>
Subject Re: Cocoon website outdated.
Date Sun, 05 Oct 2003 13:03:40 GMT
Antonio Gallardo wrote:
> Hi:
> 
> The news page at: http://cocoon.apache.org/news/index.html
> It does not show there is a 2.1.2 release!
> 
> I will be glad to update all the site, but since I dont know the mechanics
> to update the site. I prefer to don't touch it at all.

I will try to build on Joerg's reply.

As with most things the best way is to start small. Do just the
news page in the cocoon-site and gradually do more as you gain
confidence.

> It would be a good idea to show how to do that. I know there is a
> "cocon-site" and a "cocoon-2.1" in the CVS, but don't know where the
> forrest source to generate the site really resides.

It is at src/documentation/.../xdocs/*.xml in each place.
Of course you need Forrest 0.5 installed on your system.

> I also search on
> maillist and nowhere is info about that.
> 
> If I assume the lastest sources are at "cocoon-2.1", then the site is
> really outdated compared with what there is. There are many changes in
> documentation and others pages in cocoon-2.1 that are not showed to the
> average user. Now I understand posts from some users telling us there is
> no documentation. Yes, It is, but in the distribution.

There are a couple of conversations in the recent cocooon-dev
mail archives about why things are out-of-sync there. It seems that
we cannot do a full update of the website until 2.2 because the 2.1
docs were restructured and we would break lots of URL contracts.

We can still update individual pages by hand, and even add any
important new pages.

We are going to need to talk more about this delay, because it will
be a while before 2.2 is released.

> People like me (too lazy), first prefer to read some docs in the website
> before download and give a try. If this is true, then we are losing
> potential users. I know you can tell me: "We don't need users" or similars
> assertion. At the end this is not the point of the discusion.

No, it is none of that. It is just that we got ourselves into
a bind.

> Some other outdated pages I saw are:
> 
> http://cocoon.apache.org/changes.html
> http://cocoon.apache.org/history.html
> http://cocoon.apache.org/whoweare.html
> http://cocoon.apache.org/news/index.html

Yes they can easily be fixed now because they are all in the
separate cocoon-site cvs.

> Mainly, there are still the old site for 1.0 and 2.0. I understand the
> nostalgia for the old good times. ;) But I think we can delete the old
> site or update it or better move the old site to "Cocoon classics site".
> That way we can avoid current problems as some contradictory statements.
> For example:

We could rather just add a big notice on the top of each page.
So if they are individually found by Google, then people will be
warned.

> Check the definition of what is cocoon in 1.0: http://cocoon.apache.org/1.x/
> vs. what is written here: http://cocoon.apache.org/2.1/
> 
> This is a total diference! Then what is cocoon at all?
> 
> I think similar conflicts are there in the site. I think it is problematic
> for some people understand what cocoon is at all. We are not stating clear
> what is Cocoon! References can be taken from both since they are oficial
> statements from the Cocoon project.
> 
> The worst case is if a users check definitions at: 1.0 and 2.1 and said:
> "Well, I prefer 1.0, because I need a publisher framework. I don't want
> 2.1, because it is a webapp framework".... and we are not supporting more
> 1.0. Poor potential user.

I think that Cocoon probably always had the same goals, and we
just have become better at expressing those goals.

> I know this is a very hard work to be done to reorganize the website. I
> propose to create an old release menu where this old sites can reside (if
> we choosed to saved it for the history).
> 
> 2. WHAT WE NEED?
> 
> I saw the lastest post from Carsten that shows us a lack in updating the
> website:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106508923825397&w=2

I suppose that you mean further on in that thread. The specific
problem Carsten mentioned at the beginning was overcome.

> That show we need a better publishing mechanism. I don't try to said
> forrest is bad here. I love forrest. The answer can be a RFE to forrest to
> be able to update just the changed HTML files. I don't know is this is
> posible at all, but by the the generated cocoon site with 62.6 MB, we saw:

There is one thing that would help with such occasions where we
need to update certain pages by hand. If the generated pages had
HTML comments to mark the start and end of the content, then we
could copy-and-paste only that so as to leave the old navigation
menus intact.

> 1.0 site: 1.2 MB
> 2.0 site: 22.9 MB
> 2.1 site: 36.7 MB
> 
> If we assume:
> 1-We are not changing at all the old sites.

That is correct. However we should put notices to that
effect in the various old documentation.

> 2-The site surely will grow, because we are documenting the project.

Yes.

> 3-The 2.1 will become "historic" with the next 2.2 release. Adding more
> almost 37 MB to "unchanged files".

I am not sure why you are concerned about this. (See next comment.)

> Then we need to:
> 1-Avoid reposting the same files over and over.

But it is still only diffs, so it is not so bad. Anyway, i am
a bit confused. Would you please explain what you mean here.

> 2-Allow committers update just the changed files easily. That way the site
> will be more dynamic than it is right now.

Are you referring to the situation where the actual body content
is still the same, but if the menu has changed then the whole html
page needs to be committed to cvs? Yes that is a bit tedious, but
what can we do?

(There is one thing, but evidently not yet achievable. We could
run a live Cocoon instance to serve our website.)

> I just tried to show some of the problems we have with the Cocoon website
> and what we can do to solve this. This is an open discussion. Please
> comments what we can do in this area.

Thanks for raising these important issues.

--David



Mime
View raw message