Re: [site] killing vendors page

2005-02-23 Thread robert burrell donkin
On Mon, 2005-02-21 at 19:20, Erik Hatcher wrote:
> On Feb 21, 2005, at 10:54 AM, Noel J. Bergman wrote:
> 
> > I'd suggest that we talk to the PRC about it.  There are some good 
> > things
> > about a vendors page.  

+1

anyone volunteer?

> Erik makes an interesting point about the Wiki, 
> > but
> > it would mean that we couldn't vet it for content to prevent grossly
> > misleading content.
> 
> Lucene has a page like this here:
> 
>   http://wiki.apache.org/jakarta-lucene/Support
> 
> All wiki changes are sent to an e-mail list for this very reason 
> though, so that the community can vet it.  If someone posted misleading 
> content, I'm sure many would take action to correct it almost 
> immediately.

a vendor list is only as good as the company it keeps. i suspect that
vendors would have a vested interest to keep it up to date.

- robert


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



Re: [site] killing vendors page

2005-02-21 Thread Erik Hatcher
On Feb 21, 2005, at 10:54 AM, Noel J. Bergman wrote:
I'd suggest that we talk to the PRC about it.  There are some good 
things
about a vendors page.  Erik makes an interesting point about the Wiki, 
but
it would mean that we couldn't vet it for content to prevent grossly
misleading content.
Lucene has a page like this here:
http://wiki.apache.org/jakarta-lucene/Support
All wiki changes are sent to an e-mail list for this very reason 
though, so that the community can vet it.  If someone posted misleading 
content, I'm sure many would take action to correct it almost 
immediately.

Erik

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


RE: [site] killing vendors page

2005-02-21 Thread Noel J. Bergman
I'd suggest that we talk to the PRC about it.  There are some good things
about a vendors page.  Erik makes an interesting point about the Wiki, but
it would mean that we couldn't vet it for content to prevent grossly
misleading content.

--- Noel


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



Re: [site] killing vendors page

2005-02-21 Thread Erik Hatcher
I like having a wiki page for this sort of thing - allow the community 
itself to maintain such lists.

Erik
On Feb 21, 2005, at 10:27 AM, Henri Yandell wrote:
Still deliberating killing the vendors page.
I suggested killing it before, one of the vendors (sorry, can't find 
your email now) replied very gracefully and I put it on the 'think 
about later' queue in my head. Analysis of the current vendor page:

3GS LLC - No website at www.3gsllc.com
Multitask - Dion's generic support
Applied Engineering Software Group - No website at www.aesgi.com
Basebeans - No website at www.basebeans.com
Cafesoft - Single Sign On J2EE product
JAMM - Very generic web support
OpenInput - Generic open-source support (I think. Spanish site)
OpenWeb - Jyve support :)
Sono - generic web dev support, no mention of Jakarta on site
Superlink - Andy's general open-source + POI support
Tachometry - Generic open-source support (incl Tomcat)
XPolog - J2EE Log management product
I already removed Ted's Struts support as no longer relevant to 
Jakarta.

Looking at the above, we have 3 dead links, 4 generic open-source 
support places, 2 J2EE products, 2 general web places and Jyve 
support, where Jyve is long dead :)

Doesn't really seem like a great answer to the original question of 
showing that there is support for open-source. So this is the usual 
email:

I'll remove vendors.html in 3 days and setup a redirect to mail2.html 
unless anybody -1's.

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


[site] killing vendors page

2005-02-21 Thread Henri Yandell
Still deliberating killing the vendors page.
I suggested killing it before, one of the vendors (sorry, can't find your 
email now) replied very gracefully and I put it on the 'think about later' 
queue in my head. Analysis of the current vendor page:

3GS LLC - No website at www.3gsllc.com
Multitask - Dion's generic support
Applied Engineering Software Group - No website at www.aesgi.com
Basebeans - No website at www.basebeans.com
Cafesoft - Single Sign On J2EE product
JAMM - Very generic web support
OpenInput - Generic open-source support (I think. Spanish site)
OpenWeb - Jyve support :)
Sono - generic web dev support, no mention of Jakarta on site
Superlink - Andy's general open-source + POI support
Tachometry - Generic open-source support (incl Tomcat)
XPolog - J2EE Log management product
I already removed Ted's Struts support as no longer relevant to Jakarta.
Looking at the above, we have 3 dead links, 4 generic open-source support 
places, 2 J2EE products, 2 general web places and Jyve support, where Jyve 
is long dead :)

