Re: Why use maillists??

2004-04-16 Thread Shane Curcuru
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

2003-11-11 Thread Shane Curcuru
 I will try to make this last message on the topic of ethics, its up
 the people sitting on the hands to see this is as a problem and do 

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

- Shane

eof .sig= November in Vegas, baby! /

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jakarta member seeking ASF membership

2002-10-24 Thread Shane Curcuru
Hmmm.  A couple of comments.

Have folks here read 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

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

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

To unsubscribe, e-mail:   mailto:general-unsubscribe;
For additional commands, e-mail: mailto:general-help;

RE: [IMPORTANT] What actions can the ASF take to enforce

2002-05-17 Thread Shane Curcuru

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 (, 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
 documentation as well, I headed to the Jakarta front page to find a
 to the licence. No dice. Then I tried the main Apache front page, no

 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
 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

To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: LICENSE in .jar files

2002-03-20 Thread Shane Curcuru

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.

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®

To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: release signing policy?

2002-01-10 Thread Shane Curcuru

Great!  I'll keep an eye out so we can propose stealing what you come
up with for as well...  8-)

-- 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 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
  wanted to share. 

 I'd start with this one

eof aka=mailto:[EMAIL PROTECTED];
 .sig=2002 The palindromic year 2002/

Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!

To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]