On Apr 5, 2012, at 9:12 AM, Alex Harui wrote: > > > > On 4/5/12 7:12 AM, "Bertrand Delacretaz" <bdelacre...@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 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 >
