I guess one more thing on this.. As soon as META is on some sort of HEAD versus branch, I think then I can start adding in the personality for Turbine 2.4. It is pretty much the same as 2.3 fortunantly.
Eric > -----Original Message----- > From: Eric Pugh [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 10, 2004 9:59 AM > To: Turbine Developers List; [EMAIL PROTECTED] > Subject: RE: Move META to CVS Head? > > > I think it all comes down to if anyone will do the work.. I > don't see why a > single repo makes releases harder then multiple repos.. I like > having less > to checkout to see a project versus more to checkout. I think more repo's > sets up a barrier to entry for people to explore around. > > I agree though with your review of the codebases, and would be HAPPY if > someone would move them to the archives. > > jakarta-turbine-3: me just trying to get it to work with latest > and greatest > commons-configuration for Scarab > jakarta-turbine-stratum: same thing. argh. > jakarta-turbine-tdk: should be marked as deleted. I think that the TDK > actually hurts people in the long run. A demo is nice, point to Antelope, > which will soon be on T2.4 HEAD. > > > So, having said all that, I'll wait to see if anyone follows up! > Eric > > > > > -----Original Message----- > > From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] > > Sent: Monday, August 09, 2004 7:40 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Move META to CVS Head? > > > > > > "Eric Pugh" <[EMAIL PROTECTED]> writes: > > > > >I'd actually be -1 to moving meta to yet another cvs tree.. > > Right now the > > >Turbine project has 9 different CVS trees.. Which means that from an > > >infrasturcture view, adding a new committer requires adding them > > to 9 trees, > > >not that it ever gts done. > > > > I know. There are not nine. There are twelve... =:-) > > > > Main thing here would be some cleaning up and moving stuff to the > > archives.apache.org > > > > Basically, we are using three trees: > > > > jakarta-turbine-2 > > jakarta-turbine-fulcrum > > jakarta-turbine-site > > > > These are alive and must be kept. > > > > jakarta-turbine-jcs - No longer a "real" part of turbine > > Should be incubated or moved to > > Jakarta 2nd level (or DB 2nd level) > > > > > > Limited work is going on here: > > > > > > jakarta-turbine-3 - Last check in six months ago. Seems to > > have the odd maintenance check in > > The relevant parts have been rolled > > into 2.4 > > => dead until someone steps up > > > > jakarta-turbine-stratum - I'm surprised. Eric, you're actually > > _working_ on this? For all I know, this > > is dead and not really used. I'm > > teased to CfV for an 1.0 release so > > we no longer have to drag a beta > > around but to me, this is quite > > dead. > > > > jakarta-turbine-tdk - While Jeff built a 2.3 version of > > the TDK, he never checked it > > into the CVS. For me, yeah, it is dead. > > > > jakarta-turbine-flux - The flux application. Could be > > easily rolled into a "turbine > > demos" CVS. Jeff did some work here > > > > Without activity are > > > > jakarta-turbine-jyve - ???? Dead. > > jakarta-turbine-origami - ???? Dead. > > jakarta-turbine-torque - Moved to db-torque > > > > jakarta-turbine-components - Never heard of this. Empty. > > > > jyve, origami and torque are definite candidates for > archives.apache.org. > > > > components, I don't know about. Something from the 2.4 tree? If > > not, nuke it. > > > > JCS _should_ be moved out of the Turbine space. We should discuss this > > with the JCS guys and in the PMC. There was limited discussion on > > [EMAIL PROTECTED] but it went nowhere. > > > > There is flux. Jeff did some work on it so I think it still runs on > > 2.3/2.4. IMHO we would be much better off with jakarta-turbine-demos > > which includes a few programs with descriptions to showcase various > > aspects of Turbine. Flux can be a part of this. > > > > stratum and turbine-3 (and tdk, too) are in "barely maintenanced" > > mode. I see no reason why they can't be moved to archives.apache.org > > (this stuff is not lost. It is there for "no longer in active > > development"). The TDK should only be moved _after_ we have an > > impression if our users accept the plugin (which means that you must > > use maven!) or want to stay with the TDK. > > > > This leaves us with > > > > jakarta-turbine-2 (which at some point IMHO _should_ be > > renamed to jakarta-turbine) > > jakarta-turbine-site > > jakarta-turbine-fulcrum > > > > and a hypothetical > > > > jakarta-turbine-meta > > jakarta-turbine-demos > > > > and maybe > > > > jakarta-turbine-tdk (depending on the activity) > > > > >Part of the reason for the extensions is because I can see > more code that > > >isn't central to turbine.jar being added, but not wanting to > > setup more SF > > >projects, CodeHaus projects, more Jakarta projects etc.. Since all the > > >committers have rights to jakarta-trubine-2, lets put everything > > in there. > > > > I don't like this. If we want to do this, we should go for a > > 2-level approach and move the > > HEAD there: > > > > jakarta-turbine/core > > jakarta-turbine/components > > jakarta-turbine/demos > > jakarta-turbine/somethingelse > > > > The problem with "put everything into single repository" are release > > cycles. I could see a quick releasing of the maven-plugin, because we > > have an automated distribution and updating mechanism in maven and > > with ibiblio.org. However, I don't want to make a new release of the > > Turbine core every two weeks or so. > > > > >However, if you really want another repo, what about > > jakarta-turbine-tdk.. > > > > The TDK is the TDK. Let's keep it at this. We can move the repo to the > > archives. > > > > >That would put it out of our misery.. (on a side ntoe, I email > > >[EMAIL PROTECTED] to remove it from gump!). > > > > Thanks. :-) > > > > > > >I think that /extensions should be in HEAD, and anything in > extensions is > > >viewed as it's own mini project, with it's own lifecyle.. > Similar to how > > >each maven plugin or commons projects gets released independenctly. > > > > Tagging and releasing independently might work. I will think about > > this a little harder. > > > > BTW: Move to SVN anyone? SVN rocks and the Eclipse support from > > tigris.org works well. > > > > I moved my current main project from CVS to SVN and I will NEVER NEVER > > NEVER NEVER go back again. > > > > Regards > > Henning > > > > > > >Eric Pugh > > > > >> -----Original Message----- > > >> From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] > > >> Sent: Monday, August 09, 2004 4:48 PM > > >> To: [EMAIL PROTECTED] > > >> Subject: Re: Move META to CVS Head? > > >> > > >> > > >> "Folkens, Brad" <[EMAIL PROTECTED]> writes: > > >> > > >> >We use it extensively (inplace) - our interface developer > > likes to modify > > >> >the .vm files (and css, etc) without having to redeploy a war > > or rerun a > > >> >target or goal each time he makes a change. The TDK was always > > >> very nice to > > >> >have that inplace development - and it's very convenient > > having the two > > >> >options in the META plugin. > > >> > > >> Cool to hear about this. > > >> > > >> >In response to moving it out of the jakarta-turbine-2 tree, and > > >> for what my > > >> >2c is worth, I'd love to see that happen. It's a little > > confusing having > > >> >that extension limited to the branch it's in. > > >> > > >> This would be my preferred option, too. I don't want to create a > > >> second TDK tree (which is only updated sporadically), though. > > >> > > >> Regards > > >> Henning > > >> > > >> -- > > >> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH > > >> [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ > > >> > > >> RedHat Certified Engineer -- Jakarta Turbine Development -- > > hero for hire > > >> Linux, Java, perl, Solaris -- Consulting, Training, Development > > >> > > >> "Fighting for one's political stand is an honorable action, but re- > > >> fusing to acknowledge that there might be weaknesses in one's > > >> position - in order to identify them so that they can be remedied - > > >> is a large enough problem with the Open Source movement that it > > >> deserves to be on this list of the top five problems." > > >> -- Michelle Levesque, "Fundamental Issues with > > >> Open Source Software Development" > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > >--------------------------------------------------------------------- > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH > > [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ > > > > RedHat Certified Engineer -- Jakarta Turbine Development -- > hero for hire > > Linux, Java, perl, Solaris -- Consulting, Training, Development > > > > "Fighting for one's political stand is an honorable action, but re- > > fusing to acknowledge that there might be weaknesses in one's > > position - in order to identify them so that they can be remedied - > > is a large enough problem with the Open Source movement that it > > deserves to be on this list of the top five problems." > > -- Michelle Levesque, "Fundamental Issues with > > Open Source Software Development" > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
