asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <>
Subject Re: Commit messages
Date Thu, 15 Jun 2017 05:43:58 GMT
+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 
lightly - 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?



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’d like to follow up on are release notes. So far we 
> didn’t
> provide them and so changes to the system came as a surprise to everybody
> who is not monitoring commits closely.
> As I think that it’s not easy to provide good release notes I’d 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 
> for
>    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’t forget to mention 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 
> that
> we should call out?
> Cheers,
> Till´

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message