Re: [tlug] QQ - consider it a poll (TDD)

["Stephen J. Turnbull" <stephenjturnbull@example.com>]

Curt J. Sampson writes:
 > On 2021-12-11 18:09 +0900 (Sat), Stephen J. Turnbull wrote:
 > 
 > > Curt J. Sampson writes:
 > > 
 > >  > I know of various groups that sit down to "study" things, or talk
 > >  > about them, or whatever. I don't know of any groups that regularly
 > >  > get together and do real programming on real programs on a regular
 > >  > basis.
 > > 
 > > They're called "open source software projects," no? ;-)
 > 
 > Well, I've yet to see one where pair-programming is even a regular thing,
 > much less the norm.

I don't recall pair-programming as being a requirement for:

 > >  > regular get together and do real programming on real programs
 > >  > on a regular basis.

But yeah, every year I sit down with a GSoC intern and do basically
that for Mailman for about 20 weeks (the paid internship is only about
12 weeks but there's an unpaid "community bonding period" and some
work we do during the application period.  I can't actually sit with
them and type on their box as they talk, them being in Pune or
Shanghai and all, but we share screens on Zoom sometimes (mostly IRC
though, a lot of Indian students are off somewhere rural on <= 3G at a
Starbucks in the summer).  That's the open source world I participate
in, all my Mailman buddies have done it in the past, though I'm the
principal mentor the last couple of years.

Moving on, I'm quite surprised you contest *this*:

 > > A lot of "real work" has to do with "our way of doing things" and
 > > "how to get the source code," and that's not something you pick
 > > up by trailing the core developers for whom "our way" is second
 > > nature and "the source" is already in a local git repo.
 > 
 > I'm not sure I see why you wouldn't pick that kind of stuff up from
 > trailing a developer experienced with that project, so long as they're
 > actually doing those things.

Well, for starters, experienced developers almost never type or
display the URL to the canonical repo *unless they're onboarding a new
developer.*

 > The "how to get the source code" (and unmentioned but even more vital, "how
 > to build the source code") bits are fairly easily covered by starting not
 > with the checkout you've been working on for ages, but pulling down a new
 > checkout on a fairly "clean" system (ideally, the trailer's system) that
 > doesn't have all the random external dependencies already installed.

Well yes, D'OH, that's *exactly* what I meant.  Is that part of your
normal worflow?  Installing the source on a system you'll never touch
again?  Except maybe as the typist in pair programming?

 > In my world, all you need to do is `git clone ...` and then `./Test` in
 > that repo, and that top-level build/test script will fetch and build any
 > dependencies needed or at least inform the developer in some reasonably
 > comprehensible manner what she's missing.

I gather you're not working in C. ;-)

Snide "a plague on all concerned" language bigotry aside, building the
software is very little of what I'm talking about, except for people
who are quite new to programming as well as to the project in question.

For example, what do you do when your pull request triggers failures
on buildbots for platforms you've never heard of?  (That doesn't
happen on Mailman, we can't afford buildbots, it's a daily occurance
in Python.)

 > Having senior developers regularly deal with getting a "fresh"
 > build running will encourage them to make their build systems work
 > like this so that it's easier for new developers to get going.

I gather you haven't paid much attention to how a Python venv works?
(I'm talking about building Mailman, obviously Python itself can't be
built in a venv.)

I admit my experience is a small sample, but even Ghostscript (I mean,
a fscking ACM Fellow retired early on the cash flow from that project,
he could afford the best workflows known to man) didn't work that way.
God knows neither Emacs nor XEmacs works that way.  Both configure
conservatively (I think you need a mininum of libc and either curses
or X11 installed), and trust that you've installed libraries and
headers for any options you request in advance.  (Of course configure
bitches in plain language if you didn't, but it's still your problem
to get and install them if you want them.)  Python OTOH builds in all
the options it can find on your system.  If you haven't installed
them, you won't get them.  It only complains about a couple of them,
though.

Now, Mailman does work that way, but that's because (a) it's a pure
Python application which hides all the platform dependencies except
that AFAIK none of our supported RDBMS backends run on Windows except
sqlite3, and that's not usable in production so we don't support
Windows, and (b) our test suite builds Mailman for several versions of
Python and Django in venvs, so we couldn't run tests if Mailman's
build didn't work like that.

 > The biggest issue with most build systems, I feel, is that when
 > something's missing developers often do whatever local hack is
 > needed to get things working (e.g., go talk to Joe who says "go
 > install this thing on your development system") and then move on,
 > without ever getting that information back into the repo itself.

That's not been my experience, but most of my experience (except for
Mailman) has been with applications that need to work on every system
known to man (and some known only to woman).  Any given developer
isn't necessarily going to know where you're supposed to get certain
things (eg, Homebrew on Mac supplies much less than MacPorts or
whatever it was I was using before MacPorts, so a port-based developer
isn't going to be able to tell a Homebrew-based developer what to do
with much certainty).  And it's not so much local hacks that cause
problems, it's platform-specific handling (which may or may not be
hacks) that have to be ifdef'd to the 5th circle of Hell and back.

 > As for "our way of doing things," that's exactly what you see as
 > you follow someone doing actual work on the code, is it not?

Not if that someone is "core".  Committers have privileges that newbs
don't.  And when it comes to style, "our way" may not be exactly
visible to the newbie.  Take PEP 8 (the style guide for contributing
Python code to the standard library aka stdlib).  Much of the stdlib
is *old*, some of the code goes back to the early 90s.  There's a
deliberate policy against PEP8ification of working code, both to
prevent code churn (including implied changes to test suites) and to
avoid introducing inadvertent changes in behavior.  So your newbie is
not going to "get" PEP 8 unless *taught* PEP 8 because they're looking
a lot of stdlib code that isn't PEP 8 conformant, and they're not going
to get the anti-churn policy unless taught that, too.  Customs around
code ownership are another thing that you won't pick up by following a
core developer around unless you're a lot more perceptive than most of
the programmers I know (present company excepted for courtesy's sake
:-).  They just won't mess with a prickly maintainer's code without
clearing it in advance, and so probably not at all in a routine day's
work.  Finally, it takes a while to figure out who's who unless you're
told.

A lot of that doesn't apply to smaller projects most of the time, but
I've seen people tripped up in Mailman (3-7 active core devs over the
last decade) by pretty much everything that you'd think would mostly
be "big project" problems.  YMMV, but that's been my experience that
shapes my opinions as quoted at the top.

Steve