Mortiz wrote: > How about my proposal from a few weeks ago: Nobody commits to > grass64release, only to grass6dev, and Hamish is the official > maintainer of grass64release and decides what can be backported ? > > This obviously can only work if Hamish has the time, so that 6.4.4 > is not stalled for lack of manpower.
Well, I don't like being the sole gatekeeper, both for community and logistical reasons. I am happy and pleased for everyone to backport, as long as we can all be working from the same ideas about where we are in a freeze and what our expectations for it are. Which is primarily (and luckily) a solvable communication problem, and not a structural, technical, or personality one. Having said that, if people find backporting to 6 is too much of a pain, simply leave a ticket open with the next release as the target version and a request to backport and I'll try to take of it for them, in $unknown time. Through bitter experience and brown bags I'm now really strict with myself about committing anything, no matter how innocent looking, to the release branch. What has been driving me nuts is spending all these hours carefully testing and trying to spend a lot of energy on attention to detail, and to then observe other developers just come through with a bulldozer and commit stuff haphazard all over the garden I'd just spent so many hours cleaning up. If all that time ends up in a hole, why bother? I note a revert needed in devbr6 where a number of features-in-testing (64 bit support, stat() checks in libgis, ...) recently got blown away by a mass backwards-sync with relbr64. I can't tell you how demotivating it is to have all those hours of work ignored and removed. Now I have to spend even more hours putting them back by hand, because I doubt any one else would care enough about devbr6 to fix it. This is not fun, and if it is not fun I have to remind myself what I'm doing here. So in the last weeks instead of working or even thinking about that stuff I have concentrated on what I really do enjoy, the creative outlet aspect of coding. Having to be the guy who says "no" all the time really eats into my enjoyment of working in a team, I hate it, it's not a healthy way to be. For sure I play it a bit too conservatively some times, and unadvertised devil's advocate others, and it is noted that this slows down releases, which frustrates and drops motivation in others too. But I'm ok with not having to be right all the time about where the right balance is since I can relax knowing everyone is doing what they consider to be best and positive, and they are really smart and often right about it. And it is frustrating to me too for the releases to take so long, especially since I know some of it is me saying "no" but not having the extra time to do the review and edits to help solve the issues, many of which are of my own making. It's a classic question I don't have an answer to: we can use the time just before a release as a huge community motivator to get all the last minute bugs fixed and all the last minute things people wanted to see in before the next release. But at the same time it's the absolute worst time to make changes which can't have time for testing. So how to harness all that energy without breaking anything by accident? My personal strategy has been to divert non-critical things in to release+1, then soon after release go through the devbr and backport it all. Yes it slips a release which may be many months apart, but I treat it like AGU meetings: you can't be everywhere and do everything at once, so it's ok, do what you can and enjoy it guilt free. Then there are things like the parallelized shell scripts in devbr6 which are wonderful and seem to be working fine, but I've not backported them because I don't know the answer to allow SIGINT to also kill the subprocesses. From the command line with `top` and maybe gkrellm running as a cpu/process monitor it's pretty obvious they are still going. But from my testing of the msys/bash background& a series of jobs + `wait` strategy with the wxGUI on MS Windows (it works!) that if you forget to change the computational region away from 1 meter, as is easy to do there, the r.univar job is going to take hours. So after a while on 1% done you press the "stop" button in the module's gui window but the children keep going in the background. Probably most Windows users wouldn't notice that, only that the machine got slow. So I don't have an answer to that problem and thus the new code remains waiting in devbr6. (I'd note parallelized python scripts in grass7, which by structural necessity of python only support multi-processes not multi-thread, have the same exact problem..) Martin: > from my personal experience I would say that than we will probably > never release any new GRASS 6 version. ;-) fwiw I felt that going into the recent code sprint we were ready for 6.4.4rc1, r.li was the last thing to solve. And now we're not. If we're ever going to get there though we have to start by agreeing on a freeze strategy for it. So AFAIU we are in pre-release hard freeze for relbr64: significant bug fixes and spelling mistakes only. And devbr6 is effectively done for refactoring and significant new development. But I wouldn't be absolutist about it, any engineer will tell you there is great strength in flexibility. If there is some really nice feature or new flag for better compatibility or great speedup from grass7 in a leaf module I wouldn't mind it eventually drifting down into stable release+1. (recent horizontal legends for ps.map come to mind, although that one might be argued as a bugfix :) thanks for listening and caring about grass too, Hamish _______________________________________________ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc