Re: [tlug] Open-source repository question

[Curt Sampson <cjs@example.com>]

On 2009-09-28 15:03 +0900 (Mon), Stephen J. Turnbull wrote:

> But the only way to fix it at the root is to exclude them from the team.

I doubt that that's the *only* way. Have you tried pairing them up with
other, somewhat more responsible developers, to see if they can be
brought up to speed?

> That's sort of antithetical to the idea of a public project.

I don't see why. "Public" does not mean "accept any crap." I'm not
allowed to poop on the grass in public parks, despite them being
"public."

> The alternative is to
> reject those patches until acceptable, which is a feature branch.  No?

That certainly works! But if that's the case, you don't really care
about branching and merging costs, do you? That all falls on the
developer who can't be trusted, who is probably not producing great work
anyway.

> Sure.  "Jesus FUCKING Christ, if you can't run a build configured
> --with-gtk before committing code that changes the GUI abstraction,
> DON'T FUCKING COMMIT, OK!!!!!!"

That's one way, yes. :-) I tend to prefer, "run the top level test
script and don't commit if it doesn't work," as opposed to "remember
this constantly changing list of things to check." 

> That normally causes the listener to go away, rather than start doing
> appropriate testing. With DVCS s/FUCKING//g and s/COMMIT/push/g, they
> don't go away, but they do end up on a feature branch.

Err...yeah. But I don't see how this changes anything; they could have
done exactly the same if you were using svn.

> In the case of XEmacs (or Linux, see Shawn Brown's recent post), the
> first step is "clean up thousands of lines of existing code".

I don't think so. If you have two feature branches that have diverged
and you want to merge them, the first step is actually just move both
copies to the same branch, and build both from their entirely separate
sources. Then you can start picking off the parts that are easy to merge
(such as the source files that are exactly the same) and putting them in
a common area, and move on from there.

> BTW, it occurs to me that one source of our apparent disagreements (as
> opposed to our real disagreements) is blanket claims by me and Josh
> that CI and related forms of coordination advocated in certain Agile
> circles "don't scale" (ie, "not ever").  But then we[1] have unfairly
> interpreted you as saying "these Agile practices constitute a panacea"
> when your real claim is "they do too scale to anything I have worked
> on or can imagine working on".  Two questions: (1) Do you think that's
> a fair statement of the situation?  (2) Does your "imagination" scale
> to working on a somewhat unclean, homongous project like the Linux
> kernel, or a positively leprous, moderate-sized project like an Emacs?

Mmm, I don't think I'd really express it that way, though I agree that
our apparent disagreements are probably much less than our actual.

I think I mostly disagree with the way things are presented: I'm hearing
"cheap branching is good," and "you should be using feature branches
under most circumstances," as opposed to "cheap branching is helpful in
pathological (albeit not rare) circumstances."

The agile approach is certainly not a panacea; think of it more as a set
of processes that will make your development better and faster, if you
can manage to implement them, and to the degree you manage to implement
them. Here, perhaps is the difference.

The non-agile guy says, "Feature branches reduced pain of a certain type.
Great! Problem solved!"

The agile guy, in the same situation, says, "Feature branches were
a relatively (compared to the other options) quick and cheap way of
reducing the pain for the moment, and we'll go with that until we can
find a better way of solving the problem that we can afford."

I would say that there's a lot of situations where one can't implement
agile approaches to the degree one might hope. That doesn't mean that
one can't do a partial implementation, or continue to work to find ways
to implement them further than has been done so far.

My imagination does scale to working on a "positively leprous" project
like an Emacs. If I started hacking on XEmacs, for example, I'd probably
start out by doing a lot of the things you are doing, and doing a lot
of them the same way for quite some time. I'd just call those things
"compromises" rather than "solutions."

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com