On Fri, 2012-04-13 at 14:42 +0100, Ross Gardler wrote:
> On 13 April 2012 14:00, drew <d...@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

Reply via email to