Re: [PROPOSAL] One development list
Daniel F. Savarese wrote: In my opinion, JMeter should really go top-level, but the community has not yet (and may never) come to that conclusion. JMeter used to be just at the brink of being viable as a TLP. Mailing list traffic is stable and high, but the number of active developers was very close or maybe below the minimum three. There were a few occasions where Sebastian had to beg for additional reviewers to make a release. But I don't know whether that changed in the last year or so. Sebastian considered JMeter to be a part of the Jakarta community, and had to watch the rest of Jakarta dissolve around it. Unless the development community has grown beyond three, there is no natural or easy way out for JMeter. Perhaps we could combine all user lists except for JMeter. Yes, that would send a clear message: You're the odd man out. Like HttpClient getting a separate mailing list in Commons. ;-) cheers, Roland - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [PROPOSAL] One development list
Daniel F. Savarese wrote: general@ as user@ to contain user traffic for all Jakarta projects, retiring all the -user lists in the process. People can specify the specific project referred to in the subject a la Commons That may work for Commons, because it is the established procedure there. It will not work as a newly defined procedure for a new all-Jakarta user list. Have you noticed how much traffic there is on jmeter-user? It will easily drown all other communication on a combined user list. Subscribers to any other Jakarta user list will *not* be amused about getting all that into their inboxes. Subscribers to jmeter-user will probably not even notice the additional traffic. http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-user/ cheers, Roland - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: Slide lists
Brett Porter wrote: A related side note - some time back I think there was a request to shut down the slide user and dev lists, but that slipped off the radar. Is that desired now? At the time when we retired Slide, the idea was to keep the lists open in case somebody picks up interest. Based on this year's activity on the lists, I'd say there is no interest. The lists can be shut down. Since there are still automated mails being sent to slide-dev from Bugzilla and Gump, that address should be forwarded to an existing mailing list. cheers, Roland - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
style/jakarta-maven.css
Hi folks, while updating the Jakarta site for the HttpComponents move, I noticed that somebody had modified jakarta-maven.css on the server directly, instead of changing the contents in SVN and checking it out. The change was to replace the ad for ApacheCon 2007 with the one for ApacheCon 2008. A good idea to update that, but I recommend to use the established procedures for updating our website. It's fixed now. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] HttpComponents has gone TLP
The Apache HttpComponents team has left Jakarta and built a new home as an Apache top level project. The new website is located here: http://httpcomponents.apache.org/ http://hc.apache.org/ Future releases of HttpComponents, including releases of the [Jakarta][Commons] HttpClient 3.1 codebase, will no longer be announced on the Jakarta mailing lists. Please subscribe to the Apache announcements list [1] or one of the HttpComponents mailing lists [2] to receive our announcements in the future. The HttpComponents team would like to thank the Jakarta project for providing us a home in which to grow up. Roland Weber, on behalf of the HttpComponents PMC [1] http://www.apache.org/foundation/mailinglists.html#foundation-announce [2] http://hc.apache.org/mail-lists.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] Jakarta Slide is retired
The Apache Jakarta PMC is sorry to announce the retirement of the Jakarta Slide subproject. After it's last release in December 2004, development activity was significantly reduced and came to a total standstill this year. Without a minimum developer community that can release security fixes, we have no choice but to retire Slide. We'll keep at least one of the mailing lists open for a transition period, so users can discuss alternatives and migration away from Slide. Further use of the Slide codebase is discouraged. One alternative to Slide is provided by the Apache Jackrabbit project. Jackrabbit has a healthy, active developer community and provides, among others things: - a server-side content repository - a WebDAV server component for access to the repository - a WebDAV client component Please visit http://jackrabbit.apache.org/ for more information. We apologize for the inconveniences. Roland Weber (wearing an Apache Jakarta PMC hat) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HttpComponents TLP discussion rekindled
Hi all, for your information, I've started another HttpComponents TLP discussion on httpcomponents-dev. This time, it's for HC alone. No offense, but reviving the Slide community around the WebDAV client codebase is a challenge of it's own, and one we'd rather not tackle at the same time as the TLP move. We still feel that a WebDAV client would be a good complement to our current codebase. However, Oliver as the only volunteer that joined the last discussion will not be able to handle the move and revival without significant help from us. So we want to be heading TLP first, and come back later to see what we can do about Slide. Everything else would be stretching our resources too thin. Anyone interested in the future of HttpComponents, please participate in the discussion and share your thoughts over at [EMAIL PROTECTED] thanks, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: External plugin repository for JMeter?
Hi Sebastian, sebb wrote: > I don't see it as splitting the community, rather as an adjunct to the > existing community. > > One of the reasons would be to allow independent release cycles. > > Also, not every user would need all the plugins. > > Perhaps this could be done by rearranging the JMeter project, but it > seems cleaner to have a separate repository - as is done with Maven. HttpComponents is also managing currently two components on separate release cycles. However, that comes with a certain overhead. At the current frequency of our releases, I can fully understand Oleg's reluctance against putting more modules on separate release cycles. If the idea is to have each extra JMeter plugin on a separate release cycle, you're probably better off without the Apache overhead. I assume Codehouse does not require three PMC votes for a release? If the extra JMeter plugins are meant to share on release cycle, and there are no licensing issues, I believe it can be handled at Apache. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMeter makes it to worsethanfailure.com
sebb wrote: > Yes, I've seen that, but AFAIK it only happens if the installation is > incomplete. I'm dreaming of writing a GUI application where clicking on 'Help' will pop up an "Are you sure?" dialog without further explanations. That should drive the noobs mad! *harharhar* ;-) Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Apache JMeter 2.3 final
Congratulations! sebb wrote: > The Apache JMeter team are pleased to announce the release of Apache > JMeter 2.3 final. > > Apache JMeter is a Java application designed to test server applications. > It can be used to: > * generate test loads > * test functional behaviour > * measure performance. > > See http://jakarta.apache.org/jmeter/ > > The release can be downloaded from: > > http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi > > Only the binary archive is needed to run JMeter - there is no need to > download the source archive. > > However there are some optional libraries which are not included. > See the "Getting Started" page for details: > > http://jakarta.apache.org/jmeter/usermanual/get-started.html > > This release fixes a few outstanding bugs which did not make it into > RC4, and some documentation has been updated. > > The full list of changes can be found at: > > http://jakarta.apache.org/jmeter/changes.html > > Please read the changes carefully as there are some minor > incompatibilities with the previous release (2.2). > > All users are recommended to upgrade to this release. > > Enjoy! > The JMeter team > > - > 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]
FYI... recently on Incubator
Hi folks, in a recent discussion on [EMAIL PROTECTED], one of the former Jakarta projects that went TLP has been mentioned [1] as an example of a community that wouldn't meet Incubator standards and might be or become an issue, community-wise. Since the projects still here at Jakarta are likely to face the same problems sooner or later, I've sent a mail asking for suggestions. (not yet in the archives at the time of this writing) I just wanted to let you know that, and provide a post to "reply to" in case any suggestions are coming in :-) cheers, Roland [1] http://mail-archives.apache.org/mod_mbox/incubator-general/200709.mbox/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Reminder: Board Report
Hi all, the Jakarta board report is due this month. The meeting is scheduled for Sep 19th, so Martin will probably have to submit the report on Sunday Sep 16th. The projects still here at Jakarta should update their reports by then: http://wiki.apache.org/jakarta/JakartaBoardReport-current cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Suggestion to use OpenGrok to index all Jakarta source code
Hello Alf, > So I would like to suggest that OpenGrok is set up to search and index > the Subversion repository at http://svn.apache.org/repos/asf/ That sounds like something that would need to be set up by the Apache infrastructure team. See this blog, section 'Why we say "no" to your ideas' to prepare for their response: http://www.jroller.com/lsd/date/200507 Considering that the future of Jakarta is rather uncertain, I don't see much chance of this being implemented on behalf of Jakarta on an Apache machine. If Jakarta had a VM or Solaris zone you could try to run it there, but afaik we haven't. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] JMeter + Cactus + ... -> Testing TLP
Hello Petar, please start vote threads for voting on proposals, not to initiate a discussion. I've seen it mentioned that Jakarta is way too vote-happy. There was some discussion of the idea on this mailing list more than a year ago, see the threads at [1], [2]. The key items I remember are: - Umbrella projects are not well received by the board. - "Testing" is a category, not a project scope. [3] To avoid re-iterating the same arguments again, I suggest the following steps: 1) everyone read through the old discussions 2) define a project scope that includes JMeter and Cactus, but preferably no existing TLP or large subproject 3) choose a project name that is not a category 4) go TLP and show that the project works Once the new project is up and running, it is still time to attract other subprojects, or to adjust the project scope. I've made suggestions for 2 just before the previous discussion ceased.[4] There were also some name suggestions. cheers, Roland [1] http://mail-archives.apache.org/mod_mbox/jakarta-general/200606.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/jakarta-general/200606.mbox/[EMAIL PROTECTED] [3] http://mail-archives.apache.org/mod_mbox/jakarta-general/200606.mbox/[EMAIL PROTECTED] [4] http://mail-archives.apache.org/mod_mbox/jakarta-general/200606.mbox/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r567258
The JDK version used may also have to do with it: http://issues.apache.org/bugzilla/show_bug.cgi?id=38781 cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r567258
Hi Sebastian, > The u-umlaut characters were replaced by ? > > [But I don't know exactly how the mangled version was generated.] > > The output is currently generated in iso-8859-1 (or iso-8859-15); the > input is specified using either an actual u-umlaut, or ü That's a nasty one to track down. Apart from encoding specs in the style sheet, there's also the encoding in the line of the source file to consider. The source file specifies ISO-8859-1. I wonder whether svn might screw up the charset on co/ci. Isn't there also a tool that does some postprocessing in order to normalize the XML? If an XML processor generates UTF instead of the specified ISO-8859-1, and the next processor expects ISO-* as input, the data could get screwed up. You'd have to chase all the chain from input to final output. > I'll see about adding a check - should be easy enough to generate a > dummy html file from an xml containing some accented characters and > check that the result is as expected. That's probably the best approach. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Slide + HttpComponents => TLP
Oleg Kalnichevski wrote: >> Will the current [EMAIL PROTECTED] and [EMAIL PROTECTED] >> mailing lists continue to exist alongside [EMAIL PROTECTED] >> and [EMAIL PROTECTED], where the Slide WebDAV client finds >> a new home? > > Yes, as aliases. Then server-related discussions would end up on the mailing lists of the new project. There is still some discussion going on, and it is not focused on the WebDAV client afaik. If the new project is not taking over the whole Slide codebase, it shouldn't take over the existing mailing lists either. I don't consider that decision as something we can care about later. We might end up doing that if Slide is officially declared dormant/unsupported, but so far the participation in this discussion is clearly insufficient for such a step. Besides, I see the new project as a potential home for more than just HttpComponents and the Slide WebDAV client. For the moment, I can think of the following: - HttpComponents - Multipart Request Entity (not HTTP, but required for WebDAV) - WebDAV - CalDAV (extension to WebDAV) - not-yet-commons-ssl (HTTPS) Anyway, with just the two of us sharing our views, this discussion is moot. Allowing 7 days for a vote and 3 days in advance for a board meeting agenda, we're already too late to make it to the board meeting on Aug 29. The next scheduled meeting after that is on Sep 19. With all due respect to Oliver, if we don't see significantly more (diverse) input from the Slide side until early September, I would prefer to send HttpComponents TLP on it's own. The WebDAV client could still join when things for Slide are sorted out here at Jakarta. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r567258 - in /jakarta/site: docs/ docs/site/ docs/site/downloads/ docs/site/news/ docs/site/pmc/ xdocs/stylesheets/
sebb wrote: > Is there a way to fix build.xml so that the user's default encoding > does not affect the output? Or perhaps we could add a check and warn > if the encoding is wrong? > > The xml source files are already flagged as ISO-8859-1, as is the > stylesheet, which uses output encoding ISO-8859-1 as well, which one > might have hoped would be enough... I don't know what the exact symptoms of the problem are. This is what the XSLT spec says about output encodings [1]: > The encoding attribute specifies the preferred encoding to use for > outputting the result tree. XSLT processors are required to respect > values of UTF-8 and UTF-16. For other values, if the XSLT processor > does not support the specified encoding it may signal an error; if > it does not signal an error it should use UTF-8 or UTF-16 instead. Is the output generated in UTF-8 or UTF-16? Then the solution would be to use one of those as the output encoding, since only those are required to be supported on all platforms. cheers, Roland [1] http://www.w3.org/TR/xslt#section-XML-Output-Method - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Slide + HttpComponents => TLP
>> Disassociation from the server side. > > What is the benefit of that? At any rate in my opinion it is not worth > trouble of rebranding the whole project. Will the current [EMAIL PROTECTED] and [EMAIL PROTECTED] mailing lists continue to exist alongside [EMAIL PROTECTED] and [EMAIL PROTECTED], where the Slide WebDAV client finds a new home? That would be bound to confuse users. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Slide + HttpComponents => TLP
Oleg Kalnichevski wrote: > > If there are no plans to develop non-client bits any further, That exactly is my concern. I still hope for some more input from Slide developers. > I personally think WebDAV client should keep Slide as its name. I could live with that. > Slide is a well established brand As a server component that happens to have a little client-side WebDAV library as an add-on. > and I see no benefit in discarding it Disassociation from the server side. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Slide + HttpComponents => TLP
Oleg Kalnichevski wrote:
>
> What's wrong with org.apache.slide for WebDAV components?
If we're not taking over the full Slide codebase,
and if Slide\{WebDAV-client} is not officially
declared dormant in Jakarta, then we'd have two
independent projects using the same namespace.
Since a WebDAV client based on the 4.0 HttpClient
will be incompatible, it's also a question whether
the same package names should be used. That will
create name clashes in applications that for some
reason - for example during migration - have to
use both old and new packages.
While Martin mentioned in the June board report [1]
that he would like to keep the Slide codebase in
one piece, the current state of the discussion tends
towards carving out the WebDAV client only. In that
case, I wonder whether we should position the "new"
component as a successor to Slide at all.
cheers,
Roland
[1] http://wiki.apache.org/jakarta/JakartaBoardReport-June2007
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Slide + HttpComponents => TLP
Oleg Kalnichevski wrote: > Could you live with HttpComponents being the name of the new TLP? I > would really like to avoid having to come up with a completely new name > for the project. HttpComponents use the package org.apache.http. I would prefer something abstract as the home for non-HTTP code such as WebDAV or multipart. How do we do that without a project name to use as the package name? (org.apache.httpcomponents is not an improvement over org.apache.http ;-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Killing the getinvolved page?
Henri Yandell wrote: > I've migrated (somewhat) the Get Involved from the Jakarta site to the > Apache site: > > * http://jakarta.apache.org/site/getinvolved.html > * http://www.apache.org/foundation/getinvolved.html > > Any thoughts on removing the Jakarta one and replacing it with a link > to the central one? Makes sense. While Jakarta is downsizing/dissolving, it makes little sense to get people involved directly here. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient 3.x Homepage
Henri Yandell wrote: > Sorry, yeah. Just doing things at the macro level and then trying to > figure out what got screwed up lower down. > > So what should we do? Oleg is planning to cut the 3.1 final release within the next two weeks. He'll re-create the site below /httpcomponents/ on that occasion. Once that is done, we'll drop you ([EMAIL PROTECTED]) a note that you can set up a redirect and remove your copy of the site. If it doesn't interfere with the Commons redirect from jakarta.a.o to commons.a.o, I would suggest to also set up a second redirect from the original location at j.a.o/commons/httpclient/, to avoid double redirection for the plenty of links in our mailing list archives. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Slide + HttpComponents => TLP
Oleg Kalnichevski wrote: > Could you live with HttpComponents being the name of the new TLP? I > would really like to avoid having to come up with a completely new name > for the project. The name is ugly and unwieldy but we have already had a > number of public releases so it is more or less established. I would have kept HttpComponents as the brand for the HTTP activities of the new project, whereas a shorter name could become the brand for activities beyond HTTP. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient 3.x Homepage
Hello Henri, > Sorry, yeah. Just doing things at the macro level and then trying to > figure out what got screwed up lower down. > > So what should we do? Since it's too late to keep the page in place, we thought about setting it up somewhere below //jakarta.a.o/httpcomponents/ and redirecting from //commons.a.o/httpclient/ back to Jakarta. Oleg meant to combine that with the 3.1 release, but we could also just move the page for now. I have some time I can spend on it this weekend. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Slide + HttpComponents => TLP
>> While I would like to get rid of HttpClient 3.x rather >> sooner than later, there's no denyig that it will stay >> with us for several years to come. From this angle, it >> would make sense to move the WebDAV client as it is. > > Maybe that could be the first step. If there is a reasonable interest of developers to help support the 3.x based WebDAV client, I am in favor of cutting it out. I hope that this discussion will heat up a bit next week. (while I'm away...) Leaving the server-side code of Slide in Jakarta will surely give the new project a better start. That code would be a huge burden on my mind, and probably not mine alone. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Slide + HttpComponents => TLP
Oliver Zeigermann wrote: > Martin's and > also my hopes had been that when the - indeed useful - WebDAV client > was moved to a different project it could actually be revived. Reasons > are that it is functional, useful and of much less complexity than the > server. I would at least volunteer to support the initial move > (including cleanup) to HttpComponents and once it is there am > confident it will attract further contributors. The command line > client should be dropped, really. So the idea would be to leave the server part behind and just cut out the WebDAV client based on HttpClient 3.x during the move? HttpClient 4.x has no API similarity to 3.x at all, so it is inevitable that the WebDAV client be ported to the new 4.0 API if it's supposed to have a future. Content related parts should be re-usable, but everything on the method level will need to be re-written. Moving Slide, or the WebDAV client from Slide, is one option. Another option is to leave Slide and it's 3.x based WebDAV client behind and just start with a new WebDAV client based on the 4.0 API in the new project. That would significantly reduce the administrative overhead and does not preclude code re-use from Slide. While I would like to get rid of HttpClient 3.x rather sooner than later, there's no denyig that it will stay with us for several years to come. From this angle, it would make sense to move the WebDAV client as it is. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Slide + HttpComponents => TLP
Oleg Kalnichevski wrote: > > Slide seems pretty inactive at the moment. I am just wondering how many > developers out there would be willing to contribute on a more or less > regular basis to the maintenance and further development of Slide, or > the new TLP will effectively end up tasked with the job of trying to > recreate the community around the old Slide code base, albeit with a > somewhat reduced scope. Indeed a valid concern. This discussion should show how much interest there is in the Slide community. I'm not eager to sift through the backlog of 180 open issues on my own. If the Slide community is inactive, I'd prefer that HttpComponents goes TLP on it's own with a transport scope. Client WebDAV support could be added if and when community interest arises, and we wouldn't have a huge chunk of code with which we're not familiar. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [name] Slide + HttpComponents => TLP
Tetsuya Kitahata wrote: > HataraCo (Hatara-ko) means "Let's work!" or "Hey you, work hard!" > > 1. H T R Co that's for "HTTP and Related COmponents". Cool, thanks for the suggestion! I'd even prefer the "original" spelling with k. There's no need to turn everything into a acronym, we've got too many already :-) For those who are not familiar with japanese pronunciation, all "a" remain short, while the "o" is a long one. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[name] Slide + HttpComponents => TLP
A project needs a name. Here are some suggestions, with varying degrees of seriousness. - HttpComponents That would be the core of the active codebase. But http://httpcomponents.apache.org is too clumsy. - Slide Short and sounds good, and the root of it all. But it's an established name, associated with a project of a very different scope. - Truposas The Re-United Project Originally Started As Slide. I wonder whether there is a language in which that is an insult :-) - Glaahay Geeks Love Acronyms, And How About You? Getting silly, isn't it? ;-) - Hataraku [1-4] Pronounce ha-ta-ra-k, with short "a" as in yadda-yadda. That's japanese for "to work", with double meaning: You've got to work to make it work. "ku" is a suffix. Taking just the consonants of the root, you get: H T R that's for "HTTP and Related". My favorite, obviously. Other suggestions? Comments? cheers, Roland [1] http://japanese.about.com/blkod585.htm [2] http://www5.big.or.jp/~otake/hey/kanji/gifmoji/fvb/hatarak.gif [3] http://www.csse.monash.edu.au/~jwb/cgi-bin/wwwhalsod.cgi?0153_%C6%AF [4] http://www.kanji-a-day.com/dictionary/kanji-detail.php?id=1512 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[discuss] Slide + HttpComponents => TLP
Hi all, two months ago, Martin contacted Slide and HttpComponents [1a,1b] with the idea of joining them into a new Top Level Project (TLP). The initial response was positive on both sides, and I feel it is time to get the ball rolling. I'm starting this discussion thread to establish a common view on the prospective TLP. Once this is achieved, we can draft and vote on a TLP proposal. I'm from HttpComponents and joined that community when it was still around HttpClient, but after HttpClient was spun off from Commons. If I am not mistaken, HttpClient was originally spun off from Slide into Commons, since an HTTP client library was considered useful on it's own. So joining these subprojects would be a kind of re-union. HttpComponents [2] currently has responsibility for two codebases. There is the new HttpComponents 4.0 codebase, which is prospering and sees a lot of activity from established committers as well as new contributors. And there is the historic HttpClient 3.x codebase. It is running in maintenance mode, but is in widespread use and will continue to be so for years to come. The new codebase is not compatible with the old one, so even if we declare the old one obsolete, it will continue to be used. And we will continue to support users of that codebase, even though development stops. I've been following the Slide [3] developer list for about two months, and I've read through their home page. The last release was at the end of 2004, and development seems to have basically stopped then. Slide comprises both client and server side components, with most of the code being for the server side. Martin indicated that the server side functionality is being replaced by Jackrabbit [4], but that the client side could have a future. Slide has two client side components, a WebDAV library and a WebDAV command line tool. In case you are not familiar with it, WebDAV is an extension of HTTP. The Slide WebDAV client library is based on the old HttpClient code. Incidentally, Jackrabbit also has a WebDAV client library which is based on the old HttpClient code. So, how would the new project look like? I see it as the home of three codebases: a) HttpComponents 4.0 + modules for a WebDAV client based on the 4.0 API, active. Maybe also the command line client. b) HttpClient 3.x, in maintenance mode. c) Slide 2.1, in maintenance mode. The scope for the activities of the new project: HTTP and related, with a focus on libraries implementing the protocols rather than applications using them. "related" encompasses HTTP extensions such as WebDAV and CalDAV, and other HTTP-like protocols such as SIP. Compared to the current scope of HttpComponents, it is an extension towards the content layer. HttpComponents is deliberately content agnostic and focusing on the transport aspects of HTTP. Compared to the current scope of Slide, it is a strong cutback. The server-side repository architecture, including ACL and whatever, is falling out of scope. Your thoughts? cheers, Roland [1a] http://mail-archives.apache.org/mod_mbox/jakarta-slide-dev/200706.mbox/[EMAIL PROTECTED] [1b] http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200706.mbox/[EMAIL PROTECTED] [2] http://jakarta.apache.org/httpcomponents/ [3] http://jakarta.apache.org/slide/ [4] http://jackrabbit.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HttpClient 3.x Homepage
Hi all, the HttpClient 3.x homepage seems to have moved to http://commons.apache.org/httpclient/index.html I'm a bit surprised to notice that, considering that I had started a discussion about the future location of that site which has not lead to a conclusion. I would at least have expected some kind of advance warning before a page for which we are responsible is moved? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons validation]
Hello Attila, > Can I get detailed help about the subject here ? For detailed help, you should post your questions to the [Jakarta] Commons User List: http://jakarta.apache.org/site/mail2.html#Commons cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons validation]
Czuczor Attila wrote: > Now I posted a mail to [EMAIL PROTECTED] and seems that > this address is ok. Yes, Commons recently graduated to a Top Level Project. Some resources have already moved, while others still point to the old values within Jakarta. We apologize for the inconveniences. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Update: HttpClient SVN move
Hello all, the code move of HttpClient 3.x in Subversion is complete. I've left a readme in the old trunk, since that is probably still referenced by some external references: http://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/trunk/ The new location of the code base is: http://svn.apache.org/repos/asf/jakarta/httpcomponents/oac.hc3x/trunk/ The web site points to the new location, GUMP is using the new location, and the Commons nightlies don't reference HttpClient anymore. The remaining entanglements between Commons and HttpClient are a) the web site http://jakarta.apache.org/commons/httpclient/ (3 opinions voice, 3 different preferences) b) the download location http://jakarta.apache.org/site/downloads/downloads_commons.html (that's actually a Jakarta-wide entanglement) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Update: HttpClient SVN move
Rahul Akolkar wrote: > http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-nightly/trunk/nightly_proper_maven_list.txt Thanks Rahul! Gone it is. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Update: HttpClient SVN move
Hi folks, I've started to move the HttpClient 3.x tree in Subversion. The old tree is copied to a new location, I've updated project definitions and the web site with the new location. An update of the DOAP location is in progress. The old tree is still in jakarta/commons/proper while it is referenced by GUMP and the nightly builds. I think I can handle GUMP, but I have no idea where the nightly builds are defined. Any help on those is appreciated. thanks, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What about HttpClient?
Roland Weber wrote: > > Henri Yandell wrote: >> Plus the svn move will be painful. > > I'd like to give the svn move a try rather sooner than > later. What kind of problems do you expect? I am beginning to understand. Quite a few links spread across the site, mainly to code examples. I even found one link still pointing to cvs :-) Nightly Builds. Gump. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What about HttpClient?
Hi Henri, Henri Yandell wrote: > On 6/24/07, Roland Weber <[EMAIL PROTECTED]> wrote: > >> [...] >> 3. Keep the httpclient site at it's current location >> in Jakarta when the rest of the commons site moves. >> Move it only once to httpcomponents when those leave >> Jakarta. >> >> Please share your thoughts on this. My preferred option >> is 3, but I don't know how much trouble that will cause >> when setting up redirects to the new commons site. > > Probably some. Plus the svn move will be painful. I'd like to give the svn move a try rather sooner than later. What kind of problems do you expect? My idea is to copy the current trunk plus old tags/branches to the new location, followed by an update of the SVN locations in the site xdocs. Anything I forgot? If I am not mistaken, the HttpClient build is independent of the commons build. > Either 1 or 2 seem fine to me and whatever those committing to > HttpComponent/HttpClient want to do is fine by me. 3 seems painful to > do. Ok. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Image problem on tomcat
Please send Tomcat questions to a Tomcat mailing list: http://tomcat.apache.org/lists.html best regards, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What about HttpClient? (was: Commons is TLP)
Martin van den Bemt wrote: > +1 to keep httpclient and move it to httpcomponents. I've taken a first look at things. Moving the tree in Subversion should be painless. Then we have to update the SVN links on the website. Changing them in xdocs is easy, but it will take some careful review to make sure that the site generated from the new tree location is still OK. I haven't stumbled across relative links to outside resources yet, so maybe we're not going to run into problems from that side. The commons list of subprojects is hard-coded, so the missing httpclient subtree in SVN should not affect it. We will have a problem when the commons website moves though. I see several options: 1. Keep the httpclient site with the rest of commons and move it to the new TLP domain. We'll have to update the httpclient build with the new location and redeploy. (Anything I've forgotten?) 2. Move the httpclient site to httpcomponents. Since httpcomponents is unlikely to remain in Jakarta indefinitely, that means the site would move again later this year. Two moves within a few months is a bit too disruptive to users for my liking. 3. Keep the httpclient site at it's current location in Jakarta when the rest of the commons site moves. Move it only once to httpcomponents when those leave Jakarta. Please share your thoughts on this. My preferred option is 3, but I don't know how much trouble that will cause when setting up redirects to the new commons site. I don't have a Maven 1 environment set up to play around right now, but I'll give it a try next week-end if time permits. Oleg will be busy with the upcoming releases. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Posted emails appear on Google
Askar Zaidi wrote: > A few weeks ago I posted an email to one of the Jakarta commons mailing > lists. When I search a particular word on Google, this email appears in the > listing. Is there a way I could (or the Admin) delete this email from the > archives so that this email does not appear on Google listings ? No. The commons mailing lists are public, and there are several public mailing lists archives that will be indexed by all major search engines. That is the whole point of these mailing lists: questions are answered once, and everyone with the same or a similar problem can find the answers afterwards. You can't expect privacy when posting to a public forum. best regards, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons is TLP
Martin van den Bemt wrote: > The commons one is probably less straight forward, although could be a lot > easier. Since there was a > commons in the past, it could well be that you don't need to do a lot > (website, mailinglists, etc > already there), besides setting up the karma for the people, moving over the > website, etc,etc.. So > probably best to figure out on infrastructure how to approach this specific > situation. This also raises the question how the HttpClient 3.x code should be managed. Path-wise it is part of commons in SVN: /jakarta/commons/proper/httpclient but it is maintained by HttpComponents which doesn't move to the Commons TLP. If it isn't too much effort for infra, I would suggest to keep that part of the tree under Jakarta karma control. Either in place, or by moving it to the HttpComponents part of the repository, for example as /jakarta/httpcomponents/oachttpclient or /jakarta/httpcomponents/httpclient3x cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta site directory no longer contains .svn directories
Danny Angus wrote: > On 6/7/07, Thomas Vandahl <[EMAIL PROTECTED]> wrote: >> Danny Angus wrote: >> > Yes.. http://jakarta.apache.org/site/jakarta-site2.html >> >> I've never seen this before. What link would have taken me there? From >> jakarta.apache.org, I mean? > > Oh I don't know the answer to *that* question! I just knew the page > was there. :-) Maybe the idea is that you will find the page while you're browsing the file system before your first update? I know why I never tried ;-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta site directory no longer contains .svn directories
Hi Thomas, > Is this procedure "svn > update - edit - ant - svn commit - svn update site" documented > somewhere? I've never seen anything like this. This one covers svn, but not the Ant part: http://www.apache.org/dev/project-site.html cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Broken link
Hello Ognjen, > I found a broken link on ASF web site, more precisely on > > http://www.apache.org/dev/contributors.html Which one is broken? There are plenty to choose from :-) > To what list should I report this? Is there something like > [EMAIL PROTECTED] I would have tried [EMAIL PROTECTED] first, infrastructure@ next. But there are probably also some folks subscribed here who can update the page. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result: [VOTE] Release JCS 1.3
Hi Sebastian, > So a release can be developed in a branch or the trunk; before the > release is finally built the current files should be copied to a > subdirectory of tags. > > The tags subdirectory should not be updated once created. The branch was the correct term. You copy trunk into a branch in case you need to update something. Once the release is done you cut off the branch and stick a tag to it :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result: [VOTE] Release JCS 1.3
sebb wrote: > s/branch/tag/g surely? Eh... CVS tag = SVN branch? Whatever, the things that are not trunk and from which you can get a named historic version (=revision?) of what used to be in trunk :-) It's called "level" in CMVC, and I just don't want to spend my time on learning a separate vocabulary for every source repository system out there :-( cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result: [VOTE] Release JCS 1.3
Hi Thomas, >> If you changed the release files manually, you >> should commit those changes to SVN and give Sebastian some time to >> change his vote. > > We were voting on the artifacts on people.apache.org/~tv/jcs/, not on > SVN. This is at least what I understood the release-then-vote-policy > means. The point of a SVN branch is to have an archived version of the exact files that go into the release. If you have to change a release after creating the branch, you should update the branch and re-build the release from scratch. This is the best way to make sure that releases can be reproduced. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result: [VOTE] Release JCS 1.3
Hi Thomas, > I could not find any information about whether Rony Flatscher is a > member of the PMC In the committers-only SVN module is a file board/committee-info.txt which lists the PMCs of all Apache projects. It's (supposed to be ;-) the authoritative source. Rony Flatscher is listed there as PMC member. I'm not sure myself how Sebastian's -1 will be weighed here. I would have expected that the NOTICE and LICENSE files get fixed and he changes his vote. As by his last mail on the topic, the content in SVN did not get fixed. If you changed the release files manually, you should commit those changes to SVN and give Sebastian some time to change his vote. Btw, he asked on legal-discuss about the correct usage of these files, but I see little point in delaying the release until that question has been answered. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
Ted Husted wrote: > As to the point of active consent, did each and every individual > listed on the proposed resolution either actively consent in an email > message on an ASF list, or add their own name to the list? Based on the Wiki history... http://wiki.apache.org/jakarta-commons/TLPResolution?action=info Rory Winston - was added by Daniel Savarese Torsten Curdt - was added as chair by Henri Yandell All others added themselves. hope that helps, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
Dion Gillard wrote: > Many of those who voted +1, aren't on the initial list of committers > in the proposal. As has been mentioned, it's an initial list of PMC members. But the votes come from all of Jakarta, not just Commons. Some of them are from Commons people voting to get out of here, others are from Jakarta people waving good-bye, and some are from folks that care about both. > Wouldn't it be better if the initial list came from the svn acl? Wouldn't that beat the purpose of the move in the first place? I thought this was an attempt to disentangle Commons and Jakarta in order to see what's left of Jakarta afterwards. And the whole discussion about Commons becoming Jakarta is based on the assumption that Jakarta w/o Commons will not survive anyway. just my 0.02€... Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
+1 > [ ] +1 I support the proposal > [ ] +0 I don't care > [ ] -1 I'm opposed to the proposal because... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move POI to TLP
+1 > [ ] +1 I support the proposal > [ ] +0 I don't care > [ ] -1 I'm opposed to the proposal because... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move Turbine to TLP
+1 Scott Eade wrote: > The Turbine project has been discussing a proposal to the board that the > Turbine projects leave the Jakarta umbrella and become their own top > level project. We are now at the point in the process that calls for a > vote to take place. > > The proposal is available at: >http://wiki.apache.org/jakarta-turbine/TLPTurbine > > For the interested, most of the discussion took place in the following > thread: >http://www.nabble.com/-DISCUSS--TLP--tf3574436.html > > Here are the vote options: > [ ] +1 I support the proposal > [ ] +0 I don't care > [ ] -1 I'm opposed to the proposal because... > > Voting will close in one week. > > Thanks, > > Scott > > - > 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]
Re: FYI: Commons->TLP discussion on common-dev
Hello Henri, > So people know, I started up a discussion on moving Commons to TLP a > couple of days ago. It's looking very positive, so I'll probably go > ahead and kick off a vote in a day or so. Commons HttpClient code is still managed as part of Commons, though it is maintained by HttpComponents. That's not a problem while we are all one big Jakarta community. But if Commons goes TLP, we will have to decide where the Commons HttpClient (that's HttpClient 3.x) should reside. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Petar Tahchiev as Jakarta Committer
+1 Felipe Leme wrote: > Hi all, > > I'd like to call a vote to have Petar Tahchiev as a Jakarta Committer. > > Petar currently works as software engineer in Bulgaria, but was a MSc > student last year, when we proposed porting the Cactus build to Maven > 2 as a "GSOC" (Google Summer of Code) project. Although the project > didn't make it to the allotted ASF projects, Petar kept doing the > (hard) work, despite my slowness to support him. > > Prior to participate on Cactus development, he made some contributions > to Apache Ant and other ASF projects. He also has a blog at java.net > (http://weblogs.java.net/blog/paranoiabla/). > > A couple of months ago, I failed (again :-() to setup a sandbox SVN > branch at ASF for him to continue his work, so he ended up creating a > separated repository on SourceForge where we could do some work in > parallel. Now that code is ready to come back to the Jakarta codebase, > and the proper legal measures has already been taken (see > http://incubator.apache.org/ip-clearance/jakarta-cactus-tahchiev.html). > > Besides the technical aspect, I can tell from personal experience that > he is a talented and enthusiastic developer, and will be a valuable > contributor to the Cactus/Jakarta communities. So, here is my (PMC > binding) +1 vote. > > -- Felipe > > - > 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]
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should "not-yet-commons-ssl" go?
Since there is no stated end date to this vote: Please let it (or it's replacement) run until at least March 4th. Oleg will be working through a mail backlog that week-end. If this vote thread should be replaced next week, I will not be able to re-cast my vote until the week-end of March 10/11. > [X] Jakarta should sponsor (which effectively states we like to see the code > end up here) > [ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP) > [X] commons as a component > [ ] httpcomponents as a component > [ ] subproject directly under Jakarta > [ ] integrate / merge code into project xxx (please replace x) (so not a > subcomponent of a project!) > [ ] I am willing to mentor (you need to be on the Incubator PMC / Member of > the ASF) > [ ] I want to get involved in coding > [X] No interest in getting involved. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Howto revive inactive projects ?
Hi Henri,
>> - A CLA on file from the revival candidate. ("resurrector")
>
> The mentor should guide them through a few patches to show they are
> committed, then we can make them a committer. I don't think there's
> any reason to do CLAs without also making them committers.
>
> I'm not sure we need to define a 'resurrector'. Rather we should
> define the project as being revived and explain that that means that
> Person X is mentoring it and that N people are submitting patches to
> get it moving along. Often when one person gets active on a component,
> others start to show up. Having a resurrector limits the new
> contributions.
Ok, that's a scenario I didn't consider. I didn't mean to limit
the procedure to "one resurrector only". The idea was to say:
Ok, your patches will go in without much of a discussion.
>> - The mentor reviews patches for style only, not for functionality.
>
> Why not functionality? To keep the time required for the mentor low?
I'm assuming that there is nobody around who knows the code base
well enough to tell what implications a change might have.
> However - the mentor refuses to commit without a test patch would be
> something I'd expect to see.
Hmm, you're putting the hurdly high right from the start :-)
I thought of it as "hey, here's your playground, but you'll
need to get down to business if you want to see that code
go into the trunk".
>> - All discussions take place on the regular mailing list(s) of the
>> project, so that users are aware of the revival attempt.
>
> +1, though a lot tends to take place in JIRA/Bugzilla. The mentor
> should be encouraging the people contributing patches to prepare
> release plans and communicate them to the mailing list.
No objections. This was meant as "we're doing it within Jakarta,
not anywhere off-site".
> We could be doing the revival branch in the nightlies too.
If it can be done, good.
>> - If there is a significant number of fixes in the revival branch
>> and code quality is considered good enough by the mentor (for
>> example based on Clover test coverage results), a "Possible
>> REvival alpha release" (PRE-alpha) is created.
>> - Publication of the not-quite-release is done on a low profile,
>> as it is not a full quality release of an Apache project. For
>> example, due to the lack of a developer community, there won't
>> be three binding votes as required for a real release.
>
> -1. That's nothing more than saying "We think the nightly is pretty
> good now" on a mailing list.
>
> Do an actual alpha release. The vote should be held here if there's
> not enough voting on the components list.
See my "playground" comment above, plus the "style only review".
I would consider the PRE-alpha as saying: We've got something
that is significantly different from the last release, but we
don't know whether it's working. Coding style has been reviewed
by the mentor, but now we need some user feedback on the
functionality to tell us whether this is good enough to build
future releases on.
Voting on general@ can help to overcome the 3-binding-votes
requirement, but it doesn't help code reviews. Of course it
all depends on the quality you expect from an alpha release.
And there's the branch thing. If the release is not good enough
and/or the committer(s) loose(s) interest, that code will not
go into the trunk and future releases, if any, will not be
based on it.
>> - The first task of the new committer is to merge the revival
>> branch into the main trunk.
>
> I forgot about the revivial branch. Bit worrying having any kind of
> release that is from the branch; I'd like to see this merging happen
> prior to discussions of an alpha release.
That's why I suggested the "irregular" PRE-release :-)
cheers,
Roland
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Howto revive inactive projects ?
Hi Julius,
> If someone is interested in taking over a truly inactive project,
> maybe they should fork and start their own SVN repository from their
> own domain. The person should make it clear that their fork is in no
> way sanctioned by Apache.
That would be OK for projects that are, as you call it, "truly inactive".
Meaning: no developers and no users. But I believe our main concern is
with projects where the developers have moved on, but a user community
is left. Forking this kind of project is disadvantages in various ways:
- The developer not only has to learn the new code base, but must also
build a new user community either from scratch or by winning over
the users of the Apache code base. That means a lot more work for
the developer candidate, and makes a successful revival less likely.
- The users are left with a choice between the inactive Apache project
and the live fork. Re-integration of the fork is a possibility but
can not be guaranteed. Meanwhile, users of the forked codebase are
missing the legal protection provided by the Apache foundation. And
potential new users of either codebase face uncertainty.
I believe that Jakarta projects with an active user base should be
revived within Jakarta. I thought a while about some kind of second
class committer status, but found more reasons against than for the
idea. Here is my take on a revival procedure...
Preconditions:
- A mentor with committer/admin access to both the software repository
and the bug tracking system. One that is willing to invest significant
time and not just give a useful tip once or twice a week.
- A CLA on file from the revival candidate. ("resurrector")
Procedure:
- Create a "revival" fork of the code base in the software repository.
- The resurrector submits patches for the revival fork in the bug
tracking system.
- The mentor reviews patches for style only, not for functionality.
- Patches are committed by the mentor to the revival fork.
- The mentor is responsible for running tools with committers-only
access, such as Clover. The mentor encourages the writing of test
cases by the resurrector.
- All discussions take place on the regular mailing list(s) of the
project, so that users are aware of the revival attempt.
- Adventurous users are encouraged to try out the revival branch.
They'll probably have to compile themselves, or use a manually
created snapshot as the nightlies would still be based on the
main trunk rather than the revival branch.
- If there is a significant number of fixes in the revival branch
and code quality is considered good enough by the mentor (for
example based on Clover test coverage results), a "Possible
REvival alpha release" (PRE-alpha) is created.
- Publication of the not-quite-release is done on a low profile,
as it is not a full quality release of an Apache project. For
example, due to the lack of a developer community, there won't
be three binding votes as required for a real release.
- Adventurous users are encouraged to try out the PRE-alpha.
- If the PRE-alpha exhibits major quality problems, continue with
bug fixes and improved test coverage. Repeat PRE-alpha procedure.
The decision about the quality is at the discretion of the mentor.
- Once a PRE-alpha release meets quality standards, the mentor
calls for a Jakarta-wide vote to promote the resurrector to
committer status.
- The first task of the new committer is to merge the revival
branch into the main trunk.
Or something along that line. Multiple mentors would be better
than one, but who believes in that many volunteers? A mentor is
of course free to ask for help, in particular on major decisions
such as whether a PRE-alpha is good enough or not.
cheers,
Roland
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Voting
Hi Danny, > It would only be necessary for binding votes to be signed. No? That's a possibility. On the other hand, that could send a wrong signal to the non-binding voters: you don't have to sign your votes, they're not important anyway. I'd be very careful with such distinctions. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Voting
Hi Danny, >> As we get more and more into auth, it becomes tempting to auth the >> whole thing. Vote through the webapp and not an email, > > You could sign your mail with a key you register for the purpose. that's a big hurdle for a guest voter. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Voting
Hi Henri, > [...] I was mostly thinking > about it because I felt like writing something new rather than > maintaining code): That's the best reason of all :-) > * Simplifies calling a vote. > * Adds a better audit trail. > * Can know about the binding votes and it can decide whether a vote is > successful or not. > * Enforces things - so having an end date to a vote for example. > > Problems it causes: > > * Might make us vote more often rather than just agree consensus has > been reached. * Complicates casting a vote > Thoughts on implementation. > [...] > It needs to be listening to emails, > [...] > Vote through the webapp and not an email, > [...] > People often comment with a vote > though > [...] > Another would be to just monitor the mailing list. Create a bot that > listens to emails and a script that sends out emails in a particular > format. Might work, but parsing replies would probably suck. Correct me if I am wrong: the actual collecting of the votes from a vote thread is not that time-consuming, or is it? The following sorting and checking for binding/non-binding status is the really tedious work? If somebody feels like simplifying the voting by coding, I would rather suggest to define a simple text input format for votes. The one who called the vote goes through the replies and collects all votes into a text file, in random (or chronological) order. That could look like this: # allowed votes +1 +0 -0 -1 # cast votes -0 [EMAIL PROTECTED] +1 [EMAIL PROTECTED] ... That text file can then be processed by a script which: - checks for invalid votes (like -0 if only +1, -1 are allowed) - checks for duplicates (somebody changing his or her vote) - checks for binding/non-binding status based on email address - sorts the cast votes into groups - generates a text summary for pasting into an email That alone is tricky enough, if one should consider MailAliases.txt for the binding/non-binding check and maybe also the duplicate check. With a plain text format as the input, it is also easier to create an exhaustive set of unit test cases. Compare that to setting up a new mailing list plus generating emails there just for testing the voting application. But what I like most about this approach is that the voter experience doesn't change. You can still reply by email using informal language. The original mail can be quoted internet style, or TOFU, or not at all. You can write your +1 above the quote, or below, or you put your X into the line the lists the appropriate vote option, or you embed it in natural language. If the mails are parsed automatically, expect communications like this: >> Here's my +1. >> > Could you write that again with just the +1 in a single line, > with an empty line before and after? or if the parser is more flexible: >> I would have voted +1, but I'd like to get an answer to the >> following question first: [...] > > Oh, sorry, that was counted as +1 by the voting application. > Could you send another mail with the text 1-- to undo that? Such syntactical ambiguities are easily enough resolved by an HVC preprocessor (Human Vote Collector) before the script ever gets to see the data. Mandating that votes be cast through a web application would solve the input format problem. But it would also require the voter to change from the email application to a web browser, and maybe from the keyboard to the mouse, to cast the vote. That may not be much of a problem (except for accessibility), but it is surely not an improvement of the voter experience. Vote casting by email encourages the lively discussions that are so important for community building ;-) Once such a script is done and thoroughly tested, there is still time to think about an automated input interface. I would suggest connecting to the mailing list archive rather than to the mailing list though. Since vote threads run for several days, you can't expect the voting application to run through without interruption. To allow for regular shutdown and startup, you'd need a persistent data store for the votes that have already been counted. Even so, if there is a crash and the server needs to be restored from a backup, the mails that came in between the backup and the crash would not be counted. And I guess no automated tool can deal with off-thread votes. Consider a controversial vote that is started, and people joining the mailing list afterwards just to cast their votes. These folks will not have the original mail to reply to. They might reply to another mail in that thread, or they might just type the subject line into a new mail. In the latter case, the mail would not be considered as belonging to the vote thread, or would it? In summary: if somebody wants to spend time on simplifying vote counting, I recommend to focus on the actual counting while leaving it to the human who called for the vote to collect the input. That should also help to keep the number of vote calls in check :-) cheers, Roland
Re: [VOTE] Remove POI svn restrictions.
I'm not sure whether this vote will be cancelled or not, so... > [+1] Open up POI svn commit access. > [-1] Don't open POI svn commit access, because... -1 because POI will make a move to spin off from Jakarta early next year. There is no point in force-merging at this time. If POI should decide not to leave Jakarta, we will reconsider. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: POI TLP -- constructively
Hi Andrew, thanks a lot for that mail. > It is > fair to criticize our build...it is pretty rusty and yucky. I do > however thing focusing too much on it is a bit well...mean. See my reply to Avik's mail. I didn't mean to focus. (That pun was unintentional, but I'll leave it in.) > I really don't want POI to really merge into > Jakarta (which is really now the successor to Jakarta Commons) and I > don't think the majority of the committers do either. That answers the question I was asking myself since shortly after the vote thread started. Is POI going to go independent, or is it going to merge into Jakarta? If it's going independent within a few months, there is no point in opening SVN access. > On the other > hand, I really don't think POI by itself can be a TLP as its scope is > too narrow (historically this was deliberate). I also don't think that > parts of POI have much of a future as we're moving to an XML formats I was told that vinyl is dead in the early 90s. "Starting next year, nothing will be released on vinyl anymore." I built a collection of well over 1000 records since, and there are still new releases. It's not mainstream anymore, but it exists and has it's followers. > era, but other parts certainly do. Partly because of projects like POI, > Microsoft is even moving. Once the default is to save in an XML format > then will anyone really care about POI "as it is" as more than a > migration tool. There's nothing wrong with being a migration tool. Being more than a migration tool is even better. +1 to the rest of your mail. cheers, Roland > > That being said, there is considerable interest in unified APIs for each > of these verticals (spreadsheets, documents, etc) and considerable life > in POI with a very active userbase. Many people dealing with data > formats have asked for common APIs for the various verticals that output > to the various formats. Moreover, many of us are no longer as single > minded with regards to Java as we once were (POI ruby for example). And > achieving API compatibility across these could be interesting. > > I therefore propose this: > > * Jakarta PMC has the responsibility to not call more votes on > restructuring POI during the next X months. (Access or otherwise) > > * POI committers have responsibility for achieving the proper oversight > procedures and putting out a new release in the next X months > > * POI committers have responsibility for putting together a TLP proposal > and working out a consensus. > > (BTW that pretty much is batting 1000 on this: > http://wiki.apache.org/jakarta/JakartaPMCRequestTLPBenchmark) > > Full disclosure: > > I've also submitted a counter proposal to the committers as an > alternative to leave apache entirely. However thus far most folks seem > to value POIs association with Apache and the opportunities afforded > them, even if they find it "difficult to work with" as one person stated > in response. I suspect TLP status would alleviate some of the mutual > snags between apache and POI (for one we could get poor Marc his access > back despite him having sent in his CLA now like 3 times including when > the project moved to Apache and for two we'd be sending our reports in > ourselves and thus have to do more proper oversight). > However, PLLEEAASS let's press the PAUSE button > until January 3rd so that we can all get very drunk and open presents > rather than jerk each other's chains in front of a computer on a mailing > list. > > -Andy > > Andrew C. Oliver > Buni Luni > http://buni.org > > > - > 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]
Re: [VOTE] Remove POI svn restrictions.
Hello Avik, Avik Sengupta wrote: > This is completely out of line (to say the least). Yes it was. Henri already pointed out my error, and I apologize for mixing things up and thereby offending the POI community. The problem was not in the release files, it was with the procedure used for publishing it. The responsibility for that is with the PMC and not the developer community. My thoughts started spinning around this vote thread over the week-end, they spun too far from what was actually happening, and I failed to re-read the mails on the PMC list. Again: I apologize. I'll do my best to avoid misinterpretations in the future. > Maybe you want to help out on the list, rather than presume that the POI > developers want to become a commons subproject. How presumptuous! I did not presume that POI developers want to become a commons subproject. It was you who mentioned becoming a commons subproject, and you clearly stated that you did not want that to happen. I just pointed out that neither promoting up to TLP (to make a clean split between POI and Jakarta) nor promoting down to a commons subproject (to somehow cover up the existing community split) would address the problem at hand. I was not suggesting nor considering moving POI to a commons subproject at any time, and I am sorry if I phrased that ambiguously. As for helping the (POI) list, I'm afraid that I don't have time left for that. HttpComponents is taking up the time I have available. I am trying to help the Jakarta community - including POI - by participating in this discussion on [EMAIL PROTECTED] I share my views and current understanding of the discussion's subject, however wrong they may be at times, and hope to get new information and to be corrected where I am wrong before I cast my vote. If I should vote at all, since there are only +1 and -1 to choose from. > As to voting on files, I'm yet to see a board resolution that makes it > mandatory. So yes, that's a suggestion that the POI team will surely > consider (read the dev list archives, we've done that for major releases > earlier... the current release is considered alpha for a reason [yes i > know, its still a legal release] ), but is not reason to bash four years > of existence on a project. For the latter, I apologize once more. But I also ask you to take note that I phrased that part of my mail as a question. Provocative, yes, but still a question. Thank you (and Henri) for answering it. For the future, I'll try to avoid writing such mails late at night when I am tired and my thoughts have spun around for too long. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
Hello Henri, > I bet a lot of Jakarta does not conform - it's only when a release > happens that we think about bringing it up to date. This is not a > problem of the POI community but a problem of the Jakarta community > structure and for the PMC. It's the PMC's responsibility to make sure > these releases are right and not the POI community. OK. > A plus point of POI as a TLP is that then it becomes the POI > community's responsibility far more (as I imagine there would be far > more of 1:1 ratio of committers to PMC there). You see a chance to move POI to TLP in the current situation? I've always see "going TLP" as a way to gain visibility, and would have expected the board to make sure that projects doing that step are working well. You've definitely more insight here. > Let's not go over the top here - the release itself isn't that bad and > it's got the important things right (license, notice). Having gone and > looked at them, I'm not overly worried about the two particular > releases themselves, just that it's clear that information is not > getting out to POI and that it urgently needs to somehow. OK again. Thanks for putting that into perspective. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Trivial Update of "JakartaBoardReport-March2007" by RolandWeber
Hi Martin, Martin van den Bemt wrote: > Feel free to remove it from commons and add it to HttpComponents. > It was just a dumb copy & paste from the commons webpage :) I'll take care of it this evening (european time). > While you are at it, you could also add this to the template (+ httpcode > and httpasync) Those are just "components", separate compilation units. With just 1.5 active developers for all of HttpComponents, I don't see a point in splitting it into subprojects :-( cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
Hello Avik, > I'd have been happy seeing POI move to a TLP. However, some of the > comments in this thread seem to preclude that possibility either. I > think his leaves the community between a rock and a hard place ... I > dont want us to be subsumed as a commons project I don't think that the level at which POI resides will make any difference. I admit that at the beginning of this thread and after Andy's first responses I also thought "hey, let's get them promoted to TLP and we're finally rid of these discussions in Jakarta". I've since had time to reconsider and realize that this is not a solution. And actually I don't think that it is even an option. POI is not running the Apache way. Promoting it to TLP or "hiding" it in commons will not change anything. If it were a TLP, you'd be having basically the same discussions directly with the board. Do you think they'll look more kindly on failure to follow the established Apache procedures? If we made a proposal to promote POI now, I would expect the board to reject it and tell us "make POI work in Jakarta before you promote it to TLP". A release can go wrong all right. That this wasn't detected by the POI community itself is reason for worry. But the kind of things that went wrong, like files being in the wrong place or missing is even more reason for worry. The copyright statements on the POI web site indicate that the project has been around since 2002. Does that mean that in 4 years nobody cared to write a build process that generates release jars conforming to Apache standards? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
Hello Niall, > Why is it any different than Harmony? Harmony requires that an "Authorized Contributor Questionnaire" be signed. The ACQ surely has been reviewd by the ASF legal team, and signatures are legally significant. http://harmony.apache.org/auth_cont_quest.html The POI "Get Involved" page only mentions this: > Those submitting patches that show insight into the file format > may be asked to state explicitly that they are eligible or > possibly sign an agreement. http://jakarta.apache.org/poi/getinvolved/index.html "may be"? "possibly"? Did the ASF legal team prepare such a document for signing or not? If they did, shouldn't it be linked on the web page? And why isn't every contributor required to state or sign something? Who decides who will have to state or sign? And who will process and keep track of the statements or signed documents if not the ASF legal team, who obviously are not aware of any such thing? If there is an established procedure addressing these questions, it should be documented on the web page. If there is not, the statement quoted above is just idle. > If someone has received > knowledge of MS propriety formats under a NDA then wouldn't using that > knowledge to contribute to POI put the POI project at risk? Yes it would. That's why the page mentions that people with access to NDA'd information are not allowed to contribute. As far as I can tell, there is no discussion about this policy. There is a discussion about access restrictions in SVN. Let me throw the following statements/opinions into this discussion: 1. Jakarta committers have proven that they are responsible developers, otherwise they wouldn't have been voted committers. 2. No responsible developer would just commit some code to a Jakarta subproject with which he/she is not familiar, or ignore the rules and policies in place for that subproject. 3. If current committers show interest in contributing to the POI subproject, they will make an appearance on the mailing lists and submit patches to the bug tracking system for review. There is plenty of opportunity to educate them about the policy and to question them about possible NDA contamination. 4. If anyone would commit unwanted/dangerous code to POI (directly without patch review!) that contribution would immediately be detected from the commit message that is automatically generated, and would be vetoed and undone by the regular committers to the subproject. This discussion is about removing technical barriers in SVN, not about throwing random (barbed ;-) code into POI. It's about running a community based on mutual trust and review as opposed to walls and fences. At least that's how I see it. > I also think its a mistake to deal with whatever issues people think > there are in POI via a vote. Back in March the POI devs voted to > exclude POI from this policy of opening SVN access. If we think the > reason underlying POI's exclusion from this policy is not valid then > it would have been far better to start a discussion with them > regarding this first - rather than launching straight into a vote. I'd > have rather seem an attempt at consensus first rather than going > straight for conflict. +1 > Seems to me that svn access isn't the root of the issue here and > therefore a red herring, since changing that isn't IMO going to > resolve whatever the real issues people think there are. +1 cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
Henri Yandell wrote: > Reasoning being that Martin has done the same thing I did - asked > legal vp and secretary if they know anything about the need for POI to > be legally special and they don't. Then either the ASF legal team wasn't involved in the discussion Andy mentioned, or the current staff doesn't remember it, or their assessment of the situation is different from Andy's. Who can shed some light on this? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove POI svn restrictions.
Andrew C. Oliver wrote: > [...] > I would like to see a formats.apache.org project which was devoted to > Java/Ruby/C# APIs for office software file formats and more. That's a very unspecific name. "formats" can mean anything, from formatting a file system to data formats/representations like BER. How about "compound documents" -> compdocs or compdogs? That's probably better than some acronym like jivoff (Java Implementations of Various Office File Formats :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PROPOSAL: commons-ssl
Hi Julius, > Regarding the BouncyCastle code, I sent an email to the BouncyCastle > mailing list. Here's the reply I got: > > [...] >> If attribution is included we have no issue with the section of code >> being included in a product distributed under Apache 2.0. > [...] > > I hope that's sufficient to address the licensing concern. The "attribution" part probably means that the code must still carry the BouncyCastle license rather than the Apache license. I guess a lawyer will have to look into this, unless the BouncyCastle license has been discussed before. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PROPOSAL: commons-ssl
Hi Julius, it's great to see that you finally got the proposal ball rolling :-) I didn't look into your code, so my comments are based on the proposal itself and on your web page. I like the positive attitude with which you present the advantages of the project. However, I a missing a clear definition of the _project_scope_. That may seem like a small detail, but it really is a precondition for finding both an appropriate name and home for your code base. >From your description, I understand that the purpose is - giving easy access to different types of key material and certificates - verifying certificates and certificate chains - bridging different Java APIs (?) The working title "Commons-SSL" does not really reflect this. Do you plan to implement the SSL protocol as part of the project? Probably not, so the title is misleading. An all-encompassing name might also be offensive to people working on other SSL-related projects. I think you should spend the time and define not only a motto, but a very clear scope of the project. Both in terms of what's in scope as well as what's out of scope. From there on, we can work on finding a name and home. Please do not underestimate the importance of this step. Finding a name may seem like a minor detail, but the problem of defining the scope is very real. Only a few months ago, there was a long discussion on this list about a proposal for "testing.apache.org". I haven't read anything about it anymore after the supporters realized that a scope of "everything that has to do with testing" was overly broad. We don't want to see that happen to your proposal. I am also a little worried about this statement on your web page: > The PKCS12 key derivation function (for some PKCS8 version 1.5 encrypted > keys) was cut & paste from BouncyCastle (bouncycastle.org). They > originally got it from RSA's PKCS12 specification > (ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf), > so we hope this copy & paste operation is okay! The BouncyCastle license (http://bouncycastle.org/licence.html) is quite specific that the license must remain intact. You can not just relicense their code under the Apache License. That's assuming that the part you copied and pasted was not explicitly released with a different license. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Opening up the PMC
Hi Henri, > By being a part of the PMC (and active on the PMC if you're an active > committer), then you are ensuring that the foundation is involved in > decisions and not just you personally. Thanks, that sounds much better indeed. > Sorry to cause worry. It's the other way around from how you've > interpreted it and my reason for the above opinion is that I'd be > worried about someone who wanted to sit and code but wanted to continue > to delegate responsibility to the pmc/foundation for their code. No problem. Glad we talked about it :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Opening up the PMC
Hello Henri, I'm one of those whom it concerns: committer but not PMC. > So being on a PMC means that your legal protection is something you're > supposed to be proactive about Meaning that a PMC member should get an insurance that covers the cost of lawsuits, or contact a lawyer right away to discuss the legal implications of a lawsuit that might be filed in a different country, or what? > I'm of the opinion that if we have a committer who doesn't want to be on > the pmc, [...], that that committer should become a contributor again. Meaning that because I don't want to get an insurance or contact a lawyer proactively, all the code I submit has to be checked in by another committer, of whom we have too few anyway in HttpComponents? I hope I got you all wrong, because the way I understand it, your proposal sounds really bad. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Poll: Why does the loose development process of OS work?
Hi Oliver, > Why does the loose development process of OS work? I think you should distinguish between OSS on private time and OS done by companies. I guess there's much more hierarchy in the latter case. My first answer to the question is a negative one: no other process could work. Some people are willing to contribute to OSS on their own time and schedule, but hardly anyone would agree to fit into the lower levels of a hierarchy for fun. > Or more in detail: Why are almost all commercial projects organized as > a strict hierarchy while most OS projects work with a loose > organisation or even none at all. Commercial projects are organized in strict hierarchies because the job needs to get done in time, and somebody has to take responsibility for that. OSS is ready "when it's ready", and there you have the luxury of waiting until somebody is willing to take the responsibility and drive things forward. > Additionally, roles are always > switched on demand. This is something that would never be done in a > classically organized project. Don't know what "roles" exactly you mean. I've switched from developer to more architectural roles in professional development projects. I wouldn't switch to a project manager role because I don't like to track MS Project plans, but within my skills I'm comfortable to do what I see needs to be done. If that's development, or architecture, or mentoring, or teaching, or writing documentation, I hardly care. As long as there's minimal paper work ;-) In a commercial environment it is of course easier to hide behind your job description. Cover your ass, don't take responsibility you don't have to so you won't get blamed if things fail, don't be the messenger of bad news, and so on. OSS on private time means you care about the project and want it to succeed, so you're more likely to do what you feel should be done, rather than see the project go down. There may also be an issue with careers - in OSS you're less likely to meet someone up the hierarchy who doesn't want to let you pass. Or maybe I was just lucky so far. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org, take 2
Jesse Kuhnert wrote: > "The Rack" conjures up images having nothing to do with torture for me. > (probably because I'm such a filthy animal) ;) I guess software quality would be much higher if more people had *fun* with testing... ;-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org, take 2
Hi folks, what has happened to this thread? Ever since Henri wrote that it's heading in the right direction, it seems to be dead. Bad beer chitchat hangover? Summer break? Everyone busy watching soccer? Or were my last suggestions so far off that they don't even deserve a response? Just to get discussion starting again, here is yet another alternative name suggestion: "The Rack" in reminiscence of a 70s british TV series :-) http://www.personal.u-net.com/~carnfort/Professionals/b02.htm cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org, take 2
Hi all, Felipe Leme wrote: > 1.What should it be named ? > 2.What exactly do these 2 projects have in common so they can be > grouped together? > 3.Could the TLP accept more projects? What's the criteria? I suggest we add "runtime testing" to the list of criteria. I guess it's one of those implicit assumptions we've been making, but it really should be pointed out. It reduces the scope by eliminating projects or products like: Gump - build time testing Clover - requires static code analysis to determine test coverage Quality Assurance stuff - something that runs statistics on issues opened or closed resulting from manually executing test cases Those are examples for things "related to testing" that are probably not meant to be in the scope of the currently discussed new project. If I am not mistaken, both Cactus and JMeter are executing test cases at runtime, collecting data without instrumentation of byte code or JVM plugins. By restricting the scope to this kind of testing stuff, we should be able to alleviate some concerns about over-broadness. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing.apache.org, take 2
Hi Felipe, I fully agree with you. > So, let's say we decide to promote Cactus+JMeter to a TLP > of their own, but not the broad "testing.apache.org"; I have 3 > questions: > > 1.What should it be named ? > 2.What exactly do these 2 projects have in common so they can be > grouped together? > 3.Could the TLP accept more projects? What's the criteria? > > Here are my preliminary answers: > > 2.This is the crucial point and ca be the guide for 1 and 3. Consider > the project originated from Jakarta, whose roots come from the Java in > the server side, we could work on something related to "Java EE > Testing" or "Server-side Java Testing". Java + (focus on) server-side should also allow for the testing related artifacts from Struts and Tomcat mentioned as candidates: http://marc.theaimsgroup.com/?l=jakarta-general&m=115047715227445&w=2 I'm not sure whether server-side should be tied to J2EE though. Maybe the project description should state that it does not claim exclusiveness within it's scope, just to be sure. After all, it is still an effort to create a home for several related projects, and not an attempt to find a solution for a specific technical problem. > 1.I'm too bad on naming (JCacter? MetrusJ? :-). Scrutiny? Ordeal? > 3.My guess is that once 2 is answered, we would have a criteria for > letting new projects be incorporated to the TLP. > > >> Roy Fielding on 6/22: > > >> A federation is simply an umbrella project with no significant >> responsibilities of its own -- all of its projects report directly >> to the board and simply view the federation as a communal thing. >> I think XML and Jakarta should already fall into that category. >> Starting one is just like starting a project, except that the >> purpose is limited to community/commons like things and not actual >> products. " > > Please forgive my ignorance, but I didn't understand this conclusion: > does it means we could have testing as a 'federation TLP'? Os does the > federation concept would apply to the Cactus+JMeter project? The former, I guess. "no significant responsibilities" means that kind of project should not release code itself, the way I read it. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] regenerating the jakarta site
Hi Sebastian, > What I found originally was that there was a difference between the > output produced by 1.4 and 1.5, in that 1.4 adds an extra space before > the terminating "/>". I'm not sure that it does this for every tag, so > the only way I could see to make sure that the output was the same for > both was to remove the extra spaces. > > It seemed unnecessary to strip the spaces for 1.5, so I made it > conditional. > Later I discovered that some VMs other than Sun added the spaces, so I > changed the check to look for Sun 1.5 only. > > Seems like you have found that the replace needs to be done always. > > The alternative would have been to insist that everyone used the same > JVM and vendor to generate the output ... > > There is another difference between JVMs - tags with multiple > attributes are ordered differently when converted to XHTML. This was > handled by only allowing a single attribute per XML tag, and using > for the others. There's a task which checks the > XSL files to enforce this. I admit it's a long shot, but this sounds like a lot of effort with the intention to make "diff" work on XHTML files. Is there no "xmldiff" tool that knows how to ignore whitspace within tags and the order of attributes? Or is there another reason why these things should remain constant though XML (and therefore XHTML) considers them dont-cares? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Copyright dates
Martin Cooper wrote: > I think it would be worth asking whether or not a "copyright" notice > without > specified years is actually meaningful. My expectation is that it would not > - i.e. that it would not imbue the pages with copyright protection at all. My expectation is that copyright protection applies simply because we own the copyright, not because of some notice being in the page. The notice is just to make people aware of the fact. But copyright is different from the USA here in Germany. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Cleanup pmc members
Hi Hen, > My proposal is that we create a file in SVN in which PMC members can > list themselves as being active. After 1 month, failure to appear in > that list will result in removal from the PMC. If it goes well we could > consider doing it periodically, or just when it feels like the numbers > are getting out of sync again. > > Thoughts? Make sure there is an easy way for the removed people to get back on the list. Somebody might just be taking a longer vacation, or have a big backlog of things to do after a shorter vacation. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Stephen Colebourne wrote: >>> other 1-word suggestions would be great. >> >> >> since they're language components, you can call them "Syllables" :-) > > > I understand the desire for 'fancy' names, but it misses the point > unfortunately. This is merely a grouping a several *Jakarta* components. Oh please - do I really have to spell it out? "Jakarta Syllables" Yoav asked for 1-word suggestions, so I wrote only one word. I think it perfectly catches the point of having a collection of tiny items, of which you combine several to create something that makes sense as a whole. > A fancy name should be thought of as implying TLP status. I don't get that, but it doesn't really matter. Somebody asked for suggestions, I provided one. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Hello, > other 1-word suggestions would be great. since they're language components, you can call them "Syllables" :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
