Re: [RT] Starting 2.2
On Thursday, Sep 18, 2003, at 05:12 Europe/Rome, Geoff Howard wrote: Stefano Mazzocchi wrote: All right, what the hell, you are right, let's move out of the "impasse". I thought we'd come to some agreement that no option was without problems but that splitting to a separate cocoon-2.2 module was probably the least bad option. Yes, this seems to be the consensus. let's do a quick poll: who would be absolutely against using Subversion for the Cocoon 2.2 tree (granted that we can safely import the existing CVS tree into it)? state your reasons and try to be as less inertial and defensive on your status quo as possible. Did Niclas' comment about the unreleased status kill this? Yes, it did. We will consider moving to Subversion only when they release a public final version that will not move under our feet. It's a defensive attitude, admittedly, but we don't want any more problems. -- Stefano.
Re: [RT] Starting 2.2
Stefano Mazzocchi wrote: All right, what the hell, you are right, let's move out of the "impasse". I thought we'd come to some agreement that no option was without problems but that splitting to a separate cocoon-2.2 module was probably the least bad option. let's do a quick poll: who would be absolutely against using Subversion for the Cocoon 2.2 tree (granted that we can safely import the existing CVS tree into it)? state your reasons and try to be as less inertial and defensive on your status quo as possible. Did Niclas' comment about the unreleased status kill this? Geoff
Re: [RT] Starting 2.2
On Saturday 13 September 2003 18:40, Stefano Mazzocchi wrote: > let's do a quick poll: who would be absolutely against using Subversion > for the Cocoon 2.2 tree (granted that we can safely import the existing > CVS tree into it)? > > state your reasons and try to be as less inertial and defensive on your > status quo as possible. Subversion is not final. They say themselves that it is reliable, but not stable, i.e. there will be additional data migration issues prior to ver 1.0. Niclas
Re: [RT] Starting 2.2
On Friday, Aug 29, 2003, at 20:27 Europe/Rome, Jay Freeman ((saurik)) wrote: Stefano: I totally agree on the "evolution" thing. To start, the process of moving to Subversion would be a repository import, not starting from scratch. As for tools: http://subclipse.tigris.org/ (Subversion plugin for Eclipse, although only on Win32 currently, haven't tried it as I hate Eclipse; it seems like it could be gotten to work on Unix easily, just would require compiling the JNI stubs on your platform yourself and dropping them in as the subclipse people are currently relying on some precompiled binaries) http://ankhsvn.tigris.org/ (Subversion plugin for VS.NET, a little slow at times, but usable) They already have it integrated into ViewCVS (which is what I thought Apache used, might be wrong; there was a lot of impetus to do it as the guy who originally forked ViewCVS from CVSWeb is one of the lead Subversion developers). I've been working with the Chora (another web interface) people and we have it working in that as well. What I think would be more productive, both for Cocoon and for Subversion, is to have more than a flat out "no, stick with something that works" but instead to put forward a list of requirements from a revision control system for it to be considered an "evolutionary move". Then people who work on version control know where to apply effort and people working on Cocoon have a roadmap for their evolution (rather than just getting stuck with existing systems and never moving). It's somewhat like deciding to switch to a different underlying framework for component/block management; one wouldn't want to just say "hey, this is newer and has one better feature, let's do it", but if that one feature is crucial enough you'd want to have a list of requirements of a new system (one that obviously includes everything important from the old system) so that you'd know when you _would_ be able to move to it and when it would be worth it. All right, what the hell, you are right, let's move out of the "impasse". let's do a quick poll: who would be absolutely against using Subversion for the Cocoon 2.2 tree (granted that we can safely import the existing CVS tree into it)? state your reasons and try to be as less inertial and defensive on your status quo as possible. [as win2k->macosx/mozilla->Mail.app switcher I can attest that sometimes changing your habits is dramatic and painful, but can help you a lot down the road and you never look back. This sounds another one of those situations] -- Stefano.
Re: [RT] Starting 2.2
Stefano: I totally agree on the "evolution" thing. To start, the process of moving to Subversion would be a repository import, not starting from scratch. As for tools: http://subclipse.tigris.org/ (Subversion plugin for Eclipse, although only on Win32 currently, haven't tried it as I hate Eclipse; it seems like it could be gotten to work on Unix easily, just would require compiling the JNI stubs on your platform yourself and dropping them in as the subclipse people are currently relying on some precompiled binaries) http://ankhsvn.tigris.org/ (Subversion plugin for VS.NET, a little slow at times, but usable) They already have it integrated into ViewCVS (which is what I thought Apache used, might be wrong; there was a lot of impetus to do it as the guy who originally forked ViewCVS from CVSWeb is one of the lead Subversion developers). I've been working with the Chora (another web interface) people and we have it working in that as well. What I think would be more productive, both for Cocoon and for Subversion, is to have more than a flat out "no, stick with something that works" but instead to put forward a list of requirements from a revision control system for it to be considered an "evolutionary move". Then people who work on version control know where to apply effort and people working on Cocoon have a roadmap for their evolution (rather than just getting stuck with existing systems and never moving). It's somewhat like deciding to switch to a different underlying framework for component/block management; one wouldn't want to just say "hey, this is newer and has one better feature, let's do it", but if that one feature is crucial enough you'd want to have a list of requirements of a new system (one that obviously includes everything important from the old system) so that you'd know when you _would_ be able to move to it and when it would be worth it. Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] - Original Message - From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 29, 2003 5:36 AM Subject: Re: [RT] Starting 2.2 ... > Yes, you are right, CVS sucks, but the way it's integrated with the > apache infrastructure and with tools that people use is not. > > there is a huge inertia there. greatly underestimated by the subversion > people, expecially for people used to IDEs like eclipse that hide CVS > stuff under the hood and do things automatically. > > I'm sick of this thread. It's stopping evolution. > > Carsten, forget beauty of versioning and let's start working on > cocoon-2.1 HEAD, this will: > > 1) reduce effort and duplication > 2) keep people sane since every commit will have to keep the tree in > shape (it's entirely possible to implement real blocks with what we > have, without moving things around, even turning the current static > blocks into real ones). > > So, my vote is: cut the crap, let's work on the thing right here and > right now, we'll think about what to do later. > > Evolution is always prefered to revolution. > > [believe me, I've made this mistake so many times that I learned my way > thru] > > -- > Stefano.
RE: [RT] Starting 2.2
On Fri, 29 Aug 2003, Carsten Ziegeler wrote: > > Berin Loritsch wrote: > > > > > > > > > Ah, btw. I will replace ECM with fortress over the weekend. Any problems > > > with that? > > > > > > > > > > > > Don't tease me... Want I should do it? > > > Hey, great! > > I'm definitly +5 for this! So if you want to do it, you could start a vote > and see what will happen next... Go ahead +1 -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: [RT] Starting 2.2
Carsten Ziegeler wrote: Ah, btw. I will replace ECM with fortress over the weekend. Any problems with that? Yep. Aren't we supposed to use Merlin instead? I'm checking in the code as we speak... Vadim
Re: [RT] Starting 2.2
Carsten Ziegeler wrote, On 29/08/2003 16.11: Berin Loritsch wrote: Ah, btw. I will replace ECM with fortress over the weekend. Any problems with that? Don't tease me... Want I should do it? Hey, great! I'm definitly +5 for this! So if you want to do it, you could start a vote and see what will happen next... Plase! :-) It will be fun to do some statistics to see if it's a faster plugin replacement, I'm really really curious! -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
RE: [RT] Starting 2.2
Berin Loritsch wrote: > > > > > > Ah, btw. I will replace ECM with fortress over the weekend. Any problems > > with that? > > > > > > > Don't tease me... Want I should do it? > Hey, great! I'm definitly +5 for this! So if you want to do it, you could start a vote and see what will happen next... Carsten
Re: [RT] Starting 2.2
Carsten Ziegeler wrote: Ah, btw. I will replace ECM with fortress over the weekend. Any problems with that? Don't tease me... Want I should do it? -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin
RE: [RT] Starting 2.2
Stefano Mazzocchi wrote: > Carsten, forget beauty of versioning and let's start working on > cocoon-2.1 HEAD, this will: > > 1) reduce effort and duplication > 2) keep people sane since every commit will have to keep the tree in > shape (it's entirely possible to implement real blocks with what we > have, without moving things around, even turning the current static > blocks into real ones). > This is a very optimistic assumption, which I personally doubt. But, ok, I can live with doing everything in cocoon-2.1 HEAD, no problem. I'm absolutely frustrated as well: over the last months people always said, "Let's get 2.1 out, we want to start 2.2". Now that we can do it, I'm the only one keeping to it. Great! Now I can already imagine what will happen. Someday someone checks in something that is not suitable for a 2.1.x version and then a new "flame war" against this person will begin. Ok, agreed. Let's stop the crap and work with the 2.1 repo then. Ah, btw. I will replace ECM with fortress over the weekend. Any problems with that? Carsten
Re: [RT] Starting 2.2
On Thursday, Aug 28, 2003, at 20:00 Europe/Rome, Jay Freeman ((saurik)) wrote: So my eye finally caught on the "Starting 2.2" thread today, it seemed interesting, and I went to read through this... and I must say the main reaction I ended up having to it is "HUH?!?". :) Is the reason you need a new repository because CVS doesn't support move/copy/rename (especially so on directories?). I guess I've just been using Subversion so long that some of the solutions people have been proposing sound rather terrifying... making a new repository and copying all of the RCS files into it in order to "preserve history"? But then you'd still be maintaining the files in both versions seperately with no computer way to know "this file is a copy of that one" to try to help you do that. Then there was the suggestion to have the new repository copy stuff from the 2.1 repository during build or something... With Subversion you could just copy the current trunk off to a cocoon-2.1 branch (as you'd likely be doing many less fixes on that over the future than enhancements to 2.2, so that would be considered the branch) and then start reorganizing the directories in the trunk by just moving them around and committing the move operations (so far with no space duplication on the server as all of these copy/move operations are just references to the same file data in the repository), files that need to be renamed could easily be done so, and this entire process would be keeping track of the history through all of the move operations... (although merging the 2.1 branch changes into 2.2 still wouldn't be entirely automated, but I'm pretty sure the Subversion people are working on this; 0.28.0, released a few days ago, has some features that is bringing it a lot closer). Has any thought been put into "the next time we have to create another new repository should be the day we look into better version control"? Yes, you are right, CVS sucks, but the way it's integrated with the apache infrastructure and with tools that people use is not. there is a huge inertia there. greatly underestimated by the subversion people, expecially for people used to IDEs like eclipse that hide CVS stuff under the hood and do things automatically. I'm sick of this thread. It's stopping evolution. Carsten, forget beauty of versioning and let's start working on cocoon-2.1 HEAD, this will: 1) reduce effort and duplication 2) keep people sane since every commit will have to keep the tree in shape (it's entirely possible to implement real blocks with what we have, without moving things around, even turning the current static blocks into real ones). So, my vote is: cut the crap, let's work on the thing right here and right now, we'll think about what to do later. Evolution is always prefered to revolution. [believe me, I've made this mistake so many times that I learned my way thru] -- Stefano.
Re: [RT] Starting 2.2
Yeah, the Win32 client used to have all kinds of / vs. \ issues and they tended to break the build a lot. However, nowadays, the windows client (at least the command line one, which is what I first thought you meant) works quite well. RapidSVN (a Win32 GUI) is probably buggy as all hell still. However! TortoiseSVN (a Win32 shell extension) works extremely well. When I'm not using the command line client that's what I now use (and what I set up the few other developers at Gnostic Labs with when I finally switched us over to Subversion a week or two ago). As for the CVS to Subversion repository importer, it seems to at least partially support branches. BUT, it doesn't seem to support the Cocoon2 repository somehow. *Got it out of rsync earlier and let it sit for an hour or something converting.* I'm working on looking at the input, generated dump file, and partial output to try to figure out what's going wrong (it has something to do with a branch where some files got added to the branch later and then got deleted and it doesn't know they weren't int the branch to begin with for whatever reason). Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] - Original Message - From: "Berin Loritsch" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 28, 2003 3:30 PM Subject: Re: [RT] Starting 2.2 > J.Pietschmann wrote: > > > Timothy Larson wrote: > > > >> I also wondered about Subversion when the repositories started > >> multiplying :) > >> Is this a possibility? Is there a good CVS->Subversion repository > >> converter? > > > > > > What's "good"? The Subversion project has a converter, last time > > I checked they said it still can't convert branches, and that this > > was *the* killer for declaring SVN to be "production ready". Trunk > > only CVS repositories seem to work for a long time already > > (disclaimer: gathered from various messages, I didn't try personally). > > Hmm. Do we still have a test server available? > > The last time I played with SVN, the Windows client was a bit buggy. > However that was roughly a year ago. I'm sure it has gotten better > since then. > > > -- > > "They that give up essential liberty to obtain a little temporary safety > deserve neither liberty nor safety." > - Benjamin Franklin
Re: [RT] Starting 2.2 (was going to be "The Project Formerly KnownAs Cocoon")
Tony Collen wrote: Geoff Howard wrote: What about renaming the next release to an unpronounceable set of symbols, like Prince, or that Led Zepplin album? I'd suggest "!&#". How about: Cocoon It would be pronounced, "Cocoon?!" Actually, my proposal could be pronounced "bang and pound" which might not be positive... In all seriousness, I'm all for 2.2, but what sorts of loose ends are there that could be tied up for 2.1.x? Howabout a push to clear out some bugs from bugzilla? Me too, but a push for bug fix (and I'd like to see a docs blitz) wouldn't need to hold up creating the repository and working out the best way of working two trees at once would it? Hrm, actually a docs push would be more like it, since I was prodded by a few people to do up some nice InputModule docs, so I am guilty as charged :) I just didn't want to see new stuff get started and have older issues unresolved. I don't see why we'd need to postpone a new repository, really, I'd just hate to see things forgotten about. Agreed. Side note: Is a build of 2.1.x or 2.2 going to be using the new forrest-style skins for the docs anytime soon? It's kind of nasty seeing the old site design when I build docs from the current CVS. I asked about this before and got the impression that some people are getting the forrest look. Near as I can tell, it falls back to the old xml.apache "metal" look if forrest is not downloaded at ../xml-forrest or as specified in build.properties? So far I've been too lazy to confirm. I'd much rather be able to import the stylesheets, etc. which would be needed but I've been too lazy for that as well. By the way, I thought we were planning on breaking from ECM in 2.2 because it would make blocks easier among other great benefits. Is this still a thought? That would certainly make a new repo an attractive thing. I'm not a hugely knowledgeable on Avalon, so I'm not sure about the issues surrounding it. Just when I thought I'd start to learn Avalon stuff, the carpet gets pulled out from under me! :) Hopefully it's not as bad as that. Avalon's not going away, just the implementation that's changing... Geoff
Re: [RT] Starting 2.2
Berin Loritsch wrote: What's "good"? The Subversion project has a converter, last time I checked they said it still can't convert branches, and that this was *the* killer for declaring SVN to be "production ready". Trunk only CVS repositories seem to work for a long time already (disclaimer: gathered from various messages, I didn't try personally). Hmm. Do we still have a test server available? The last time I played with SVN, the Windows client was a bit buggy. However that was roughly a year ago. I'm sure it has gotten better since then. Look at: http://cvs.apache.org/repos/asf/ On infrastructure@ there was an email describing how to add yourself to the right passwd file (with htpasswd). I don't know how sensible that information is, so I'd rather not write it here. Just contact me if you feel lik playing around. :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Starting 2.2
J.Pietschmann wrote: Timothy Larson wrote: I also wondered about Subversion when the repositories started multiplying :) Is this a possibility? Is there a good CVS->Subversion repository converter? What's "good"? The Subversion project has a converter, last time I checked they said it still can't convert branches, and that this was *the* killer for declaring SVN to be "production ready". Trunk only CVS repositories seem to work for a long time already (disclaimer: gathered from various messages, I didn't try personally). Hmm. Do we still have a test server available? The last time I played with SVN, the Windows client was a bit buggy. However that was roughly a year ago. I'm sure it has gotten better since then. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin
Re: [RT] Starting 2.2
Timothy Larson wrote: I also wondered about Subversion when the repositories started multiplying :) Is this a possibility? Is there a good CVS->Subversion repository converter? What's "good"? The Subversion project has a converter, last time I checked they said it still can't convert branches, and that this was *the* killer for declaring SVN to be "production ready". Trunk only CVS repositories seem to work for a long time already (disclaimer: gathered from various messages, I didn't try personally). J.Pietschmann
Re: [RT] Starting 2.2 (was going to be "The Project Formerly KnownAs Cocoon")
Geoff Howard wrote: What about renaming the next release to an unpronounceable set of symbols, like Prince, or that Led Zepplin album? I'd suggest "!&#". How about: Cocoon It would be pronounced, "Cocoon?!" In all seriousness, I'm all for 2.2, but what sorts of loose ends are there that could be tied up for 2.1.x? Howabout a push to clear out some bugs from bugzilla? Me too, but a push for bug fix (and I'd like to see a docs blitz) wouldn't need to hold up creating the repository and working out the best way of working two trees at once would it? Hrm, actually a docs push would be more like it, since I was prodded by a few people to do up some nice InputModule docs, so I am guilty as charged :) I just didn't want to see new stuff get started and have older issues unresolved. I don't see why we'd need to postpone a new repository, really, I'd just hate to see things forgotten about. Side note: Is a build of 2.1.x or 2.2 going to be using the new forrest-style skins for the docs anytime soon? It's kind of nasty seeing the old site design when I build docs from the current CVS. By the way, I thought we were planning on breaking from ECM in 2.2 because it would make blocks easier among other great benefits. Is this still a thought? That would certainly make a new repo an attractive thing. I'm not a hugely knowledgeable on Avalon, so I'm not sure about the issues surrounding it. Just when I thought I'd start to learn Avalon stuff, the carpet gets pulled out from under me! :) Regards, Tony
Re: [RT] Starting 2.2
Jay Freeman (saurik) wrote: Has any thought been put into "the next time we have to create another new repository should be the day we look into better version control"? Amen! Personally I'd +1 the subversion switch in any moment. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Starting 2.2
I also wondered about Subversion when the repositories started multiplying :) Is this a possibility? Is there a good CVS->Subversion repository converter? --Tim Larson --- "Jay Freeman (saurik)" <[EMAIL PROTECTED]> wrote: ... > Has any thought been put into "the next time we have to create another new > repository should be the day we look into better version control"? ... __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Re: [RT] Starting 2.2 (was going to be "The Project Formerly KnownAs Cocoon")
Tony Collen wrote: Nicola Ken Barozzi wrote: Maybe start 2.5, just to be in line with Linux? ;-P Screw that, let's just skip a couple major versions, everyone's doing it now, how does "Cocoon 5.0" look? :) Better yet, let's just change the name alltogether: Cocoon XP Cocoon MX Cocoon MX 2004 I just love Macromedia, at least they admit MX doesn't mean anything: What does "MX" mean? The "MX" moniker is not an acronym and doesn't have a literal translation. What about renaming the next release to an unpronounceable set of symbols, like Prince, or that Led Zepplin album? I'd suggest "!&#". In all seriousness, I'm all for 2.2, but what sorts of loose ends are there that could be tied up for 2.1.x? Howabout a push to clear out some bugs from bugzilla? Me too, but a push for bug fix (and I'd like to see a docs blitz) wouldn't need to hold up creating the repository and working out the best way of working two trees at once would it? By the way, I thought we were planning on breaking from ECM in 2.2 because it would make blocks easier among other great benefits. Is this still a thought? That would certainly make a new repo an attractive thing. Geoff
Re: [RT] Starting 2.2
Nicola Ken Barozzi wrote: Maybe start 2.5, just to be in line with Linux? ;-P Screw that, let's just skip a couple major versions, everyone's doing it now, how does "Cocoon 5.0" look? :) Better yet, let's just change the name alltogether: Cocoon XP Cocoon MX Cocoon MX 2004 I just love Macromedia, at least they admit MX doesn't mean anything: What does "MX" mean? The "MX" moniker is not an acronym and doesn't have a literal translation. They add the MX, and then they realize they have to release a new version so they tack a "2004" on the end. In all seriousness, I'm all for 2.2, but what sorts of loose ends are there that could be tied up for 2.1.x? Howabout a push to clear out some bugs from bugzilla? Regards, Tony
Re: [RT] Starting 2.2
So my eye finally caught on the "Starting 2.2" thread today, it seemed interesting, and I went to read through this... and I must say the main reaction I ended up having to it is "HUH?!?". :) Is the reason you need a new repository because CVS doesn't support move/copy/rename (especially so on directories?). I guess I've just been using Subversion so long that some of the solutions people have been proposing sound rather terrifying... making a new repository and copying all of the RCS files into it in order to "preserve history"? But then you'd still be maintaining the files in both versions seperately with no computer way to know "this file is a copy of that one" to try to help you do that. Then there was the suggestion to have the new repository copy stuff from the 2.1 repository during build or something... With Subversion you could just copy the current trunk off to a cocoon-2.1 branch (as you'd likely be doing many less fixes on that over the future than enhancements to 2.2, so that would be considered the branch) and then start reorganizing the directories in the trunk by just moving them around and committing the move operations (so far with no space duplication on the server as all of these copy/move operations are just references to the same file data in the repository), files that need to be renamed could easily be done so, and this entire process would be keeping track of the history through all of the move operations... (although merging the 2.1 branch changes into 2.2 still wouldn't be entirely automated, but I'm pretty sure the Subversion people are working on this; 0.28.0, released a few days ago, has some features that is bringing it a lot closer). Has any thought been put into "the next time we have to create another new repository should be the day we look into better version control"? Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] - Original Message - From: "Carsten Ziegeler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 26, 2003 2:18 AM Subject: RE: [RT] Starting 2.2 > Pier Fumagalli wrote: > > > > On 13/8/03 16:37, "Carsten Ziegeler" <[EMAIL PROTECTED]> wrote: > > > > > Ok, let's do simple steps perhaps: > > > > > > Do you think that we should start a new repository? This is > > > equivalent to saying "we start a new major version (2.2)". > > > > > > (if the answer is yes, we can talk about the layout). > > > > YES! :-) As I have few [RT]s on my own! :-) :-) :-) > > > Great! Combined with the recent RTs, does still someone feel that > starting 2.2 is the right thing? Or a there still objections? > > Carsten
RE: [RT] Starting 2.2
Carsten Ziegeler dijo: > "Hello. > Is there anybody in there? > Just nod if you can hear me. > Is there anyone home?" Great :) Antonio Gallardo
Re: [RT] Starting 2.2
Upayavira wrote: I think we should consider the 2.2 repository _only_ when we've got a concrete proposal for code that _cannot_ be included in the 2.1 repository. +1. Or at least only when we've got a concrete proposal for a build system that cleanly separates (current) blocks from the core sources. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Starting 2.2
Le Jeudi, 28 aoû 2003, à 11:22 Europe/Zurich, Upayavira a écrit : ...Switching repositories last time was a pain. Switching to a 2.2 repository will also be a pain, and that pain has to be worth it, and at present I do not see any proposals being made (that is, people proposing to implement proposals) that actually require this 2.2 repository... I see your point - OTOH, we *know* things are going to happen, so switching during this relatively quiet period might be easier. -Bertrand
Re: [RT] Starting 2.2
Bertrand Delacretaz wrote: Le Jeudi, 28 aoû 2003, à 09:18 Europe/Zurich, Carsten Ziegeler a écrit : ...Great! Combined with the recent RTs, does still someone feel that starting 2.2 is the right thing? Or are there still objections?... I'm +1 on starting 2.2 given what's going on (or planned) with blocks, forms, etc. -Bertrand I think, as has been said before, we need to discuss _what_ it is that would require a new repository. So far, we've had a number of RTs, but to my knowledge, no one is working on implementing any of these yet, and no one is working on code that cannot be placed into the 2.1 repository without breaking interfaces (at least ones that aren't still alpha). I think we should consider the 2.2 repository _only_ when we've got a concrete proposal for code that _cannot_ be included in the 2.1 repository. Switching repositories last time was a pain. Switching to a 2.2 repository will also be a pain, and that pain has to be worth it, and at present I do not see any proposals being made (that is, people proposing to implement proposals) that actually require this 2.2 repository. Therefore, at present I think we should stick with 2.1, until concrete proposals emerge that make it worth the effort. Regards, Upayavira
Re: [RT] Starting 2.2
Le Jeudi, 28 aoû 2003, à 09:18 Europe/Zurich, Carsten Ziegeler a écrit : ...Great! Combined with the recent RTs, does still someone feel that starting 2.2 is the right thing? Or are there still objections?... I'm +1 on starting 2.2 given what's going on (or planned) with blocks, forms, etc. -Bertrand
Re: [RT] Starting 2.2
Carsten Ziegeler wrote, On 28/08/2003 9.18: "Hello. Is there anybody in there? Just nod if you can hear me. Is there anyone home?" Carsten Ziegeler wrote: ... does still someone feel that starting 2.2 is the right thing? Maybe start 2.5, just to be in line with Linux? ;-P No objections == do it or ask for a vote. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
RE: [RT] Starting 2.2
"Hello. Is there anybody in there? Just nod if you can hear me. Is there anyone home?" Carsten Ziegeler wrote: > > Pier Fumagalli wrote: > > > > On 13/8/03 16:37, "Carsten Ziegeler" <[EMAIL PROTECTED]> wrote: > > > > > Ok, let's do simple steps perhaps: > > > > > > Do you think that we should start a new repository? This is > > > equivalent to saying "we start a new major version (2.2)". > > > > > > (if the answer is yes, we can talk about the layout). > > > > YES! :-) As I have few [RT]s on my own! :-) :-) :-) > > > Great! Combined with the recent RTs, does still someone feel that > starting 2.2 is the right thing? Or are there still objections? > > Carsten >
RE: [RT] Starting 2.2
Pier Fumagalli wrote: > > On 13/8/03 16:37, "Carsten Ziegeler" <[EMAIL PROTECTED]> wrote: > > > Ok, let's do simple steps perhaps: > > > > Do you think that we should start a new repository? This is > > equivalent to saying "we start a new major version (2.2)". > > > > (if the answer is yes, we can talk about the layout). > > YES! :-) As I have few [RT]s on my own! :-) :-) :-) > Great! Combined with the recent RTs, does still someone feel that starting 2.2 is the right thing? Or a there still objections? Carsten
Re: [RT] Starting 2.2
On Wednesday, Aug 13, 2003, at 22:04 Europe/Rome, Tony Collen wrote: Joerg Heinicke wrote: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106077110314347&w=2 Stefano: "the road to real blocks: how to build it minimizing the impact on the existing code and with complete back compatibility (yes, it's possible!)" Here's my own Mini-RT: If you've used a BSD, you've quite possibly run into what's known as _ports_. Ports is really cool, and for anyone who doesn't know what it is, here's a little description. Yes. BSD ports or Debian APT has been influencing the design of blocks since day one. Ports is a big directory skeleton which usually sits in /usr/ports. It is organized in a hierarchy, so you end up with a directory structure like /usr/ports/games, /usr/ports/mail, /usr/ports/irc, etc. I strongly dislike the taxonomy approach. Because finding agreement on where to place a block will be hard in several cases. But this is an issue that will be addressed by the block librarian. Under each category is another directory for each program which belongs to it, so /usr/ports/games/fortune, etc. Now the cool thing is that each program directory contains a makefile, unified diffs, and a list of repositories where the software resides. (FTP, WWW, etc) I have presented a much more abstract way of achiving the same functionality using pluggable locators and non-locating identifiers. When you run make, it automatically downloads the software from the repository, and patches the software specifically for BSD. Even cooler, is that it automatically takes care of dependencies recursively. Once all the dependencies are done, the software is built. There are several other commands, such as "make install" or "make clean" which does the usual expected chores. We (luckily!) don't need all this. java can be shipped precompiled and blocks will be configured by the block deployer. The only downfall is that you have to keep the directory skeleton up to date. FreeBSD does this over CVS. Very handy. Handy, but painful because it mixes concerns between cataloging and location. We should avoid this. Now, imagine this applied to Cocoon and blocks. If we distributed a "core" Cocoon, we could dramatically cut down the typical amount of code that gets distributed. absolutely, this is one of the goals. If we wanted the PDF block installed, all we would do is go to $cocoon_src/blocks/pdf/ and type build install. that would be an improvement on what we have today, but it's poor compared to what I want to achieve with blocks (see my latest RT on this) It would download the PDFSerializer, and realize that the FOP jars are required, and download them. We could also come up with some "block packages" that are geared towards some basic tasks, i.e. blocks which are grouped together to accomplish some goal.. sort of how the more popular Linux distros have a "workstation", "server", "basic", "everything" install. Yes, "block bundles" will be available and will be the preferred way of downloading complex software (say forrest, linotype or lenya) on top of cocoon. That's my RT, I hope I didn't spoil anything anybody was saving :) Not at all. Thanks much for the info, but everything you want will be there and much more ;-) -- Stefano.
Re: [RT] Starting 2.2
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
...
Hmm, yes, but we could start the 2.2 repo with the current core
source, so we have a starting point. I expect that blocks will
require longer discussions and I personally don't want to wait with
2.2 for this.
I'm wondering. What are you personally planning which requires 2.2
repo and can not be done in the current repo?
/me feels that you are trying to solve some problem without stating
what the problem is
/me feels the same ;-)
/me thinks we should continue with the 2.1 repo until either someone
comes with a change that obviously doesn't fit with 2.1.1 or until we
have precise plans for what should go in the 2.2 repo.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Starting 2.2
Carsten Ziegeler wrote: Vadim Gritsenko wrote: Carsten Ziegeler wrote: ... Hmm, yes, but we could start the 2.2 repo with the current core source, so we have a starting point. I expect that blocks will require longer discussions and I personally don't want to wait with 2.2 for this. I'm wondering. What are you personally planning which requires 2.2 repo and can not be done in the current repo? /me feels that you are trying to solve some problem without stating what the problem is Secret plans something like "world domination" ... :) (just kidding) I have several smaller RTs that require major changes in the core, so I think they are targetted for a 2.2 release rather than 2.1.1. And the blocks require a major version change, so I thought about merging them. I will write the RTs as soon as we have the repository. Let's do the other way around -- send in RT first and let's hear about those major changes :) Vadim
Re: [RT] Starting 2.2
Carsten Ziegeler wrote:
Ok, let's do simple steps perhaps:
Do you think that we should start a new repository? This is
equivalent to saying "we start a new major version (2.2)".
(if the answer is yes, we can talk about the layout).
You ask for the solution to a problem that's not defined... Why do you
need the 2.2 repo to be created before writing your RTs ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Starting 2.2
Tony Collen wrote:
Joerg Heinicke wrote:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106077110314347&w=2
Stefano:
"the road to real blocks: how to build it minimizing the impact on
the existing code and with complete back compatibility (yes, it's
possible!)"
Here's my own Mini-RT:
Now, imagine this applied to Cocoon and blocks. If we distributed a
"core" Cocoon, we could dramatically cut down the typical amount of
code that gets distributed. If we wanted the PDF block installed, all
we would do is go to $cocoon_src/blocks/pdf/ and type build install.
It would download the PDFSerializer, and realize that the FOP jars are
required, and download them. We could also come up with some "block
packages" that are geared towards some basic tasks, i.e. blocks which
are grouped together to accomplish some goal.. sort of how the more
popular Linux distros have a "workstation", "server", "basic",
"everything" install.
That's my RT, I hope I didn't spoil anything anybody was saving :)
You did ;-)
The idea behind blocks uses similar concepts but goes even further by
relying on a discovery system that can ask a server for the location of
dependencies. This means you won't even need a local list of the
available blocks.
But let's not steal Stefano's pleasure of explaining us the results of
his worldwide discussions !
Stefano, seems like a lot of people are ready and waiting ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: [RT] Starting 2.2
Sylvain Wallez wrote: > > Carsten Ziegeler wrote: > > >Ok, let's do simple steps perhaps: > > > >Do you think that we should start a new repository? This is > >equivalent to saying "we start a new major version (2.2)". > > > >(if the answer is yes, we can talk about the layout). > > > > > > You ask for the solution to a problem that's not defined... Why do you > need the 2.2 repo to be created before writing your RTs ? > Ok, it has nothing to do with my RT's, I had the impression that blocks required a major version changes and that we want to start with it asap. If I'm wrong here, let's stop this RT. Carsten
RE: [RT] Starting 2.2
Ok, let's do simple steps perhaps: Do you think that we should start a new repository? This is equivalent to saying "we start a new major version (2.2)". (if the answer is yes, we can talk about the layout). Carsten
RE: [RT] Starting 2.2
Vadim Gritsenko wrote: > Carsten Ziegeler wrote: > ... > > >Hmm, yes, but we could start the 2.2 repo with the current core source, > >so we have a starting point. I expect that blocks will require longer > >discussions and I personally don't want to wait with 2.2 for this. > > > > I'm wondering. What are you personally planning which requires 2.2 repo > and can not be done in the current repo? > > /me feels that you are trying to solve some problem without stating what > the problem is > Secret plans something like "world domination" ... :) (just kidding) I have several smaller RTs that require major changes in the core, so I think they are targetted for a 2.2 release rather than 2.1.1. And the blocks require a major version change, so I thought about merging them. I will write the RTs as soon as we have the repository. Carsten
RE: [RT] Starting 2.2
Sylvain Wallez wrote: > > Ah, so we'll have a 2.2 repo containing only those parts whose structure > will change, and keep the 2.1 repo as a "fallback" for those parts whose > structure is the same (but who may have been upgraded since 2.1.0) ? > > But how do we decide that some modifications should occur in 2.2 and not > in 2.1 ? > Yupp. > >As I expect that we will end in a different structure when we > have real blocks (e.g. perhaps a blocks repository etc.) this > would be imho an easier migration strategy. > > > > That's right. With real blocks, we'll have several distinct CVS > repositories. But will we have distinct "kernel" and "core component" > blocks ? Should the kernel be really naked (in which case it may even > contain only the block manager and the main interfaces but nothing > else), or should it provide the common services used by every > application (e.g. WildcardMatcher, FileGenerator, HTMLSerializer, etc) ? > I'm not sure if we will have this distinction, so I thought perhaps moving them (generators etc) out and later move them into the core again is less pain then having to maintain two branches. Perhaps the latter one is easier, I honestly don't know. > >Does this make sense? > > > > Yep. But the granularity has to be found. Maybe we should wait for > Stefano's RT so that everybody has a common understanding of the > consequences of blocks on the Cocoon organisation. > Hmm, yes, but we could start the 2.2 repo with the current core source, so we have a starting point. I expect that blocks will require longer discussions and I personally don't want to wait with 2.2 for this. Carsten
Re: [RT] Starting 2.2
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
I don't clearly understand what you want to achieve...
It's plain simple :) Now, the usual way would be to create a new repository
(cocoon-2.2) and copy everything from 2.1 in there.
Then we have two "branches" which require syncing which can be a real pita. My
approach is to sync as less as possible by only copying those parts that we will change in the
near future. And this should be the core sources, but not the documentation or any block.
Ah, so we'll have a 2.2 repo containing only those parts whose structure
will change, and keep the 2.1 repo as a "fallback" for those parts whose
structure is the same (but who may have been upgraded since 2.1.0) ?
But how do we decide that some modifications should occur in 2.2 and not
in 2.1 ?
As I expect that we will end in a different structure when we have real blocks (e.g. perhaps a blocks repository etc.) this would be imho an easier migration strategy.
That's right. With real blocks, we'll have several distinct CVS
repositories. But will we have distinct "kernel" and "core component"
blocks ? Should the kernel be really naked (in which case it may even
contain only the block manager and the main interfaces but nothing
else), or should it provide the common services used by every
application (e.g. WildcardMatcher, FileGenerator, HTMLSerializer, etc) ?
Does this make sense?
Yep. But the granularity has to be found. Maybe we should wait for
Stefano's RT so that everybody has a common understanding of the
consequences of blocks on the Cocoon organisation.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Starting 2.2
Joerg Heinicke wrote: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106077110314347&w=2 Stefano: "the road to real blocks: how to build it minimizing the impact on the existing code and with complete back compatibility (yes, it's possible!)" Here's my own Mini-RT: If you've used a BSD, you've quite possibly run into what's known as _ports_. Ports is really cool, and for anyone who doesn't know what it is, here's a little description. Ports is a big directory skeleton which usually sits in /usr/ports. It is organized in a hierarchy, so you end up with a directory structure like /usr/ports/games, /usr/ports/mail, /usr/ports/irc, etc. Under each category is another directory for each program which belongs to it, so /usr/ports/games/fortune, etc. Now the cool thing is that each program directory contains a makefile, unified diffs, and a list of repositories where the software resides. (FTP, WWW, etc) When you run make, it automatically downloads the software from the repository, and patches the software specifically for BSD. Even cooler, is that it automatically takes care of dependencies recursively. Once all the dependencies are done, the software is built. There are several other commands, such as "make install" or "make clean" which does the usual expected chores. The only downfall is that you have to keep the directory skeleton up to date. FreeBSD does this over CVS. Very handy. Now, imagine this applied to Cocoon and blocks. If we distributed a "core" Cocoon, we could dramatically cut down the typical amount of code that gets distributed. If we wanted the PDF block installed, all we would do is go to $cocoon_src/blocks/pdf/ and type build install. It would download the PDFSerializer, and realize that the FOP jars are required, and download them. We could also come up with some "block packages" that are geared towards some basic tasks, i.e. blocks which are grouped together to accomplish some goal.. sort of how the more popular Linux distros have a "workstation", "server", "basic", "everything" install. That's my RT, I hope I didn't spoil anything anybody was saving :) Tony
RE: [RT] Starting 2.2
Title: RE: [RT] Starting 2.2 > /me feels that you are trying to solve some problem without > stating what > the problem is > > Vadim Planning a IRC block with a mIRC log generator and all ? Great ! ;) fabien.
Re: [RT] Starting 2.2
Carsten Ziegeler wrote:
Hi, as 2.1 is now out, we should think about starting 2.2.
Here is my idea about how to start 2.2 (I wrote this already some days ago):
We create a new repository cocoon-2.2 and copy (while preserving history) only the
real required parts from the 2.1 repo:
this should be the core src and the build system. Everything else can be fetched from
the 2.1 repo during the build.
Uh? What's the purpose for a 2.2 repo if we fetch sources from the 2.1 one ?
In addition I think we should make a "components block" in the 2.1 repo where we move all components of the core, like all actions, generators etc.
What's the purpose of this ? Do you want to separate the "kernel" (the
very required classes) from the "core" (general-purpose components
unrelated to external libraries) ? If so, what will be part of the
kernel : interfaces, the few statically-accessed classes and the
pipeline/sitemap classes ?
If we do this we really separate the core from everything else and we don't need to
copy the components into 2.2 as well.
This reduces duplicate code to the minimum which should imho make bootstrapping 2.2
much easier.
What do you think?
I don't clearly understand what you want to achieve...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Starting 2.2
Carsten Ziegeler wrote: ... Hmm, yes, but we could start the 2.2 repo with the current core source, so we have a starting point. I expect that blocks will require longer discussions and I personally don't want to wait with 2.2 for this. I'm wondering. What are you personally planning which requires 2.2 repo and can not be done in the current repo? /me feels that you are trying to solve some problem without stating what the problem is Vadim
Re: [RT] Starting 2.2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106077110314347&w=2 Stefano: "the road to real blocks: how to build it minimizing the impact on the existing code and with complete back compatibility (yes, it's possible!)" So let's wait for his RTs. Joerg Carsten Ziegeler wrote: Sylvain Wallez wrote: Carsten Ziegeler wrote: Ok, let's do simple steps perhaps: Do you think that we should start a new repository? This is equivalent to saying "we start a new major version (2.2)". (if the answer is yes, we can talk about the layout). You ask for the solution to a problem that's not defined... Why do you need the 2.2 repo to be created before writing your RTs ? Ok, it has nothing to do with my RT's, I had the impression that blocks required a major version changes and that we want to start with it asap. If I'm wrong here, let's stop this RT. Carsten
Re: [RT] Starting 2.2
On 13/8/03 16:37, "Carsten Ziegeler" <[EMAIL PROTECTED]> wrote: > Ok, let's do simple steps perhaps: > > Do you think that we should start a new repository? This is > equivalent to saying "we start a new major version (2.2)". > > (if the answer is yes, we can talk about the layout). YES! :-) As I have few [RT]s on my own! :-) :-) :-) Pier
RE: [RT] Starting 2.2
Sylvain Wallez wrote: > I don't clearly understand what you want to achieve... > It's plain simple :) Now, the usual way would be to create a new repository (cocoon-2.2) and copy everything from 2.1 in there. Then we have two "branches" which require syncing which can be a real pita. My approach is to sync as less as possible by only copying those parts that we will change in the near future. And this should be the core sources, but not the documentation or any block. As I expect that we will end in a different structure when we have real blocks (e.g. perhaps a blocks repository etc.) this would be imho an easier migration strategy. Does this make sense? Carsten
