asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yingyi Bu <buyin...@gmail.com>
Subject Re: Commit messages
Date Thu, 15 Jun 2017 20:19:07 GMT
>> 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