[FFmpeg-devel] release feedback

[Michael Niedermayer]

On Sun, Mar 15, 2009 at 02:12:12AM +0000, Jethro Walters wrote:
> 
> --- On Sun, 15/3/09, Michael Niedermayer <michaelni at gmx.at> wrote:
> 
> > From: Michael Niedermayer <michaelni at gmx.at>
> > Subject: Re: [FFmpeg-devel] release feedback
> > To: "FFmpeg development discussions and patches" <ffmpeg-devel at mplayerhq.hu>
> > Date: Sunday, 15 March, 2009, 2:02 AM
> > On Sun, Mar 15, 2009 at 01:32:38AM +0000, Jethro Walters wrote:
> > > 
> > > --- On Sun, 15/3/09, Michael Niedermayer <michaelni at gmx.at> wrote:
> > > 
> > > > From: Michael Niedermayer <michaelni at gmx.at>
> > > > Subject: Re: [FFmpeg-devel] release feedback
> > > > To: "FFmpeg development discussions and patches" <ffmpeg-devel at mplayerhq.hu>
> > > > Date: Sunday, 15 March, 2009, 12:36 AM
> > > > On Sat, Mar 14, 2009 at 10:22:53PM +0000, Robert Swain
> > > > wrote:
> > > > > On 14/3/09 23:20, compn wrote:
> > > > > > On Sat, 14 Mar 2009 21:16:32 +0000, Robert Swain
> > > > wrote:
> > > > [...]
> > > > > > i know the roundup list has been mirrored on gmane since that first
> > > > > > downtime. so i'm not sure what else can be done for that.
> > > > > 
> > > > > The other lists are on gmane aren't they? Are they actually mirrored 
> > > > > there and synced back and forth with the lists on mphq? Do distributed 
> > > > > mailing lists exist? ;)
> > > > 
> > > > usenet
> > > 
> > > Sorta related, but in the case of downtime on the mailing list, you could migrate current development chatter to an IRC channel.
> > 
> > or go bugfixing on roundup which is together with its ML on
> > a different server.
> > 
> > Which brings me to underline a past comment of mine, avoid
> > a single point of failure, be that a person or equipment.
> 
> Surely doing that just gives more chances of hardware failure?

AFAIK mphq and the latest roundup failure where caused by DoS that becomes
harder not easier if there are multiple targets.
Besides when one of the 3 (fate, roundup, mphq) where down the others still
where up and useable, where all on a single server even if that failed just
1/3 as often i belive that would have been more disruptive.

also having all on a single server means an exploitable hole in one of (fate
roundup/python, svn) could take more down then when they are spread.
Besides this raises the issue of what the admin of that server would
allow to be installed due to security of that one and important server


> You spread the load, you spread the risk, but equally, the manpower has to be there to back it up and solve problems when they arise. You have it in one area and one person only needs to solve it. You have failure across a number of areas, more people are needed.

fate needs someone to admin it, roundup needs someone to admin it,
svn, ftp, ... needs ...
that is where the bulk of work is and that doesnt increase with
them being spread on multiple servers.

The once in 3 years hw failure per server is not a big cause of work
IMHO.
also we have the manpower for the servers we have, i dont see what we
could gain from putting things on a single server, it seems simply a
bad idea to me.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090315/a6682b5a/attachment.pgp>