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