flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: Board report, "Apache internals are starting to become a problem" ?
Date Thu, 05 Apr 2012 17:43:17 GMT

On Apr 5, 2012, at 10:29 AM, Carol Frampton wrote:

> 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.

I sent an email to infrastructure suggesting we start exploring options like a project specific
VM and separate JIRA instance. I've experience with JIRA configuration at work, so I can help.

There could be two goals that Infra could accomplish:

(1) Get Apache Flex it's JIRA instance.

(2) Explore a supported configuration.

But then it isn't clear what part of the configuration Atlassian does not support. JIRA runs
on Tomcat and a Database. Apache is likely to run the most advanced and secure Tomcat. Likely
before almost anyone else. Or it could be the Database. Or, the JVM. Or, the OS.

If there are any JIRA / Tomcat folks on the PPMC who can help then it would be good to know
it now. The more volunteers to help with Project specific Infrastructure requests the better.


> 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

View raw message