Doesn't really seem like a great answer to the original question of 
showing that there is support for open-source. So this is the usual email:

I'll remove vendors.html in 3 days and setup a redirect to mail2.html 
unless anybody -1's.

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


Re: Vendors page

2003-11-06 Thread Dirk Verbeeck
Please submit a patch against the vendors.xml source file:
http://cvs.apache.org/viewcvs/jakarta-site/xdocs/site/vendors.xml?rev=HEAD
follow the patch guidelines described here:
http://jakarta.apache.org/site/source.html
-- Dirk

Koschitzky Omry wrote:

Hello,
 
This is the second email I am sending to you, I didn't get any reply
from Apache, if there is any problem in which I can help I will be
happy.
 
We are a company that develops a product named XpoLog. We use Apache
projects in our solutions.
We would like to have a link and description in your vendor's page.
 
Our web site: http://www.xpolog.com
Apache projects integration page at XpoLog:
http://www.xpolog.com/resources/allies/apache.htm
 
 
XpoLog / http://www.xpolog.com
*	XpoLog is a log viewer and analysis server with integration
support to Apache projects like log4j and Tomcat. XpoLog provides a
solution for both log analysis and support station. 
*	Tel Aviv/ Israel 
*	[EMAIL PROTECTED]
 
Best regards,
 
 
Koschitzky Omry
[EMAIL PROTECTED]
XpoLog




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


RE: Vendors page

2003-10-29 Thread Fernandez Martinez, Alejandro
I'm not the one to answer this, but...

I think I remember reading something about vendors submitting a patch to the
vendor's page. That way, the vendor proves its technical competence, and
it's less work for the maintainers.

Perhaps you should try to submit a diff or a patch.

