Ron,

The board of the ASF do keep taps on each of the TL projects. See 
http://whimsy.apache.org/board/minutes.
The board has insights into all of the projects, whether it is through 
quarterly reports by the V.P., or through ASF members being part of the 
projects' communities, or others mailing to [email protected]. when they feel 
something is structurally wrong within the project. Don't worry about that.

But rest assured that not only the board welcomes it when a project takes into 
consideration the cost of operations related to how they operate. Believing 
that everything a project does is for free and costs nothing is a pipe dream.

But are we not straying from the original intent of this mail thread?

Pierre

Verstuurd vanaf mijn iPad

> Op 13 nov. 2014 om 23:08 heeft Ron Wheeler <[email protected]> 
> het volgende geschreven:
> 
> I don't know anything about the conversations with ASF but I suspect for them 
> it is a policy issue.
> They have 200 projects and don't want to have to follow-up with each one to 
> see when their use of the ASF infrastructure is excessive.
> They don't have the resources to chase each project to verify the source of 
> the SVN traffic.
> 
> They have some projects that get tens of thousands of downloads per day and 
> some that don't have 10 in a week.
> 
> If OFBiz never becomes a "successful" product, there is no problem but before 
> it gets to be the number 2 or three ERP, this will cause ASF a big headache.
> 
> Ron
> 
> 
>> On 13/11/2014 4:51 PM, Pierre Smits wrote:
>> That is not difficult to assess. Do a download from trunk, and see how many 
>> Mb's are transferred. Do a ./ant clean-all. Subsequently remove all hidden 
>> files in .svn folders. Finally do a zip of the cleaned download and compare 
>> the original amount of Mb's with the size of the zip file. That difference 
>> is what is saved on storage and transfer cost of trunk code.
>> 
>> Now multiply that with the number of branches you had in mind.
>> 
>> Verstuurd vanaf mijn iPad
>> 
>>> Op 13 nov. 2014 om 22:32 heeft Jacques Le Roux 
>>> <[email protected]> het volgende geschreven:
>>> 
>>> 
>>> Le 13/11/2014 21:25, Ron Wheeler a écrit :
>>>> Is it Apache's concern that while people may be free to choose, ASF server 
>>>> capacity is not free nor unlimited?
>>>> 
>>>> I doubt that OFBiz really puts a big load on the ASF infrastructure but 
>>>> users are not supposed to be downloading from the SVN.
>>>> They are supposed to get downloads from local mirrors.
>>> You said it :) At the moment I don't fear any overload on the svn server 
>>> from users downloading from releases branches instead of released packages. 
>>> OFBiz is not Tomcat ;)
>>> But I must say I have no measures, so you got a point until-we/if-we-can 
>>> discover that. Because users can already do that, I think it's fair to use 
>>> this method as long as it's reasonable.
>>> Of course, having that suggested in a TLP project could be viewed as an 
>>> abuse from the Board, but let's be pragmatic, numbers should tell us the 
>>> truth (if can get them)
>>> 
>>>> That may be the practical side of Apache's urging to get the releases 
>>>> following their guidelines.
>>> Yes for Tomcat, HTTPD or such that's understandable. For OFBiz I "fear" 
>>> it's not a problem. Can we discuss with the board in case, instead of 
>>> hiding behind unknown numbers?
>>> 
>>> Jacques
>>> 
>>>> Ron
>>>> 
>>>> 
>>>>> On 13/11/2014 3:13 PM, Jacques Le Roux wrote:
>>>>> 
>>>>> Le 13/11/2014 20:03, Ron Wheeler a écrit :
>>>>>> Does this solve ASF's issue about having users access the main servers?
>>>>> I don't try to solve an issue, just to propose an alternative. It's a 
>>>>> free user choice, but with more elements
>>>>> 
>>>>>> What do you put on the mirrors and how do you stop users from accessing 
>>>>>> the development SVN which is ASF's concern?
>>>>> Things stay as they are, it's only that we inform our users than another 
>>>>> way is possible and we give them enough elements of comparison to choice, 
>>>>> it's called freedom
>>>>> 
>>>>> Jacques
>>>>> 
>>>>>> Ron
>>>>>> 
>>>>>> 
>>>>>>> On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
>>>>>>> For the licence free issues (an other related stuff) we could put a 
>>>>>>> disclaimer in the wiki page where all alternatives would be explained
>>>>>>> 
>>>>>>> Jacques
>>>>>>> 
>>>>>>> Le 13/11/2014 12:38, Jacopo Cappellato a écrit :
>>>>>>>> In the past the ASF Board asked to the OFBiz PMC to fix the release
>>>>>>>> strategy of the project by providing officially voted release files 
>>>>>>>> thru
>>>>>>>> the ASF mirrors: at that time we were pushing the users to get the 
>>>>>>>> trunk.
>>>>>>>> Officially asking the user to use a release branch would be better 
>>>>>>>> than the
>>>>>>>> trunk but would bring back similar concerns: an official vote is 
>>>>>>>> required
>>>>>>>> to publish a product to the outside of the project in order to 
>>>>>>>> guarantee
>>>>>>>> License free issues etc...
>>>>>>>> 
>>>>>>>> On Thu, Nov 13, 2014 at 11:38 AM, Jacques Le Roux <
>>>>>>>> [email protected]> wrote:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> In a recent user ML 
>>>>>>>>> threadhttp://markmail.org/message/ivjocjr2ull7lwqe  I
>>>>>>>>> suggested we could propose our users to use a release branch strategy
>>>>>>>>> rather than downloaded packages.
>>>>>>>>> And that we could  expose this way of doing in our download page, or 
>>>>>>>>> maybe
>>>>>>>>> better with a link to an explaining page (in details) in the wiki.
>>>>>>>>> 
>>>>>>>>> I know it's not the recommended way of doing at the ASF. But we all 
>>>>>>>>> know
>>>>>>>>> the OFBiz differences when compared with other TLPs which are mostly 
>>>>>>>>> libs,
>>>>>>>>> and even mostly jars.
>>>>>>>>> Most of us are actually using this way in their custom projects and I 
>>>>>>>>> have
>>>>>>>>> a feeling it would not only help our users but also us to support 
>>>>>>>>> them.
>>>>>>>>> 
>>>>>>>>> What do you think?
>>>>>>>>> 
>>>>>>>>> Jacques
>>>>>>>>> 
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: [email protected]
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> 

Reply via email to