[Fwd: Re: Making Daffodil Replicator an Open Source : Suggestion]

[Simon Kitching]

[resent from apache.org address]
-Forwarded Message-
> From: Simon Kitching <[EMAIL PROTECTED]>
> To: community@apache.org
> Cc: general@incubator.apache.org, general@jakarta.apache.org, 
> general@db.apache.org
> Subject: Re: Making Daffodil Replicator an Open Source : Suggestion
> Date: Sat, 07 Aug 2004 13:10:17 +1200
> 
> On Sat, 2004-08-07 at 05:20, Nicola Ken Barozzi wrote:
> > Ashish Srivastava wrote:
> > > Hi,
> > > 
> > > We are a product based company named Daffodil Software Ltd, based in
> > > India. We have developed many good products using JAVA out of which our
> > > two premium product Daffodil DB (an RDBMS) and Daffodil Replicator
> > > (database utility software) is largely accepted by world software
> > > community.
> > > 
> > > We are planning to make our Daffodil Replicator an open source project.
> > > 
> > > How can we make it with www.apache.org please let us know how we have to
> > > proceed.
> > > 
> > > I visited at http://incubator.apache.org but unable to find the answer
> > > how to proceed in order to make our product open source. 
> > 
> > I'm cross-posting to lists where there might be interest in helping you 
> > out on this.
> > 
> > > www.daffodildb.com
> 
> Hi Ashish,
> 
> The following is just my personal opinion, as a member of the ASF
> (Apache Software Foundation); I am not speaking on behalf of the ASF.
> 
> I think it is great that you are considering releasing some of your code
> under an open-source licence. I am sure there are a number of people
> that are willing to offer advice on the process of releasing your code
> as open-source. And if you do this, you are certainly welcome to reuse
> the Apache Public License legal document as the base for the license
> terms you release your code under; the ASF and its legal advisors
> deliberately designed the license in a way that makes it easy for
> non-ASF-hosted projects to use.
> 
> However if you are suggesting that the code you release may be hosted
> and maintained by the Apache Software Foundation, I personally think
> this is unlikely to happen.
> 
> Firstly, the code you are considering releasing under an open-source
> licence is an add-on to a proprietory product. The ASF is unlikely to
> consider adopting that kind of project. This doesn't mean that making
> the code open-source is a bad idea, it's just something that the ASF
> usually avoids being involved with.
> 
> Secondly when the ASF adopts existing code, the provider of the code is
> expected to show evidence that there is a group of developers willing to
> continue maintenance and development of the code in the future. Apache
> doesn't want to end up hosting lots of code with no associated
> developers. Given that the code you are considering releasing can only
> be used with a proprietory database which does not have a large market
> share, I think this will be a difficult thing for the Daffodil
> Replicator project to demonstrate.
> 
> If your replicator tool can actually replicate data for multiple
> different brands of database then please let us know; that would make
> the project much more interesting, and therefore more likely to obtain
> an adequate pool of developers. In particular, if it could be used with
> the IBM "CloudScape" product which has recently been offered by IBM and
> accepted by the ASF (and to be renamed "Derby" I believe), there could
> be significant interest. The result could well be an improved replicator
> for both Derby and Daffodil - but only if the architecture of your
> current code is not too tightly bound to the Daffodil database.
> 
> If you are interested in discussing this further, then please describe
> what Daffodil Software expects to gain by outsourcing this software.
> There are a number of different open-source licences available, and
> which one is appropriate depends upon the business strategy of Daffodil.
> The ASF always uses the apache license, which is a "BSD-like" license,
> but there are many successful open-source projects that use a different
> approach. You may wish to investigate MySQL and JBoss as alternative
> business models.
> 
> As I am sure you are aware, the ASF is not the only way to make code
> open-source. You can always host the source code and associated
> development framework (newsgroups, email lists, etc) on your own site,
> or use the SourceForge site. If you let us know a little more about the
> business goals of Daffodil Software we may be able to offer better
> advice.
> 
> Disclaime

Re: Making Daffodil Replicator an Open Source : Suggestion

[Nicola Ken Barozzi]

