On Wed, Dec 18, 2013 at 4:00 PM, Martin Gregorie <martin@xxxxxxxxxxxx> wrote: > On Wed, 2013-12-18 at 14:38 +0100, Hartmut Figge wrote: >> Regarding regressions, i am compiling SeaMonkey, much more code than >> wine, nearly daily. Unless there is a bustage. Currently there is one >> since 5 days. >I'm not as bothered if a developer build breaks or fails regression >tests, though IMHO changes that do either shouldn't be committed, as I >am if a release candidate gets published while its still failing >regression tests. > >> Regressions do occur there and it takes time to fix them. And there is >> the issue with using much of the code from Firefox and Thunderbird, >> which changes often and has the tendency to damage SeaMonkey. Sigh. >> > Indeed, but: > (1) devs that commit code that breaks a compile or fails regression > testing deserve a warning followed, if needed, by having their commit > privileges revoked. Yes, I know they may be volunteers, but does any > project need devs that make such gross mistakes Checking for regressions for every commit, given the amount of work needed, isn't feasible: there are a lot of windows programs in existence, so regressions inevitably happen... you can't test them all for every commit, and it can be very difficult to automate, if possible at all. There are a lot of unit tests in the code though, which are run for every commit. And FYI non-compiling code isn't committed... And only the project leader has commit rights. Kicking developers out for every regression... If one would do what you suggest, I guess you would be the only Wine developer remaining?!? Good way to kill a project... When regressions are reported (http://bugs.winehq.org), they are usually fixed quickly, especially when they are reported quickly after they appear. Remember 1.7.x series are *development* releases... regressions can happen e.g. when someone adds a new dll: some programs which would work previously because they workaround the missing DLL might not work when that (stub) DLL is added. If you want to avoid regressions at all costs, stay with stable branch (1.6.x). Use development versions at your own risk. > (2) publishing a version that fails regression or has incomplete changes > testing is a really good way to destroy its reputation. Gnome 3 anybody? IIRC the issues with Gnome 3 was released as a stable version with a lot of bugs. Wine development releases ARE NOT stable versions. >> In wine itself i had the luck to meet regressions very seldom. And >> regressions *are* fixed. See the release notes of wine-1.6.1 from Alexandre. >> > I've regularly seen apps that initially ran OK gradually develop runtime > faults and eventually stop running altogether. My apps weren't changing > at all, but the current Wine version certainly was. Nobody forces you to upgrade your Wine version. You can keep an old Wine version for some apps, and even distinct versions on the same system (as a developer, this shouldn't be difficult for you). Moreover, if you find a regression, please report it on http://bugs.winehq.org/. Not everybody runs the same applications as you do, again checking every app in existence is just unrealistic. >That certainly looks > like a failing in the regression test system to me: I don't tolerate > that in my own code, so why should I put up with it from others? >> Maybe there exists a lack of developers and likely they are all >> volunteers which cannot be forced. >> > As I said above, volunteer dev or not, does any project need devs that > don't follow the project standards and procedures? > > Martin It seems you don't know much about Wine development procedures, if at all. Please inquire about them before criticizing so harshly. They do exist, and are very much enforced. Look e.g. on the wiki for more information. Feel free to suggest improvements on Wine development standards/procedures on the wine-devel mailing list, or on IRC (http://wiki.winehq.org/IRC). Regards, Frédéric
