Re: against paranoia Re: [Gnu-arch-users] Arch Roadmap Draft (the anticipated part 3)

[Stephen J. Turnbull]

>>>>> "Tom" == Tom Lord <address@hidden> writes:

    Tom> [Those] suspicians are incorrect and they seem to be based on
    Tom> rude assumptions about me.

Although I agree that they don't fit you at all, I think it's worth
considering what would happen in the hands of a maintainer who either
wanted to maintain close control or simply doesn't want to know at all
about what happens in the other fork(s).  I'd like to see costs of
communication as small as possible, even if one-sided.

As far as I can tell, you already have done so, but it's not entirely
clear whether it's reaction to jblack, or proactive.  I think the
latter, but I'd still like to encourage frontloading cost reductions
for submitters (within the framework of the scalable process, that of
course must come first).

    Tom> In and of itself, that's arguably ok.  _Somebody_ has to do
    Tom> the equivalent work of creating a submission branch for each
    Tom> merge request.  By asking submitters to do that work we would
    Tom> be, as I said, implementing a scalable process.

And, even absent your own work on maintaining submission branches,
providing strong incentives to the submitters to figure how to do so
efficiently.  Which method(s) they could then share.  (But see "Force,
no" below.)

    Tom> In other words, the features that are coming will relieve
    Tom> developers of any onerous burden in preparing their (limited
    Tom> format) merge requests.

s/any onerous/unnecessarily onerous/

In my experience, record-keeping burden increases faster than
processes mature, even in the face of honest efforts to reduce it.  I
don't see why that would be untrue of a software process, despite all
efforts to automate---keeping good records is a matter of choosing
what needs to be reported, and that requires somebody smart and
informed == the submitter.  Automation just pushes the abstraction
level higher---ie, the process is more mature and effective, but the
percentage of effort devoted to recordkeeping and planning (which is
sort of prospective recordkeeping, you see) still rises.

    Tom> I'm somehow forcing people to "keep their patches scattered
    Tom> around in different branches."

Force, no.  But even with the power of Emacs available to me at all
times, I find myself doing so many repetitive tasks "by hand",
especially when I'm tired.  I have to work at it to consistently apply
what I know about automating tasks to the work at hand.

As Lessig points out in his Bovinity Principle, that gives a lot of
power to the person who sets up the system.  Please set the priority
of submitter-oriented features with that in mind.  Submitters are not
going to be as good at setting this up as you are, although they can
work out details plenty fast if a good framework is provided.

    Tom> The limited merge request format wouldn't _hurt_ the
    Tom> prospects of forks: it would _help_ the prospect of forks.
    Tom> In fact, that's an important property of it and one reason to
    Tom> do it this way.  The work needed to make a
    Tom> limited-format-merge-request is the very same work needed to
    Tom> express a change in a way that it's easily portable to other
    Tom> forks!

FWIW, I agree with your assessment.  But it's important to me that
_you_ (and the Lieutenants) keep thinking about this stuff in somewhat
paranoid terms (see above); I can't do more than keep up and say
"yeah, I can see that".  ;-)  I'd like to see you (and Andrew, et al)
formalize _in the software_ some of the processes that you would
undoubtedly institute as part of the _social_ framework of arch
development.

Yeah, I know, that's hard, and not something that should be done
lightly or prematurely---but I hope you can find time to think about
it as you go along.

Although in general, up to this point, I've been attracted to your
position that (in my words) "arch is easy enough to use, let the users
straighten things out and we'll formalize that when consensus starts
to appear" (which appears to be working), I think with the PQM stuff
you're getting to a level of abstraction that leaves a lot of people
behind.  I wonder if there isn't a qualitative thing happening right
now, like in a marathon where about 10km out the "lead group" is going
to break away from the pack.  It would be kind of cool if, having
dragged us all into the 90s with arch itself, the PQM could propel the
"pack" (and not just the "leaders") into the 21st century!

    > Then Tom Lord replied:
    > > Um...  no.  I'm saying that if you want me to consider those points in
    > > detail you should remember them until it's closer to the time to work
    > > on those details.

Or how about putting them on the wiki, in a plan review document?  Of
course somebody would have to put your "roadmap" posts there too, so
there'd be a plan to review.  (Not me, not until I get grades
submitted some time next week, sorry.)

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.