Here are my notes from the discussion. Please feel free to edit if I misunderstood what you were saying!
-----------
tight maintenance branch (very careful selection and QA) ... but not maintained without a planned release
2.0.2 didn't happen because everyone was focussed on 2.1... not enough developers (time).... there was no plan for a 2.0.2 release
production branch: the last release plus things that could be in production but haven't been through release QA. Make point releases with QA periodically or as necessary
the big diff: there aren't tags and QA and packaged release artifacts every two weeks. (GGolden) There are two separate types of QA: central and institutional.
Seth T: thinks it was hard to evaluate 201 because there was no plan for the follow-up. It's good to have packets you can pick and choose for updating.
David thinks patches were hard to find and hard to contribute.
Beau Patrette: thinks that one problem is correlating info about the bugs that exist; many bugs manifest in different ways across different tools or databases. Bug fixes are tough to be informed about when they are not stored in a consistent place in the SCM. Patches are helpful but confusing if not clearly applicable to the branch/tag that you are using 1.5.x -> 2.0.1. QA'ing specific functionality once a patch is applied adds to the labor required to deploy. Fixes stored in branches outside the main are often valuable and should be integrated into the mainline to maximize community benefit.
GGolden: JIRA is useful, but it's impossible to be sure which bug fix to use for a particular bug. If someone like Lance or Glen were to merge those patches onto production, it would be much easier for the institutional developers.
GGolden: CTAG (the group who approves of which patches to put on production) is extremely conservative. Contrast with Indiana who takes risks with modifying their production code.
GGolden: Lance has been making exclusive decisions as to what gets merged onto the production branch. Soon Glen will join Lance with that responsibility. Anyone who wants to adopt the official prod branch can do so, and those members can help eachother out.
Seth T: We run 2.01 stock release at columbia. It's helpful to be working with a known quantity.
GGolden: If you want to be on the cutting-edge of the branch, you need to be very much on top of development, whereas if you want to wait for the official releases, it is much easier.
Seth T: It is nice to be conservative, but frustrating when updates never happen on that branch (when everyone develops for the next big release)
GGolden: we probably can't afford to do a lot of wide-reaching QA.
GGolden: the institutional implementor is ultimately responsible for testing. It helps a great deal to know the QA that other institutions have done.
Beau Patrette: does unit testing, agrees that people need to do their own testing. Still, everyone will have their own local configs and tweaks.
Seth T: QA has been divided into two areas: functional QA (contributes lots of bugs to JIRA) and deployment QA (basic tech compatibility). Making the results of your tests public would be extremely helpful. Benefit of the prod branch is the security and performance issues that periodically get fixed.
GGolden: three directions:
- trunk: wild west... the build must build and run, but it is probably not stable
- branch: picking and choosing from the trunk
- production: - stability
re: Eric's official patches idea, GGolden says svn merging is pretty powerful and helpful... if you've decided to make mods of an official branch, then you must stay on the cutting edge of things.
Seth agrees that SVN is very helpful for creating patches for your heavily-modified branch version to adopt changes that were made to an official branch.
David Knoop: feature requests should inform your development choices... look on JIRA for ideas to see what people want. It's tough to actually get work done on those things.When a feature request is adopted by a developer, it gets changed to a "task".
Duffy Gillman: Hard to predict what work will be done in the future because there are no mandates on the community developers.
GGolden: agrees, especially because the community is so much larger now. Our software is in better shape than our process.
David: doesn't sense (based on this discussion) the demand for a frequently-updated prod branch.
Seth and person from UCDVM: Have some set of automated local patches you can apply to the production releases so when you upgrade, you can easily apply your local changes.
GGolden: there is basically no plan for those three-digit releases.. it's more of a criteria for when things come up.
GGolden: points out that when people see there is a new three-digit release, they assume there is QA behind it... but the dev community actually needs to do that QA!
Beau Patrette: points out that it's important to know which platform is in use at each QA site (oracle, mysql, tools, etc).
GGolden: don't get fooled by hibernate's claim of database-modularity... you need to test all platforms to be sure it is working!
GGolden: one of the best things about having a production branch is that we all get to move together as a group...