> -Mensaje original-
> De: Koschitzky Omry [mailto:[EMAIL PROTECTED]
> Enviado el: lunes 1 de diciembre de 2003 9:32
> Para: [EMAIL PROTECTED]
> Asunto: Vendors page
> 
> 
> Hello,
>  
> This is the second email I am sending to you, I didn't get any reply
> from Apache, if there is any problem in which I can help I will be
> happy.
>  
> We are a company that develops a product named XpoLog. We use Apache
> projects in our solutions.
> We would like to have a link and description in your vendor's page.
>  
> Our web site: http://www.xpolog.com
> Apache projects integration page at XpoLog:
> http://www.xpolog.com/resources/allies/apache.htm
>  
>  
> XpoLog / http://www.xpolog.com
> * XpoLog is a log viewer and analysis server with integration
> support to Apache projects like log4j and Tomcat. XpoLog provides a
> solution for both log analysis and support station. 
> * Tel Aviv/ Israel 
> * [EMAIL PROTECTED]
>  
> Best regards,
>  
>  
> Koschitzky Omry
> [EMAIL PROTECTED]
> XpoLog
>  
> 


Vendors page

2003-10-29 Thread Koschitzky Omry
Hello,
 
This is the second email I am sending to you, I didn't get any reply
from Apache, if there is any problem in which I can help I will be
happy.
 
We are a company that develops a product named XpoLog. We use Apache
projects in our solutions.
We would like to have a link and description in your vendor's page.
 
Our web site: http://www.xpolog.com
Apache projects integration page at XpoLog:
http://www.xpolog.com/resources/allies/apache.htm
 
 
XpoLog / http://www.xpolog.com
*   XpoLog is a log viewer and analysis server with integration
support to Apache projects like log4j and Tomcat. XpoLog provides a
solution for both log analysis and support station. 
*   Tel Aviv/ Israel 
*   [EMAIL PROTECTED]
 
Best regards,
 
 
Koschitzky Omry
[EMAIL PROTECTED]
XpoLog
 


Re: The vendors page

2003-07-17 Thread Tetsuya Kitahata

Ah... what's going on with this below finally??

Discussions have gone away in a dense fog??

Sincerely,

-- Tetsuya ([EMAIL PROTECTED])

-

On Mon, 7 Jul 2003 19:58:06 +0100
(Subject: Re: The vendors page)
robert burrell donkin <[EMAIL PROTECTED]> wrote:

> FWIW i think that the original arguments which lead to the creation of the 
> vendors page are still relevant. it's very hard for any folks here to 
> judge the merit (or otherwise) of companies providing support. on the 
> other hand, there was a definite demand from users and vendors for a 
> dating service.
> 
> the original rule seemed to be a good one (a minimal test which some 
> vendors have failed) as well having the merit of simplicity. on the other 
> hand i do think that andrew's arguments have served a useful purpose in 
> making us think harder about the purpose of that page. i also agree with 
> alex in that probably the future direction is to something more 
> apache-wide.
> 
> on the other hand, i think that michael's answers have been reasonable and 
> give him at least as much a reason as many of the existing vendors. unless 
> i hear some good reasons not to, i'll probably commit something along 
> those lines sometime soonish. i might also try to think of some ways to 
> reorganize the page.
> 
> - robert
> 
> On Thursday, July 3, 2003, at 10:08 AM, Alex McLintock wrote:
> 
> > At 09:51 02/07/03 -0400, Howard M. Lewis Ship wrote:
> >> I'm tending towards the argument that if you can convince someone who 
> >> has the right access to update
> >> the vendors.xml
> >> page, then you deserve to be on the list.
> >>
> >
> >
> >
> >
> >>
> >> > Yep - so basically this should be decided on a subproject-level in
> >> > Jakarta's case. I doubt *anyone* is able to support *all* Jakarta
> >> > subprojects on a level that he/she serves his customers well.
> >> > Suggestion: move this page away from the Jakarta main site, and
> >> > stimulate subprojects to host their own vendor pages.
> >> >
> >> > 
> >> > --
> >> > Steven Noelshttp://outerthought.org/
> >
> >
> > I'm not sure of the point of a Vendors page. There are so many different 
> > types of "vendors" covering so many projects that a single page - or even 
> > a single XML is not necessarily the right thing.
> >
> > I started a database of companies who support open source software but I 
> > am not sure it is the right as it is.
> >
> > I think Apache has grown large enough to need a database of trainers, 
> > consultants, developers, vendors, and other support companies who will 
> > provide assistence with using Apache software.
> >
> > We had a small mailing list for discussing these sorts of commercial 
> > aspects to using Apache software but it never really got off the ground.
> >
> > Alex McLintock


-
Tetsuya Kitahata --  Terra-International, Inc.
E-mail: [EMAIL PROTECTED] : [EMAIL PROTECTED]
http://www.terra-intl.com/
(Apache Jakarta Translation, Japanese)
http://jakarta.terra-intl.com/



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



Re: The vendors page

2003-07-07 Thread robert burrell donkin
FWIW i think that the original arguments which lead to the creation of the 
vendors page are still relevant. it's very hard for any folks here to 
judge the merit (or otherwise) of companies providing support. on the 
other hand, there was a definite demand from users and vendors for a 
dating service.

the original rule seemed to be a good one (a minimal test which some 
vendors have failed) as well having the merit of simplicity. on the other 
hand i do think that andrew's arguments have served a useful purpose in 
making us think harder about the purpose of that page. i also agree with 
alex in that probably the future direction is to something more 
apache-wide.

on the other hand, i think that michael's answers have been reasonable and 
give him at least as much a reason as many of the existing vendors. unless 
i hear some good reasons not to, i'll probably commit something along 
those lines sometime soonish. i might also try to think of some ways to 
reorganize the page.

- robert

On Thursday, July 3, 2003, at 10:08 AM, Alex McLintock wrote:

At 09:51 02/07/03 -0400, Howard M. Lewis Ship wrote:
I'm tending towards the argument that if you can convince someone who 
has the right access to update
the vendors.xml
page, then you deserve to be on the list.





> Yep - so basically this should be decided on a subproject-level in
> Jakarta's case. I doubt *anyone* is able to support *all* Jakarta
> subprojects on a level that he/she serves his customers well.
> Suggestion: move this page away from the Jakarta main site, and
> stimulate subprojects to host their own vendor pages.
>
> 
> --
> Steven Noelshttp://outerthought.org/


I'm not sure of the point of a Vendors page. There are so many different 
types of "vendors" covering so many projects that a single page - or even 
a single XML is not necessarily the right thing.

I started a database of companies who support open source software but I 
am not sure it is the right as it is.

I think Apache has grown large enough to need a database of trainers, 
consultants, developers, vendors, and other support companies who will 
provide assistence with using Apache software.

We had a small mailing list for discussing these sorts of commercial 
aspects to using Apache software but it never really got off the ground.

Alex McLintock

-
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: The vendors page

2003-07-03 Thread Alex McLintock
At 09:51 02/07/03 -0400, Howard M. Lewis Ship wrote:
I'm tending towards the argument that if you can convince someone who has 
the right access to update
the vendors.xml
page, then you deserve to be on the list.





> Yep - so basically this should be decided on a subproject-level in
> Jakarta's case. I doubt *anyone* is able to support *all* Jakarta
> subprojects on a level that he/she serves his customers well.
> Suggestion: move this page away from the Jakarta main site, and
> stimulate subprojects to host their own vendor pages.
>
> 
> --
> Steven Noelshttp://outerthought.org/


I'm not sure of the point of a Vendors page. There are so many different 
types of "vendors" covering so many projects that a single page - or even a 
single XML is not necessarily the right thing.

I started a database of companies who support open source software but I am 
not sure it is the right as it is.

I think Apache has grown large enough to need a database of trainers, 
consultants, developers, vendors, and other support companies who will 
provide assistence with using Apache software.

We had a small mailing list for discussing these sorts of commercial 
aspects to using Apache software but it never really got off the ground.

Alex McLintock

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


Re: The vendors page

2003-07-02 Thread Andrew C. Oliver
The problem is that ALL projects are ALWAYS desperate for help.  Its just
often they need help from a particular kind of person.  POI for instance
needs people who LIKE hex dumps and can think at a binary level.  That¹s a
very small minority of Java developers.

Other projects have various other needs, but I doubt any project would say
"yeah, we're overstaffed"...

On 7/2/03 2:14 PM, "Brian McCallister" <[EMAIL PROTECTED]>
wrote:

> It might be useful for projects who *need* help to let that be known in
> some easy-to-find way. Some projects are well staffed, some are
> understaffed. If you are involved with several of the project mailing
> lists it becomes more clear, but if you are say, a company who wants to
> contribute effort and talent it might be tough to figure out which
> projects need manpower.
> 
> While no project is going to be accepted into Jakarta without a
> development community around it, there are always places that need more
> help than others.
> 
> Just my 2 cents.
> 
> -Brian
> 
> On Wednesday, July 2, 2003, at 02:00 PM, Howard M. Lewis Ship wrote:
> 
>>> Perhaps over time, he would get known and accepted in the
>>> community and
>>> someone would choose to nominate him for committer priviledges.
>>>  Obviously, that is something that Collabra would have very little
>>> control over.
>>> 
>> 
>> If you have someone with talent and a decent amount of time to spend,
>> my experience is that they can
>> become a committer pretty quickly.  If they are providing quality
>> mentoring and patches, it quickly
>> becomes easier to vote them in as a committer than to manually apply
>> their patches.  So if your
>> primary goal is to establish Collabra's rep and your incidental goal
>> is to be listed on the vendors
>> page, start now and see results soon.
>> 
>> --
>> Howard M. Lewis Ship
>> Creator, Tapestry: Java Web Components
>> http://jakarta.apache.org/tapestry
>> 
>> 
>> 
>> -
>> 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]
> 