Ashish Srivastava wrote:
Hi,
We are a product based company named Daffodil Software Ltd, based in
India. We have developed many good products using JAVA out of which our
two premium product Daffodil DB (an RDBMS) and Daffodil Replicator
(database utility software) is largely accepted by world software
community.
We are planning to make our Daffodil Replicator an open source project.
How can we make it with www.apache.org please let us know how we have to
proceed.
I visited at http://incubator.apache.org but unable to find the answer
how to proceed in order to make our product open source. 
I'm cross-posting to lists where there might be interest in helping you 
out on this.

www.daffodildb.com
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Suggestion...

[Nicola Ken Barozzi]

Noel J. Bergman wrote, On 13/02/2003 21.14:
...
Pulling together all of the Committer information that already exists
*somewhere* on the ASF sites would be a major start.  And once that is all
finished, it will be easier to see more of what is missing.
This is the conclusion we can to @ incubator. First, let's have in the 
incubator pages with all the links to the resources on Apache sites. 
then let's make a common document and ask those projects to review it 
and eventually switch to linking that. One by one. Step by step. :-)

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Suggestion...

[Noel J. Bergman]

> Agreed to a point. We don't have the tools that readily available
though...

What tools are you lacking?  You check out the module, you edit the
contents, you submit patches via e-mail.  If you want collaborative editing,
you use the Wiki to construct the content before [HTML|XML]-izing it.

> > The information exists.  The real problem is that different
> > projects have been providing different bits and pieces of it,
> > if at all:

> >  http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases
> >  http://www.apache.org.dev
> >  http://cvs.apache.org/~bodewig/mirror.html
> >  http://jakarta.apache.org/site/guidelines.html
> >  http://xml.apache.org/guidelines.html
> >  http://httpd.apache.org/dev/

> What a mess..

Well, yes.  :-)

This particular subject of educating new Committers has come up multiple
times over the past months.  I don't see it covering any new ground so far.
Someone just needs to actually DO something about the collection and
collation process, and submit patches to infrastructure for the site module
(you have karma, yourself), as well as resolve any issues with the other
project's related to centralized content.  Have you seen Leo Simons' work,
yet?

> IMHO we need to do a bit more than that! Really if that's all you think is
> needed then our opinions differ by a larger margin that I thought they
did.

Pulling together all of the Committer information that already exists
*somewhere* on the ASF sites would be a major start.  And once that is all
finished, it will be easier to see more of what is missing.  So far very
little is written in the way of a step-by-step guide.  The release signing
instructions, for example, could use an actual example, perhaps some shell
scripts.  I might provide those, since I had to do them for myself.  But it
also sounds as if you have a broader agenda in mind.

--- Noel


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

Re: Suggestion...

[David Reid]

> > Community should be responsible for the pages and the content of the
> email.
>
> > Infrastructure are responsible for providing us with the tools to allow
> them
> > to be created/maintained etc.
>
> Those tools already exist.  After being prepared, patches would be
submitted
> against the site module, and sent to infrastructure for appplication.
Based
> upon some of the comments you've just made elsewhere, we agree that the
> point is not to burden the infrastructure team more than necessary.

Agreed to a point. We don't have the tools that readily available though...

> > As we're still trying to get to the first stone let's be patient and not
> try
> > to leap the river in one jump!
>
> I don't understand this perspective.  The information exists.  The real
> problem is that different projects have been providing different bits and
> pieces of it, if at all:
>
>  http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases
>  http://www.apache.org.dev
>  http://cvs.apache.org/~bodewig/mirror.html
>  http://jakarta.apache.org/site/guidelines.html
>  http://xml.apache.org/guidelines.html
>  http://httpd.apache.org/dev/

What a mess...

> And those are just a few.  That doesn't count the document Leo Simons is
> working on, and submitted.
>
> There is a great value in this effort, but it isn't a matter of developing
> new information or new tools so much as a matter of collecting and
collating
> the information, providing a central location, and coordinating getting
all
> of the projects using it.

IMHO we need to do a bit more than that! Really if that's all you think is
needed then our opinions differ by a larger margin that I thought they did.

david


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

RE: Suggestion...

[Noel J. Bergman]

> Community should be responsible for the pages and the content of the
email.

> Infrastructure are responsible for providing us with the tools to allow
them
> to be created/maintained etc.

