On 29 September 2011 15:03, Vitaliy Margolen wine-devel@kievinfo.com wrote:
I can think of few things can be implemented right away and see how it goes:
A lot of these seem like a great way to slow wine development down. Honestly I think better investment in automated application testing would be more helpful to the project (I'm just an outside observer of course). I know cxtest didn't really work out, but Scott Ritchie has talked of some very straight-forward scripted testing of apps available in winetricks which seems sensible. Additionally, you could imagine checking a large library of game demos that 1) they don't crash 2) some sort of sound output is produced. It's a weak test, but it could be easily automated.
- Longer release cycle. Lets start with 3-4 weeks and extend if needed.
Allow any new features first week of the release cycle only. Next two weeks are bug fixes and stabilization before release.
Or have same 2 week release cycle with every other release being release candidate and code freeze for the second 2 weeks to stabilize it.
This is actually not a bad idea. I think that currently changes which are likely to break things mostly end up in the first week of the two week cycle, but then not many users test (with some notable exceptions, like GyB the one-person regression-hunting machine). 1.3.odd releases having larger changes with more likelihood of breakage than 1.3.even releases (hopefully fixing any reported issues) does sound worth considering.
- All regressions should be treated as blockers. And fixed before next
release. If a regression is in some other area then patch introducing regression, no patches should be accepted from anyone else to the area in question until this regression is fixed. Or a work around found.
People complaining about the difficulty of getting a patch in to wine already seems to be an issue. This all sounds a little arbitrary to me. I do subscribe to wine-bugs and it seems to me that most bisected regressions get addressed promptly.
Alex