Re: Why use maillists??
A couple of other reasons to supplement Danny's reply: -- Because they're easy to use at one level, and they're the lowest common denominator. Everyone (well, nearly) has an email account, and can read and respond to mailing lists. We have some contributors who still live over part-time dial-up accounts - making browsing fancy web forums a pain. But email's easy to send. -- Because it stores a record of the decisions the community makes. Having this history in archives is invaluable, especially one that doesn't change (like most wiki's do). The best kind of Apache project isn't about the latest code or the coolest programmer - it's about a collaborative community that works together - even when some people leave, there's enough of a community to continue the project. -- Because it's the Apache Way. Not that we have this written down anywhere in an agreed fashion, but both due to tradition, ease of use, and board mandate, mailing lists are the official way to conduct most business on any Apache project (and there are many more besides jakarta). It's not really a technical question - it's more an organizational and community question. 8-) - Shane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Call on Stein to resin
[EMAIL PROTECTED] wrote I will try to make this last message on the topic of ethics, its up to the people sitting on the hands to see this is as a problem and do something. Well, I've been sitting on my hands realy hard trying not to jump in with a witty and sarcastic reply supporting the board@ - in both the technical and ethical realms - and fanning the flames back at Vic, but I guess I've failed. 8- Especially since I haven't thought of anything nearly as funny as the 'switch to Resin' jokes yet. Really, though; please move the discussion to an appropriate forum. [EMAIL PROTECTED] is a good one for general project management stuff (like allegations of legal problems); geronimo-dev@ will actually reach the people working on the project - i.e. ones who will be reviewing the code for this issue; and you should be able to file any official notices to the [EMAIL PROTECTED] list, which is the governing body for the Incubator project itself, and hence the only real authority that matters in an organizational sense at this point (below the board//members). = - Shane eof .sig=http://apachecon.com/ November in Vegas, baby! / - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta member seeking ASF membership
Hmmm. A couple of comments. Have folks here read http://www.apache.org/foundation/bylaws.html yet? If not, you really need to (well, skim it, plus the opening paras on the /foundation/ page). The ASF (Apache Software Foundation) is an 'official' non-profit corporation under Delaware, US laws. It is membership-based, rather than share based, and Members of the ASF are essentially the stockholders of the corporation itself. Membership carries a number of legal responsibilities, along with whatever moral or technical ones that Members feel towards both the ASF itself and towards it's component projects (or subprojects, etc., or bits of code, or communities). You should read on the /foundation/ page why the ASF exists; I can add my 2cents. Legally, it's there so that committers don't get sued; since the ASF owns the code, any suit would be brought against *it* instead (this can be important in the US at least 8-). Organizationally it's there to provide the actively managed framework that holds this all together. In one way, it's the thing that differentiates the ASF from sourceforge: sourceforge may provide plenty of project hosting services, but the ASF also provides a sense of mission, community, and guidelines that help keep it more focused. I believe the very fact that we are more organized (or at least the belief or appearance thereof) is what draws both cool people to contribute here, as well as draws other contributions - like servers, bandwith, and a crack root team who keeps it all running as volunteers. So in my mind membership and committership are different things : members think much more strategically about the whole of the ASF, not just individual bits of code or communities. Some other random notes: -- While the members can and will decide how the ASF runs (it's a legal responsibility to do so), don't worry, we really do care about what the committers think! (Many/most/all?) Members believe that it is the communities of committers (and regular users) that make the ASF strong, and we definitely want to keep them going. -- We all shape the ASF through our contributions. If you care, then read up on the existing topics on reorg or community and respond - we have a lot of people doing that already. Just remember, if you have a great idea and someone takes you up on it, you need to follow through and help out with it - hopefully in an organized fashion. -- There's a lot of stuff that is happening, and plenty more that may happen. Lots of people are trying to all share ideas at the same time. And we're all volunteering here in some way or another, so it's hard to keep up. Unfortunately I've also seen a lot of miscommunication or people responding without really reading the rest of the email chain, which makes for a lot more worries and bad feelings than I think are really due. -- Not being a jakarta 'regular', it's a little difficult to judge the mood here. But I believe that many of the jakartaites who are participating are more worried than they should be. We'll have plenty more discussion before we decide on a way to reorganize how the ASF works (if we even do make changes), and we'll definitely want to keep the jakarta community strong. The central 'Commons' project is *not* a replacement for jakarta-commons; IMO it's quite a different beast (although complimentary); likewise the central 'Inbubator' project should *not* be a replacement for jakarta-commons-sandbox, but again, should be complimentary. And why don't they have much documentation yet? Because people haven't had time to write it up yet! I don't think most things happen in 'secret', it's just that we don't always get around to documenting stuff publicly as soon as we should - since in an all-volunteer organization, it takes longer to do things sometimes. - Shane Disclaimers: ASF Member; xml-xalan, xml-commons committer; IBM Employee; Massachusetts, USA resident; lover of bad puns and cats. = - Shane eof .sig='When I use a word,' Humpty Dumpty said, in a very scornful tone, 'it means just what I choose it to mean - neither more nor less' Oohayu oyod?!=gis. / __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
RE: [IMPORTANT] What actions can the ASF take to enforce
As already noted, several of the FAQ documents include links to copies of the license. Plus the fact that virtually all Apache projects include a LICENSE or the like file in an obvious place inside the project (which you presumably downloaded to see if you wanted to use it) as well as the fact that most of the sources (certainly .java files and many other doc sources as well) include the text of the license inside of them. Also, although you can view a master copy of the Apache Software License, Version 1.1 (http://www.apache.org/LICENSE), you really need to follow the actual license provided with the specific product you're using, since there are currently subtle changes in many of them (mainly the project names) and of course some projects may in the future use newer versions of an Apache license. - Shane (Thanks to the jakartaites who have the nifty 'Website Maintenance' section, which I really like! Sorry if we're a little behind in improving the xml website... 8-) you Henri Yandell [mailto:[EMAIL PROTECTED]] wrote Having decided to licence some code under the Apache licence, and some documentation as well, I headed to the Jakarta front page to find a link to the licence. No dice. Then I tried the main Apache front page, no luck again. Shouldn't these link to the licence? Or the two or three licences in question? I would have thought the link would be quite prominent. The legal section on Jakarta has no reference, and the Press kit section on the main site also has nothing. = - Shane eof aka=mailto:[EMAIL PROTECTED]; .sig=Du sublime au ridicule il n'y a qu'un pas. / __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LICENSE in .jar files
Sorry for my tangent - it's clear that on legal matters, I should just
get the heck outta Dodge and let someone with more patience work on it.
8-{
I've forwarded a link (with threading) to your (Conor's) message to the
xml PMC so they should be aware of this licensing issue with JAXP and xml-commons.
=
- Shane
eof aka=mailto:[EMAIL PROTECTED];
.sig=Du sublime au ridicule il n'y a qu'un pas. /
__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: release signing policy?
Great! I'll keep an eye out so we can propose stealing what you come up with for xml.apache.org as well... 8-) Suggestions/comments/questions: -- Focus on overall how-to steps for the release process and signing 'public' distribution units; I can volunteer to do QA on any instructions you come up with. -- The dev.apache.org stuff is a good start, but very C and Unix-centric. Plus very terse; hopefully over time we can come up with a friendlier version. -- PGP or GPG or either? (I'm pretty sure those are the two real contenders). In theory they're compatible with each other somehow, but I've never been able to get it to work. I prefer PGP since I like having the flashy GUI in 6.x/7.x versions, but I could understand someone philosophically or whatever wanting to use GPG. As long as we provide basic instructions for someone to verify a distro, either should be fine. -- As noted, a release signer's key must be in the KEYS file that was previously checked in and gets stuck inside the distro. We should also suggest that release signers consider posting public keys to well-known keyservers when possible. -- Key management: We hashed this out on general@xml a while back (and I'm sure other places): realistically, I think the only practical thing is to have individual commiters use their own personal keys for signing, and have each project manage their own keys. Given how the ASF works, I don't think we're going to have 'official' ASF master keys anytime soon. If there were a site-wide KEYS file in CVS that projects could *choose* to use instead, that would be fine too. -- Key signing: Since we're having individual committers sign releases, we should encourage folks to sign each other's keys. This way, when a user tries to verify a release versus the .sig, even if they don't know the individual who signed the distro, they might know someone else who signed their key, establishing at least some level of trust. You should remember to allow your signature of someone else's public key to be exportable too. I've tried to cross-sign keys in xml-land; if there are jakartaites who know me, I'd be happy to do the same here. -- Separate out any discussion of signing .jar files. Actually using Java's jar signing abilities is both more complex and has a variety of technical code issues that each project will probably have to consider separately from signing the distros. - Shane you Stefan Bodewig [EMAIL PROTECTED] wrote Ted Husted [EMAIL PROTECTED] wrote: then I was volunteering to draft the general Release HOWTO, and asking if anyone had any existing documentation about this that they wanted to share. I'd start with this one http://dev.apache.org/how-to-release.html. Stefan = eof aka=mailto:[EMAIL PROTECTED]; .sig=2002 The palindromic year 2002/ __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
