[STATUS] (incubator) Wed Dec 28 23:55:48 2005
APACHE INCUBATOR PROJECT STATUS: -*-indented-text-*- Last modified at [$Date: 2005-11-24 00:30:24 -0500 (Thu, 24 Nov 2005) $] Web site: http://Incubator.Apache.Org/ Wiki page: http://wiki.apache.org/incubator/ [note: the Web site is the 'official' documentation; the wiki pages are for collaborative development, including stuff destined for the Web site.] Pending Issues == o Clearly and authoritatively document how to edit, generate, and update the Web site (three separate functions). o Move the stable wiki pages into the official site. o We need to be very very clear about what it takes to be accepted into the incubator. It should be a very low bar to leap, possibly not much more than 'no problematic code' and the existence of a healthy community (we don't want to become a dumping ground). o We need to be very very clear about what it takes for a podling to graduate from the incubator. The basic requirements obviously include: has a home, either as part of another ASF project or as a new top-level project of its own; needs to be a credit to the ASF and function well in the ASF framework; ... o Moving the bylaw documentation from the Wiki to the main site o fix formatting of the project status pages Resolved Issues === o The policy documentation does not need ratification of changes if there seems consensus. Accordingly, the draft status of these documents can be removed and we will use the lazy "commit first, discuss later" mode common across the ASF for documentation (http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=517190) o Coming up with a set of bylaws for the project (http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=517190) o All projects under incubation must maintain a status Web page that contains information the PMC needs about the project. (http://incubator.apache.org/guides/website.html) o Projects under incubation should display appropriate "disclaimers" so that it is clear that they are, indeed, under incubation (http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=504543) The Incubation Process == This tries to list all the actions items that must be complete for a project before it can graduate from the incubator. It is probably incomplete. Identify the project to be incubated: -- Make sure that the requested project name does not already exist and check www.nameprotect.com to be sure that the name is not already trademarked for an existing software product. -- If request from an existing Apache project to adopt an external package, then ask the Apache project for the cvs module and mail address names. -- If request from outside Apache to enter an existing Apache project, then post a message to that project for them to decide on acceptance. -- If request from anywhere to become a stand-alone PMC, then assess the fit with the ASF, and create the lists and modules under the incubator address/module names if accepted. Interim responsibility: -- Who has been identified as the mentor for the incubation? -- Are they tracking progress on the "project status" Web page? Copyright: -- Have the papers that transfer rights to the ASF been received? It is only necessary to transfer rights for the package, the core code, and any new code produced by the project. -- Have the files been updated to reflect the new ASF copyright? Verify distribution rights: -- For all code included with the distribution that is not under the Apache license, do we have the right to combine with Apache-licensed code and redistribute? -- Is all source code distributed by the project covered by one or more of the following approved licenses: Apache, BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially the same terms? Establish a list of active committers: -- Are all active committers listed in the "project status" file? -- Do they have accounts on cvs.apache.org? -- Have they submitted a contributors agreement? Infrastructure: -- CVS modules created and committers added to avail file? -- Mailing lists set up and archived? -- Problem tracking system (Bugzilla)? -- Has the project migrated to our infrastructure? Collaborative Development: -- Have all of the active long-term volunteers been identified and acknowledged as committers on the project? -- Are there three or more independent committers? [The legal definition of independent is long and boring, but basically it means that there is no binding relationship between the individuals, such as a shared employer, that is capable of overriding their free will as individuals, directly or indirectly.] --
Re: The line between full incubation and IP clearance
On 12/28/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > > Martin, > > > Is there a well-defined line between these two mechanisms for bringing > new > > code to the ASF? > > No, not a well-defined one. The IP Clearance is primarily intended for > use > with a relatively simple Software Grant situation into an existing > project, > such as libtool, which we can contrast with mod_cli or mod_ftp. And, > honestly, I think that we have made a few mistakes in the past by using > the > simpler form when a fuller incubation would have yielded a better result > in > terms of community building around new code. > > > I would expect the Oracle ADF Faces donation to be substantial, > > and include a framework that ties everything together. I would > > have thought that would have warranted full incubation > > Is there community, or just code? If a community comes with it, too, I > would certainly expect incubation, however, the e-mail you referenced says > (in part): "[after clearance,] the MyFaces committers treat the code as if > we wrote it ourselves", and I don't see any mention of a community coming, > too. But here is a sample grey area: one or two committers absorbed into > a > healthy community might be deemed acceptable, whereas a substantial number > of new ones might not. So if you buy that argument, where do we draw the > line, and how do we address potential abuse? I suppose I'm asking prematurely, since, of course, I haven't seen a proposal either. ;-) However, up until now, ADF Faces has been part of (or an add-on to - I'm not sure) a commercial Oracle product (JDeveloper). There may be OTN forums that it's discussed on; not sure if that counts as a community. Also, since it's no longer all of ADF Faces that's going to be offered to the ASF, I don't know how that would affect any existing community. I expect that some Oracle developers will be listed in the forthcoming proposal, and they will most likely be needed, too. How many, I have no idea. How much cross-pollination between the ADF Faces code base and the existing MyFaces code is also an open question in my mind. At least initially, I would expect that the ADF Faces code base will be set up as a separate build and download from the existing MyFaces code, until the collective team decides how to integrate the two, or even if integrating them makes sense, versus treating ADF Faces as a separate sub-project. -- Martin Cooper > I'm new in Incubator-land, so I'm not altogether savvy about processes and > > procedures, but wanted to ask about this one. > > It is a fine question. Hypothetically, without judging the merits of this > submission, you raise the spectre of a type of situation that I'd want to > ward against as a general rule. > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: The line between full incubation and IP clearance
Noel, I agree, as we need a better polic/process for IP Clearance, it can't be left to one person. I already insisted on full incubation for the specific issue. Though mind you, i'd love to have some guidelines i can check off of to back up why i think a full incubation is prudent. In this specific case, i think we need a closer look at what's happening given the circumstances and the spectre of a large code base helps reinforce that thought. thanks, dims On 12/28/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Dims, > > > it's been a line in the sand AFAIK, i guess it's Noel's call. > > -1 > > Although that might be technically true, we do things collectively in the > ASF. Mind you, we've not had a process for voting on IP Clearance type > submissions, so that's been a potential loophole. > > > I think we should insist on a full incubation for > > Cherokee/Tomahawk/ADF (whatever it's name is today) > > I responded on the generic issue, but as for this specific submission, I > don't know enough about it, yet. I just got back on e-mail today for the > first time since Friday, so I've got some reading to do. :-) Please feel > free to reply to my e-mail to Martin with your observations, but change the > subject to reflect the specific, rather than general. :-) > > --- Noel > > -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: The line between full incubation and IP clearance
Martin, > Is there a well-defined line between these two mechanisms for bringing new > code to the ASF? No, not a well-defined one. The IP Clearance is primarily intended for use with a relatively simple Software Grant situation into an existing project, such as libtool, which we can contrast with mod_cli or mod_ftp. And, honestly, I think that we have made a few mistakes in the past by using the simpler form when a fuller incubation would have yielded a better result in terms of community building around new code. > I would expect the Oracle ADF Faces donation to be substantial, > and include a framework that ties everything together. I would > have thought that would have warranted full incubation Is there community, or just code? If a community comes with it, too, I would certainly expect incubation, however, the e-mail you referenced says (in part): "[after clearance,] the MyFaces committers treat the code as if we wrote it ourselves", and I don't see any mention of a community coming, too. But here is a sample grey area: one or two committers absorbed into a healthy community might be deemed acceptable, whereas a substantial number of new ones might not. So if you buy that argument, where do we draw the line, and how do we address potential abuse? > I'm new in Incubator-land, so I'm not altogether savvy about processes and > procedures, but wanted to ask about this one. It is a fine question. Hypothetically, without judging the merits of this submission, you raise the spectre of a type of situation that I'd want to ward against as a general rule. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: The line between full incubation and IP clearance
Dims, > it's been a line in the sand AFAIK, i guess it's Noel's call. -1 Although that might be technically true, we do things collectively in the ASF. Mind you, we've not had a process for voting on IP Clearance type submissions, so that's been a potential loophole. > I think we should insist on a full incubation for > Cherokee/Tomahawk/ADF (whatever it's name is today) I responded on the generic issue, but as for this specific submission, I don't know enough about it, yet. I just got back on e-mail today for the first time since Friday, so I've got some reading to do. :-) Please feel free to reply to my e-mail to Martin with your observations, but change the subject to reflect the specific, rather than general. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IP Clearance vs Full incubation
Folks, I was browsing the ip-clearance documents (http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/). IMNSHO, I don't like what's happening. It *SHOULD* be incubator PMC's call whether an incoming donation can take "IP Clearance" route or whether it needs undergo full incubation. A sponsoring PMC should not call the shots on which mechanism is to be used. I don't remember how/who decided on some of the ip clearance things that happened so far. Does anyone agree/disagree? thanks, dims -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is the incubator out of control?
On Wed, Dec 28, 2005 at 03:53:31PM -0500, Davanum Srinivas wrote: > +1 to 3 ASF Members/Officers as mentors > +1 to require Incubator PMC vote for *ALL* incoming projects > +1 to require Incubator PMC vote even on simpler IP imports > yeah, sounds good to me. More mentors / oversight is likely to help quite a bit. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The line between full incubation and IP clearance
Martin, it's been a line in the sand AFAIK, i guess it's Noel's call. I don't remember voting on some of the things on the site (http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/) I think we should insist on a full incubation for Cherokee/Tomahawk/ADF (whatever it's name is today) thanks, dims On 12/28/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > Is there a well-defined line between these two mechanisms for bringing new > code to the ASF? Not having seen the code yet, I can't say for sure, but I > would expect the Oracle ADF Faces donation to be substantial, and include > a framework that ties everything together. I would have thought that would > have warranted full incubation, but it appears to be going through only > the UP Clearance procedure. See: > > http://mail-archives.apache.org/mod_mbox/myfaces-dev/200512.mbox/[EMAIL > PROTECTED] > > I'm new in Incubator-land, so I'm not altogether savvy about processes and > procedures, but wanted to ask about this one. > > -- > Martin Cooper > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is the incubator out of control?
+1 to 3 ASF Members/Officers as mentors +1 to require Incubator PMC vote for *ALL* incoming projects +1 to require Incubator PMC vote even on simpler IP imports thanks, dims On 12/28/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Steven Noels wrote: > > > The Incubator PMC only needs to care about IP and legal blahblah, > > thus the receiving PMCs are tasked with community and brand abuse > > stuff. > > Not true. If there is community development, the Incubator PMC had better > be involved. We're going to have to adjust things, such as Mentorship and > votes to leave the Incubator, e.g., > > - a minimum of 3 ASF Members and/or Officers who have differing > corporate affiliations as Mentors per project. The sponsoring > PMC must identify those ASF Members. Projects who lose one or > more sponsors -- even if they just go quiet -- must make sure > that they regain the minimum of 3. Existing projects that are > not meeting the quorum will not be permitted to release any > code, regardless of otherwise meeting Incubator release guidelines. > > - the Board will determine if there is an Incubator PMC vote to > accept a new project, but at the moment, any PMC can vote to > bring a new project into the Incubator, assuming that they > otherwise meet the guidelines. There are still guidelines > regarding candidacy, and the Board will be encouraged to > take a dim view of any PMC trying to game the system. > > - the Incubator PMC having the sole vote on all graduations from > the Incubator. The target PMC votes to accept first, and then > notifies us that they are ready for our vote. > > It is a talking point, but we may have to perform that vote even on simpler > IP imports, just to prevent gaming the system, e.g., "well, it's not really > a new project". Actually, all of those are talking points. > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The line between full incubation and IP clearance
Is there a well-defined line between these two mechanisms for bringing new code to the ASF? Not having seen the code yet, I can't say for sure, but I would expect the Oracle ADF Faces donation to be substantial, and include a framework that ties everything together. I would have thought that would have warranted full incubation, but it appears to be going through only the UP Clearance procedure. See: http://mail-archives.apache.org/mod_mbox/myfaces-dev/200512.mbox/[EMAIL PROTECTED] I'm new in Incubator-land, so I'm not altogether savvy about processes and procedures, but wanted to ask about this one. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is the incubator out of control?
Steven Noels wrote: > The Incubator PMC only needs to care about IP and legal blahblah, > thus the receiving PMCs are tasked with community and brand abuse > stuff. Not true. If there is community development, the Incubator PMC had better be involved. We're going to have to adjust things, such as Mentorship and votes to leave the Incubator, e.g., - a minimum of 3 ASF Members and/or Officers who have differing corporate affiliations as Mentors per project. The sponsoring PMC must identify those ASF Members. Projects who lose one or more sponsors -- even if they just go quiet -- must make sure that they regain the minimum of 3. Existing projects that are not meeting the quorum will not be permitted to release any code, regardless of otherwise meeting Incubator release guidelines. - the Board will determine if there is an Incubator PMC vote to accept a new project, but at the moment, any PMC can vote to bring a new project into the Incubator, assuming that they otherwise meet the guidelines. There are still guidelines regarding candidacy, and the Board will be encouraged to take a dim view of any PMC trying to game the system. - the Incubator PMC having the sole vote on all graduations from the Incubator. The target PMC votes to accept first, and then notifies us that they are ready for our vote. It is a talking point, but we may have to perform that vote even on simpler IP imports, just to prevent gaming the system, e.g., "well, it's not really a new project". Actually, all of those are talking points. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is the incubator out of control?
Erik Abele wrote: > Roy T. Fielding wrote: >>> What you do have is the right to vote against their graduation if >>> you so desire. > The second sentence does exactly what the first sentence forbids, no? > It tells people what they cannot do at the ASF. It is established that the Incubator is the sole authority on new entry into the ASF. The talking point is the barrier into the vestibule, if you will. Roy wants an open policy, others are concerned that there is too much chaos and confusion in the antechambers. Worse, they are concerned that projects under the Incubator may be causing confusion about what is and is not under the imprimatur of the ASF. We can revisit branding, but I don't believe that a totally non-ASF brand is at all warranted, as explained by Justin. --- Noel smime.p7s Description: S/MIME cryptographic signature
RE: Is the incubator out of control?
Justin Erenkrantz wrote:
> If any ASF PMC believes it is in the best interest of the Foundation to
> accept a podling and they are willing to dedicate resources ("people") -
> then anyone on the Incubator PMC has no standing to challenge that
> decision. When a PMC approves a podling, the only thing the Incubator
> PMC can decide is whether the project can "leave" the Incubator.
A fair summation, although there are people who believe that the Incubator
PMC should have more of a say in the entry of a project for Incubation.
Jim and Geir both raise the hypothetical of what would have happened if
Tuscany were submitted as a fait accompli by the WS PMC, rather than being
critiqued here. Following up on some comments and other examples from Dims,
I'd say that this raises a separate issue, which is something to address
Foundation-wide: how to push for more synergy and cooperation where
appropriate between our projects, without excluding cooperation with
external ones. To date, that has only been something promoted by
individuals, such as myself, who want to see ASF projects collaborating.
> Even without a PMC, if *one* of our members out there thinks a project is
> worth doing and they can write something mildly resembling a charter down
> on paper, that's all I need to hear for a +1.
That has been my policy, too, although if we adopt the notion that there
must be 3 Members/Officers as project mentors, it would take more than one
such mentor for a project to start.
I don't know whether or not that would satisfy Geir, unless we did something
about not having all of those mentors from the same PMC. There seem to be
concerns that some other PMC could become out of control, and game the rules
in the absence of some balance. Personally, I would hope for better from an
ASF Member, and will consider whether future candidates would make good
Incubator Mentors.
> That's the fundamental problem I have with this entire thread: people
> are trying to limit the growth or exclude projects. How? On what basis?
Agreed. We must plan for scale, and ensure that AS WE SCALE, that the
proper processes are in place.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is the incubator out of control?
Jim Jagielski wrote: > I have never envisioned a case where the Incubator would > be at odds with the desires of the PMCs and the members. As Geir noted, I can see the potential for the former, but of the latter, I would hope not. The Members are the Incubator in many real ways, and the Incubator exists to directly serve the interests of the ASF Membership. > I would see such as thing (denying acceptance) as something that > would require as much reason and rationale as a code-based veto > would; much more so, in fact. Are you suggesting that graduation from the Incubator should be vetoable, i.e., treated as a vote on code rather than treated as policy? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is the incubator out of control?
Justin Erenkrantz wrote: > I'm all in favor of enforcing a strict embargo until the Incubator PMC ? approves a proposal, an initial code drop lands, and the mailing lists are > created. Until those happen, any active publicity claiming it to be a part > of the ASF is a flat-out lie. (In the future, the PRC is almost certainly > going to reject any releases before this happens.) Then we have a different policy to put into place: NO PR WITHOUT THE APPROVAL OF THE PRC. And that should be applied to ALL ASF PROJECTS, not just those in the Incubator. That puts more work on the PRC, which will need to grow to scale, but I'd go for such an ASF-wide policy. We would have to document that broadly, and make it clear to donors. That probably won't help with the "We're planning to donate" type announcements, but ... > after those steps occur (which should be relatively quickly in the > order of a few weeks), removing the Apache brand from podlings would > be incredibly harmful. +1 > The only reason that these projects can have the 'Apache' brand is because > a member of the Foundation is willing to act as mentor *and* the Incubator > PMC approves each interim release. If the mentor isn't keeping the project > in line with respect to our values, then the Incubator or the 'destination' > PMC needs to step in and provide guidance or terminate it. Hopefully, a 3 active mentor policy will help with this issue. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RT] Super Simple Site Generation Tool
[Sorry for the delayed response ... spent a few days rebuilding my laptop.] David tried to get people interested in the issue, constructively, back in November. ref: http://mail-archives.apache.org/mod_mbox/incubator-general/200511.mbox/%3c20 [EMAIL PROTECTED] Please review David's post from almost two months ago, and contribute constructively to the discussion. There is no need to waste an hour. For one thing, we've told people repeatedly to just publish their HTML changes, and that the site will be taken care of for them. All tools have issues. Anakia remains the one I am most comfortable with, but I have even had issues with anakia, which we use with JAMES, trying to manage the occassionally annoying project stylesheet. And Maven ... well, no thanks. In any event, there are a variety of ways forward. Alex, Ted, Serge and others appear to like the idea of a authentication restricted Confluence to use for generating HTML. Daisy is used by Cocoon for similar purposes. But most of the discussion probably belongs on the [EMAIL PROTECTED] list, where we're trying to bring some semblance of sanity to the overall ASF site management process. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting a java specs project
On 12/27/2005 7:12 PM, Henri Yandell wrote: On 12/27/05, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: Seems like an oxymoron, community should be active, but the code may not, no? How can this be? Two ways: 1) The conversation that Brett mentions. General pan-apache Java things. I'm a little worried about any authorization issues where only an EG is able to commit. If they get quiet, the community would be unable to make changes. I agree with Brett on the worry about 'how do I do servlets' questions. My recommendation would be to avoid a specs-users list until there are people asking relevant questions. Just make a specs-dev list to start with. 2) The commons community to the side provides a paralleling structure, with hopefully much of the same people in both; people who do pan-apache Java things. I still don't see #1. However, I still feel that this all belongs in Jakarta Commons. Regards, Alan
Re: Starting a java specs project
On 12/27/2005 4:25 PM, Brett Porter wrote: Discussion of upcoming specs, discussion of usage of the specs, a users list that helps people use the specs (this is necessary, but worries me about getting "how do I do servlets" type questions). I guess there is also scope to innovate in addition to the specs and work on commons components that do things the specs missed. Is there much non-code activity around specs in Geronimo right now? There is no activity. Once the specs have passed the TCK, people are really only interested in the implementation that's on top of the specs. Regards, Alan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] [draft #2] "How to graduate from the incubator" topic
On 12/23/05, Martin Sebor <[EMAIL PROTECTED]> wrote: > I spotted the same "discrepancy" myself a while back (I only found > one podling with a STATUS file -- Beehive). Eventually it turned out > that what was meant by the STATUS file was the podling's status Web > page. > > > > I think that was just how the derby mentor started the derby project off > > and I was generalizing. Should I remove this reference to the project > > repo status file? > > That sounds reasonable to me. As I understand from Noel and David's > responses to my query, a file named STATUS is not required to exist. I think a STATUS file is original HTTPD practice that too few ASF projects have adopted or maintained. In my experience, it is more difficult for someone to get started in a community without a STATUS file that summarizes what is happening the the project, as well as outstanding decisions. As projects mature, there are decisions that we made months or years ago that are difficult to document anywhere but in a STATUS file. Some of what HTTPD now carries in the STATUS file, many projects would now carry as part of a RoadMap, either as a manual web page or in something like JIRA. But, I would suggest that it would be useful to encourage project to keep a standard record of the decisions, votes, and reports made by a project. Here's the STATUS file that HTTPD keeps now. * http://svn.apache.org/viewcvs.cgi/httpd/httpd/trunk/STATUS?view=markup Here's what we've setup for iBATIS and Struts. * http://svn.apache.org/viewcvs.cgi/ibatis/trunk/STATUS.txt?view=markup * http://svn.apache.org/viewcvs.cgi/struts/build/trunk/STATUS.txt?view=markup -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Super Simple Site Generation Tool
David Crossley wrote: If people have issues with Forrest, then please take them to the [EMAIL PROTECTED] mailing list. It is totally unfair to a new project to just criticise it from afar. We get very few emails to the user mailing list about any issues with Forrest. This seems to be especially the case with committers from Apache projects that decided to use Forrest. This is *very* important. In cal my time on the Forrest project I do not recall a single question from an Incubator volunteer on our user lists. In this thread one person encouraged people to visit the archives of the Forrest lists because they were fed up of working with Forrest to get it to where they want. I checked, last post with that name on the dev list was March 2004 and there were no posts to the user list. How is that working with us? Why is it that I find myself joining yet another list because I hear grumbles in a completely unrelated list saying that Incubator has some issues with Forrest? Why should I, as a Forrest dev, have to join your list? Even having joined this list, I see almost no contributions to Davids repeated attempts to try and understand what incubator need, so I am still unaware of the problems. In my opinion the problem is not the tool, it is the number of volunteers wanting to work with whatever tool is in use. This is the issue that needs addressing regardless of whether you use Forrest/Maven/Anakia or some Python tool created specifically for the purpose. That being said, as people will see from my replies on the site-dev list, I have some sympathy with Leo, and I do agree that Forrest is large and cumbersome for building a simple site. However, I am annoyed at various statements in this thread that claim to represent Forrest as it stands today but in fact illustrate a lack of understanding of the capabilities of Forrest head which is an increasingly stable platform that has been working towards the goals of the site-build project [1] (despite claims to the contrary in this thread). Current SVN head of Forrest, coupled with Davids implementation of the ForrestBot means Forrest can do steps one through seven of Leo's workflow (with a local install of Forrest being optional). Of course, we are a 0.8-dev project, not a 1.0 project. The solution is not perfect, it is still a 0.8-dev project, and the claimed support needs to be tested and validated in a wider range of projects (currently we only have private dev projects, Forrest test sites and Cocoon-docs) Step 8 (publishing) cannot currently be done by any tool due to the fact that infra require that the live server to be updated by a pull rather than a push process (for security reasons). It'd be great to work with the incubator to help validate things, but that requries more than David (and now myself) to support the incubator site, it requires at least a willingness to provide feedback to the Forrest community about what is good and what is bad. I don't see that happening so maybe Leo's Python scripts are the solution (at least they will allow me to not worry about the incubator site). Ross [1] http://people.apache.org/~rgardler/site-dev/Site-Build.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: [RT] Super Simple Site Generation Tool
On Wed, 28 Dec 2005 14:03:34 +1100, "David Crossley" <[EMAIL PROTECTED]> said: > Davanum Srinivas wrote: > > > > Example: last apachecon, Geir was trying to update geronimo.html, it > > took 30+ mins before asking for help. It took me 15+ minutes to figure > > out that geronimo.html was not being linked from any page in the web > > site. So we lost close to an hour of hackathon time trying to do > > something really simple and silly - add a line of text to the > > geronimo.html asking folks to go to the geronimo actual web site. > > Steady on. Just prior to that, someone made a change that > removed geronimo.html from the /projects/ area. The normal process > with such a sudden break, is to investigate the prior changes that > caused it. Something that Forrest could do would be extend the Cocoon CLI so that it doesn't crawl to find links, but gets them from the site.xml. It is an obvious feature that Cocoon's CLI could use, and shouldn't be _too_ hard to implement. Sounds like this might have avoided this particular issue and, to my mind would suit the Forrest use-case much better. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
