I’m loving the ideas and energy on this list so far. And so, the subject
question needs to be answered: What should we (the committers in this project)
do first?
I recall from the summit that a healthy Apache project releases at least every
4 to 6 months, and one of the things an incubator podling has to do is cut at
least one release so it can show it knows the Apache way of doing so. So,
while we’ve got lots of good ideas out there around refactoring Flex, lots of
those seem like more than a 4 to 6 month project. They should certainly get
underway, but we also need to make sure we make enough useful, short-term fixes
to be worthy of a release so we can practice making a release. I’m thinking
that means we pick off a bunch of bugs to fix, and maybe take a new component
or two or three.
To do so without getting de-stabilized by the longer term projects, we should
agree on a branch strategy. It sounds like many Apache projects have multiple
branches like:
-Sandbox: Anything that doesn’t fall over immediately can go here
-Unstable: Things that are being polished for release can go here
-Stable: The release candidate goes here.
-Released: The latest release.
Long term projects would go in Sandbox and shorter term stuff would go in
Unstable and get synched to Sandbox if required.
Most of you are volunteers trying to scratch out spare time to make
contributions, but some of us have all day to work on this stuff. I am
thinking of splitting time between long-term work and short term work and use
JIRA to guide what short-term work I do.
So, add your thoughts on branch strategy (especially Apache veterans). You can
discuss your favorite short-term project if you want, but what really matters
is whether you’ll get around to committing it. And of course, this is all talk
until we get cleared to submit the code and get JIRA up and running.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
