On Fri, Jan 6, 2012 at 2:49 PM, Dave Fisher <[email protected]> wrote: > > On Jan 6, 2012, at 11:07 AM, Andrew Rist wrote: > >> +1 >> >> - short-medium term stabilise the extensions code and hosting >> - long term move to a federated approach >> >> I think this is indeed the growing consensus. I support moving forward with >> SF in negotiating an approach that conforms to the boundaries you describe >> below and lead us in this direction. > > Agreed that this is the general consensus. I think that these are different > threads of conversation. > > One thread is the MOU with SF defining what a stable E & T requires including > dealing with the loss of the Oracle based user registrations on which it > still depends. >
Just to be fair, we should ask if Infra@ had a solution for how they would maintain the service "with the loss of the Oracle based user registrations on which still depends"? > The second thread is what does the federated approach look-like. Jürgen has > provided some of what is already supported. I think we need a page somewhere > to show the existing structure. We can't proceed intelligently without real > choices clearly presented. Otherwise we are talking generalities, or making > decisions based on our perceptions of policy boundaries and not technical > merit. The fastest approach to graduation might not be the best approach for > the whole ecosystem. > > While we are on the topic of externally hosted services last week Rory > Flatscher was happy to report that codesnippets.s.oo.o was still functional. > This is an externally hosted site at BestSolutions@ ... > > Regards, > Dave > >> >> Andrew >> >> >> On 1/6/2012 4:38 AM, Ross Gardler wrote: >>> On 6 January 2012 11:52, Ross Gardler<[email protected]> wrote: >>>> On 6 January 2012 09:32, Andrea Pescetti<[email protected]> wrote: >>>>> On 04/01/2012 Roberto Galoppini wrote: >>>>>> 2012/1/4 Jürgen Schmidt: >>>> ... >>>> >>>>> Sounds good. The stabilization phase can be done anywhere, but as Rob >>>>> wrote >>>>> if we cannot keep the current repository as part of the project anyway, it >>>>> makes sense to do it as part of a larger effort. >>>> Can we please put a stop to this meme. Nobody has said that it *can't* >>>> be kept as part of the project. I have no idea why this keeps getting >>>> repeated. There are issues to be addressed, but nobody has said we >>>> can't address them. That's what this thread is about, creating a >>>> proposal for the board to consider and give us an indication as to >>>> whether it would be acceptable or not. >>> Furthermore, please remember that to allow a single third party to >>> host a required service for an Apache project is also against ASF >>> policy. In fact it is quite possibly against the law (I'm no lawyer so >>> this is speculation). >>> >>> The ASF is a charity, as such we cannot do anything that benefits one >>> organisation more than another. Allowing SF to host the *only* >>> extensions site would mean that only SF could make a profit from doing >>> so and thus the ASF would be benefiting SF more than anyone else. We >>> can't slam one organisation (TOO, for example) whilst actively >>> supporting another. >>> >>> So far this thread has made it clear (at least to me) that there are >>> two phases to this: >>> >>> - short-medium term stabilise the extensions code and hosting >>> - long term move to a federated approach >>> >>> Stabilisation needs to happen before the 3.3 release >>> Federation can't happen before the 3.4 release and may not happen until >>> later >>> >>> Rob has suggested we consider accepting the SF offer and asking infra >>> to help with the longer term goal of federation (which was originally >>> suggested by Gav). >>> >>> In this proposal I would like to require that SF open source their >>> work on stabilising the platform (which is their intention, as I >>> understand it). The federation code would be managed here in the >>> foundation. >>> >>> This means that the ASF remains in control of the "level playing >>> field" since we control the point of entry to the federated platform. >>> Others can start up catalogue sites if they want by using the existing >>> Drupal code or by building something else that plugs into the >>> federation site, which could simply be an FTP site and an meta-data >>> file. >>> >>> The downside of this plan is that we lose control over the existing >>> extensions platform, although we can take it back for internal hosting >>> at any point since it is open source. >>> >>> On the other hand if the ASF maintains the Drupal extensions platform >>> we cannot distribute it since it is GPL. We could put it on >>> apache-extras, but that is no different to it being in SF without the >>> SF offered resources. >>> >>> However, infra is not proposing, as I understand it, to distribute the >>> platform. The infra proposal is for the ASF to host a federation >>> platform and for individuals to provide a download location for their >>> extensions (which could be their own website, SF, Google Code or >>> whatever they want). >>> >>> There is very little difference, in my opinion, between these two >>> proposals. The only significant different that I can see is who does >>> the work in the short term. Am I missing something? >>> >>> The middle ground is to have SF do the stabilisation and for the ASF >>> to accelerate the move to a federated site. In my opinion (and it is >>> only my opinion), this model risks slowing down graduation since the >>> federation site would need to be active in order to ensure a level >>> playing field for all. >>> >>> From my point of view the decision hinges on how high up the priority >>> list does the AOO community have a federated extensions site? If it's >>> high and there will be plenty of work on the federation code then the >>> "middle ground" option is a good one. If it is not high then we need >>> to get feedback from the board as to whether my concerns about level >>> playing fields are valid or not. We also need feedback from the IPMC >>> (since legal@ has delegated to them) on whether we can resolve the IP >>> issues relating to distributing non-apache licensed code via an ASF >>> hosted extensions site (my personal opinion is that this will not be a >>> significant problem as long as branding is managed correctly). >>> >>> Is this a fair (high level) summary of the position so far? If so >>> which is the preferred route for AOO? >>> >>> Ross >> >
