I've seen this discussion a hundred times or so at Apache, whether it's forums issue trackers or version control. The story is always the same: a handful of software artisans want full uncompromising control over their toolchain. Half the time as is true here what they want is already functionally available to other projects. The other half the time what they want is probably being worked on on a voluntary basis so it's progressing too slowly for some version of too slow.
What we need more of in the open source movement are scientific programmers for which an objective reality outside ones own personal biases actually exists. These people already understand why the ubiquity and ease of archival and search available to mailing lists make them a good choice for standardization in our record keeping and official communications. There will always be a place for biased artisans but they need to lead with code not debate. After all git is born out of dissatisfaction with svn, but Linus wrote the tool instead of simply publicly whinging about his hatred for svn. Sent from my iPhone > On Jan 18, 2015, at 11:34 AM, David Nalley <da...@gnsa.us> wrote: > >> On Sun, Jan 18, 2015 at 11:19 AM, jan i <j...@apache.org> wrote: >> 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. >> >> > > I agree that those principles need to be at a high level and not worry > about tools directly. You can't, however, avoid the fact that it has > to be applied. When Infrastructure (as opposed to a project) deploys > something, we have to do so with the knowledge that 1 or 200 projects > may make use of it, and we have to be able to scale with it. > > Could projects use forums, in the strictest sense of the word, almost > certainly; and some already do for certain types of communication. A > good example of this is website publishing. That's all done via > svnpubsub today. Lots of projects use git for source code and would > love to use git (and gitpubsub) for their website publishing. > Technically that isn't a difficult thing to make happen. However that > adds much complexity to the work of the group that has to maintain > that infrastructure, and thus we won't be doing that. Yes, that means > we aren't as agile as we'd like to be, but hopefully it benefits us in > the scale department over the long haul. > > --David