-- 
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI

http://jakarta.apache.org/poi
For Java and Excel, Got POI?


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



Re: The vendors page

2003-07-02 Thread Brian McCallister
It might be useful for projects who *need* help to let that be known in 
some easy-to-find way. Some projects are well staffed, some are 
understaffed. If you are involved with several of the project mailing 
lists it becomes more clear, but if you are say, a company who wants to 
contribute effort and talent it might be tough to figure out which 
projects need manpower.

While no project is going to be accepted into Jakarta without a 
development community around it, there are always places that need more 
help than others.

Just my 2 cents.

-Brian

On Wednesday, July 2, 2003, at 02:00 PM, Howard M. Lewis Ship wrote:

Perhaps over time, he would get known and accepted in the
community and
someone would choose to nominate him for committer priviledges.
 Obviously, that is something that Collabra would have very little
control over.
If you have someone with talent and a decent amount of time to spend, 
my experience is that they can
become a committer pretty quickly.  If they are providing quality 
mentoring and patches, it quickly
becomes easier to vote them in as a committer than to manually apply 
their patches.  So if your
primary goal is to establish Collabra's rep and your incidental goal 
is to be listed on the vendors
page, start now and see results soon.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry


-
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: The vendors page

2003-07-02 Thread Howard M. Lewis Ship
> Perhaps over time, he would get known and accepted in the 
> community and 
> someone would choose to nominate him for committer priviledges. 
>  Obviously, that is something that Collabra would have very little 
> control over.
> 

