incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Re: Ditching our mirror system for an inferior solution?
Date Fri, 13 Apr 2012 18:11:51 GMT
FTR, I just got thru discussing these issues with
Henk Penning, our Apache mirror guy.  While he's
tried to reach out to Peter without success recently,
he'd like to get in contact with whoever currently
is managing the mirrorbrain mirrors because those
mirror operators are in the dark about what our plans
are, and maintaining good relations with mirror operators
is essential for all concerned.  Please provide me
with a list of mirror network managers for the old
system so I can pass it along to Henk for followup.


Infra's position is currently that, for the upcoming
release ONLY, continuing to use the legacy mirrorbrain
system in conjunction with ASF mirrors and SF downloads
is A-OK.  However it is painfully obvious that maintaining
two different mirror networks causes trouble for everyone,
so we will ask that this PPMC take steps to phase out
the mirrorbrain network for all subsequent releases, leaving
just ASF mirrors and SF downloads.  At that point we will
be better positioned to avoid duplication of download
resources and hopefully have incorporated many of the old
mirrors into the ASF mirror network.


Note: while you are required to use ASF mirrors, your use
of SF download services is contingent on satisfactory performance
and whatever criterion you consider essential- IOW its up to you
whether you want to keep using it or not.  All SF has asked of
us is timely notification so they can cancel whatever supporting
arrangements they have made to not incur needless costs, something
I consider eminently fair and reasonable.


HTH



>________________________________
> From: Rob Weir <robweir@apache.org>
>To: ooo-dev@incubator.apache.org 
>Sent: Friday, April 13, 2012 1:20 PM
>Subject: Re: Ditching our mirror system for an inferior solution?
> 
>On Fri, Apr 13, 2012 at 12:58 PM, drew <drew@baseanswers.com> wrote:
>> On Fri, 2012-04-13 at 14:42 +0100, Ross Gardler wrote:
>>> On 13 April 2012 14:00, drew <drew@baseanswers.com> wrote:
>>> > On Fri, 2012-04-13 at 05:38 -0700, Joe Schaefer wrote:
>>> >> Bit late to pretend you're trying to be helpful
>>> >> here with the bits about NIH you like tossing around.
>>> >>
>>> >> What questions are you asking again?  And what facts
>>> >> are you pointing out?  Seems to me we had a working
>>> >> agreementabout a month or so, settled entirely on-list,
>>> >> but yesterday Peter pitches a fit and you decide NOW
>>> >> is the time for complaints?  Gee if that's not kicking
>>> >> sand in the faces of the people who worked out this
>>> >> deal you'll have to excuse me while I figure out where
>>> >> else all this unwanted sand could've come from.
>>> >
>>> > From my recollection the discussion earlier always started from the
>>> > premise that Apache mirrors would take over, I thought because that was
>>> > the policy, only apache mirrors.
>>>
>>> Apache mirrors are ones sanctioned and coordinated by the ASF infra
>>> team. They are not ones that the ASF manage. SF are working directly
>>> with ASF Infra so that they become an official ASF mirror, the fact
>>> that they are providing much more than a single mirror site changes
>>> nothing.
>>>
>>> Any organisation whether they were part of the previous mirrorbrain
>>> service or not is free to work with ASF Infra to become a part of the
>>> ASF mirror system.
>>>
>>> > I asked when (how) it was determined that the Mirrorbrain service was
>>> > broken and had to be replaced?
>>>
>>> Nobody said it was broken. What was said is that ASF Infra are not
>>> willing or able to support two distinct mirror systems so either
>>> people step up and move (and support) mirrorbrain at the ASF or the
>>> ASF Infra team step up and make it work. ASF Infra is making it work,
>>> using the resources being offered, including those from SF. Actions
>>> speak louder than words.
>>>
>>> I'm sure ASF Infra will continue accept offers of long term support
>>> and assistance from any third party willing and able.
>>>
>>> > I pointed out that it had never stopped serving up files, that TTBOMK
>>> > the mirror operators had never notified this project that they would no
>>> > longer work with the project.
>>>
>>> True, and the ASF Infra team asked the PPMC to reach our to those
>>> operators and ask them if they wanted to continue as part of the ASF
>>> mirror system. Infra are not dumping the old network, they are
>>> augmenting it with the existing ASF mirror and newcomers. Things look
>>> different when you look from a different angle.
>>>
>> Hi Ross
>>
>> Alright, so it is just a matter of existing policy, which is to say that
>> as part of matriculation into Apache the project relinquishes control of
>> the distribution process from the project proper to the foundation,
>> specifically the Infrastructure team, no exceptions.
>>
>> In the case of the existing mirrorbrain network then individual mirrors
>> must conform to the existing requirements for becoming an official
>> Apache mirror.
>>
>> In this case then the fact that the individual mirrorbrain server
>> operators have not said they would stop supporting the project is of no
>> consideration, rather what was needed, or lacking, is an active
>> declaration of support via execution of the required steps needed to be
>> recognized as official Apache mirrors, unless as is the case for some
>> they already are such.
>>
>> Which is where I get a bit confused as to the reality of the situation
>> on the ground, at this moment.
>>
>> When it is said that the mirrorbrain network will also be used for
>> distribution what is meant is those servers in the current network which
>> have become, or were already, Apache mirrors, but not the full
>> contingent of servers? I believe that is accurate, but as I say I'm not
>> really positive this is the case.
>>
>> So the facts on the ground are, that there has not been a large number
>> of mirrorbrain operators executing these steps and therefore the project
>> is faced with the necessity of augmenting the system by including the SF
>> services.
>>
>> As to Peter then, it is in no way impugning the quality of all the hard
>> work that he and others have contributed over the years, or the ability
>> to continue to deliver the 'goods' (even patches), it is simply a
>> consequence of the move to Apache and pre-existing foundation policy.
>>
>> It is just an unfortunate consequence that in this specific case one of
>> the better executed, and well functioning, aspects of the community
>> efforts from the old project falls afoul of the requirements in the
>> projects in it's new home.
>>
>
>
>Drew, consider our recent OOo track record of community-supported
>infrastructure:
>
>1) Extensions and Templates?  It gradually fell apart, over a period
>of months, a horrible user experience, embarrassing,  with zero
>volunteers from the community able or willing to fix it, before
>SourgeForge volunteered to host it.  (Apache Infra also volunteered to
>help, and certainly could have done it as well.  Point is, the AOO PMC
>failed to solve this problem)
>
>2) phpBB Forums?   No admin, no maintenance.  It is one critical bug
>away from falling over, or one XSS away from being shut down.
>
>3) Pootle?  No one in the project ever stepped forward to set this up.
>We were fortunate that Apache Infra eventually did this and saved our
>asses.
>
>So we're not exactly showing our strength when we talk about the
>community's ability to maintain complex infrastructure.  Maybe these
>all worked before. Maybe there was some Sun/Oracle staff helping?  I
>don't know.
>
>In any case, I don't think, given this recent track record, it is very
>wise to put all of our eggs in one basket and rely entirely on
>MirrorBrain for our downloads. Some diversity and redundancy is a good
>thing, both for peak demand, as well as insurance against the same
>things happening to our downloads as happened to Extensions, Templates
>and forums.
>
>-Rob
>
>> //drew
>>
>
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message