Those tools already exist.  After being prepared, patches would be submitted
against the site module, and sent to infrastructure for appplication.  Based
upon some of the comments you've just made elsewhere, we agree that the
point is not to burden the infrastructure team more than necessary.

> As we're still trying to get to the first stone let's be patient and not
try
> to leap the river in one jump!

I don't understand this perspective.  The information exists.  The real
problem is that different projects have been providing different bits and
pieces of it, if at all:

 http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases
 http://www.apache.org.dev
 http://cvs.apache.org/~bodewig/mirror.html
 http://jakarta.apache.org/site/guidelines.html
 http://xml.apache.org/guidelines.html
 http://httpd.apache.org/dev/

And those are just a few.  That doesn't count the document Leo Simons is
working on, and submitted.

There is a great value in this effort, but it isn't a matter of developing
new information or new tools so much as a matter of collecting and collating
the information, providing a central location, and coordinating getting all
of the projects using it.

--- Noel


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

RE: Suggestion...

[Noel J. Bergman]

> It thought it was a bit unhandy to dump part of the
> documentation on the Incubator site and part on www.apache.org/dev/.

Agreed.  One or the other should be the repository for such content.  The
point is to make it all available in a central place, not scattered like
chicken feed across the yard.  At least a master TOC, if not a common
repository for the information.

--- Noel


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

RE: Suggestion...

[Sander Striker]

> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 13, 2003 7:33 PM

> --On Thursday, February 13, 2003 1:12 PM -0500 "Noel J. Bergman" 
> <[EMAIL PROTECTED]> wrote:
> 
> > enough to do with keeping the plant running.  The documents should
> > live in either Incubator (to be provided to PMCs), or on the main
> > apache site.
> 
> The Incubator PMC has refused to add committer docs to their site,

Err, no, it didn't.  It thought it was a bit unhandy to dump part
of the documentation on the Incubator site and part on www.apache.org/dev/.


Sander


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

RE: Suggestion...

[Justin Erenkrantz]

--On Thursday, February 13, 2003 1:12 PM -0500 "Noel J. Bergman" 
<[EMAIL PROTECTED]> wrote:

enough to do with keeping the plant running.  The documents should
live in either Incubator (to be provided to PMCs), or on the main
apache site.
The Incubator PMC has refused to add committer docs to their site, so 
any email content should be replicated on www.apache.org/dev/ space. 
Hopefully, an email template should be on the site as well.  This 
wouldn't require much oversight and infrastructure@ is responsible 
for the www.apache.org space anyway.  -- justin

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

Re: Suggestion...

[David Reid]

Have I suggested that infrastructure be involved in writing/maintaining the
web pages?

I agree with what you say and have stated that web pages are a good idea,
but I also know that when a person gets commit and gets emails from the ASF
they read them! It's a one off thing and I think that it's something we
should be doing - in fact something we should have been doing for a long
time now. Belt & braces generally work better than either in isolation.

Community should be responsible for the pages and the content of the email.
Infrastructure are responsible for providing us with the tools to allow them
to be created/maintained etc. That's a different discussion and one we will
have, but all these things require a stepping stone approach.

As we're still trying to get to the first stone let's be patient and not try
to leap the river in one jump! I don't want to get wet at present.

david

