>> Another angle to explore is whether it would be ok from an Apache >> perspective to simply do our work on the public GitHub and only copy >> released sources back to either Apache SVN or some simpler Apache Git >> installation > > > I would have trouble with that approach and I suspect the board would too. > We want development to be open and transparent. The way we accomplish that > at Apache is for commit messages and code discussions to take place on the > mailing list. In this way we know code is being developed in the open by > watching the mailing lists. I've never used GitHub. It doesn't have a way to monitor commits that couldn't send a notification to flex-commits@?
> But they want to change it without sacrificing core tenets of > the Apache Way. So this is not easy and it won't happen overnight. But > there's good reasons IMO for us to stick with the program instead of trying > to do an end-run around it. I didn't see it as an end-run. But I have been trying to understand how much of the Apache Way is tied to Infra. As you know, I've been complaining about centralized Infra for the whole time we've been in incubation. Meanwhile, some topics like signed binaries, while they are being worked on by Infra, have at least temporarily been foisted out to external entities like the companies that sign binary distributions of SVN. With all of the new projects I see entering Apache, I wonder if Infra is going to collapse from all of that weight. So why not off-load Infra by using GitHub for some things? Here is a list of other things I've been thinking about regarding Apache infra. 1) JIRA Import. We still don't have the attachments imported for old bugs. The last two pings on INFRA-4380 have been unanswered. 2) JIRA SubProjects. All of our JIRA issues are listed as FLEX-nnnnn. Yes, we could push for FALCON-nnnnn and some other things like that, but that doesn't scale well. When you go to enter a new bug, imagine how many choices there will be if all of these other new Apache Projects also need different JIRA subproject prefixes for different things. Some Apache projects should share a JIRA instance since bugs may be more frequently misfiled and transferred among projects, but for some like Flex, I think we would be better off on our own. 3) CI. We have to share a server that keeps going down. I'm seriously thinking of hooking up some old machines and doing CI on my own hardware. 4) Custom web-services. There are flex tests that need to talk to a server in order to test web-services APIs and security. I've been thinking of paying for my own domain to host these things. 5) Showcase apps. If we want to have a set of showcase apps on our website, they will also want to talk to custom web services on the backend. 6) Custom web-sites. Flex is still currently about Flash. Is it even possible to put Flash on our Apache Flex web-site? So what are really the minimum requirements of the Apache Way? For sure the mailing lists and voting and the processes for earning committer-hood. And that source code for releases and release packages are on Apache hardware. Other than #1, I have not approached Infra since I get the sense they are way overloaded since they have not replied to pings on #1. But I'd appreciate your thoughts on how to approach Infra and/or how to help Apache change. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
