Woo. September 30th will be a 3.4.0 release candidate, right? Who gets to
be release manager this time?
I think the general consensus was *not* to branch 3.4.0 off of trunk, but
to leave it in trunk, and just do releases from trunk for a while?
Time to wrap up some last minute bugs. Which ones actually need to get
closed for a release?
My $0.02:
re: 3.4.0RC. Hard to say if it's 3.3.X or a 3.4.X. We have the minor
API change with one variable is about the only reason to call it 3.4
because that API change needs to wait for a major release. I'm not sure
ANYTHING else classifies as a major change.
I'd like to make a goal to get sa-update a lot cleaner and ipv6 native
release which I'm working on infrastructure for and call it 3.4.x.
re: Release manager. We still have a cart before the horse issue on
release manager due to the key signature. The number of people who can
sign a release is dramatically too low. I might step up as the manager
so I can document more of the process and so we have more hands making
light work
re: leaving 3.4 as trunk to me makes sense. We have nothing major
enough in the works to justify otherwise EXCEPT our r-t-c rules for
branches vs trunk. I could argue it either way which probably means I'd
vote to maintain status quo (i.e. to move trunk to a branch and create a
new trunk).
Regards,
KAM
