Re: [Audacity-devel] VC2012 and wxWidgets30
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Martyn S. <mar...@gm...> - 2014-02-23 23:51:06
|
+1 to what Vaughan said. Let's not even put VS2012 and wx3.0 stuff in before the 2.0.6 release, but go for it wholeheartedly afterwards. Just have 'submitted patches' until then. TTFN Martyn On 21/02/2014 01:52, Vaughan Johnson wrote: > On 2/20/2014 1:40 PM, Andrew Hallendorff wrote: >> >> On 2/19/2014 7:52 PM, Vaughan Johnson wrote: >>> Very much -1. There's already a great deal of new stuff in 2.0.6-alpha. >>> Even with the possible safe encapsulation via #define (and we've seen it >>> fail before), I'm opposed to adding substantial changes until we release >>> 2.0.6. >>> >>> And I think we should release 2.0.6 soon. That requires some discussions >>> on team@, not here, though. >>> >>> - Vaughan >>> >>> >> >> Let me just say my management skills are suck. > > Ha-ha. Way to sell your capabilities! ;-) > > Seriously, though, thanks for the humility. > > >> >> However, one plus about getting groundwork into a release is, there are >> outside people who build off a release ignoring the day to day changes >> that go in between those releases. > > Well, let's clarify. We're talking about whether to put these changes > into the source code repository, not whether to release them in 2.0.6. > These changes would definitely be turned off in the repository, and for > 2.0.6 release builds. > > >> If a simple switch allows them to >> experiment with a new platform, it leads to more people getting familiar >> with that change. > > But in your intermediate email, you wrote "General statement: It's been > a while on some of these changes and my code has some creep. Basically I > need some time to do work." I think that's clear from the details you > described. > > I read that as not ready for people to even start playing with really, > even from SVN. So please, for James and whoever wants to work with you > on it in it's current state, do a branch or do it offline. > > I'm very much in favor of doing it via our traditional EXPERIMENTAL_* > flags. I'm not opposing adding the changes. I just want it to be > (immediately) after we release 2.0.6, if it's ready. > > I hope we're close to releasing 2.0.6. I think it's overdue (for good > reasons, but still, about a month overdue). I do not want to add a lot > of incomplete code to the repository as it would almost certainly delay > 2.0.6. > > > Several times, we've run into big chunks of #ifdef "turned off" code > added late in the release cycle, and as carefully as we thought it had > been reviewed and tested, it has shown to not be and we've had release > delays, support nightmares. and needed embarrassing hotfix releases > shortly after release. > > Not surprising, because it's been shown for decades of software > engineering case studies that adding a lot, close to a release, greatly > increases the risks of that release being unstable. It just has too > little time for code review and alpha testing. > > > If you push it out past a release, many of those who >> were inclined to do so, may not. > > I'm suggesting that if it's actually ready by the time we release 2.0.6, > put it in the source repository immediately after. It could even still > be crashing then, to be cleared up in the 2.0.7-alpha period. Point is, > it would add no risk to 2.0.6. > > Anybody who's sophisticated enough to figure out how to build Audacity > is sophisticated enough to get it from the repository then. > > >> I stand by my changes, as experimental >> as they are, I was way way overly careful in the way I entered them. If >> and when you see them, I'm sure half the feedback I get is why didn't >> you just make that change? > > Not from what I saw in your description in your previous email, or the > descriptions of how much work it was in prior ones, or the many places > that are obviously a correct change. > > >> >> You did commit one change already. > > Yes, one small change, that was obviously a correct change. And to note, > I didn't make your change, I made a simpler one. That's just to point > out it will need a lot of developer review, as well as testing. > > I don't want the review of a lot more of these to delay 2.0.6. And > again, no matter how careful you were and how carefully we review them, > it introduces unnecessary risk into releasing 2.0.6. We don't want that, > we've seen the bad results. > > >> >> As to previous define fails, it happens. People make mistakes, you >> really have to weigh the risk vs reward. Although at the moment the >> reward is not overly high, the risk, as I've coded it is much much lower >> than that. > > No-risk vs totally-unknown-risk is an easy decision, in terms of doing > releases, especially for low reward. > > I say 'low' reward instead of 'not overly high' based on how many > developers would be delayed in getting to play with it, vs the millions > of users who would have unknown increased risk. > > >> >> The biggest negatives that I can see. > > Thanks, but we've seen this movie before, and it's far wiser to be safe. > If we had a tiny user base, I'd have a different opinion. > > As I wrote, I do not think this is practically a significant delay for you. > > >> >> I have to resolve all my changes from work I've done elsewhere. I cannot >> create a patch without editing out other changes. >> >> As much as reviewing the 60-70 changes may be tedious, the ability to >> resist resolving the define will be greater. > > I'm just asking that the extra work load for you and the TLs be delayed > for what I hope will be just a few weeks. > > And to be clear, thanks *very* much for the contribution!!! I very much > want us to make these upgrades. But not delay 2.0.6. Thanks! > > all best, > Vaughan > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |