Merge conflicts

[Sean Owen <sr...@gmail.com>]

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.)

Re: Merge conflicts

[Ted Dunning <te...@gmail.com>]

It matters to me if it was me since that is the signal I need to improve my
change management process.

As you can guess, we have lots of internal changes happening over periods of
days without a checkin.  Without
knowledge of which code, I would have considered myself the prime suspect.

On Wed, Sep 15, 2010 at 7:26 AM, Sean Owen <sr...@gmail.com> wrote:

> I think it was Jeff but it matters little -- the particular merge
> conflict wasn't of any consequence. Just food-for-thought.
>

Re: Merge conflicts

[Sean Owen <sr...@gmail.com>]

I think it was Jeff but it matters little -- the particular merge
conflict wasn't of any consequence. Just food-for-thought.

On Wed, Sep 15, 2010 at 3:05 PM, Ted Dunning <te...@gmail.com> wrote:
> Do you know whose commits did this?
>
> I have done this in the past, but was under the impression that my edits
> were more careful lately (and not on that file).
>
> Some of the style changes are very easy to miss on visual inspection.

Re: Merge conflicts

[Ted Dunning <te...@gmail.com>]

Do you know whose commits did this?

I have done this in the past, but was under the impression that my edits
were more careful lately (and not on that file).

Some of the style changes are very easy to miss on visual inspection.

On Wed, Sep 15, 2010 at 2:29 AM, Sean Owen <sr...@gmail.com> 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.)
>

Re: Merge conflicts

[Drew Farris <dr...@apache.org>]

Yes, much thanks Sean.

On Wed, Sep 15, 2010 at 12:06 PM, Ted Dunning <te...@gmail.com> wrote:
> +1 !!
>
> On Wed, Sep 15, 2010 at 8:31 AM, Jeff Eastman <jd...@windwardsolutions.com>wrote:
>
>> the thankless job (BTW, thank you) of removing checkstyle warnings
>

Re: Merge conflicts

[Ted Dunning <te...@gmail.com>]

+1 !!

On Wed, Sep 15, 2010 at 8:31 AM, Jeff Eastman <jd...@windwardsolutions.com>wrote:

> the thankless job (BTW, thank you) of removing checkstyle warnings

Re: Merge conflicts

[Jeff Eastman <jd...@windwardsolutions.com>]

  Mea culpa. I had several changes to the ClusterDumper SVD tests in 
limbo when you committed your changes. I thought I'd caught all your 
changes in the merge but evidently missed some. I'd be happy to work out 
some sort of 'hands off' mechanism to reduce this in the future because, 
I agree, its inefficient and annoying. I think that most people work in 
one pretty vertical section of the code base at a time and thus do not 
usually compete. Its the horizontal work like the thankless job (BTW, 
thank you) of removing checkstyle warnings, migrating all the unit tests 
to Junit 4, and so forth that touch large sections of the code which 
likely cause most of the merge issues.


On 9/15/10 2: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.)
>

Re: Merge conflicts

[Jeff Eastman <jd...@windwardsolutions.com>]

  +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<gs...@apache.org>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.
>

Re: Merge conflicts

[Ted Dunning <te...@gmail.com>]

On Wed, Sep 15, 2010 at 2:02 PM, Grant Ingersoll <gs...@apache.org>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.

Re: Merge conflicts

[Sean Owen <sr...@gmail.com>]

Can we liaise with them -- who's the contact? surely we can manage
keeping whatever's of interest while not having to keep things nobody
uses. I'd like that since it won't be feasible later, and because it
paves the way for me to start polishing the bits of code we will keep.
At the moment piles of it remains deprecated.

On Thu, Sep 16, 2010 at 4:39 PM, Grant Ingersoll <gs...@apache.org> wrote:
>
> On Sep 16, 2010, at 1:27 AM, Sean Owen wrote:
>
>>
>> Speaking of, would like to keep trimming out unused math code, but
>> perhaps better to encourage those that know more about what's used and
>> not to have a go. It's pretty easy in IntelliJ -- just grays out
>> methods that aren't in use now.
>
> If only it did it for all downstream users, too!  For instance, somethings we aren't using internally are being used by Carrot2.  Such is the case when we ship separate JARs.
>
> -Grant

Re: Merge conflicts

[Grant Ingersoll <gs...@apache.org>]

On Sep 16, 2010, at 1:27 AM, Sean Owen wrote:

> 
> Speaking of, would like to keep trimming out unused math code, but
> perhaps better to encourage those that know more about what's used and
> not to have a go. It's pretty easy in IntelliJ -- just grays out
> methods that aren't in use now.

If only it did it for all downstream users, too!  For instance, somethings we aren't using internally are being used by Carrot2.  Such is the case when we ship separate JARs.

-Grant

Re: Merge conflicts

[Sean Owen <sr...@gmail.com>]

I hope this is mostly a one-time change, and that there are
substantially no warnings to fix going forward.

There aren't many (any?) outstanding patches now. But there will be
later, and changes harder to make. At version 0.4, no problem. At 1.4
with lots of dependent users, not so much. So that is why I want to
get in these changes before the code starts to "congeal" and we start
to say things like, well, yeah would have liked to adjust that but it
would break X now... such is the root of all code base rot in my
experience.

Speaking of, would like to keep trimming out unused math code, but
perhaps better to encourage those that know more about what's used and
not to have a go. It's pretty easy in IntelliJ -- just grays out
methods that aren't in use now.

On Wed, Sep 15, 2010 at 10:02 PM, Grant Ingersoll <gs...@apache.org> wrote:
> 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.

Re: Merge conflicts

[Grant Ingersoll <gs...@apache.org>]

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.