On 18 January 2015 at 16:48, Ross Gardler (MS OPEN TECH) < ross.gard...@microsoft.com> wrote:
> There are many reasons why the ASF requires projects to use its own > servers for some items. For example, we couldn't use GitHub until we had > built a system that would provide adequate traceability of contributions. > > Failure to do that would have meant it was no longer possible to provide > the legal umbrella necessary to protect developers and reassure users. > > Such work takes resources. > > Add to that the fact there is no guarantee that an external service will > still be available, in an appropriate form, tomorrow. There is therefore a > risk that projects will be damaged by decisions outside of our control. > > Replacing such lost services requires resources. > > Finally, one of the advantages of the ASF is that once you know the core > principles of how one project works, you know them for all projects. > > Our response to these issues is to require projects to use ASF provided > services for essential items. > > What has been unclear is what are these essential items and what can our > projects expect from the ASF in the non-essential areas. David Nalley and > I, as part of our budget planning, are working on identifying what is > considered core and what is not. This will help address the confusion and > therefore make it easier for project communities to decide whether they > can use external services. > > What we will not be doing is relaxing any of our rules designed to protect > the independence and legal governance of our projects. > Relaxing would be wrong, but maybe look at tools we require as part of the rules. Not long ago GIT was a not well heard word at ASF, and look where we are now. Rules should define what our requirements are, not the tooling used to reach the requirement. Mailing list is a good example of that, while I agree to the fundamental rule about openess etc...I cannot see why that can only be done on a mailing list. When I speak with new people (like myself), most people find the principle of our rules very good and needed, but not the mixing of rule and tool. just my 2ct. rgds jan i. > Sent from my Windows Phone > ________________________________ > From: Jay Vyas<mailto:jayunit100.apa...@gmail.com> > Sent: 1/18/2015 7:37 AM > To: dev@community.apache.org<mailto:dev@community.apache.org> > Subject: Mailing lists, sites, ... > > Hi Apache . > > Every so often we get the question come up: does Apache infra > allow/support ____. The answer is sometimes "not yet" and related to the > fact that there are 100s of projects that require uniformity at Apache, and > it would be chaos of every new project was allowed a new infrastructure. > > Idea: > > Now that project infrastructure is easier using things like github and > static sites or google groups forums etc.... Maybe the ASF could loosely > agree to support some types of "alternative" project tooling, as long all > project conversations and decisions and artifacts were centrally archived > at Apache?This can easily be done by simply adding an Apache email address > to a monitor a particular forum , or github issues notifications or > whatever. > > Benefits of looser grip on community infrastructure: > > The main benefit of Apache in a post github era is not the storage and > mail servers - it's the centralized archiving, community process, and > transparent workflow. And those things can be implemented with any > technology. > > So, my general thought is : Apache still can enforce its core principals > while loosening some of the more granular rules around infrastructure . > Maybe the time is now (or maybe not) to start allowing projects to branch > out their tooling ... While still supporting the tried and true mechanisms > and not pressuring infra every time someone wants to use some new email > alternative or site hosting solution. > > In any case looking forward to feedback on this from some Apache veterans > . > > > > >
