Re: [boost] [release] Tags are not being used correctly

Subject: Re: [boost] [release] Tags are not being used correctly
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2016-03-22 23:05:39

1. Stop CC'ing individuals when you also send to the list. It's useless, as
we all already get the list messages, and counterproductive as we have to
filter out replies to the correct place and can mess up the threading.

2. Do you have **concrete** changes you are proposing to the release
procedure/code?

3. Unless you are are willing to devote resources, i.e. time/money, expect
NOTHING to happen (Yes I meant to yell for emphasis). Or I'm certain we can
ink out an agreement for whomever you work for to fund the development of a
better release process.

4. You can start by reviewing some of the release procedures and scripts.. <
https://github.com/boostorg/release-tools> <
https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList>

On Tue, Mar 22, 2016 at 7:58 PM, Michael Witten <mfwitten_at_[hidden]> wrote:

>   * When was the release officially tagged?
>

Define "officially".

>   * Who tagged the release?
>

Why is that needed?

>   * Is there any important information particular to this tagging?
>     The tag body could include the `Message-ID' of the announcement email.
>

Not possible. The message is sent *after* the tag is created (IIRC).

>   * Is this tagging *authentic*? Is this really the tag developers
> intended?
>

Define "authentic".

Given that this project uses centralized repositories to which multiple
> people have write access, it would probably be prudent to designate
> officially one person to be the lead release manager, who by widespread
> convention will be the only one allowed to tag a release (including
> a release candidate);

Are you willing to employ, at a competitive rate, the person who would be
the lead release manager? Because in my experience that's a full time job
for projects that are smaller than Boost.

> To facilitate this designation, the lead release manager should publish
> conspicuously (and widely) the public key associated with his or her
> personal identity in this role (an impersonal, project-level private key is
> unlikely to enjoy the inherently intense security incentives that surround
> a personal private key); this publishing includes:
>
>   * Emailing the Boost developer mailing list with the plaintext
>     version of the public key.
>
>   * Disseminating the public key via specialized services (such as PGP
>     keyservers).
>
>   * Providing on the Boost website links to independently archived
>     versions of the public key (such as the aforementioned email as
>     hosted on Gmane, and a keyserver's file, and the webpage's own
>     file).
>
>   * Making sure community members with whom he or she officially meets
>     (say, at an industry conference), have the opportunity to review,
>     to accept, and to publicly validate the public key (i.e., to create
>     a web of trust).
>
>   * etc.
>
> I know, it sounds terrible; but, it's really not that bad.
>

I will personally NEVER EVER do this, unless.. I was hired by say a Google
sized company to specifically back the GIANT LEGAL LIABILITY incurred when
even insinuating the certification of a code base like Boost.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail