+1 Component names in the headline would be very useful when we traverse the commits history!
Best, Xikui On Thu, Jun 15, 2017 at 2:55 PM, Mike Carey <[email protected]> wrote: > +1 > > > > On 6/15/17 1:19 PM, Yingyi Bu wrote: > >> 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´ >>>>> >>>>> >>>> >
