Re: Tough Questions on Struts and Webwork Integration

[Martin Cooper <ma...@apache.org>]

On 11/30/05, Ted Husted <te...@gmail.com> wrote:
>
> Or vice-versa. :) I have a strong preference for Confluence, and
> Atlassian is providing this space for use of Apache projects.  I'd
> like to look into making similar arrangements for use of the Jive
> forums.


I am very much against taking ASF content off-site, as it were. We have a
perfectly good wiki, and that's where our content should be. I know there
are a bunch of Confluence fans out there, and maybe it's a better product in
some ways. But the ASF has standardised on a wiki, and we shouldabide by
that. (Was anyone hosting ASF code on an SVN server outside the foundation,
before we moved to CVS, just because it was better? I don't think so.)

--
Martin Cooper


-Ted.
>
> On 11/29/05, Don Brown <mr...@twdata.org> wrote:
> > Ted, I've started to bring some of the merger stuff over to the Struts
> Ti wiki.
> >   Could I migrate the FAQ as well, or were you wanting to keep it where
> it is?
> >
> > Don
> >
> > Ted Husted wrote:
> > > On 11/29/05, Don Brown <mr...@twdata.org> wrote:
> > >
> > >
> > >>Of course, as I send this, I see Patrick responded saying the same
> thing but
> > >>much better :)
> > >
> > >
> > > See also
> > >
> > > *
> http://opensource2.atlassian.com/confluence/oss/display/STRUTS2/WebWork+Merger+FAQ
> > >
> > > -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Tough Questions on Struts and Webwork Integration

[Ted Husted <te...@gmail.com>]

On 12/1/05, Patrick Lightbody <pl...@gmail.com> wrote:
> I would volunteer that Contegix, the hosting company that handles
> OpenSymphony, OpenQA, Spring, Atlassian, Jive, Cenqua, and others
> would be happy to help Struts (and Apache, I suppose) in the future.
> As I mentioned to Ted and Don, I've been putting together a nice
> stack based on Jive Forums, JIRA, Confluence, Jive Messenger (XMPP
> and group chat), Subversion, and SSH - all of which use a single LDAP
> repository and Single Sign-On. Perhaps when that is complete we can
> take a look at it.

We're in the midst of a search for a better way to handle our
infrastructure. I'll make sure that Contegrix is in the loop.

In fact, they are already helping out. The "OSS" Confluence instance
that projects like iBATIS and Geronimo already use was setup by
Atlassian through Contegrix. We've been very happy with the
arrangement so far.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Tough Questions on Struts and Webwork Integration

[Patrick Lightbody <pl...@gmail.com>]

I totally understand Martin's concerns.

Let's not try to bite off more than we can chew just yet. We've got  
enough on our hands with the WebWork/Struts merger :)

I would volunteer that Contegix, the hosting company that handles  
OpenSymphony, OpenQA, Spring, Atlassian, Jive, Cenqua, and others  
would be happy to help Struts (and Apache, I suppose) in the future.  
As I mentioned to Ted and Don, I've been putting together a nice  
stack based on Jive Forums, JIRA, Confluence, Jive Messenger (XMPP  
and group chat), Subversion, and SSH - all of which use a single LDAP  
repository and Single Sign-On. Perhaps when that is complete we can  
take a look at it.

Patrick


On Dec 1, 2005, at 3:42 AM, Ted Husted wrote:

> On 11/30/05, Martin Cooper <ma...@apache.org> wrote:
>>  I am very much against taking ASF content off-site, as it were.  
>> We have a
>> perfectly good wiki, and that's where our content should be. I  
>> know there
>> are a bunch of Confluence fans out there, and maybe it's a better  
>> product in
>> some ways. But the ASF has standardised on a wiki, and we  
>> shouldabide by
>> that. (Was anyone hosting ASF code on an SVN server outside the  
>> foundation,
>> before we moved to CVS, just because it was better? I don't think  
>> so.)
>
> The ASF doesn't "standardize" on this type of tool. Them that do the
> work make the decisions. What tools a community uses and how we use
> them is up to the individual PMCs. What the ASF cares about is whether
> the project's development community uses the tools to collaborate.
>
> Point in fact, the only reason we have a JIRA instance now is because
> some projects started using their own instance off site. Because
> projects were voting with their feet, we were able to find volunteers
> to setup the JIRA instance. Now, people didn't push for our own JIRA
> instance because it was "wrong" to have an issue tracker elsewhere, we
> pushed for it because if some projects wanted to use JIRA, then it
> follows that others would want to use it too. Looking at our JIRA
> instance now, I'm thinking that was a good call :)
>
> For security and legal reasons, the ASF has decided that the
> foundation must have all of our *source code* in our repository on our
> machines, and the ASF does want us to retain essential services, like
> the mailing lists and primary web site, on ASF hardware. But secondary
> services, like issue trackers and wikis, can be kept anywhere a
> project finds convenient.
>
> When security and legal issues do not trump, what works for the
> volunteers, works for the ASF. Volunteers are the only ASF resource
> that matters.
>
> If the WebWorks merger goes through, another aspect will be "eating
> our own dog food". JIRA, Confluence, and Jive all use WebWork, and the
> ASF *does* prefer that we use our own software when we can. If WebWork
> is going to be our software, then, all things remaining equal, we
> should give first preference to WebWork products.
>
> Of course, personally, I don't believe all things are equal. By
> comparison, I find moin-moin painful to use. Being only human, I will
> contribute fewer hours to working on a moin-moin wiki then I will a
> Confluence wiki. I'm in the web application business, and I enjoy
> using well-designed web applications, like JIRA, Confluence, and Jive.
> Like most volunteers, I prefer to "volunteer with pleasure".
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Tough Questions on Struts and Webwork Integration

