Markus M: > My ;-) was kind of a teaser. I regard 6.4.svn as more stable than > 6.4.2.
I don't think it matters much, but for the purposes better discussion I think it's worth pointing out that I am perhaps using a slightly different definition of "stable" than you. To me, "stable" includes well tested, bugs (and perhaps work arounds) are known. Untested code with bug fixes applied is to me less stable, and I would not give it to a new user or use in a production environment since it hasn't been through the same QA labors. That's not to say that either definition is better than the other, or others should make recommendations following my thoughts on the matter, just the definition from the POV I'm looking at it from. > You said that there is no stable 6.4.3 that a user could see. > [This is directed at all other devs:] Then we should make sure that > there is a stable 6.4.3 that a user could see. [devil's advocate] .. why not just do away with releases then and promote the nightly builds as a rolling release? [no, I'm not really suggesting that] but really, for the stable release I'd be happy to see monthly releases to add in new bug fixes (but only bug fixes :), subject to longer or shorter cycles depending on how important the bugs found in that cycle were, eventually trailing off to infinity like 5.4.x. I was under the assumption that there were no major bugs in 6.4.2, so hadn't been too worried that it has taken a bit longer. I had hoped the broken addons repo for the MS Windows version could be taken care of by a quick 6.4.2-3_setup.exe rebuild, but that didn't happen. The news that there was a flaw in the wxGUI is news to me in the last few days, and I would have pushed for a smaller-but-faster 6.4.3 release sooner if I had realized that there were important bugs holding people back. > At the the very least, please release 6.4.3rc1 before yesterday > (commonly used deadline definition). anyone have ideas on this one? #1692 calling a script within a script failing on Windows XP v.db.* and lots of other fail. wrt blockers, I'd take the stance that it just has to be less-broken than 6.4.2, releasing a 6.4.3 with known flaws that were also in 6.4.2 is not the end of the world, but it is useful to harness the pre-release energy to try and fix such things. I'll note that I had been using devbr6 for experiments and adding debug messages in ways I'm not comfortable doing in the 6.4 release branch to investigate this particular bug (hmm, actually it might have been the clean_temp.exe bug. no matter). Then I'd wait for the next nightly build, test, and repeat. Helena: > After reading through the entire discussion I think even Hamish would > agree that there is a broad consensus that the number of branches needs > to be reduced (as I read it, it should be grass64 and grass7) There is no support for that from me. Devbr6 (I'll try to stop calling it 6.5svn, we had a discussion about that months ago) is highly useful to me, I use it almost every day, and I'd be very upset and inconvenienced if it were removed from svn. It has maturing code aimed for future stable releases beyond the immediate next one, and backporting fixes from trunk directly is not always a trivial task. (e.g. see r52853) > and the sooner it is done, the fewer problems and confusion there will be. please, just let it slip away into old age and irrelevance in peace like devbr5_5 ... I think too much is being made of it, primarily because have been distracted by other work and left small bugfixes too long waiting to be backported, which accounts to many of the 'problems' -- the gardening I'd quietly been doing there had been left unattended for while and started to fall on other people. In general I am quite happy to volunteer to maintain the stable branch(es), even if I have to do that alone, but from time to time the day job and real life pull me away so it is not always as immediate as I'd like. wrt the 'confusion' issue, I fully agree that the downloads page should be cleaned up, and 6.5 de-emphasized there to a single line. I'd already added discouraging "(restricted development; testbed for backporting, ... Utility version for developers." text to it, and would not at all mind its table being reduced to a simple link to http://trac.osgeo.org/grass/wiki/DownloadSource#GRASS6.5 even though, as mentioned above, the nightly Windows builds of it have helped me to work on bugs in 6.4 in the past, in an environment where I could experiment safely. As for releasebranch_6_4 (calling it 6.4.3 is confusing I think), IM 2c O that should also be a one-liner on the download page, but if there are pending (important) bug fixes we should aim for minimal-change monthly releases, instead of long waits between big releases and then higher- stress to get them out the door. wrt cutting a release branch for trunk, IMO to avoid double merging that should wait as long as possible until we have identified release goals and are nearing the bug-fixes-only stage. Even then we can rely on personal discipline for a time instead of needing a special branch. thanks, Hamish ps- hot off the press, checkitout: http://live.osgeo.org _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
