asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xikui Wang <xik...@uci.edu>
Subject Re: Commit messages
Date Thu, 15 Jun 2017 22:20:38 GMT
+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 <dtabass@gmail.com> 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 <buyingyi@gmail.com> wrote:
>>
>> +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
>>>> 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´
>>>>>
>>>>>
>>>>
>

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