Mailing lists, sites, ...

[Jay Vyas <ja...@gmail.com>]

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 .

Re: Mailing lists, sites, ...

[Branko Čibej <br...@apache.org>]

On 18.01.2015 18:10, Joseph Schaefer wrote:
> 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.

You mean, "as well as," not "instead of." :)

-- Brane

Re: Mailing lists, sites, ...

[Joseph Schaefer <jo...@yahoo.com.INVALID>]

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 <ja...@apache.org> wrote:
>> On 18 January 2015 at 16:48, Ross Gardler (MS OPEN TECH) <
>> Ross.Gardler@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

Re: Mailing lists, sites, ...

[David Nalley <da...@gnsa.us>]

On Sun, Jan 18, 2015 at 11:19 AM, jan i <ja...@apache.org> wrote:
> On 18 January 2015 at 16:48, Ross Gardler (MS OPEN TECH) <
> Ross.Gardler@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

Re: Mailing lists, sites, ...

[jan i <ja...@apache.org>]

On 18 January 2015 at 16:48, Ross Gardler (MS OPEN TECH) <
Ross.Gardler@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<ma...@gmail.com>
> Sent: ‎1/‎18/‎2015 7:37 AM
> To: dev@community.apache.org<ma...@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
> .
>
>
>
>
>

RE: Mailing lists, sites, ...

["Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>]

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.

Sent from my Windows Phone
________________________________
From: Jay Vyas<ma...@gmail.com>
Sent: ‎1/‎18/‎2015 7:37 AM
To: dev@community.apache.org<ma...@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 .