incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carol Frampton <cfram...@adobe.com>
Subject Re: Board report, "Apache internals are starting to become a problem" ?
Date Thu, 05 Apr 2012 17:29:31 GMT


On 4/5/12 1 :21PM, "Dave Fisher" <dave2wave@comcast.net> wrote:

>
>On Apr 5, 2012, at 9:12 AM, Alex Harui wrote:
>
>> 
>> 
>> 
>> On 4/5/12 7:12 AM, "Bertrand Delacretaz" <bdelacretaz@apache.org> wrote:
>> 
>>> 
>>> I don't think it's fair to blame the secretary or infra for that - a
>>> few hours delay in recording a code grant is certainly acceptable, and
>>> infra requiring big svn imports to happen on weekends for minimal
>>> disruption sounds totally reasonable to me as well.
>>> 
>>> Those big svn imports do not happen every day, so it seems ok to have
>>> to plan them a bit in advance.
>>> 
>>> I agree that the overall delays in getting the code in svn are
>>> frustrating, but secretary/infra is only a minor part in that IMO. And
>>> in the meantime people can play with the copy that Carol committed
>>> anyway IIUC.
>>> 
>>> My suggestion: tone that down a bit, and remove the secretary bit
>>>completely.
>> My goal isn't to blame any set of individuals, but I think the process
>>is
>> cumbersome given this is 2012.  If the actual deadline to submit a
>>grant in
>> order to make a weekend SVN import is Thursday and not Friday, that
>>really
>> needs to be known to all future podlings.  It is no fun to ask a VP to
>>come
>> in on his vacation to sign the grant and then have it be for naught.
>> 
>> I also don't get how SVN scales for 10 years down the road with 1000
>>more
>> podlings and 1000000 of files.  The maintenance and overhead and maybe
>> performance of the server might be prohibitive.  Why not assign podlings
>> their own server and give import rights to a few select folks?
>> 
>> Folks know the code is on the whiteboard, but there is a tendency to
>>wait
>> until it gets into the trunk.  We want to try to start building and
>> packaging a release from the trunk and now we are waiting another week.
>> 
>> I'll think about how to re-word this section, but I still think there
>>is a
>> scalability problem that is impeding us.  The podling doesn't have
>>enough
>> autonomy around its own databases.
>> 
>>> 
>>>> ...The same holds true for the bug database as well.  We have been
>>>>waiting
>>>> for the bug database since Feb 1.  A gating concern is that our import
>>>> of 30000 bugs might take down the main JIRA instance.  Having
>>>>distributed
>>>> JIRA instances would scale better...
>>> 
>>> Here I agree that INFRA-4380 seems to be stalled. At some point IIRC
>>> we discussed the alternative of importing issues via jira's RESTful or
>>> other API, throttling to avoid putting too much load on the instance.
>>> Has that been pursued?
>> Infra refuses to let us try to import this many issues, even throttled.
>> Again, another example of the scalability issue.  If we had our own JIRA
>> instance, we could try things without taking down everybody else.  I
>>don't
>> know how many issues are in the rest of Apache JIRA, but we're about to
>>jam
>> in 30000 issues.
>
>Please recall that part of the trouble is that JIRA is not open source
>and Apache is waiting on Atlassian for a bug fix.
>
>Please see the notes from Monday on the issue:
>https://issues.apache.org/jira/browse/INFRA-4380

If I read the recent note from Tony in INFRA-4380 correctly, Apache is
running JIRA in an unsupported configuration.  To me that means it is
unlikely there will be a bug fix forthcoming from Atlassian.

Carol

>
>It is not forgotten. If it is time to discuss alternative approaches with
>Infrastructure.
>
>Regards,
>Dave
>
>
>
>> 
>> -- 
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>> 
>


Mime
View raw message