Re: Non-released Dependencies
Agreed that #2 is best. (and I'll also note I was a bit slack with some commentary; releases need to be signed, so a path/revision or git-tag is not necessarily a true release; just trying to get across that you need a *specific* set of source for a dependency) Seems that Andreas is going to explore some options at dev@pdfbox. Cheers, -g On Fri, Jul 25, 2014 at 9:34 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I think the key bit here is that releases of Apache projects must have an associated source release and have been voted on by the PMC making the release. If the project you depend on is an independent project, you need to remember that their -SNAPSHOT build is *not* a release. Therefore you need it to become a release to include it. You therefore have three choices: 1. Fork the code into your project and do a big-bang release... a rude option but once it's in your project your PMC can vote to release it. 2. Join the dependent project and help them get to a release 3. Find somebody outside the ASF (or at a minimum not wearing an ASF hat) and get them to fork the code you want and release that. Then you can depend on the non-ASF fork of the ASF project... again a rude option, but perhaps less so than #1 I vote you go for #2. It plays best with community which is what we are here to foster On 25 July 2014 15:26, Greg Stein gst...@gmail.com wrote: [adding dev@community, as I believe this should go there...] On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert vhenneb...@gmail.com wrote: ... Hi, there's an undergoing debate in the XML Graphics project about doing a release that has a dependency on a snapshot version of another (Apache, for that matter) project. The fact that it is an Apache project is *key* for my commentary below. Don't take my words for external projects, please :-P I know there's a policy at Apache to not release a project that has non-released dependencies. The problem is, I don't know how I know that... I cannot seem to be able to find any official documentation that explicitly states it. That's why you can't find it... I don't recall any such policy (over the past 15+ years I've been around) ... it just isn't a good idea. That's all. The following link: http://www.apache.org/dev/release.html#what is apparently not convincing enough. I'm answered that this concerns our own project but that it's fine to do an official release containing a snapshot binary. Well. You need to produce a full set of sources. No binaries. Those sources might be by-reference, but you definitely can't release a binary within your source distribution. Even if that other Apache project had a release you're happy with, there would be a source release available for it. Saying that every binary artefact has to be backed by source code and that, in the case of a snapshot, we have to point to some Subversion revision number, is apparently not convincing enough either. Despite the obvious dependency nightmare that that would cause to users (and, in particular, Maven users and Linux distributions). Pause. This is not negotiable. You *must* have a source release. If you do that through a signed tarball, or through a git tag, or a Subversion revision number ... all of these identify a *specific* set of source code. That satisfies the need. You raise some concerns about nightmares... sure. Telling users you must get r123 of /some/path, for $LIBRARY is not exactly friendly. BUT: it satisfies all release requirements. It will specify the exact dependency. Good to go. Does anybody have any official reference to point at, that I may have missed? More convincing arguments, legal reasons (should I forward to legal-discuss@)? Much of this kind of stuff is institutional knowledge because having to write down rules and procedures just sucks. It is such a rare event, that it is best to leave it for the particular situation. There are no legal ramifications, if you're talking about a sibling Apache project. Now... you *should not* do any sort of release of a sibling. That will screw over that community. (version skew, unsupported bits, issue tracking, blah blah) I believe you have two options: fork their code into your project, and do some appropriate subpackage renaming to clarify it is distinct. Or, ideally, you join *their* community and help them cut a release, and then base your code on that. Cheers, -g
Re: Non-released Dependencies
[adding dev@community, as I believe this should go there...] On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert vhenneb...@gmail.com wrote: ... Hi, there's an undergoing debate in the XML Graphics project about doing a release that has a dependency on a snapshot version of another (Apache, for that matter) project. The fact that it is an Apache project is *key* for my commentary below. Don't take my words for external projects, please :-P I know there's a policy at Apache to not release a project that has non-released dependencies. The problem is, I don't know how I know that... I cannot seem to be able to find any official documentation that explicitly states it. That's why you can't find it... I don't recall any such policy (over the past 15+ years I've been around) ... it just isn't a good idea. That's all. The following link: http://www.apache.org/dev/release.html#what is apparently not convincing enough. I'm answered that this concerns our own project but that it's fine to do an official release containing a snapshot binary. Well. You need to produce a full set of sources. No binaries. Those sources might be by-reference, but you definitely can't release a binary within your source distribution. Even if that other Apache project had a release you're happy with, there would be a source release available for it. Saying that every binary artefact has to be backed by source code and that, in the case of a snapshot, we have to point to some Subversion revision number, is apparently not convincing enough either. Despite the obvious dependency nightmare that that would cause to users (and, in particular, Maven users and Linux distributions). Pause. This is not negotiable. You *must* have a source release. If you do that through a signed tarball, or through a git tag, or a Subversion revision number ... all of these identify a *specific* set of source code. That satisfies the need. You raise some concerns about nightmares... sure. Telling users you must get r123 of /some/path, for $LIBRARY is not exactly friendly. BUT: it satisfies all release requirements. It will specify the exact dependency. Good to go. Does anybody have any official reference to point at, that I may have missed? More convincing arguments, legal reasons (should I forward to legal-discuss@)? Much of this kind of stuff is institutional knowledge because having to write down rules and procedures just sucks. It is such a rare event, that it is best to leave it for the particular situation. There are no legal ramifications, if you're talking about a sibling Apache project. Now... you *should not* do any sort of release of a sibling. That will screw over that community. (version skew, unsupported bits, issue tracking, blah blah) I believe you have two options: fork their code into your project, and do some appropriate subpackage renaming to clarify it is distinct. Or, ideally, you join *their* community and help them cut a release, and then base your code on that. Cheers, -g
Re: Government License
On Wed, Jul 2, 2014 at 2:24 AM, David Welton dav...@dedasys.com wrote: Closest I've seen in the 'free' area is licensing that forbids military uses. Which is, once again, neither 'free software' nor open source because it goes against the definition. You can't have it both ways: you can't exclude people from using it because they are military, gay, Illinois nazis, Alaskan women, Liechtensteiners or whatever else you happen to dislike. I'm with you, Jake.
Re: WELCOME to community@apache.org
On Apr 23, 2012 3:20 PM, Greg Stein gst...@gmail.com wrote: On Apr 23, 2012 2:21 PM, Marvin Humphrey mar...@rectangular.com wrote: ... In theory, the fuzzy end-time could be abused on a contentious VOTE by say, coordinating a block of votes and having the RM terminate the VOTE immediately after those votes come in. So perhaps VOTEs which are expected to be contentious should have a fixed end-time. Since a release cannot be vetoed... sure, the RM could stop the vote. But the goal is to get signatures, too, so there is no strong benefit to stopping early. To rephrase: there is no such thing as a contentious release vote. Cheers -g
Re: WELCOME to community@apache.org
On Apr 23, 2012 2:21 PM, Marvin Humphrey mar...@rectangular.com wrote: ... In theory, the fuzzy end-time could be abused on a contentious VOTE by say, coordinating a block of votes and having the RM terminate the VOTE immediately after those votes come in. So perhaps VOTEs which are expected to be contentious should have a fixed end-time. Since a release cannot be vetoed... sure, the RM could stop the vote. But the goal is to get signatures, too, so there is no strong benefit to stopping early. Cheers, -g
Re: WELCOME to community@apache.org
The short answer is that you need to grow the number of active PMC members (not sure why users is on a vote; they don't at all). You need three +1 votes to ensure that the release has been fully-reviewed. One or two PMC Members cannot make a release in the name of the ASF. It takes a minimum of three. So... get more actives and/or get the other PMC Members off their butt to inspect the release candidate and sign it with their key. Three signatures, and you're good to go. (and please avoid rubber stamps; get some real review) Cheers, -g On Apr 23, 2012 11:40 AM, Lewis John Mcgibbney lewis.mcgibb...@gmail.com wrote: Hi Everyone, We recently held a VOTE [0] over on user@ and d...@gora.apache.org and only two official VOTE's were actually passed. For the record both were weighted in favour of a +1. Based on the nature of the VOTE and its conformance to the 'minimum quorum of three +1 votes' rule I am pretty much stumped about where to go next? As a whole the Gora community relies on lazy consensus, however in this case I am not satisfied that we can apply this attitude to the release package VOTE'ing process. I would therefore really appreciate some advice on how to progress with this. Thanks for any direction and/or comments. Best Lewis [0] http://mail-archives.apache.org/mod_mbox/gora-user/201204.mbox/%3CCAGaRif0LwzaoH2CvVvecG8zMXYVkOWZhOTi3qegFgGfTKMEUxw%40mail.gmail.com%3E
Re: WELCOME to community@apache.org
Huh? A release is not lazy consensus. You need three +1 votes. On Apr 23, 2012 11:52 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hey Lewis, FYI my reply to you in context on the Gora list: http://s.apache.org/49d In general, I just let the VOTE stay open for *at least* 72 hours. That way folks that are busy/lazy/whatever have a chance to still chime in. The truth is, as the one that called the VOTE, you are the one pushing for a particular desired outcome, so just wait till you get it :) Then when you are satisfied with the outcome, so long as *at least* 72 hours have passed, you are welcome to call the VOTE closed, and then move forward. Great job pushing this forward. My 2c. Cheers, Chris On Apr 23, 2012, at 8:39 AM, Lewis John Mcgibbney wrote: Hi Everyone, We recently held a VOTE [0] over on user@ and d...@gora.apache.org and only two official VOTE's were actually passed. For the record both were weighted in favour of a +1. Based on the nature of the VOTE and its conformance to the 'minimum quorum of three +1 votes' rule I am pretty much stumped about where to go next? As a whole the Gora community relies on lazy consensus, however in this case I am not satisfied that we can apply this attitude to the release package VOTE'ing process. I would therefore really appreciate some advice on how to progress with this. Thanks for any direction and/or comments. Best Lewis [0] http://mail-archives.apache.org/mod_mbox/gora-user/201204.mbox/%3CCAGaRif0LwzaoH2CvVvecG8zMXYVkOWZhOTi3qegFgGfTKMEUxw%40mail.gmail.com%3E ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: REMINDER: party list
On Thu, May 12, 2005 at 11:00:44PM +0100, David Reid wrote: Just a gentle reminder that the party@ list is an internal list who's membership is restricted to ASF committers. I've just had a request to join from someone who isn't an ASF committer (first time it's happenned so not a huge issue) hence this gentle reminder :-) Please don't crosspost to the party@ list and external lists. Please post about any social event that may interest ASF committers. And note that it is also used when people are travelling. As in, Hey, I'm going to be HERE. Anybody else around? Want to get together? Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wikis for Geeks: anyone have a wiki that supports CVS/SVN for users?
On Tue, Apr 26, 2005 at 11:26:26AM -0700, Brian Behlendorf wrote: There is SVNwiki, but it only uses SVN as the database backend; it's not designed to have the content also be edited directly, though someone could carefully do that. The issue is that Wikis do things to data on the way in, from syntax checking to (perhaps) glossary-izing, as well as to the data on the way out. Viewing the raw data in a simple text editor results in something that may be hard to read; editing the data may result in an inconsistant Wiki database. Just like calling SQL directly on data stored in a DB avoids the normalizing that application logic applies to it. Nah. I have yet to see a wiki do any checks on input. They're just very lenient on output. And there isn't any problem with poor integrity with writing straight to SVN. SubWiki depends upon a commit hook to index pages. No matter how you make a change (whether thru the interface, via SVN, or via WebDAV) the hook will run and the page will be indexed. Dunno how SVNWiki does it, but I know SubWiki is safe for multiple avenues of changing it. By design :-) Regarding its status: it is still being developed, albeit a bit slowly. It recognizes all the MoinMoin wiki syntax except for tables. It does not have all of the macros. It has some very basic authentication and authorization stuff -- I'm mid-process on adding cookie-based auth to the system. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: I need a Tomcat Consultant experience]
Yah, I got the spammage, too. (sigh) On Fri, Jan 14, 2005 at 06:45:49AM -0500, Rich Bowen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My experience with Tomcat ends at the feline. But, if anyone wants to follow up on this, feel free to tell them to pass the enormous referral bonus back to me. :-) On the other hand, for all I know, she spammed *all* the members. - Original Message Subject: I need a Tomcat Consultant experience Date: Thu, 13 Jan 2005 13:37:37 -0800 From: Suzie Jimenez [EMAIL PROTECTED] To: [EMAIL PROTECTED] Help... I am working with one of my clients and we need a Tomcat consultant w/VMS background can you refer me to someone... The position is in Costa Mesa, CA Suzie Jimenez Sr. IT Recruiter mailto:[EMAIL PROTECTED] ISSG- Information Systems Support Group, LLC 300 E Magnolia Blvd. Ste 403 4th Fl. Burbank, CA 91502 818-846-4774 x116 818-846-9971 Fax 818-554-6825 Cell www.issgjobs.com www.issg.com - -- Rich Bowen -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB57DtXP03+sx4yJMRAnZEAKCiGy0vu+dA3JU3fwEUMh2VY/snTgCgrsLj znNKzaaWMjSkyIlwyEPa0zc= =P6eo -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Requesting clarification in ByLaw text.
the other position, and people felt they had a mandate. Bleh. They just had a majority vote. Avalon bylaws are now no longer online, but let's look at an example of contradiction in the Excalibur TLP bylaws, passed by their PMC [1]; http://wiki.apache.org/excalibur/Bylaws Under 1.2.2.4 Project Management Committee, first paragraph, second sentence; quote The PMC is responsible to the board and the ASF for the management and oversight of the Apache Excalibur codebase. /quote Well, apparently the PMC is not responsible and not authorative, only the PMC Chair. In the strictest sense, yes. But in the everyday sense? No. IOW, for all intents and purposes, it *is* the PMC. But when push comes to shove and the PMC is fucking up, then the Chair has to do whatever is necessary to act in the best interests of the ASF. IMHO, these types of discrepancies are the true root of this thread. And instead of dismissing everything from my mouth at sight and being sick of me dragging this on, please take a moment and review my findings and move for a clarification of the PMC role (and the Chair), its responsibility and authority, and make that in writing to avoid any future misunderstandings elsewhere. And in the same go, ask the PMCs to review their PMC Bylaws (if they exist) whether they are in conflict with this clarified view. As I mentioned, in the typical case, they are totally fine. Avalon ran into a set of extreme situations, and my points [in IRC and other places] were made to demonstrate where the buck *really* stopped. And with that, to let Aaron know that he had the right and responsibility to do what is necessary rather than continue to get hamstrung by a defective PMC membership. When you look at the wording in the Bylaws, there is nothing that prevents a Chair from saying my PMC will have no members. I will be the sole decision maker. That Chair better have good reasons for that, but it *is* possible. On one occasion during the summer, the Board told one of the VPs something along the lines of, stop asking us to make your decisions. we put *you* in charge to do this. so go do it. The VPs are officers of the corporation, in every sense of the word in US corporate law. When things go to shit, they have incredible leeway (and the responsibility!) to make things right. But please don't confuse the typical from the atypical. If a VP was running rampant without due cause, then they wouldn't be a VP for long :-) FWIW, I liked your phrase in another email about renaming the PMC Bylaws to something like Standard Operating Rules or somesuch. Tho my personal opinion is to just lose them and have one set of rules for all ASF PMCs. We haven't done that in the past because the idea has always been to let the PMCs figure out what is best for their community, rather than to the Board (i.e. the ASF) mandate a particular set of rules. I hope that clarifies things. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Avalon Closed
On Tue, Dec 21, 2004 at 07:21:09AM +0100, Stephen McConnell wrote: ... a committee should have the ability to remove a chair The PMC lacks the authority to do so. Which is why it was presented as a recommendation! Do you see an inherent problem with the notion of a Chair accountable to the committee? It would not establish the necessary paths of responsibility and oversight necessary for the proper and legal operation of the ASf. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Avalon Closed
On Wed, Dec 01, 2004 at 02:26:43AM +0100, Stephen McConnell wrote: ... The Avalon community established a PMC to represent the community interests concerning the direction and administration of the Avalon project. Um. No. The Apache Software Foundation established the PMC. Its purpose was to provide the necessary (legal) oversight of the development of the Avalon project. That oversight is/was necessary to establish the appropriate legal protection for the committers on the project and the ASF itself. It is the ASF that releases the Avalon code, not the committers. To do that properly, certain things need to be done for the benefit of all involved. You may disagree with some of those processes, their purpose, and how it was done, but that is simply too bad. They need to exist so that our users can properly trust the code we provide. The community interests were clear - a single platform, one specification, a cohesive solution. No, that was never clear. That was *your* desire, Stephen, and you did everything you could to steer things in that direction. You alienated people, you berated people, and you generally made things unpleasant for anybody that did not have your same vision. Avalon went through many phases, and the single platform you mention was simply the last thing standing after your various escapades. That decision was not respected by the outgoing chair nor the board of directors of the ASF. The Board had nothing to do with these directions or choices. Our only (recent) involvment was that the VP in charge of Avalon asked us to terminate the project, so we did. Also recently, we directed the Avalon project to step up and deal with the problems that it has had, and to take proper care of its legacy users. But we did not specify any particular solutions. The PMC came up with the solutions. That is not the definition of a job-well-done. Instead this is much more about the weakness of individuals - in particular the members of the board of directors of the ASF and not least of all our outgoing chain. However - there is much that can be learnt from this. The weaknesses of the BOD can be attributed to their collective unwillingness to confront members of their own board. I have no idea what you're talking about here. The Board of Directors of the Apache Software Foundation does not have or need any confrontation. As a group, we work together very, very well. In the past three years or so that I've been on the Board, I can only recall *two* votes that were not unanimous. We reach consensus very easily, and it isn't because we beat some unnamed board member into submission. The weakness of our Chair was more a question of his personal loyalty to the community. I disagree. I very much respect what J Aaron Farr has done for Avalon. You made it a rather difficult task, but he stepped up and dealt with it. He didn't have to, but he did. And he did it because the community needed somebody to deal with the issues. Further, I think that he handled it very, very well. Some of the posts that he has written shows great insight into why great communities are needed here at Apache, and what makes a great community. He's shown that he can also help to shape those communities, despite adversity that was caused by certain folks. At times, he didn't take as much action as I might have, but I fully believe that he had good reasons, and I support the choices he made. Aaron has my respect, and I hope he continues to be involved in other Apache projects. Irrespective of the above obstacles a real and tangible alternative to ASF continues under http://www.dpml.net. The fundamental difference - no distinction between the people who contribute and the people who run the process. You may not like the process, but the legal backing provided by the ASF for the code that we release needs it. And in the end, our users need that. You are certainly free to create a different model, but it does mean the resulting code will not have the same kinds of assurances the ASF provides, nor will you have an entity that can assume legal liability for your results. It's your choice to make, and for your users to decide whether that is important. Cheers, -g -- [EMAIL PROTECTED] ... ASF Chairman ... http://www.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
gmail accounts?
Hi all, A while back, I offered gmail accounts to a number of people when the number of invites that I had was pretty limited. However, I now have unlimited invites... If anybody would like a gmail account, then please reply to me privately and I'll hook you up. I'm happy to provide them to any ASF committer and their family. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
patents (was: Inexpensive Lists)
On Thu, Jul 22, 2004 at 12:15:18AM -0700, Justin Erenkrantz wrote: --On Thursday, July 22, 2004 4:54 PM +1000 David Crossley [EMAIL PROTECTED] wrote: BTW, i thought that Antonio's alert about another potential M$ attack was warranted. He seems to care for the ASF as a whole. On which other list is he going to alert us all? FWIW, the only sensible strategy to software patents is to ignore them completely until we get served with a lawsuit. As much as it might sound foolish, it's almost the only way to legally protect ourselves. -- justin I'll go one better and state that is the official ASF position, supported by our legal counsel. - Ignore thought-scenarios around patents. Period. - Don't violate them if you know about them. But do *nothing* about unknown patents. If we get a suit brought against us, *then* we take action. Until then, don't go looking for patent violations. That is not our job. It is the job of the patent owner. Any research on our part *increases* our liability. Cheers, -g -- [EMAIL PROTECTED] ... ASF Chairman ... http://www.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Mon, Jun 14, 2004 at 06:13:17PM +0200, Dirk-Willem van Gulik wrote: ... Cause it actually lives on another machine than the repo (with an ocean in between). We tried this however for the toy site wleiden.webweaving.org:8080/svn/node-config/ (just 3.5Gb and a few thousands commits sofar) and ran into too many puzzles; like index.html; ensuring mod_perl did the right thing, etc. Though I am sure it is possible. No, actually it isn't. Too many of the standard Apache modules (such as mod_autoindex and mod_dir) look directly into the filesystem. We need a data store mechanism in core Apache which those modules can use to query filesystem-ish properties. We've discussed this a number of times on the httpd developer list. mod_perl could be used to write some filters to apply to the SVN content, but some serious work in mod_perl (and possibly core apache) would be needed for SVN to serve up Perl scripts to mod_perl to execute to generate the content. mod_php can't integrate well; the PHP parser actually requires a handle onto the filesystem, so it isn't possible at this time to pick up scripts from arbitrary data stores. So... if you have anything beyond a basic site, you'd need to use Dirk's suggestion of an auto-checkout (heck, you need it simply for index.html). Eventually, we'll have better support in core Apache, but don't hold your breath until then. It might be a while :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion 1.0
On Fri, Feb 27, 2004 at 09:50:20AM -0500, Stefano Mazzocchi wrote: ... SVN is built on top of APR, and also implements an Apache module (mod_dav_svn), so it already uses a lot of ASF code. That said, it would totally rock if SVN would come to the ASF. ... I wonder how the SVN community would feel about this. I suspect the SVN community would be quite fine with that. Greg, do you have any idea? what would be your opinion about this? As I mentioned elsewhere, there isn't really any move afoot or discussion about this. Some day in the far future, CollabNet might want to donate it to the ASF, but there isn't really any impetus to do that today. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion 1.0
On Thu, Feb 26, 2004 at 03:02:39PM -0500, Noel J. Bergman wrote: what's the checklist of TODOs to handle before dumping CVS? I'm in favor of migration, but have all of the client tools caught up? Have the Eclipse plug-ins caught up with current Eclipse? Subclipse works against Eclipse 2.x. I don't know what the schedule for 3.0 is; the Eclipse APIs for repositories changed quite a bit. ... Huge improvements over CVS asside, I'd much rather use tools built on top of [Apache] software. The dogfood has arrived, time for chow. Is SVN being proposed for Incubation? I hadn't heard. No, it isn't. There is *zero* discussion around this. Sounds like Fitz is working to get out the last kinks in cvs2svn.py, which will be a good thing. A lot of work on cvs2svn was done in February. Fitz is essentially using the ASF repositories as a very large test dataset :-) If something comes up, then it'll get fixed by Fitz and/or Karl. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Violation of ASF license, how to resolve?
On Wed, Feb 25, 2004 at 04:51:50AM -0600, Antonio Gallardo wrote: ... Just to make things clear to me: The notice in the about box is OBLIGATORY with ASL 1.1? What about ASL 2.0? Section 4 of AL 2.0 describes the new requirements, and 4d specifically notes that the same kind of acknowledgement must occur. Cheers, -g p.s. it is the Apache License (AL), rather than Apache Software License (ASL) -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[kfo...@collab.net: Subversion 1.0.0 released.]
fyi... - Forwarded message from [EMAIL PROTECTED] - From: [EMAIL PROTECTED] Subject: Subversion 1.0.0 released. To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Mon, 23 Feb 2004 04:24:55 -0600 (CST) Reply-To: [EMAIL PROTECTED] Subversion 1.0.0 is ready! Grab it from: http://subversion.tigris.org/tarballs/subversion-1.0.0.tar.gz http://subversion.tigris.org/tarballs/subversion-1.0.0.tar.bz2 The MD5 checksums are: 32f2c6e8c7f97587f19275c4e3219363 subversion-1.0.0.tar.gz ee14f19960c7fa9f2640ff04acdce804 subversion-1.0.0.tar.bz2 Subversion is the work of many volunteers from around the world. It would be impossible to thank them all by name here, though they certainly deserve it. If you see a Subversion developer, documenter, or tester in the street, buy 'em a beer -- they've earned it. Thanks also to CollabNet, which started the Subversion project and continues to pay for three (and sometimes four) full time developers. Praise, blame, questions, and bug reports are all cheerfully accepted at [EMAIL PROTECTED] Enjoy, -Karl Fogel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - End forwarded message - -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about Board resolutions
On Sun, Jan 25, 2004 at 01:49:00PM -0600, Tim O'Brien wrote: Anyone know where board resolutions are kept in CVS? I'm wondering if there is any historical record of board resolutions available to members of a PMC? The minutes of all Board meetings are posted to the foundation's web site. See: http://www.apache.org/foundation/board/calendar.html Those are also located within the 'site' module in CVS. There is no singular location for passed resolutions; only the minutes. For ASF Members, they can also look in the 'board' module for the agendas and the unofficial minutes of board meetings. (i.e. those which have not been drafted and voted as official) Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Internationalization list/team
On Wed, Oct 22, 2003 at 12:37:28PM -0400, Noel J. Bergman wrote: Tetsuya Kitahata wrote: * Mailing Team (Board Committee) * Internationalization Team (Board Committee) are what I needed and wanted. (*NOT* [EMAIL PROTECTED]: for i18n) There is a mailing team. apmail is part of infrastructure. Right. As for internationalization, I don't see why it should not be part of Apache Commons. I think that it is exactly the correct place for it. I don't know that it needs a CVS module, but I'm not opposed to one. Apache Commons uses SVN :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Follow the example
On Thu, Sep 18, 2003 at 11:24:52PM -0400, Noel J. Bergman wrote: And your point would be? That since ApacheCon doesn't have a session on James, that the James home page should not advertise ApacheCon? Hey guys, leave us out of this argument. Hehe... James was on the list, so I used you as an example :-) I was asked a pointed question of Dion, rather than the James PMC. I think it is great to see the apachecon gif on the james site. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Follow the example
On Fri, Sep 19, 2003 at 10:03:12AM +1000, [EMAIL PROTECTED] wrote: Ceki Gülcü [EMAIL PROTECTED] wrote on 18/09/2003 11:55:43 PM: Everyone would agree that spreading the good word on ApacheCon US 2003 will contribute significantly to its success. ... Thus, I urge all ASF projects (and subprojects) follow their example and add a prominent icon to their project pages. Please do not wait ... There's no coverage on some of the top level projects you mention, e.g. no sessions on Ant, Avalon, James Maven. And your point would be? That since ApacheCon doesn't have a session on James, that the James home page should not advertise ApacheCon? That because Maven isn't present, that the Maven PMC should ignore ApacheCon? I really hope that I'm reading your message wrong... The more successful ApacheCon is, the more successful the ASF is. We *all* gain by helping ApacheCon be successful. Cheers, -g -- [EMAIL PROTECTED] ... ASF Chairman ... http://www.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN (was: RE: The cash of our lives / Dvorak)
One of the previous concerns was tool support. Since then, we have SVN capability in ViewCVS, and there is also an SVN plugin for Eclipse and IDEA, and several GUIs. SVN itself has been stable for a long while; the only real concern [for the ASF] is the related tool support. For Maven compatibility... somebody will just have to code it up. I believe somebody out there has done an Ant task for SVN, but I dunno what the status of that is, or whether it has seen its way back to the Ant folks. SVN easily supports anonymous, read-only access (and without the nonsense of needing to supply some arbitrary name/password like CVS). There isn't a CVS proxy, however. Does BK actually proxy a CVS connection to the bk repos, or do they just mirror changes into a cvs repos? Cheers, -g On Wed, Jun 11, 2003 at 10:34:54AM +0200, Henning Schmiedehausen wrote: I'm all +1 on moving our repositories forward, but I've got used to some of the nice tools surrounding SVN that I don't want to miss. And then there is the question of things like maven supporting SVN just as well as CVS. For bk there is some sort of CVS compatible read-only view into the repository. Is this possible for SVN, too? Regards Henning On Wed, 2003-06-11 at 10:16, Sander Striker wrote: From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2003 10:00 AM Greg Stein wrote, On 10/06/2003 21.01: ObPlug Use Subversion. /ObPlug :-) Cry4Help Release the baby! /Cry4Help ;-) Once Karl has finished up the branch/tag support in cvs2svn we can do some experimenting with converting cvs repositories. This is the major obstacle, the price of not being able to look at history, unless going back to some cvs graveyard, when moving to svn at this point in time. Hence the wait for cvs2svn to be finished. And then there is the community backing. Each project has to have enough people wanting to move away from cvs, over to subversion. I haven't done any polling, but I've a hunch that it won't be an objectionless transition for all. Sander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
author tags (was: The cash of our lives / Dvorak)
On Mon, Jun 09, 2003 at 06:06:54PM -0400, Noel J. Bergman wrote: I don't know whether this was a symptom, a remedy, or a cause. Isn't the fact these tags needed to be removed some telltale? I'm just wondering, since you seem to advocate this as a good community pattern. I fully admit that I suggested it after seeing what was going on in Avalon, In Avalon, it was a remedy (IMO). In general, I believe it is a very good thing to omit them. ... Many (most?) @author tags, even in the Java distribution, have become nothing more than legacy markers. Some of the people listed as the author of a class aren't even employed at Sun anymore. Even if they are, they likely aren't the ones still maintaining or developing that code. Perhaps we don't have access to the internal source control system for Java, but everyone can browse the CVS for an ASF project to see who has been doing what to any code for which an @author tag would matter. Right. And people get visibility in CHANGES files, on the web site, or what have you. But to identify people with a specific file? Hmm... Some negative aspects of @author would be the impression that the author owns the code, and reluctance on the part of others to make changes to someone else's code. I've seen this more times than I care to count, over the years. It is an especially bad thing at the ASF, where even a little of that isn't right. Consider: the ASF is all about creating a community around a codebase so that the code can survive the departure of any/all developers. If that is the case, then why are their names in there? The code should be owned and maintained indefinitely by the ASF and the community that has been established as the caretakers of that code. From a legal standpoint, it is worrisome if your name is in the code. The ASF is also built as a legal shield against (malicious) lawsuits. If your name is in the code, then the plaintiff stands a very reasonable chance of saying you're name's in there, so you're at fault. If you leave the name out, then the ASF has a *very* good chance of saying so what if the made the commit? they did it at the direction of the PMC, which is at the direction of the ASF. thus, the ASF made the change. drop them from the lawsuit. Positive aspects of @author are ... umm ... ? People maintain that it is so you know who to talk to. I don't buy it. They get out of date, or they don't include the right people, or the addresses are wrong, or ... Look at CVS. That'll tell you. But even better, pose the question on the community's dev list. So, yah... I haven't seen any real good reasons for author tags yet. Nor have I over my years over professional development. And when you're talking about a codebase that is intended to last for *decades* at the ASF, then I *really* don't see the purpose of author tags or other types of in-code credits. Decades. Think about it... The ASF isn't fooling around here :-) Speaking of good community pattern[s] ... what are considered good and bad patterns? That would be an interesting discussion, and perhaps something to record for incubator. What problems have people encountered in their ASF communities? What has worked/not worked? What forms of behavior are acceptable/unacceptable? Can technical debate go too far? How do you resolve differences/conflict? Within the httpd and APR communities, we studiously avoid author tags. People have contributed patches, and we reject them until they remove their name(s) from the patch. Within the dev community, we certainly know who knows best about particular subjects, but there is zero ownership or territorialism in the code. The Subversion community operates the same. We rejected a number of patches from a guy that wanted his name in there. After he kept pestering us, we eventually told him flat out, no. We haven't seen him since, so in retrospect, I'm glad. It implies that he was seeking to have his name as part of the project, more than he wanted to help the project. Your question goes well beyond author tags, though, and is boundless. I'm not going there right now. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The cash of our lives / Dvorak
On Tue, Jun 10, 2003 at 01:58:16PM +0100, Danny Angus wrote: Jeff, Yes, and isn't it fun. --fun snipped-- ;-) So should we only do things that are fun? Moving and re-naming files in an ssh terminal session is not crazily graphical nor easy enough for a 4 year old, but I bet there are enough people in Apache who can do it without sweating that it is, IMO, a poor excuse for throwing away useful information. Bah. ObPlug Use Subversion. /ObPlug :-) -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
On Thu, Feb 27, 2003 at 10:12:35AM +1100, [EMAIL PROTECTED] wrote: ... sourcecode under its own license. Yes, binary, but it is the best first step and it solves a real need. Just to play devils advocate, what is that need, Given that there current is a repository distributing ASF binaries with their license. This is not a facetious comment, but a desire to explore what the need is for an ASF-blessed repository. The ASF doesn't need to have a repository. But it cannot operate or condone a repository that has or allows license violations. The ASF is primarily concerned with the original, authoritative distribution of its code. For proper authenticity, security, mirroring, etc, that distribution has a set of requirements and policy which has been defined by the infrastructure team. Beyond the original distribution, then it's all gravy. What facilities do we want to provide our users and downstream developers? How can we simplify their lives? Ted points out that it is reasonable to state that the ASF is creating problems (classpath and whatnot), so maybe you could even say we must create a repos simply as a way to help recover from the mess that we have made. *shrug* It does seem like people are narrowing in on some proposals, designs, etc. I might suggest it is about time to Wiki-ize the current thoughts so that you have something concrete to reference in further mailing list discussion. And to iterate on or to provide some alternatives. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
On Wed, Feb 26, 2003 at 09:46:16AM -0500, Jason van Zyl wrote: On Wed, 2003-02-26 at 09:34, Greg Stein wrote: ... Bah. The Board can easily change the scope if there are better ways to organize the software that we [the ASF] produce. Existing charters shouldn't get in the way of What Is Right. What Is Right ? So that's going to be the board deciding what is right? What project's themselves want is not right enough? That is frightening. What happened to project self direction/determination? People have said this in followups, but I'll specifically clarify my intent. If the projects at the ASF are hampered by their charters from doing the right thing, then they can simple ask the Board to get them changed. It is an easy process for the Board. There is no reason for you to suspect anything wonky from me, and your attitude towards my email is quite bewildering. To be honest, your response and the rest of the followups don't sit well with me at all. The Board exists to help projects in their work. We exist to protect the ASF to ensure that it will continue to exist, to help projects. Our intent is to let projects do whatever they feel is right and correct, subject to the constraints of the operation of the ASF and to what we feel may be injurious to the overall health of the ASF. I do think you're unfairly calling the Board a tool of Sam. Speaking for myself, that is a negative input to my own decision-making process. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
On Wed, Feb 26, 2003 at 10:43:05AM -0500, Jason van Zyl wrote: ... Or how about we make a tautalogical resolution like the Ant or Cocoon resolutions which got passed. I'm fine with changing the resolution to something like those of Ant or Cocoon: The Maven Project will deal with the Maven system. And the Board already told Cocoon that it did not like that tautology. For the Cocoon case, the Board was comfortable in creating the PMC and letting them get started, with the caveat that they must submit a refined charter to the Board. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
On Wed, Feb 26, 2003 at 04:01:06PM -0500, Noel J. Bergman wrote: ... As I understand it, the ASF is flattening the hierarchy, but I see top-level projects established around synergistic semantic domains, not code bases. There is a bit of tension between those two, but generally: yes. There is a continuum between umbrella and per-codebase. We're shifting away from umbrella; will we ever reach *per* codebase? Not without additional infrastructure support tools(*). Isn't that why the ASF Board established webservices.apache.org, and rejected the Cocoon charter? The fact that they would promote Cocoon in the absence of an acceptable charter is an extension of respect to that Community, showing the the Board is confident that they will return with a proper charter governing ... dynamic XML-based content serving, I would expect. You hit the nail on the head. Yes, exactly: the Board was quite confident in its trust that Stefano and the rest of the PMC would iron this out. There was no reason to hold up the new PMC for what amounts to a correction in some text. This is all Maven is trying to do. Any kinds of integration/merging is an internal decision for the Ant and Maven communities isn't it? Remember, this started as a question. WHY aren't they under by a common TLP? No one said that the Board was, would, or should enforce it. Right. From the meeting this morning, the Board basically said, so what if they compete? But the Board *also* said, if they compete to the detriment of the ASF as a whole, then we would need to do something. [ where something starts with directing the PMCs to figure out what to do ] Cheers, -g (*) SourceCast has been referenced in the past, but I have to abstain on decisions surrounding its acceptance, and tread carefully when referring to it. [conflict of interest; especially if I use [EMAIL PROTECTED] -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
infrastructure team (was: Ant PMC Issue ...)
On Wed, Feb 26, 2003 at 04:01:06PM -0500, Noel J. Bergman wrote: ... With respect to the repository, and classpaths, I have proposed that Dion Gillard be selected to chair a Apache Repository (sub)-committee under the infrastructure PMC. Just a clarification: the infrastructure team is actually a President's Committee rather than a PMC. Um, why? you may ask :-) The Chair of a PMC is an officer of the corporation. Within the constraints of their job role, an officer can do a lot of things. Board Committees also have a lot of power. In the infrastructure team case, when the Board considered the resolution, we effectively said nope; we don't want them to have that much leeway. So... the Board asked Dirk if he could form a committee; he said yes :-) And no, we'll skip what a lot of power means. No sense in riddling people's heads with ideas :-) In general, I believe any officer can form a committee. It is simply an operational issue in getting that officer's work completed (well, not directly the officer's, but what that person is responsible for). And yes, this means that PMCs can create little subcommittees to take on specific tasks. If that makes sense for the PMC, then they should do it. As long as the PMC is *still* handling their primary responsibility of oversight; they cannot delegate away responsibility, only operational types of things. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sponsoring of asf: fud or truth?
On Tue, Jan 28, 2003 at 08:55:33AM -0500, Ben Hyde wrote: ... are accounting records available? I thought there were, I know we discussed having them be public in the first year. It maybe that some reason arose to keep them underwraps. The short form though is they wouldn't help resolve this issue. Most of our needs are met by donations in kind of resources - particularly the labor of the many kinds of community members. As a public charity, I believe they are required to be public. Roy would know the definitive answer (CC'd on this email). Cheers, -g -- Greg Stein, http://www.lyra.org/
wiki utility (was: Wiki Administration)
On Tue, Jan 28, 2003 at 07:55:45PM +0100, Dirk-Willem van Gulik wrote: Our project is getting value out of the Wiki, in part because we have non-Committers feeling empowered and able to contribute directly. People can do the same with patches on mailing list; and seem less likely to abuse that. Perhaps the simple validation (and display) of a valid email address may do the trick. I would say that empirical evidence shows that the Wiki fulfills a need that patches on a mailing list do not. If the mailing list were sufficient, then the Wiki would be empty. The simplest answer is that the Wiki is *much* easier to use and respond to. Consider these two operations: A. the Wiki approach 1. view a web page 2. oops. something is wrong. 3. edit the page. 4. Goodness(tm) B. the mailing list approach 1. view a web page 2. oops. something is wrong. 3. view source, develop a patch. 4. send patch to mailing list. 5. rejected. patch should be against source. 6. crawl thru CVS to find the source. oh! the *xml* source 7. redo the patch. 8. send patch to mailing list. 9. rejected. patch broke the transform process. 10. screw this... :-) Yes, I know that variations are possible on (B). But even the simplest case: 1. view a web page. 2. oops. something is wrong. 3. send email to mailing list. 4. committer updates his working copy or gets a new one. 5. change is made 6. changes are committed 7. web site is refreshed. 8. Goodness(tm) Meanwhile, it would be typical for a good amount of time to pass. The feedback loop as ben put it just isn't there like it is for a Wiki. I'm not a Wiki == Documentation guy (I think there are many more uses), but it has significant utility over mailing lists... Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Weblogs and Obstructionism
On Mon, Jan 27, 2003 at 01:25:47AM -0500, Noel J. Bergman wrote: ... A project site, such as James or Jakarta, could integrate their SubWiki with the rest of their SVN-backed web content. I am expecting that Greg and the rest of the Subversion folks will be ensuring that unchanged DAV content, such as a News page, is capable of being served by httpd at quite close to static content speed. We've gotta yank that data out of a Berkeley DB. Of course, maybe it is sitting in a shared memory segment, or the OS cache, or whatever, but it will take a bit of time. That said: we *do* support etags which can optimize GET performance. And depending on how you ask for the content, it can be *very* cacheable. In particular, it is possible that checkouts can cache at a local [caching] proxy, enabling the guy sitting next to you to fetch his checkout at LAN speed. And last, but not least, you could put a caching reverse proxy in front of Subversion. That would seriously offload the server. And if some Smart Guys wrote a post-commit script to issue an ICP request to that proxy, then you could keep the proxy up to date on all the content. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Do vs. Talk (Re: email notification done...sorta)
On Thu, Jan 09, 2003 at 05:51:55PM +1100, Jeff Turner wrote: On Wed, Jan 08, 2003 at 10:26:41PM -0800, [EMAIL PROTECTED] wrote: Sometimes it's better to _think_ before talking or doing :-) And it's nothing wrong to think after talking and doing - and make changes and adjustments. Agreed. I don't think open source or meritocracy is about doing, it's more about feedback and review and improvements. Costin: spot on. Thx. If you like. Then what I'm describing is in this article Sam once posted: http://www.libertyforall.net/2002/archive/do-ocracy.html Ah. Reliance on a higher authority. I think there is a term for that... :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
python foo (was: email notification done...sorta)
On Thu, Jan 09, 2003 at 08:42:58AM -0800, Stefano Mazzocchi wrote:
David N. Welton wrote:
...
Anyone can code in Python. It's easy, and it runs anywhere. Not
quite an offer of help, but... if you have figured out one programming
language, picking up Python will not be hard, nor unpleasant.
That's been my experience... but python really needs better support for
multidimensional arrays :-) or merge numeric python in the default
language. But anyway...
Huh?
array = [ [1, 2, 3],
... [4, 5, 6],
... [7, 8, 9] ]
print array[1][2]
6
sparse = { (1,2): 6, (2,1): 8 }
sparse[1,2]
6
The Numeric package is for high-performance numeric computation. Most users
don't need that kind of heavy-lifting. There are also some semantic oddities
in the package that need to be ironed about before it could move into the
core Python distribution.
But out of the box? Python has multidimensional arrays. Not sure what you're
smoking :-)
(and don't ask me about the time I tried to do a hash of hashes of hashes in
Perl... even with Perl hacker help, I gave up; Perl just wouldn't do it)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: email notification done...sorta
On Tue, Jan 07, 2003 at 10:12:50PM -0500, Andrew C. Oliver wrote: So I have email notification sorta working. I can't get the diffs included.. Its too bad we don't have any decent perl programmers. I'm apparently the master PERL programmer here. The rest of you are all talk. To see the error (which since I cant fix it, you all are obviously not good enough to fix) subscribe to [EMAIL PROTECTED] Andy, I'm getting quite sick of your you're all talk attitude. Chill the hell out. -g -- Greg Stein, http://www.lyra.org/
Re: email notification done...sorta
On Wed, Jan 08, 2003 at 02:17:38PM -0500, Noel J. Bergman wrote: http://www.freeroller.net/page/acoliver/20030108#when_is_community_not_a ... - he was criticized for a message that he made in jest, but which wasn't at all obvious in that intent. To be honest, I usually find people who say but that was a joke are simply trying to cover up a social blunder under the ruse of you didn't get it. Whether the case here or not, it certainly was non-obvious. And why did he unsubscribe? We can make guesses, but that's about it. Unless he clarifies further in his blog or posts elsewhere... Just Do It is a great ad slogan, but it doesn't seem to me to always be the appropriate model for group projects. Right. Yes, it makes things happen. But when people are actively discussing an issue of communal interest, it makes sense to me that the issue be discussed, various ways to doing something examined, tradeoffs weighed, and then execute a change based upon some concensus. Otherwise, when more than one person cares about a subject, Just Do It results in one person's vision being realized, and a cycle of potentially conflicting changes necessary to stablize the code. Am I missing something? You're missing the fact that a just do it attitude can be totally inconsiderate towards your peers. I don't care about your opinion, I'm just getting it done. It certainly doesn't help foster a community based on mutual respect. I'm going to be curious to see how Subwiki works out -- if the intent is to switch --- being in Python, not Perl, but still not in Java. Are there more Python coders than Perl here? It is probably about the same number, but the SubWiki author is here while the UseModWiki author is not :-) To be honest, any kind of switch would be based on features rather than on the language. (and the fact that I can maintain our installation) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: fyi wiki statistics
On Tue, Jan 07, 2003 at 11:53:52AM -0500, Ben Hyde wrote: ... It turns out if you build a event driven mail based notification system you shortly there after discover that it's too painful to use. The Wiki model results in editors writing changes so they can preview; and in tangles of nodes going thru periods of total chaos[1] as an editor attempts to make any changes that involve more than one node. Both these make the change stream very hard to read. I suspect that much of that could be resolved by sending mail with changes when the dust settles. Bah. Use SubWiki, check out the Wiki pages into a working copy, make all your changes, then commit them. Regular commit email sends the full bunch of changes. Simple as that :-) Cheers, -g p.s. of course, if SubWiki were anything beyond pre-alpha, I might actually recommend deploying it to apache.org :-) -- Greg Stein, http://www.lyra.org/
subversion (was: fyi wiki statistics)
On Tue, Jan 07, 2003 at 04:48:11PM -0500, Noel J. Bergman wrote: Bah. Use SubWiki, check out the Wiki pages into a working copy, make all your changes, then commit them. Regular commit email sends the full bunch of changes. grin Does this mean that Subversion is coming soon to replace a CVS repository near us? Not that updating a Wiki that way is in the spirit of Wikis as I know them, but I'm looking forward to Subversion. A couple days ago, Brian installed some dependencies on icarus and daedalus to support building Subversion. Next up is to try building it. Assuming that works, then yes: we're going to enable a Subversion server on icarus, and we'll have clients on icarus and daedalus. The Apache Commons project is going to start its work in an SVN repository. Other projects can migrate as they choose. (we'll also be upgrading ViewCVS to the CVS version which has SVN support) Once we have SVN, then we can also start playing with stuff like SubWiki. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: fyi wiki statistics
On Tue, Jan 07, 2003 at 05:08:19PM -0500, James Taylor wrote: You are stating that: 0) download a working copy [this is done only once] 1) go to a page 2) edit it 3) save it 4) commit the page is comparably simple with Feh. I said no such thing. I said that if you wanted to do multiple page edits without spamming the change-notification mailing list, then SubWiki makes it possible [by following the steps you suggest]. In no way did I say it was comparably simple to standard Wiki editing. Of course not... jeez, just how small do you think my brain is? :-) 1) go to a page 2) edit it 3) save it and I disagree. If it means I can edit the page in my fancy editor of choice rather than a dumb web browser then it is much simpler. And standard tools and standard commit emails and standard access control and all kinds of other stuff. The (only?) beauty of a wiki is its dead-simple editing cycle. I believe sub wiki also has a TTW editing interface. No reason you can't have both. Because it uses subversion to hold pages, the interface is nicely seperated from the data store. Yes. You definitely cna edit pages via the web site. That *is* what a Wiki is all about. Not the stupid formatting rules. http://test.webdav.org/wiki/Welcome And both is actually incorrect. You have four ways to view the content and three ways to edit the content: 1) read/write via the Wiki itself 2) read/write via working copies 3) read/write via WebDAV (new from sussman and jerenkrantz) 4) read via web browser Sure, it is not ready for primetime, but I like the idea a lot. The code is ready, but I don't have all the standard formatting rules and macros in there right now. There are a number of things that people expect which just aren't in there. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: fyi wiki statistics
On Tue, Jan 07, 2003 at 02:01:43PM -0800, Stefano Mazzocchi wrote: ... Paint me PITA, but I think it's worth playing devil's advocate on this muddy ground. Play devil's advocate, sure, but I'd suggest a bit more research... the ground isn't actually muddy :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: fyi wiki statistics
On Tue, Jan 07, 2003 at 06:08:25PM -0500, Ben Hyde wrote: ... Greg Stein wrote: In no way did I say it was comparably simple to standard Wiki editing. Of course not... jeez, just how small do you think my brain is? :-) Well my brain got a lot smaller after I cut my hair, so bear that in mind. Well, geez. I could have told you that. Why do you think I keep my hair long? :-) -- Greg Stein, http://www.lyra.org/
Re: mailing list organizatoin
On Sun, Jan 05, 2003 at 09:32:18PM -0800, Aaron Bannert wrote: No, this does not belong on the community mailing list. If you are interested in helping foster new projects, and have opinions on how things like mailing lists should be formed, then join the incubator list. You bet! +1 to that. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Tapestry incubation
On Mon, Jan 06, 2003 at 11:38:41AM -0700, Eric Dobbs wrote: On Monday, January 6, 2003, at 02:35 AM, Henning Schmiedehausen wrote: My only concern is, that we will spread a limited number of developers over too many projects. The developers and their communities are already spread over those many projects. Yup. And there is nothing you can do about that. You can't simply state, Well, the ASF will only have 10 projects so that our 500 developers can concentrate on those. We won't start an eleventh project. Guess what? If you don't, then the developers that were interested are *still* going to go wherever it ended up and work on it. It isn't possible to artificially limit the number of projects under some preconception that your limited pool of developers will only work on those. The ASF members and committers will work on what they want. That is here or there. But you can't coerce them. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: [discussion] Jakarta PMC bylaws change
On Mon, Nov 04, 2002 at 06:51:04PM +0100, Dirk-Willem van Gulik wrote: ... Now if this would be all - no worries. However I personally think that the transition from that one HTTP crowd to one for HTTP, one for APR, etc, etc was already showing that something is a bit amiss in the scaling; even though the group of peopple is nearly overlapping; long term goal, feature creep in APR, versioning issues between APR/HTTP and even getting release notes out with some sort of coordination with php/perl treading-aint-work warnings, required a fair amount of noise in order to get the coordination they required. I cannot help to think that a much smaller group of people across those projects whould have done better than the current cabal keeping things on track simply by being a smaller focal point who know that they cannot dodge the issue. I don't think smaller would have done it. For these specific cases, I think the issue is with volunteerism. If somebody doesn't volunteer, then it doesn't get done. Putting somebody into a small PMC does not increase the amount of volunteered effort. It's possible to address each of the items you raise, but that isn't quite relevant. We're talking about the meta-issue: small or large? The Board is composed of nine people because we assume that everybody can't participate all of the time. When those (hopefully few) are unavailable for a particular item, we still have quorum to get things done. If the Board had five people, then just a few busy people would deactivate the Board. When the Python Software Foundation was formed, it was asked, wow. why such a large board? why not a smaller number, like five? Well, it is a damned glad thing that I made it seven; there are already issues with inactivity, let alone what would happen with just five. The same issue applies to the various PMCs. A large group means that you get a large body to take on any issue that requires the PMC (which is few, as you point out: mostly, it is a dev@ issue). ... And I also think that too large a cabal will simply create 'chair's whose job is much bigger than a volunteer can handle. I disagree. Ben Hyde is the HTTPD PMC chair, and he hasn't ever really been needed. He'll pop up around Members Meeting times to prompt for member nominations, and he has sometimes interjected useful comments to help refine the discussion and keep it on track. But as we've added people to the PMC, I haven't seen his job get any more difficult. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: ASF Membership Nomination
On Tue, Oct 29, 2002 at 06:51:35AM -0500, Sam Ruby wrote: Greg Stein wrote: Sorry, but nominations for membership, commit status, or PMC membership really should be private. I absolutely will not participate in such an environment, and will encourage others to avoid it also. These kinds of discussions really don't enhance the community. Greg, At a minimum, please acknowledge that a large number of ASF commiters ACK have never participated in (or even have access to) private ASF mailing lists, have only seen commiter nominations done in public (and many have done so themselves), and the only PMC nominations that they have seen have also been done in the open (Jakarta, XML). I already knew that. It doesn't change my thinking, though. The fact that it happened doesn't mean it is good/bad, just that it happened that way. Personally, I think it was bad. I had no place or right to say so, so I didn't. But when that behavior impacts member nominations? i.e. the ASF itself? Oh yah, then I'll add some commentary :-) But it works -- we have committers But it works -- Jakarta has produced some great code But it works -- ... Well, yes to all of those. Sure it did. My concern is about the impact on the community, not the ability to get work done. And measuring the health of a community is quite a bit less objective. I never had the opportunity to interact or really view or hear about the ins-and-outs of the Jakarta community until these past two or three weeks. And you know what? I think it *is* fractured, and that is sad. I witnessed some straight-on personal attacks on the reorg@ list, and been privy to others due to my Board role. People actively stating they don't want to work with somebody or interact with them. I've never seen the like in the httpd and apr communities where we avoid talking about people publicly. Is there a causal link? Probably not, or if so, then very minor. But I don't want to test the hypothesis. I don't want to give any foothold for community fractures; it just isn't worth the risk. Cheers, -g -- Greg Stein, http://www.lyra.org/
committers repos (was: ASF Membership Nomination)
On Wed, Oct 30, 2002 at 12:50:59AM +1100, David Crossley wrote: ... What about using CVS for this? Can only committers checkout the committers module? (I see that it is not available via ViewCVS.) Yes, the committers repos is only available to committers. Its absence from ViewCVS is probably more of an oversight than intended, but that *is* the correct standpoint. The repos contains committer-private information; in particular, the hackathon signup sheet is there -- the hackathon is not a public event. I've been thinking about putting a list of all the top-level projects in there and detailing who is on the PMC for each, along with the chair. Partly for my own benefit when I need to mail the PMC Chairs for their reports to the Board :-) If so then that makes it a semi-private place. Each project could have their own document (e.g. cocoon-new-committers.txt) where we discuss via editing the file. This also helps to keep track of various developers that we may want to invite later. Too often i have seen people overlooked because we have just plain forgotten to invite them. That repository is open to all committers. While we don't want each person to have a field day in there, I'd also point out that you *can* put whatever you think is appropriate into it. Just try to be considerate about the structure you use. Until we switch to Subversion, CVS is rather stiff with its directory layout :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: [VOTE] Open this list
On Sat, Oct 26, 2002 at 09:38:03AM -0400, Andrew C. Oliver wrote: ... View 1: Open the list completely, anyone can subscribe, post and read the archive -1 View 2: Keep the list open only to committers, members and invitees (highly contributive developers and users) so far as posting goes, however allow anyone to read or view the archive (and include an archive such as MARC, etc. +0 View 3: Close the list to all except members and committers. +1 We need a forum for the ASF to discuss itself without worrying about the viewing public. Cheers, -g -- Greg Stein, http://www.lyra.org/
