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:05:33 GMT

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.

Please, Apache is a volunteer organization. The secretary is a volunteer. Did you give the
ASF secretary a heads up that the signature was coming and you wanted an expedited approval?

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

How would 1000 separate SVN servers work?

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

Personally I don't understand the waiting. JFDI.

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

I think that you can certainly reword the report to indicate that delays in importing the
large JIRA database are a concern.

The main scalability is the number of paid Infrastructure consultants. AFAIK this is now 3.5
people in addition to numerous volunteers. This is for 100+ TLPs and over 50 podlings. I don't
think that it helps to call into question scalability of volunteers. It helps to understand
that it will always be an issue.

The report should focus on the podling's concerns. The IPMC can then note that you need attention
that will help.

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

When did you have your last discussion with Infrastructure about JIRA? Was it the conversation
from a few weeks ago that I tried to kick start? We'll have to get back to that. Sorry if
I've been focused on my $job and Apache OpenOffice and stopped pushing that issue with Infra.
I'll get back on it later today.

Deep breaths, have patience.


> -- 
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui

View raw message