If you have someone with talent and a decent amount of time to spend, my experience is 
that they can
become a committer pretty quickly.  If they are providing quality mentoring and 
patches, it quickly
becomes easier to vote them in as a committer than to manually apply their patches.  
So if your
primary goal is to establish Collabra's rep and your incidental goal is to be listed 
on the vendors
page, start now and see results soon.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry



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



Re: The vendors page

2003-07-02 Thread Michael Davey
Howard M. Lewis Ship wrote:

I'm tending towards the argument that if you can convince someone who has the right 
access to update
the vendors.xml
page, then you deserve to be on the list.
My motivation for attempting to add Collabra to the list was with the 
long-term plan of moving one of my engineers to a full time open source 
role in response to the additional business that the entry produced. 
Right now we make the occasional contribution to other Open Source 
projects but virtually no contributions to Apache (and those were done 
in employees' own time).  If there is enough paid Jakarta work to keep 
one of my engineers busy for 3 or 4 days a week, the decision to ask him 
to "find other Jakarta stuff to do" for the rest of his time is an easy 
one to make.

Perhaps over time, he would get known and accepted in the community and 
someone would choose to nominate him for committer priviledges. 
Obviously, that is something that Collabra would have very little 
control over.

An alternative would be to employ an existing committer (perhaps 
poaching them from their existing employer).  A side-effect would be 
that they would then be obligated for the most part to work on features 
that Collabra deems important, rather than what the wider community 
wants, thus actually reducing the capacity of the Jakarta project to 
achieve its aims.  This goes completely against our corporate philosophy 
and, IMHO, the spirit of the communtiy and I won't do it.

I guess what I am saying is that we are a small company with limited 
resources (heck, even Sendmail, Inc. only contributes ~50 man-hours per 
week to freeware sendmail). We want to help out and give something back 
to the community (beyond increasing the install base and training 
users), but we need you to help us help you.

--
Michael Davey
Technical Director
Collabra Ltd.


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


Re: The vendors page

2003-07-02 Thread Andrew C. Oliver
Okay, then I shall for now on dutifully ignore patches to the page from
names I do not recognize.  I, personally, am unlikely to commit patches at
all (figuring most should be able to commit them themselves with the rare
exceptions mentioned) from this point on.

-Andy

On 7/2/03 9:51 AM, "Howard M. Lewis Ship" <[EMAIL PROTECTED]> wrote:

> I'm tending towards the argument that if you can convince someone who has the
> right access to update
> the vendors.xml
> page, then you deserve to be on the list.
> 
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
> 
> 
> 
>> -Original Message-
>> From: Steven Noels [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, July 02, 2003 8:37 AM
>> To: Jakarta General List
>> Subject: Re: The vendors page
>> 
>> 
>> On 2/07/2003 11:13 Santiago Gala wrote:
>> 
>>> I would not say "you employ", but "just convince one
>> jakarta commiter
>>> to
>>> make the change". This would ensure at least some level of
>> communication 
>>> (like sending it to the project -dev list and discussing it
>> there, etc.)
>> 
>> +1 on being present on the list and discussing things
>> 
>> 
>> 
>>> the project committers should be aware of them existing and
>>> supporting the project.
>> 
>> Yep - so basically this should be decided on a subproject-level in
>> Jakarta's case. I doubt *anyone* is able to support *all* Jakarta
>> subprojects on a level that he/she serves his customers well.
>> Suggestion: move this page away from the Jakarta main site, and
>> stimulate subprojects to host their own vendor pages.
>> 
>> 
>> -- 
>> Steven Noelshttp://outerthought.org/
>> Outerthought - Open Source, Java & XML Competence Support Center
>> Read my weblog athttp://blogs.cocoondev.org/stevenn/
>> stevenn at outerthought.orgstevenn at apache.org
>> 
>> 
>> -
>> 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]
> 

-- 
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI

http://jakarta.apache.org/poi
For Java and Excel, Got POI?


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



RE: The vendors page

2003-07-02 Thread Howard M. Lewis Ship
I'm tending towards the argument that if you can convince someone who has the right 
access to update
the vendors.xml
page, then you deserve to be on the list.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry



> -Original Message-
> From: Steven Noels [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, July 02, 2003 8:37 AM
> To: Jakarta General List
> Subject: Re: The vendors page
> 
> 
> On 2/07/2003 11:13 Santiago Gala wrote:
> 
> > I would not say "you employ", but "just convince one 
> jakarta commiter 
> > to
> > make the change". This would ensure at least some level of 
> communication 
> > (like sending it to the project -dev list and discussing it 
> there, etc.)
> 
> +1 on being present on the list and discussing things
> 
> 
> 
> > the project committers should be aware of them existing and
> > supporting the project.
> 
> Yep - so basically this should be decided on a subproject-level in 
> Jakarta's case. I doubt *anyone* is able to support *all* Jakarta 
> subprojects on a level that he/she serves his customers well. 
> Suggestion: move this page away from the Jakarta main site, and 
> stimulate subprojects to host their own vendor pages.
> 
> 
> -- 
> Steven Noelshttp://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog athttp://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.orgstevenn at apache.org
> 
> 
> -
> 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: The vendors page

2003-07-02 Thread Steven Noels
On 2/07/2003 11:13 Santiago Gala wrote:

I would not say "you employ", but "just convince one jakarta commiter to 
make the change". This would ensure at least some level of communication 
(like sending it to the project -dev list and discussing it there, etc.)
+1 on being present on the list and discussing things



the project committers should be aware of them existing and 
supporting the project.
Yep - so basically this should be decided on a subproject-level in 
Jakarta's case. I doubt *anyone* is able to support *all* Jakarta 
subprojects on a level that he/she serves his customers well. 
Suggestion: move this page away from the Jakarta main site, and 
stimulate subprojects to host their own vendor pages.


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: The vendors page

2003-07-02 Thread Santiago Gala
Andrew C. Oliver escribió:
The original intent of the vendors.xml page was:

 1. Because I got sick of hearing people say "Jakarta projects are not
supported" and wanted a page to send people to during presentations.
 2. So a certain unnamed committer would not feel the need to spam the lists
(because I though if he got away with it, others would start doing it and
then I'd get lists full of consultancy spam).
Now that Open Source is no longer a commercial cussword and I doubt even an
economic turnaround will kill the momentum, I think that the policy for that
page ought to be "just have one of the committers you employ on the Jakarta
projects you support make the change".  Thus tightening it from people who
"support" Jakarta projects to people who support Jakarta projects.
Thoughts/Objections?

+1 It is a simple test of reasonable support, not just lurking.

I would not say "you employ", but "just convince one jakarta commiter to 
make the change". This would ensure at least some level of communication 
(like sending it to the project -dev list and discussing it there, etc.)

It the spirit of Open Source, if a Company is not able to have a fluid 
relation with at least one committer of one of the projects they 
support, I can't see how they can claim support of the projects.

Note I'm saying less than Andy. Not "employing" a committer, but 
channelling the change through one committer. The company maybe 
contributed some patches or docs, or just good answers in the -user 
list, but the project committers should be aware of them existing and 
supporting the project.


-Andy
Regards
--
Santiago Gala
High Sierra Technology, S.L. (http://hisitech.com)
http://memojo.com?page=SantiagoGalaBlog


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


Re: The vendors page

2003-07-01 Thread Tetsuya Kitahata

On Tue, 01 Jul 2003 15:58:37 -0400
(Subject: The vendors page)
"Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:

> The original intent of the vendors.xml page was:
> 
>  1. Because I got sick of hearing people say "Jakarta projects are not
> supported" and wanted a page to send people to during presentations.
> 
>  2. So a certain unnamed committer would not feel the need to spam
> the lists (because I though if he got away with it, others would start
> doing it and then I'd get lists full of consultancy spam).
> 
> Now that Open Source is no longer a commercial cussword and I doubt
> even an economic turnaround will kill the momentum, I think that the
> policy for that page ought to be "just have one of the committers you
> employ on the Jakarta projects you support make the change".  Thus
> tightening it from people who "support" Jakarta projects to people who
> support Jakarta projects.
> 
> Thoughts/Objections?

I agree, but with qualifications.

How about preparing new page for the companies/vendors which have no
'committer' in jakarta? Just devide into the vendors.html
and vendorlist.html.
And make vendors.html for the vendors which employ the committers and
vendorlist.html for the vendors which do not employ the committers.

I really want to prepare the vendorlist.html with the list of the
regions (Asia, US, Europe, etc.). Apache-Jakarta is suffering the
shortage of the Asian vendors' support.

If there will be no 'another page' which can complement the vendors.html,
I oppose to your opinions (especially the requirement for *committership*).

Sincerely,

-- Tetsuya ([EMAIL PROTECTED])

-
Tetsuya Kitahata --  Terra-International, Inc.
E-mail: [EMAIL PROTECTED] : [EMAIL PROTECTED]
http://www.terra-intl.com/
(Apache Jakarta Translation, Japanese)
http://jakarta.terra-intl.com/



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



Re: The vendors page

2003-07-01 Thread Andrus Adamchik
-1

While (1) is no longer an issue (c'mon, it wasn't a real issue when the
vendor page was first created!), (2) is still true.

And the main things I disagree with is that criteria of "support" vs.
support should be committer status of one of the company employees. There
should definitely be some (more or less strict) "lameness" review of each
submission, but making it elitist just doesn't make sense.

Say for instance someone has a company that does a training course on a
number of Jakarta projects. None of the course instructors are Jakarta
committers, but they still educate the world about OpenSource software and
make whatever money they can while serving the community in their own way.
Is it that bad to list them on the vendor page?

Andrus Adamchik


> The original intent of the vendors.xml page was:
>
>  1. Because I got sick of hearing people say "Jakarta projects are not
> supported" and wanted a page to send people to during presentations.
>
>  2. So a certain unnamed committer would not feel the need to spam the
> lists
> (because I though if he got away with it, others would start doing it
> and then I'd get lists full of consultancy spam).
>
> Now that Open Source is no longer a commercial cussword and I doubt even
> an economic turnaround will kill the momentum, I think that the policy
> for that page ought to be "just have one of the committers you employ on
> the Jakarta projects you support make the change".  Thus tightening it
> from people who "support" Jakarta projects to people who support Jakarta
> projects.
>
> Thoughts/Objections?
>
> -Andy



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



The vendors page

2003-07-01 Thread Andrew C. Oliver
The original intent of the vendors.xml page was:

 1. Because I got sick of hearing people say "Jakarta projects are not
supported" and wanted a page to send people to during presentations.

 2. So a certain unnamed committer would not feel the need to spam the lists
(because I though if he got away with it, others would start doing it and
then I'd get lists full of consultancy spam).

Now that Open Source is no longer a commercial cussword and I doubt even an
economic turnaround will kill the momentum, I think that the policy for that
page ought to be "just have one of the committers you employ on the Jakarta
projects you support make the change".  Thus tightening it from people who
"support" Jakarta projects to people who support Jakarta projects.

Thoughts/Objections?

-Andy
-- 
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI

http://jakarta.apache.org/poi
For Java and Excel, Got POI?


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