[Patrick Lightbody <pl...@gmail.com>]

Definitely getting a bit off topic, but... :)

Matthew Porter, who works for Contegix, recently wrote an article that
I think is very relevant:

http://www.porterhome.com/blog/matthew/2005/11/15/1132088805733.html

Contegix has tried to address these "single points of failure" by
providing a broad team of experts to manage the servers -- all of whom
are experts at Java and these products.

Even still, I think for open source organizations to feel "truly
free", hosting solutions like java.net, SourceForge, or even Contegix
need to offer things like nightly backups of not just source code, but
_all_ the data (jira, wiki, etc). Organizations like Apache could then
download those backups and have a much better contingency plan.

On 12/1/05, Martin Cooper <ma...@apache.org> wrote:
> On 12/1/05, Ted Husted <te...@gmail.com> wrote:
> >
> > On 11/30/05, Martin Cooper <ma...@apache.org> wrote:
> > >  I am very much against taking ASF content off-site, as it were. We have
> > a
> > > perfectly good wiki, and that's where our content should be. I know
> > there
> > > are a bunch of Confluence fans out there, and maybe it's a better
> > product in
> > > some ways. But the ASF has standardised on a wiki, and we shouldabide by
> > > that. (Was anyone hosting ASF code on an SVN server outside the
> > foundation,
> > > before we moved to CVS, just because it was better? I don't think so.)
> >
> > The ASF doesn't "standardize" on this type of tool. Them that do the
> > work make the decisions. What tools a community uses and how we use
> > them is up to the individual PMCs. What the ASF cares about is whether
> > the project's development community uses the tools to collaborate.
> >
> > Point in fact, the only reason we have a JIRA instance now is because
> > some projects started using their own instance off site. Because
> > projects were voting with their feet, we were able to find volunteers
> > to setup the JIRA instance. Now, people didn't push for our own JIRA
> > instance because it was "wrong" to have an issue tracker elsewhere, we
> > pushed for it because if some projects wanted to use JIRA, then it
> > follows that others would want to use it too. Looking at our JIRA
> > instance now, I'm thinking that was a good call :)
>
>
> I'm not so sure. Much as I like JIRA, the ASF JIRA installation is
> vulnerable. It is effectively supported only by Jeff Turner, who works for
> Atlassian. We are dependent on him - and the fact that he works for
> Atlassian - for fixes, maintenance, and enhancements to JIRA itself. If he
> disappears, we are in trouble. The same concern has been expressed about
> adding a Confluence installation at the ASF.
>
> For security and legal reasons, the ASF has decided that the
> > foundation must have all of our *source code* in our repository on our
> > machines, and the ASF does want us to retain essential services, like
> > the mailing lists and primary web site, on ASF hardware. But secondary
> > services, like issue trackers and wikis, can be kept anywhere a
> > project finds convenient.
>
>
> If you ask on infra@, I don't think you'll get agreement with that last
> statement.
>
> --
> Martin Cooper
>
>
> When security and legal issues do not trump, what works for the
> > volunteers, works for the ASF. Volunteers are the only ASF resource
> > that matters.
> >
> > If the WebWorks merger goes through, another aspect will be "eating
> > our own dog food". JIRA, Confluence, and Jive all use WebWork, and the
> > ASF *does* prefer that we use our own software when we can. If WebWork
> > is going to be our software, then, all things remaining equal, we
> > should give first preference to WebWork products.
> >
> > Of course, personally, I don't believe all things are equal. By
> > comparison, I find moin-moin painful to use. Being only human, I will
> > contribute fewer hours to working on a moin-moin wiki then I will a
> > Confluence wiki. I'm in the web application business, and I enjoy
> > using well-designed web applications, like JIRA, Confluence, and Jive.
> > Like most volunteers, I prefer to "volunteer with pleasure".
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Tough Questions on Struts and Webwork Integration

[Martin Cooper <ma...@apache.org>]

On 12/1/05, Ted Husted <te...@gmail.com> wrote:
>
> On 11/30/05, Martin Cooper <ma...@apache.org> wrote:
> >  I am very much against taking ASF content off-site, as it were. We have
> a
> > perfectly good wiki, and that's where our content should be. I know
> there
> > are a bunch of Confluence fans out there, and maybe it's a better
> product in
> > some ways. But the ASF has standardised on a wiki, and we shouldabide by
> > that. (Was anyone hosting ASF code on an SVN server outside the
> foundation,
> > before we moved to CVS, just because it was better? I don't think so.)
>
> The ASF doesn't "standardize" on this type of tool. Them that do the
> work make the decisions. What tools a community uses and how we use
> them is up to the individual PMCs. What the ASF cares about is whether
> the project's development community uses the tools to collaborate.
>
> Point in fact, the only reason we have a JIRA instance now is because
> some projects started using their own instance off site. Because
> projects were voting with their feet, we were able to find volunteers
> to setup the JIRA instance. Now, people didn't push for our own JIRA
> instance because it was "wrong" to have an issue tracker elsewhere, we
> pushed for it because if some projects wanted to use JIRA, then it
> follows that others would want to use it too. Looking at our JIRA
> instance now, I'm thinking that was a good call :)


I'm not so sure. Much as I like JIRA, the ASF JIRA installation is
vulnerable. It is effectively supported only by Jeff Turner, who works for
Atlassian. We are dependent on him - and the fact that he works for
Atlassian - for fixes, maintenance, and enhancements to JIRA itself. If he
disappears, we are in trouble. The same concern has been expressed about
adding a Confluence installation at the ASF.

For security and legal reasons, the ASF has decided that the
> foundation must have all of our *source code* in our repository on our
> machines, and the ASF does want us to retain essential services, like
> the mailing lists and primary web site, on ASF hardware. But secondary
> services, like issue trackers and wikis, can be kept anywhere a
> project finds convenient.


If you ask on infra@, I don't think you'll get agreement with that last
statement.

--
Martin Cooper


When security and legal issues do not trump, what works for the
> volunteers, works for the ASF. Volunteers are the only ASF resource
> that matters.
>
> If the WebWorks merger goes through, another aspect will be "eating
> our own dog food". JIRA, Confluence, and Jive all use WebWork, and the
> ASF *does* prefer that we use our own software when we can. If WebWork
> is going to be our software, then, all things remaining equal, we
> should give first preference to WebWork products.
>
> Of course, personally, I don't believe all things are equal. By
> comparison, I find moin-moin painful to use. Being only human, I will
> contribute fewer hours to working on a moin-moin wiki then I will a
> Confluence wiki. I'm in the web application business, and I enjoy
> using well-designed web applications, like JIRA, Confluence, and Jive.
> Like most volunteers, I prefer to "volunteer with pleasure".
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Tough Questions on Struts and Webwork Integration

[Ted Husted <te...@gmail.com>]

On 11/30/05, Martin Cooper <ma...@apache.org> wrote:
>  I am very much against taking ASF content off-site, as it were. We have a
> perfectly good wiki, and that's where our content should be. I know there
> are a bunch of Confluence fans out there, and maybe it's a better product in
> some ways. But the ASF has standardised on a wiki, and we shouldabide by
> that. (Was anyone hosting ASF code on an SVN server outside the foundation,
> before we moved to CVS, just because it was better? I don't think so.)

The ASF doesn't "standardize" on this type of tool. Them that do the
work make the decisions. What tools a community uses and how we use
them is up to the individual PMCs. What the ASF cares about is whether
the project's development community uses the tools to collaborate.

Point in fact, the only reason we have a JIRA instance now is because
some projects started using their own instance off site. Because
projects were voting with their feet, we were able to find volunteers
to setup the JIRA instance. Now, people didn't push for our own JIRA
instance because it was "wrong" to have an issue tracker elsewhere, we
pushed for it because if some projects wanted to use JIRA, then it
follows that others would want to use it too. Looking at our JIRA
instance now, I'm thinking that was a good call :)

For security and legal reasons, the ASF has decided that the
foundation must have all of our *source code* in our repository on our
machines, and the ASF does want us to retain essential services, like
the mailing lists and primary web site, on ASF hardware. But secondary
services, like issue trackers and wikis, can be kept anywhere a
project finds convenient.

When security and legal issues do not trump, what works for the
volunteers, works for the ASF. Volunteers are the only ASF resource
that matters.

If the WebWorks merger goes through, another aspect will be "eating
our own dog food". JIRA, Confluence, and Jive all use WebWork, and the
ASF *does* prefer that we use our own software when we can. If WebWork
is going to be our software, then, all things remaining equal, we
should give first preference to WebWork products.

Of course, personally, I don't believe all things are equal. By
comparison, I find moin-moin painful to use. Being only human, I will
contribute fewer hours to working on a moin-moin wiki then I will a
Confluence wiki. I'm in the web application business, and I enjoy
using well-designed web applications, like JIRA, Confluence, and Jive.
Like most volunteers, I prefer to "volunteer with pleasure".

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org