On 4/5/12 1 :21PM, "Dave Fisher" <dave2w...@comcast.net> wrote:
> >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 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 >> >
