Mailing-List: contact dev-help@asterixdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.apache.org
MIME-Version: 1.0
In-Reply-To: <96b581ce-8650-9ef3-a7d1-db78b9acf73d@gmail.com>
References: <6DB13094-338D-4C68-B4D8-D14E06E1BEED@apache.org> <96b581ce-8650-9ef3-a7d1-db78b9acf73d@gmail.com>
From: Yingyi Bu <buyingyi@gmail.com>
Date: Thu, 15 Jun 2017 01:09:53 -0700
Message-ID: <CALjEsF7HL_PJ2GMjF94HO1CZhSfxkfbYXdfpLmL6EbmGQLSChA@mail.gmail.com>
Subject: Re: Commit messages
To: dev@asterixdb.apache.org
Content-Type: multipart/alternative; boundary="94eb2c059e149364700551fb31aa"
archived-at: Thu, 15 Jun 2017 08:09:59 -0000

--94eb2c059e149364700551fb31aa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

+1!

Best,
Yingyi

On Wed, Jun 14, 2017 at 10:43 PM, Mike Carey <dtabass@gmail.com> wrote:

> +1 !!!
>
> I think this is a GREAT proposal, and we can also then hopefully do the
> equivalent of grep'ing the commits to identify things that we might want =
to
> incorporate in a high-level set of release notes.  I also really like the
> "no" requirement. Also, storage changes should really NOT be taken lightl=
y
> - they seriously inconvenience our customers and will hopefully cause the
> tests to fail (the ones that check for backward-compat) - I would like to
> set storage changes actually be voted on, ideally, if we could make that
> part of our operating procedure somehow?
>
> Cheers,
>
> Mike
>
>
>
> On 6/14/17 9:15 AM, Till Westmann wrote:
>
>> Hi,
>>
>> some of us had a discussion with an SDSC team last week that is running =
an
>> AsterixDB instance. Their customer perspective on AsterixDB highlighted =
a
>> few areas of improvement to ease the consumption of AsterixDB.
>>
>> One thing that I=E2=80=99d like to follow up on are release notes. So fa=
r we
>> didn=E2=80=99t
>> provide them and so changes to the system came as a surprise to everybod=
y
>> who is not monitoring commits closely.
>>
>> As I think that it=E2=80=99s not easy to provide good release notes I=E2=
=80=99d like to
>> propose some additions to our commit messages to ease the creation of
>> release messages:
>>
>> Each commit message should
>> 1) reference 1 or more JIRA issues (that hopefully provide a rationale f=
or
>>    the change).
>> 2) contain a description of changes to the user model (language syntax,
>>    configuration parameters, ..)
>> 3) contain a description of storage format changes (that would require
>>    reloading or upgrading)
>> 4) contain a description of interface changes (for source code consumers=
)
>>
>> and all reviewers should check that these are mentioned in the commit
>> message. To increase the probability to we won=E2=80=99t forget to menti=
on the
>> changes in 2-4, I think that we should should explicitly mention the
>> absence
>> of such changes, i.e.:
>>
>> user model changes: no
>> storage format changes: no
>> interface changes: no
>>
>> Thoughts/concerns about this?
>> Is this manageable?
>> Are there other kinds of changes that have a high impact on consumers th=
at
>> we should call out?
>>
>> Cheers,
>> Till=C2=B4
>>
>
>

--94eb2c059e149364700551fb31aa--