Re: [boost] Respecting a projects toolchain decisions

Subject: Re: [boost] Respecting a projects toolchain decisions
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-02 08:54:12

On Sun, Jan 2, 2011 at 1:48 AM, Gordon Woodhull <gordon_at_[hidden]> wrote:
> Hi Dean,
>
> I happen to agree with what you are saying about there not being much support for collaborative development before review (for people who want that), and IMO git does sound neat, but -
>
>> On-going development of the library can follow that model and the
>> "review" becomes more a regular part of daily things that happen on
>> the developer's mailing list. The "management" of the review could be
>> as simple as setting up a Wordpress Poll or something similar to get
>> an actual "vote" from the members of the community -- not in an
>> anonymous manner of course.
>
> You are undervaluing what a review manager does here. Â A big part is to moderate the discussion, find points of agreement, and work out compromises on individual points - as well as deciding where there is not going to be agreement at all. Â A poll would certainly not cover this. Â It is more like consensus-building than voting. Â I could imagine tools that would help with this (e.g. email re-threading), but I haven't seen any yet.
>

Right, I missed that part completely. I guess a poll wouldn't work as well.

How about if the review was posted as Trac/Redmine/Jira issues on the
projects instead and where the review manager can curate the
discussion accordingly? The progress of which can be kept track of in
a Wiki which eventually becomes a "living record" of the actual review
process -- meaning, especially in Trac, issues can be linked to from
the Wiki and as such they can technically be referenced,
cross-referenced, and collected accordingly.

Comments in the issues should typically stay "on-topic" and thus
moderating the discussion on issues would be a part of the normal
chores for a review manager (or managers).

> In a way a review manager is an advocate for the library who is not as ego-burdened as the author(s).
>

+1 to that. I agree completely.

>> Sure, but that doesn't make the process collaborative -- which is
>> actually my main "beef" with the current way things are going. And,
>> even if someone were to re-write a signals implementation, there's no
>> need to actually fork it as a separate project as it could very well
>> just be an evolution of the implementation and just get the
>> contribution in as part of the normal process. Then, the release
>> managers just make a determination of whether to actually get a
>> certain version of the signals implementation from one repo, or get
>> another from another repo.
>
> This seems to shift a lot of the decision-making to the release managers, who are already overworked. Â Review managers can better focus on their individual libraries and judge whether the conditions on acceptance were fulfilled. Â Joachim's proposal for review manager assistants would lighten their workload considerably.
>

Well, not entirely on the release managers really. More on the
community of trusted developers alongside the release managers. The
logic goes this way:

Given:
- there are Release Managers whose main purpose is to make sure that
the upcoming release is in a shippable state
- there are Trusted Developers working on the integration and
stabilization effort on releases
- there are a list of libraries that are considered part of the Boost
distribution

Then:
- a release will consist of snapshots of releases from individual
libraries packaged as a whole
- there may be patches made on the official distribution as part of
the stabilization effort across Boost distributions releases, which
should be submitted back "upstream" to the individual libraries
- the "developer community" around a particular library (I put that in
quotes because that can very well be one person) then manages the
development of that particular library and all patches made to that
library

So in that situation there are two places where a potential
contributor can get involved in: in the evolution of an existing
library (for example, signals), or the stabilization of releases and
gain status as a "trusted developer" through the web of trust system
(as alluded to by the GPG key signing mechanism, etc.).

You lower the barrier in this situation two ways:

1. You allow for more chances for people to contribute in a
less-obtrusive manner. No need to get permission to get commit access
to the sandbox/trunk to get started with contributing.

2. You allow individual libraries to grow communities and/or
evolve/mature independently.

Note that the status quo would be a subset of this larger scheme,
which means people can keep working on a single Boost repository (may
it be Git or Subversion) and libraries can still evolve outside of
Boost getting integrated into the Boost repository later. There's
nothing really being removed in the process if you look at it, the
current process would still be supported in this expanded process to
lower the barrier to entry.

> Maybe there is a case for maintenance review managers?
>

I haven't gotten that far yet though. ;) I usually just call that the
community, which is more fluid -- no need to put a label on that role
which pretty much any Boost contributor would do in the case of
submitting patches and making sure that libraries being used are
maintained accordingly. :D

> This is a complex social process, and tools aren't going to make it easy. Â But they can help people make better judgements, and follow through better.
>

Definitely. Although I think the tools you use increases the upper
bound on the productivity of a group in general. All other things
being equal, better tools usually gives you a better advantage. ;)

> Thank you for raising many interesting ideas,

You're welcome, and thank you for the thoughtful response as well. :D

-- 
Dean Michael Berris
about.me/deanberris