+1 I like the idea of consolidating cosmetic changes to late in the
deployment cycle but many of the horizontal changes are important to do
during the main part of the release cycle. I'm thinking of 20.2
migration, CLI unification, classification/clustering convergence and
things like that. But yeah, run somebody's prettyprinter over the whole
mess just before we ship it and a lot of the submitted patches would
have a longer lifetime.
Informally, if I knew somebody was going to tackle some kind of
horizontal improvements that might cause merge issues with my work I
could take a break for a few days.
On 9/15/10 2:22 PM, Ted Dunning wrote:
On Wed, Sep 15, 2010 at 2:02 PM, Grant Ingersoll<[email protected]>wrote:
On Sep 15, 2010, at 5:29 AM, Sean Owen wrote:
I noticed that some of my last changes to TestClusterDumper, for
example, were reversed in a subsequent change. I don't mind, they were
largely cosmetic, to fix little checkstyle warnings. Not sure if that
was on purpose or an accidental artifact of the merge. But I wonder if
people are finding it hard to merge such changes and if so are people
comfortable asking to keep 'hands off' certain sections for a limited
time when it's actively being worked on? (We should be able to do
this, informally, without resorting to locking or anything.)
This kind of stuff is generally why many projects either forgo cosmetic
changes or make them automatic via SVN hooks or something similar. Large
cosmetic changes often make it next to impossible to apply patches w/o a lot
of work that were submitted previously, thus leaving you as the committer to
then go pester the original contributor to update to trunk instead of you
just being able to apply the fix.
An alternative might be to apply all cosmetic changes at release time,
after code freeze and just make reasonable efforts in the interim, but
nothing sweeping.
I don't think that we are quite ready for that, but it is possible that we
can start it after 0.4.
