Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of plightbo@gmail.com designates
 66.249.82.204 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=bg7erjThcOuujGFS0e3PvO3dMsxufw5Z1L1rXwxqictHwnj1SUetW7jllyCjtA5k6+muVhGyxvInid0ewR5N2eis3DtZhA28/zBziyfKBRWU4dKs0k25u1zklGUieV1wx3sO171t7OScvzFiQsimzs0Q00b/dpTKKc5ILJKQrcQ=
Message-ID: <c372afa40512011144r6cde6b32r4752b6df6a381da7@mail.gmail.com>
Date: Thu, 1 Dec 2005 11:44:09 -0800
From: Patrick Lightbody <plightbo@gmail.com>
To: Struts Developers List <dev@struts.apache.org>
Subject: Re: Tough Questions on Struts and Webwork Integration
Cc: husted@apache.org
In-Reply-To: <16d6c6200512011118m36a33085g8633aff535c875b7@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <E3DC86E6DA36244FBE0A5EEEEA94EF2DD12C9B@elon11p32003.csfp.co.uk>
	 <1db115340511291044o3471d4d3t9c61291274949977@mail.gmail.com>
	 <438CA39B.7090509@twdata.org>
	 <8b3ce3790511291611s3ae1de97k17971292974ada81@mail.gmail.com>
	 <438CFC0A.8030309@twdata.org>
	 <8b3ce3790511300424g77aba521s7c03f1907015ef36@mail.gmail.com>
	 <16d6c6200511301552u1080f55bm16073001ad34d49c@mail.gmail.com>
	 <8b3ce3790512010342v1ed6faa6l51846cdf60927260@mail.gmail.com>
	 <16d6c6200512011118m36a33085g8633aff535c875b7@mail.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 <martinc@apache.org> wrote:
> On 12/1/05, Ted Husted <ted.husted@gmail.com> wrote:
> >
> > On 11/30/05, Martin Cooper <martinc@apache.org> wrote:
> > >  I am very much against taking ASF content off-site, as it were. We h=
ave
> > 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 fo=
r
> Atlassian. We are dependent on him - and the fact that he works for
> Atlassian - for fixes, maintenance, and enhancements to JIRA itself. If h=
e
> 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