Re: Opening up the PMC
On 8/8/06, Henri Yandell [EMAIL PROTECTED] wrote: 2) Every new committer automatically gets added to the pmc. -0 I think the committer role as an initiation period of sorts is good thing. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove SVN restrictions
+0 I generally support the idea, but I'm skeptical it will have any lasting noticeable effect. (If this vote is limited to a +/- 1then you can count my vote a +1.) On 3/27/06, Henri Yandell [EMAIL PROTECTED] wrote: Vote to remove the SVN barriers within Jakarta such that all jakarta-* groups are merged into the one jakarta group with the exception of jakarta-hivemind, jakarta-slide, jakarta-cactus and jakarta-jmeter under the assumption that they are moving to having their own PMCs. Tapestry is already within its own auth group. [ ] +1 [ ] -1 If your -1 is only for a particular subproject (ie: you don't care what the rest of Jakarta does, feel free to say so). -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Cleanup pmc members
On 3/16/06, Henri Yandell [EMAIL PROTECTED] wrote: Previously I'd suggested that we should be cleaning up inactive committers and inactive PMC members - because I'm a bit of a tidy-addict sometimes and I enjoy deleting :) A thread on [EMAIL PROTECTED] convinced me that this was half wrong though - we shouldn't be worrying about cleaning up the large list of inactive committers, they might come back and that would be great. However I do still think we should be cleaning up the inactive PMC members. The PMC represents the active committers entrusted with oversight - so to have inactive committers on there is a detriment to its ability to get the job done. 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? Yea, why over complicate this? Simply email the inactive PMC's known email addresses explaining they have been inactive for an extended period of time and whether or not they have a problem being de-PMC-ified. Try to contact them three times at two week intervals and keep track of this either in svn or a bugzilla issue. After two months of no response let other PMCs vote on the issue. Introducing a new tasks that only your buddies will likely know about in order to maintain membership feels a bit like when the south (in the USA years ago) introduced literacy tests to keep blacks from voting. It's fine that you have an agenda, but be straight forward and honest about it. And don't make people jump through hoops so their possibly conflicting positions are still binding. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Cleanup pmc members
On 3/16/06, Henri Yandell [EMAIL PROTECTED] wrote: On Thu, 16 Mar 2006, Sandy McArthur wrote: On 3/16/06, Henri Yandell [EMAIL PROTECTED] wrote: Previously I'd suggested that we should be cleaning up inactive committers and inactive PMC members - because I'm a bit of a tidy-addict sometimes and I enjoy deleting :) A thread on [EMAIL PROTECTED] convinced me that this was half wrong though - we shouldn't be worrying about cleaning up the large list of inactive committers, they might come back and that would be great. However I do still think we should be cleaning up the inactive PMC members. The PMC represents the active committers entrusted with oversight - so to have inactive committers on there is a detriment to its ability to get the job done. 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? Yea, why over complicate this? Simply email the inactive PMC's known email addresses explaining they have been inactive for an extended period of time and whether or not they have a problem being de-PMC-ified. Try to contact them three times at two week intervals and keep track of this either in svn or a bugzilla issue. After two months of no response let other PMCs vote on the issue. See Danny's email on us being lazy :) I can definitely do this - just trying to avoid that much work and spam to the mail lists as I think I would need to cc pmc@ or general@ on each email - though I could do one big cc: email each week interval. If consensus prefers this, I'll definitely work at finding time to go ahead and do it. In my mind it is the right thing to do regardless of general consensus. If you are going to strip someone of their title or responsibilities without previously agreed terms or making an reasonable effort to directly resolve the issue with them, then it's wrong and disrespectful. Introducing a new tasks that only your buddies will likely know about in order to maintain membership feels a bit like when the south (in the USA years ago) introduced literacy tests to keep blacks from voting. It's fine that you have an agenda, but be straight forward and honest about it. And don't make people jump through hoops so their possibly conflicting positions are still binding. Hope I'm not coming across like this. My buddies in this case are described as: People who read Jakarta mailing lists. Ideally pmc@ and general@, though I can quite happily mail all the -dev lists if we think there are pmc members not listening to the central lists. My example included a little exaggeration to make it more obvious. I don't actually equate being a PMC with what I consider a human rights issue. But yes, it does seem like your avoiding the effort required to do the right thing and in the process it comes off a little underhanded. My agenda is to make things less messy. Am working hard to avoid taking the direction of introducing small changes to lead the community in a direction. That'd be the dishonest bit. I guess this does have some link to my agenda to enforce the single Jakarta community meme I generally don't have a problem with administrative goals, I'm mostly indifferent to all of them. I care about the code, the end user's experience, and my user experience. I will say I think ratio of administrivia emails and commit log emails is out of balance. Administrative tasks are important but not so much to justify a bureaucracy and kill productivity. - but even in the multi-community meme, there'd be no excuse for pmc members not being on general@ and [EMAIL PROTECTED] A pmc member who is not on pmc@ (and doesn't want to subscribe) has effectively resigned in my view; pretty much the same for [EMAIL PROTECTED] I can agree with that but unless that is made clear when someone is made a PMC. I'm not a PMC so I don't know. If the duties and expectations of a PMC don't include being responsive on a mailing list then changing the rules without their consent isn't right. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Cleanup pmc members
On 3/17/06, Noel J. Bergman [EMAIL PROTECTED] wrote: 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. Why not just send out e-mail to the PMC members asking them if they want to remain active? I dunno, I'm suggesting the same thing but I guess that is too simple of a solution. On 3/17/06, Henri Yandell [EMAIL PROTECTED] wrote: The biggest problem I have with it is that it forces me to come up with a list of people to exclude - that's the one that feels wrong to me. If you want, I'll come up with a list, starting with http://jakarta.apache.org/site/whoweare.html , and make an effort to contact them and report back after a while and it will feel right to me. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)
On 3/14/06, Thomas Dudziak [EMAIL PROTECTED] wrote: On 3/14/06, Simon Kitching [EMAIL PROTECTED] wrote: I was just considering proposing exactly this! The issues about groupings, subprojects, etc. are completely irrelevant it seems to me. A community is the set of people subscribed to emails about a particular project, no more and no less. Unfortunately the way email lists are currently run at apache forces a strict hierarchy onto community structure, and forces a choice between coarse-grained and fine-grained style communities (eg one commons list vs one-per-project). PMCs are structured hierarchically, and that is reasonable, but communities don't need to be this way. The perfect system, to me, would be a website that allows a user to register a username/email-address; the process would confirm that the user's email address is valid. A set of checkboxes would allow a user to subscribe to various lists, or to virtual groupings such as jakarta commons which would implicitly subscribe to the list for every project that is tagged as being a jakarta-commons project. Of course this implies fine-grained email lists (ie one for each project); the problems of partitioning the subscriber base too much is avoided by the existence of the groupings. This system would allow overlapping groups to occur; for example commons-digester can be filed under both commons and xml virtual groups; someone subscribing to *either* group would receive digester-related emails. It also allows projects to move from one PMC to another without destroying the existing community (which *is* the set of people receiving emails). Groups also allow new projects to be created and added to the group; all people subscribed to the group would then automatically get emails related to that new project. Any list which has less than 3 subscribers would automatically forward its emails to the PMC list (or similar) for purposes of oversight. Any person subscribed to 3 or more projects associated with commons would automatically be subscribed to the whole commons group (or maybe just sent a weekly nag email recommending they do so). That hopefully allows casual commons developers to get just postings for one or two projects, without destroying the useful commons-wide community that exists now. Having a single point for managing subscriptions would also help greatly with something that regularly frustrates me: suspending subscription when I'm away on holiday. Currently, I need to unsubscribe to half-a-dozen lists then resubscribe on return. This sort of functionality probably already exists in one of the open-source mailing list management packages; it isn't anything radical as far as I can see. Perhaps a forum frontend would be even better for users, at least for non-power-users. For instance, from what Patrick Lightbody told me about OpenQA, they have a system that is both a forum and a mailing list: any forum entry gets posted to the list, and any mail posted to the list appears in the forum (e.g. see the Selenium forum at http://forums.openqa.org/forum.jspa?forumID=3). I haven't used it myself yet, but I could ask him if there is interest in the technical details. That is a good idea. Forums don't work for extended team communication like mailing lists do. Mailing list don't work well for transient participants who only want to ask one question and then move on. You used to see this type of setup with mailing lists and news groups but news groups are all but dead to younger generations these days. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
adding a link from commons.apache.org to Jakarta Commons?
I know Jakarta Commons isn't a TLP but considering the commons.apache.org space is vacant how about addins a blurb about the Jakarta Commons. It's the convention that you use your domain as your package. The Jakarta Commons code is in the package org.apache.commons, not org.apache.jakarta.commons. Also a number of times I've seen s stack trace and simply reveresed the package name parts and pasted it into a browser in an attempt to find out more about the code. I'm thinking a blurb at the bottom to the effect of: hr/ If you came here looking for Java code in the org.apache.commons packages then go see the a href=http://jakarta.apache.org/commons/;Apache Jakarta Commons/a page. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r383773 - /jakarta/site/xdocs/site/whoweare.xml
On 3/7/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: sandymac Date: Mon Mar 6 20:30:58 2006 New Revision: 383773 URL: http://svn.apache.org/viewcvs?rev=383773view=rev Log: Added myself, Sandy McArthur, to whoweare.xml Modified: jakarta/site/xdocs/site/whoweare.xml snip/ Hi Sandy, Welcome to Jakarta ;-) This won't actually do anything to the site unless you: a) build the site (I think you'll need JDK1.5 to avoid copious whitespace/attribute rearrangement diffs) b) svn ci the matching whoweare.html in docs/ c) svn up /www/jakarta.apache.org/ Done. thanks for the directions. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
On 3/6/06, Martin Cooper [EMAIL PROTECTED] wrote: On 3/6/06, Rahul Akolkar [EMAIL PROTECTED] wrote: * FileUpload (active, martinc should confirm interest in moving to JWC) I'm not so sure about this. FileUpload has already cloned some code from HttpClient, and could undoubtedly make use of more. Its purpose is to parse HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP Components, assuming that HttpClient eventually morphs into that. (I thought it had already, but I can't seem to find a JHC anywhere.) As a programmer looking for useful code to help me with uploaded files, I'm going to look in something named Jakarta *Web* Components first. When I see Jakarta HTTP Components I think of interacting with the HTTP protocol. I know FileUpload does both, but when I'm writing an webapp I think I'm working with a *web* app first and while I am working with HTTP it is a secondary concern. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components + Jakarta HttpComponents
On 3/6/06, Nathan Bubna [EMAIL PROTECTED] wrote: On 3/6/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: May I, however, express my (humble) opinion that some of the Commons [FileUpload] code may find a better home in Commons [Codec]. To me, all the mime/multipart parsing logic clearly belongs to [Codec]. There are plans to factor out all multipart encoding code from Commons [HttpClient] and move it to Commons [Codec] This said, Commons [FileUpload] is welcome to consider joining JHC i wondered if we wouldn't see a lot of discussions like this. hard lines have always been hard to draw. is it possible to have multiple associations? some sort of tagging system, with labels instead of folders? It's not important how something is implemented, what is important is what it does. Our end users (programmers) don't care that lib Foo used lib Bar. They just care what it does. When categorizing this stuff pretend you are an end user. A lib's existence is justified by how it helps it's users get work done. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: Active Development Maintenance Mode Unsupported My preference would be: Active Development: not really named though, the implied default Hibernating: not active but will wake up as needed Dormant: no future activity is expected -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: 2) All vote threads to occur on the general@ mailing list; or the pmc@ mailing list if deemed private. I don't like the idea having a lot of discussion on one mailing list and then loosing all that context by having votes on a different mailing. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: Finding a label to match the above messages is tricky; inactive development seems to be the only one that fits. How about a project is in hibernation. In other words no future developement is expected unless the enviroment for that project changes. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/5/06, Martin Cooper [EMAIL PROTECTED] wrote: But why? If I'm a user looking for something to help me out in my development, I don't really care that much if it's active or not. What I care about is if it does the job. If there are problems with it, then I might care about whether it's active or not - or maybe I don't, since it's open source and I could fix the problems myself, if I chose to. The people who care about active versus inactive are those on the PMC, and those are not the people we should be designing the Jakarta front page for. My thoughts exactly. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
