----- Original Message -----
> [...]
> I believe we noted that these are interconnected issues. With Nathan
> being the sole dev-branch gatekeeper, he needs to keep reviewing code,
> even if someone else has also reviewed it. Spending a week per month
> on release duties reduces the time available for reviewing, merging
> others' stuff, and developing his own stuff.
To clarify further, the week we were discussing is more a week of adding
far less new code, and focussing on testing (I'm seeking something more
like a code freeze/sludge there so those of us running full QA regularly
can catch up) - release duties certainly don't occupy an entire week.
Also, we could easily release more often ... the agile crowd reckon two
weeks is a good rule of thumb. ;) Not sure thats ideal for us though,
at this stage anyway. We do tend to have a very close to releasable dev
branch at all times, so we are well on our way if we wanted to do more
frequent releases.
> > o fche suggests continual addition of code until nathans complains
> > during code review that its going too far is a Just Fine option.
>
> A more scholarly retelling would be that the consensus was that we
> should go ahead with such a prototype, while we and Nathan will keep
> an eye out for unforseen semantic "shoe-horning".
*nod* - a poor choice of words there on my part.
I mainly wanted to continue to get across the death-by-1000-cuts issue
(manipulating the existing context types to such an extent that we end
up introducing bugs/regressions/accidental-incompatibilities on those
paths, and restrict our options/thinking instead of cleanly building up
the new type of context)
But lets come back to that discussion next time, after we've tackled the
initial items we've all agreed will move us forward & build up some good
precursor knowledge.
cheers.
--
Nathan
|