> Actually, when I get a lengthy e-mail, the last thing I want to do is read
> it.  I get enough of those, and they are likely to be shelved for when I
> have time to deal with it.  Sometime between now and when hell freezes
over.
> You want a response to your e-mail?  Keep the scroll bars deactivated.
>
> A nicely formatted page with a TOC that tells me what I can learn from it,
> that I can add to Favorites, and refer to when needed; that's useful.
>
> Also, a web page can be corrected.  The first set of instructions on the
web
> page for how to setup CVS with ssh were wrong.  They were corrected after
a
> new Committer went through them, found that they were wrong, found what
> worked, and reported the problem.
>
> By the way, this does not strike me as an infrastructure problem, so much
as
> an ASF Community thing.  The infrastructure guys have enough to do with
> keeping the plant running.  The documents should live in either Incubator
> (to be provided to PMCs), or on the main apache site.
>
> --- Noel
>
> -Original Message-
> From: David Reid [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 13, 2003 5:35
> To: community@apache.org
> Subject: Re: Suggestion...
>
>
> I have a lot of sympathy with that view, and it should probably be on a
web
> page somewhere as well, but in all honesty getting an email with
> instructions makes it much easier than simply telling people to visit a
web
> page. While we'd all like to think people would follow the link to the
page
> I think deep down we all know that not everyone will. Not everyone will
read
> an email either but I think we'd get a better response with an email.
>
> The belt & braces approach is always good.
>
> As I've not heard any objections I'll send an email to infrastructure.
>
> david
>
> > David,
> >
> > I agree that there should be an e-mail.  But it should be short, and
> consist
> > of little more than a reference to the web site.  All of this
information
> > should be available on the web site for review and update.  As that
> content
> > is enhanced, e-mail can go out to [EMAIL PROTECTED]
> >
> > > - forwarding instructions for the @apache.org email address
> > > - contacts for common problems
> > > - information about the committers list and the reason for it
> > > - information on opt-in lists such as licensing, community
> >
> > Also explain public_html, umask 002, using ssh with keys, pgp/gnupg,
> source
> > control, mirroring,  and every other process issue that a Committer
might
> > need to know during the course of their duties.
> >
> > --- Noel


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

RE: Suggestion...

[Noel J. Bergman]

> True. I often pull new e-mail over to my notebook and read it on the
train.
> Not only that I won't follow links, I simply can't.

Have you tried marking pages for offline reading?

--- Noel


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

RE: Suggestion...

[Noel J. Bergman]

David,

Actually, when I get a lengthy e-mail, the last thing I want to do is read
it.  I get enough of those, and they are likely to be shelved for when I
have time to deal with it.  Sometime between now and when hell freezes over.
You want a response to your e-mail?  Keep the scroll bars deactivated.

A nicely formatted page with a TOC that tells me what I can learn from it,
that I can add to Favorites, and refer to when needed; that's useful.

Also, a web page can be corrected.  The first set of instructions on the web
page for how to setup CVS with ssh were wrong.  They were corrected after a
new Committer went through them, found that they were wrong, found what
worked, and reported the problem.

By the way, this does not strike me as an infrastructure problem, so much as
an ASF Community thing.  The infrastructure guys have enough to do with
keeping the plant running.  The documents should live in either Incubator
(to be provided to PMCs), or on the main apache site.

--- Noel

-Original Message-
From: David Reid [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 13, 2003 5:35
To: community@apache.org
Subject: Re: Suggestion...


I have a lot of sympathy with that view, and it should probably be on a web
page somewhere as well, but in all honesty getting an email with
instructions makes it much easier than simply telling people to visit a web
page. While we'd all like to think people would follow the link to the page
I think deep down we all know that not everyone will. Not everyone will read
an email either but I think we'd get a better response with an email.

The belt & braces approach is always good.

As I've not heard any objections I'll send an email to infrastructure.

david

> David,
>
> I agree that there should be an e-mail.  But it should be short, and
consist
> of little more than a reference to the web site.  All of this information
> should be available on the web site for review and update.  As that
content
> is enhanced, e-mail can go out to [EMAIL PROTECTED]
>
> > - forwarding instructions for the @apache.org email address
> > - contacts for common problems
> > - information about the committers list and the reason for it
> > - information on opt-in lists such as licensing, community
>
> Also explain public_html, umask 002, using ssh with keys, pgp/gnupg,
source
> control, mirroring,  and every other process issue that a Committer might
> need to know during the course of their duties.
>
> --- Noel
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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


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

Re: Suggestion...

[David Reid]

> > Perhaps, but I think we should make sure the "web page somewhere" part
> > doesn't get lost here.  Read or not, the email will get deleted or lost
> > along the way.  The web page provides a persistent location for this
> > information for new and old committers alike.
> >
> >
>
> Anakia (jakarta-site2), or forrest, I think can use the same xdoc/source
> document to generate the web page and the email text, thus making a well
> managed source somewhere be the source of the *one time* mail and the
> reference web page.

See there we go again, retreating into our own little worlds :)

The sort of information you refer to should be simple and should just be
kept/updated/maintained once as it's essentially the same for every
committer. That's what this email and the proposal I sent to infrastructure
is meant to address. We need to stop thinking in terms of "this project has
this" and start thinking in terms of "why doesn't the asf have this". I know
it's a small change, but it's an important one if the community feelings we
want to grow are ever going to have a chance.

Also, we're taling about some simple stuff here, nothing that needs huge
amounts of technology to get it running. Last time I looked email was still
just simple, plain old text...

david



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

Re: Suggestion...

[Santiago Gala]

Rodney Waldhoff wrote:
(...)
Perhaps, but I think we should make sure the "web page somewhere" part
doesn't get lost here.  Read or not, the email will get deleted or lost
along the way.  The web page provides a persistent location for this
information for new and old committers alike.

Anakia (jakarta-site2), or forrest, I think can use the same xdoc/source 
document to generate the web page and the email text, thus making a well 
managed source somewhere be the source of the *one time* mail and the 
reference web page.

I'm not sure about how httpd or perl web site is generated, but I 
imagine that they will use a similar approach.

As I've not heard any objections I'll send an email to infrastructure.

Not from em.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Suggestion...

[Rodney Waldhoff]

On Thu, 13 Feb 2003, David Reid wrote:

> I have a lot of sympathy with that view, and it should probably be on a web
> page somewhere as well, but in all honesty getting an email with
> instructions makes it much easier than simply telling people to visit a web
> page. While we'd all like to think people would follow the link to the page
> I think deep down we all know that not everyone will. Not everyone will read
> an email either but I think we'd get a better response with an email.
>

Perhaps, but I think we should make sure the "web page somewhere" part
doesn't get lost here.  Read or not, the email will get deleted or lost
along the way.  The web page provides a persistent location for this
information for new and old committers alike.

> As I've not heard any objections I'll send an email to infrastructure.

Great idea, by the way.

 - Rod

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

Re: Suggestion...

[Rainer Klute]

> I have a lot of sympathy with that view, and it should probably be on a
> web
> page somewhere as well, but in all honesty getting an email with
> instructions makes it much easier than simply telling people to visit a
> web
> page. While we'd all like to think people would follow the link to the
> page
> I think deep down we all know that not everyone will.

True. I often pull new e-mail over to my notebook and read it on the train.
Not only that I won't follow links, I simply can't. And no, I won't spend
money on a mobile connection.

Best regards
Rainer Klute

-- 
   RAINER KLUTE IT-CONSULTING
  Dipl.-Inform.
  Rainer Klute [EMAIL PROTECTED]
  Körner Grund 24  Telefon: +49 172 2324824
D-44143 Dortmund   Telefax: +49 231 5349423

+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!


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

Re: Suggestion...

[David Reid]

I have a lot of sympathy with that view, and it should probably be on a web
page somewhere as well, but in all honesty getting an email with
instructions makes it much easier than simply telling people to visit a web
page. While we'd all like to think people would follow the link to the page
I think deep down we all know that not everyone will. Not everyone will read
an email either but I think we'd get a better response with an email.

The belt & braces approach is always good.

As I've not heard any objections I'll send an email to infrastructure.

david

> David,
>
> I agree that there should be an e-mail.  But it should be short, and
consist
> of little more than a reference to the web site.  All of this information
> should be available on the web site for review and update.  As that
content
> is enhanced, e-mail can go out to [EMAIL PROTECTED]
>
> > - forwarding instructions for the @apache.org email address
> > - contacts for common problems
> > - information about the committers list and the reason for it
> > - information on opt-in lists such as licensing, community
>
> Also explain public_html, umask 002, using ssh with keys, pgp/gnupg,
source
> control, mirroring,  and every other process issue that a Committer might
> need to know during the course of their duties.
>
> --- Noel
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

RE: Suggestion...

[Noel J. Bergman]

> There are clear instructions in the jakarta web site on how to handle
> cvs through ssh ...

This sort of information is scattered across the *.apache.org sites.  There
are also instructions for doing it at
http://www.apache.org/dev/committers.html#general.  Oddly there is a
separate section on CVS, and I would expect that question to be moved to the
CVS section.  Then we have http://jakarta.apache.org/site/newbie.html.  All
of this sort of information should to be centralized, IMO.  Only things that
differ with a project should be located there.

> Also, instructions to setup a ssh key and nuke your cvs.apache.org
> password, or even to send the public key in advance, would be great.

Again, there actually is a document tells you to send in your public key in
advance; see: http://jakarta.apache.org/site/roles.html.  HOWEVER, again,
this is only on one project's site, instead of global.  And Brian would ask
that you do *not* "nuke" your password.

--- Noel


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

Re: Suggestion...

[Leo Simons]

Noel J. Bergman wrote:
David,
I agree that there should be an e-mail.  But it should be short, and consist
of little more than a reference to the web site.  All of this information
should be available on the web site for review and update.  As that content
is enhanced, e-mail can go out to [EMAIL PROTECTED]
agreed.
http://www.apache.org/dev/
is a good place for all this information. It needs some work, and more 
exposure among existing committers.

cheers!
- Leo

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

RE: Suggestion...

[Noel J. Bergman]

David,

I agree that there should be an e-mail.  But it should be short, and consist
of little more than a reference to the web site.  All of this information
should be available on the web site for review and update.  As that content
is enhanced, e-mail can go out to [EMAIL PROTECTED]

> - forwarding instructions for the @apache.org email address
> - contacts for common problems
> - information about the committers list and the reason for it
> - information on opt-in lists such as licensing, community

Also explain public_html, umask 002, using ssh with keys, pgp/gnupg, source
control, mirroring,  and every other process issue that a Committer might
need to know during the course of their duties.

--- Noel


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

Re: Suggestion...

[Aaron Bannert]

On Wednesday, February 12, 2003, at 02:12  PM, David Reid wrote:
an email that is automatically sent to new committers outlining the 
"extra"
things that becoming a committer on an ASF project bring with them. 
The aim
is to provide a sort of "Welcome to the ASF community" note.
I wonder if something like this would find a better 
volunteer-to-subscriber
ratio as part of the incubator project?

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

RE: Suggestion...

[O'brien, Tim]

> I think it could/should contain things like
> - forwarding instructions for the @apache.org email address
> - contacts for common problems
> - information about the committers list and the reason for it
> - information on opt-in lists such as licensing, community

- A pointer towards instructions for putting yourself on the map - (point to
a URL with an ICBM tag, etc..)

- Instructions for setting up your http://cvs.apache.org/~login page, and
what that page should be used for.



> If there are other things (and I'm sure there are) that 
> people would have found useful or think should be included 
> please post with details.


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

Re: Suggestion...

[Santiago Gala]

David Reid wrote:
(...)
I think it could/should contain things like
- forwarding instructions for the @apache.org email address
- contacts for common problems
- information about the committers list and the reason for it
- information on opt-in lists such as licensing, community
If there are other things (and I'm sure there are) that people would have
found useful or think should be included please post with details.
There are clear instructions in the jakarta web site on how to handle 
cvs through ssh, but (at least for people not familiar with this setup, 
as I was then) it would be nice to point to the page from the email. I 
thought that my public repository would magically become r/w at first :-)

Also, instructions to setup a ssh key and nuke your cvs.apache.org 
password, or even to send the public key in advance, would be great. I 
mean, there is windows people who has never seen ssh or any other 
RSA/DSA tool.

(...)
Regards,
 Santiago
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Suggestion...

[David Reid]

It was pointed out to me in a private email that one thing we don't do very
well is advertise the existence of things like this list to new committers!
We should change this at once :)

I'm not in favour of proposals being posted to this list, so please don't
vote on this!
- If you have nothing to say except +1 then say nothing!
- If you object then state your reasons...
- If you wish to add something useful then post!
Voting is for projects - not communities! (or xmas!)

Basically I'm planning on proposing to the infrastructure list that we have
an email that is automatically sent to new committers outlining the "extra"
things that becoming a committer on an ASF project bring with them. The aim
is to provide a sort of "Welcome to the ASF community" note.

I think it could/should contain things like
- forwarding instructions for the @apache.org email address
- contacts for common problems
- information about the committers list and the reason for it
- information on opt-in lists such as licensing, community
If there are other things (and I'm sure there are) that people would have
found useful or think should be included please post with details.

NB this isn't a replacement to the "Welcome to
[jakarta/httpd/avalon/whatever project]" email but rather an additional
email that acts as a welcome to the greater community that is the ASF.

I'm starting this thread to ensure that it's not something that is going to
cause confusion as once in place it should really be alluded to in every
projects individual welcome email (to avoid confusion).

The exact contents of the email can be worked out once we have agreement
from infrastructure that we can do this (they need to agree as they setup
and manage the accounts and it'll something else for them to do), and I
think this list is a perfect place to hash the wordy stuff out...

david


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

Re: suggestion for news...

[Andrew C. Oliver]

So, are you saying the boring repetitive 'news' from Commons is the
problem? Or just the acronym?
I'm all for adding a line to Commons releases which say what the project
is actually for :)
 

make the news explain what the significance of the release is and what 
the heck CLI is.  The news blurb should kinda be for people who aren't 
yet involved in CLI...  Not for people who already are  (as they 
probably know already ;-) )... just my opininon..

I do not regard Commons as a problem.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: suggestion for news...

[Henri Yandell]

On Sat, 16 Nov 2002, Andrew C. Oliver wrote:

> Not meaning to embarrass anyone, but I suggest not writing "news" on any
> "news" pages like this:
>
> http://jakarta.apache.org/site/news.html#1106.1
>
> The Commons CLI team is proud to announce Commons CLI 1.0, the first
> official release of this Commons component. Binary and source
> distributions are available here
> .
> More information about Commons CLI can be found on the project home page
> .
>
> The reason being is that its mirrored and carried throughout.  Reading
> thiswhat is the Commons CLI?  Why do I care it has a new
> release...what is in the new release (okay its 1.0 so maybe thats
> okay)..  CLI makes me think of Common Language Interface.  Sure there
> are links but it might be just what someone who gets it in syndication
> needs, but they won't know based on this blurb and they'll rpobably miss it.

So, are you saying the boring repetitive 'news' from Commons is the
problem? Or just the acronym?

I'm all for adding a line to Commons releases which say what the project
is actually for :)

Hen

Re: suggestion for news...

[Joe Schaefer]

"Andrew C. Oliver" <[EMAIL PROTECTED]> writes:

> Not meaning to embarrass anyone, but I suggest not writing "news" on
> any "news" pages like this:
> 
> http://jakarta.apache.org/site/news.html#1106.1
> 
> The Commons CLI team is proud to announce Commons CLI 1.0, the first 
> official release of this Commons component. Binary and source 
> distributions are available here 
> <http://jakarta.apache.org/builds/jakarta-commons/release/commons-cli/v1.0/>. 
> More information about Commons CLI can be found on the project home page 
> <http://jakarta.apache.org/commons/cli/>.
> 
> The reason being is that its mirrored and carried throughout.  Reading 
> thiswhat is the Commons CLI?  Why do I care it has a new 
> release...what is in the new release (okay its 1.0 so maybe thats 
> okay)..  CLI makes me think of Common Language Interface.  Sure there 
> are links but it might be just what someone who gets it in syndication 
> needs, but they won't know based on this blurb and they'll rpobably miss it.
> 
> Just a suggestion talk amongst yourselves...

That's not a suggestion, it's a subjunctive rant.  How should 
the announcement read?  Also, what is the relevance of this issue
to [EMAIL PROTECTED]

-- 
Joe Schaefer

suggestion for news...

[Andrew C. Oliver]

Not meaning to embarrass anyone, but I suggest not writing "news" on any 
"news" pages like this:

http://jakarta.apache.org/site/news.html#1106.1
The Commons CLI team is proud to announce Commons CLI 1.0, the first 
official release of this Commons component. Binary and source 
distributions are available here 
<http://jakarta.apache.org/builds/jakarta-commons/release/commons-cli/v1.0/>. 
More information about Commons CLI can be found on the project home page 
<http://jakarta.apache.org/commons/cli/>.

The reason being is that its mirrored and carried throughout.  Reading 
thiswhat is the Commons CLI?  Why do I care it has a new 
release...what is in the new release (okay its 1.0 so maybe thats 
okay)..  CLI makes me think of Common Language Interface.  Sure there 
are links but it might be just what someone who gets it in syndication 
needs, but they won't know based on this blurb and they'll rpobably miss it.

Just a suggestion talk amongst yourselves...