>> 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)
I wonder if we could put component name(s) into the headline of commit message. So the headline will be sth. like: [ASTERIXDB-2000][TXN] Fix a deadlock in LogManager [ASTERIXDB-2001][STORAGE] Clean up file handling in BufferCache .... It makes change localization easier. Examples: Spark: https://github.com/apache/spark/commits/master Flink: https://github.com/apache/flink/commits/master Here is a list of component names: - API - AQL - CLUSTER (cluster management) - COMPILER - CONFIGURATION (configuration parameters/mgmt) - DOC - FAILURE (failure handling) - EXTERNAL - INDEX - INGESTION - FUNC (function) - LICENSE - MAVEN - METADATA - PERF (performance monitoring etc.) - REPLICATION - RPC (cc/nc message) - RUNTIME - STATS (statistics etc.) - SITE - STORAGE - SQL++ - TEST - TXN (transaction) - TYPE (data model) - UDF (user defined function) - UI Best, Yingyi On Thu, Jun 15, 2017 at 1:09 AM, Yingyi Bu <[email protected]> wrote: > +1! > > Best, > Yingyi > > On Wed, Jun 14, 2017 at 10:43 PM, Mike Carey <[email protected]> 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 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? >> >> 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’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´ >>> >> >> >
