You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by Till Westmann <ti...@apache.org> on 2017/06/14 16:15:37 UTC
Commit messages
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´
Re: Commit messages
Posted by Xikui Wang <xi...@uci.edu>.
+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 <dt...@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 <bu...@gmail.com> wrote:
>>
>> +1!
>>>
>>> Best,
>>> Yingyi
>>>
>>> On Wed, Jun 14, 2017 at 10:43 PM, Mike Carey <dt...@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´
>>>>>
>>>>>
>>>>
>
Re: Commit messages
Posted by Mike Carey <dt...@gmail.com>.
ING?
On 6/15/17 3:45 PM, Till Westmann wrote:
> Ok, we could also do "TXN" -> "TX" and "RTM" -> "RT" as I think that
> those 2-letter acronyms are quite common.
> The one that confuses me (but I don’t have a good alternative) is "IGS".
> Any other alternatives that come to mind?
>
> Cheers,
> Till
>
> On 15 Jun 2017, at 15:27, Yingyi Bu wrote:
>
>> +1 for short acronyms:
>>
>> Here is a list of acronyms:
>> - API
>> - AQL
>> - CLUS (cluster management)
>> - COMP (compiler)
>> - CONF (configuration parameters/mgmt)
>> - DOC
>> - FAIL (failure handling)
>> - EXT (external)
>> - IDX
>> - IGS (ingestion)
>> - FUN (function)
>> - LIC
>> - MVN
>> - MTD (metadata)
>> - PERF (performance monitoring etc.)
>> - REPL
>> - RPC (cc/nc message)
>> - RTM (runtime)
>> - STAT (statistics etc.)
>> - SITE
>> - STR
>> - SQL
>> - TEST
>> - TXN (transaction)
>> - TYPE (data model)
>> - UDF (user defined function)
>> - UI
>>
>>
>> On Thu, Jun 15, 2017 at 3:23 PM, Till Westmann <ti...@apache.org> wrote:
>>
>>> But the first line should also be below 50 characters [1]. That might
>>> become tricky with a single component and it becomes more difficult, if
>>> a change touches more than one component (the ellipsis in [2] show the
>>> reason).
>>>
>>> To include components into the commit message it might be better to do
>>> that in the body instead of the subject (and we might want to use the
>>> same name that we use in JIRA).
>>> Also, it does seem redundant to have the components that are available
>>> in the referenced JIRA issue again in the message, but then it’s not
>>> exactly trivial to join the log messages with the components in JIRA
>>> (unless both are available in AsterixDB ;) )
>>>
>>> Alternatively, we could think about really short acronyms for the
>>> components to make them fit.
>>>
>>> Thoughts?
>>> Till
>>>
>>> [1] https://cwiki.apache.org/confluence/display/ASTERIXDB/Formatting
>>> [2] https://github.com/apache/spark/commits/master
>>>
>>>
>>> On 15 Jun 2017, at 14:55, Mike Carey 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 <bu...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> +1!
>>>>>>
>>>>>> Best,
>>>>>> Yingyi
>>>>>>
>>>>>> On Wed, Jun 14, 2017 at 10:43 PM, Mike Carey <dt...@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´
>>>>>>>>
>>>>>>>>
>>>>>>>
Re: Commit messages
Posted by Mike Carey <dt...@gmail.com>.
+1 :-)
On 6/15/17 3:46 PM, Yingyi Bu wrote:
> How about ING?
>
> Best,
> Yingyi
>
> On Thu, Jun 15, 2017 at 3:45 PM, Till Westmann <ti...@apache.org> wrote:
>
>> Ok, we could also do "TXN" -> "TX" and "RTM" -> "RT" as I think that
>> those 2-letter acronyms are quite common.
>> The one that confuses me (but I don’t have a good alternative) is "IGS".
>> Any other alternatives that come to mind?
>>
>> Cheers,
>> Till
>>
>>
>> On 15 Jun 2017, at 15:27, Yingyi Bu wrote:
>>
>> +1 for short acronyms:
>>> Here is a list of acronyms:
>>> - API
>>> - AQL
>>> - CLUS (cluster management)
>>> - COMP (compiler)
>>> - CONF (configuration parameters/mgmt)
>>> - DOC
>>> - FAIL (failure handling)
>>> - EXT (external)
>>> - IDX
>>> - IGS (ingestion)
>>> - FUN (function)
>>> - LIC
>>> - MVN
>>> - MTD (metadata)
>>> - PERF (performance monitoring etc.)
>>> - REPL
>>> - RPC (cc/nc message)
>>> - RTM (runtime)
>>> - STAT (statistics etc.)
>>> - SITE
>>> - STR
>>> - SQL
>>> - TEST
>>> - TXN (transaction)
>>> - TYPE (data model)
>>> - UDF (user defined function)
>>> - UI
>>>
>>>
>>> On Thu, Jun 15, 2017 at 3:23 PM, Till Westmann <ti...@apache.org> wrote:
>>>
>>> But the first line should also be below 50 characters [1]. That might
>>>> become tricky with a single component and it becomes more difficult, if
>>>> a change touches more than one component (the ellipsis in [2] show the
>>>> reason).
>>>>
>>>> To include components into the commit message it might be better to do
>>>> that in the body instead of the subject (and we might want to use the
>>>> same name that we use in JIRA).
>>>> Also, it does seem redundant to have the components that are available
>>>> in the referenced JIRA issue again in the message, but then it’s not
>>>> exactly trivial to join the log messages with the components in JIRA
>>>> (unless both are available in AsterixDB ;) )
>>>>
>>>> Alternatively, we could think about really short acronyms for the
>>>> components to make them fit.
>>>>
>>>> Thoughts?
>>>> Till
>>>>
>>>> [1] https://cwiki.apache.org/confluence/display/ASTERIXDB/Formatting
>>>> [2] https://github.com/apache/spark/commits/master
>>>>
>>>>
>>>> On 15 Jun 2017, at 14:55, Mike Carey 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 <bu...@gmail.com> wrote:
>>>>>>
>>>>>> +1!
>>>>>>
>>>>>>> Best,
>>>>>>> Yingyi
>>>>>>>
>>>>>>> On Wed, Jun 14, 2017 at 10:43 PM, Mike Carey <dt...@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´
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
Re: Commit messages
Posted by Till Westmann <ti...@apache.org>.
Ok, I’ve updated the formatting guideline [1] and adapted the
components in the JIRA project [2] by renaming them and prepending the
acronym that can be used in the subject line.
Please check if this looks right.
The list of components is not exactly the one in the e-mail.
Specifically I’ve changed the acronym for "storage" from "STR" to
"STO"
to avoid confusing "storage" with "string handling" (or something
similar).
I mention this explicitly, as there are a few open reviews that use
"STR" and it would be nice if we could update those before committing.
I hope that this works for everybody (didn't get too much feedback) as
it will help us to produce better release notes for AsterixDB's users.
Cheers,
Till
[1] https://cwiki.apache.org/confluence/display/ASTERIXDB/Formatting
[2] https://issues.apache.org/jira/projects/ASTERIXDB
On 15 Jun 2017, at 15:50, Till Westmann wrote:
> Yes, works better for me.
>
> Are there other opinions/concerns on the subject?
>
> Thanks,
> Till
>
> On 15 Jun 2017, at 15:46, Yingyi Bu wrote:
>
>> How about ING?
>>
>> Best,
>> Yingyi
>>
>> On Thu, Jun 15, 2017 at 3:45 PM, Till Westmann <ti...@apache.org>
>> wrote:
>>
>>> Ok, we could also do "TXN" -> "TX" and "RTM" -> "RT" as I think that
>>> those 2-letter acronyms are quite common.
>>> The one that confuses me (but I don’t have a good alternative) is
>>> "IGS".
>>> Any other alternatives that come to mind?
>>>
>>> Cheers,
>>> Till
>>>
>>>
>>> On 15 Jun 2017, at 15:27, Yingyi Bu wrote:
>>>
>>> +1 for short acronyms:
>>>>
>>>> Here is a list of acronyms:
>>>> - API
>>>> - AQL
>>>> - CLUS (cluster management)
>>>> - COMP (compiler)
>>>> - CONF (configuration parameters/mgmt)
>>>> - DOC
>>>> - FAIL (failure handling)
>>>> - EXT (external)
>>>> - IDX
>>>> - IGS (ingestion)
>>>> - FUN (function)
>>>> - LIC
>>>> - MVN
>>>> - MTD (metadata)
>>>> - PERF (performance monitoring etc.)
>>>> - REPL
>>>> - RPC (cc/nc message)
>>>> - RTM (runtime)
>>>> - STAT (statistics etc.)
>>>> - SITE
>>>> - STR
>>>> - SQL
>>>> - TEST
>>>> - TXN (transaction)
>>>> - TYPE (data model)
>>>> - UDF (user defined function)
>>>> - UI
>>>>
>>>>
>>>> On Thu, Jun 15, 2017 at 3:23 PM, Till Westmann <ti...@apache.org>
>>>> wrote:
>>>>
>>>> But the first line should also be below 50 characters [1]. That
>>>> might
>>>>> become tricky with a single component and it becomes more
>>>>> difficult, if
>>>>> a change touches more than one component (the ellipsis in [2] show
>>>>> the
>>>>> reason).
>>>>>
>>>>> To include components into the commit message it might be better
>>>>> to do
>>>>> that in the body instead of the subject (and we might want to use
>>>>> the
>>>>> same name that we use in JIRA).
>>>>> Also, it does seem redundant to have the components that are
>>>>> available
>>>>> in the referenced JIRA issue again in the message, but then it’s
>>>>> not
>>>>> exactly trivial to join the log messages with the components in
>>>>> JIRA
>>>>> (unless both are available in AsterixDB ;) )
>>>>>
>>>>> Alternatively, we could think about really short acronyms for the
>>>>> components to make them fit.
>>>>>
>>>>> Thoughts?
>>>>> Till
>>>>>
>>>>> [1]
>>>>> https://cwiki.apache.org/confluence/display/ASTERIXDB/Formatting
>>>>> [2] https://github.com/apache/spark/commits/master
>>>>>
>>>>>
>>>>> On 15 Jun 2017, at 14:55, Mike Carey 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 <bu...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> +1!
>>>>>>>
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Yingyi
>>>>>>>>
>>>>>>>> On Wed, Jun 14, 2017 at 10:43 PM, Mike Carey
>>>>>>>> <dt...@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´
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
Re: Commit messages
Posted by Till Westmann <ti...@apache.org>.
Yes, works better for me.
Are there other opinions/concerns on the subject?
Thanks,
Till
On 15 Jun 2017, at 15:46, Yingyi Bu wrote:
> How about ING?
>
> Best,
> Yingyi
>
> On Thu, Jun 15, 2017 at 3:45 PM, Till Westmann <ti...@apache.org>
> wrote:
>
>> Ok, we could also do "TXN" -> "TX" and "RTM" -> "RT" as I think that
>> those 2-letter acronyms are quite common.
>> The one that confuses me (but I don’t have a good alternative) is
>> "IGS".
>> Any other alternatives that come to mind?
>>
>> Cheers,
>> Till
>>
>>
>> On 15 Jun 2017, at 15:27, Yingyi Bu wrote:
>>
>> +1 for short acronyms:
>>>
>>> Here is a list of acronyms:
>>> - API
>>> - AQL
>>> - CLUS (cluster management)
>>> - COMP (compiler)
>>> - CONF (configuration parameters/mgmt)
>>> - DOC
>>> - FAIL (failure handling)
>>> - EXT (external)
>>> - IDX
>>> - IGS (ingestion)
>>> - FUN (function)
>>> - LIC
>>> - MVN
>>> - MTD (metadata)
>>> - PERF (performance monitoring etc.)
>>> - REPL
>>> - RPC (cc/nc message)
>>> - RTM (runtime)
>>> - STAT (statistics etc.)
>>> - SITE
>>> - STR
>>> - SQL
>>> - TEST
>>> - TXN (transaction)
>>> - TYPE (data model)
>>> - UDF (user defined function)
>>> - UI
>>>
>>>
>>> On Thu, Jun 15, 2017 at 3:23 PM, Till Westmann <ti...@apache.org>
>>> wrote:
>>>
>>> But the first line should also be below 50 characters [1]. That
>>> might
>>>> become tricky with a single component and it becomes more
>>>> difficult, if
>>>> a change touches more than one component (the ellipsis in [2] show
>>>> the
>>>> reason).
>>>>
>>>> To include components into the commit message it might be better to
>>>> do
>>>> that in the body instead of the subject (and we might want to use
>>>> the
>>>> same name that we use in JIRA).
>>>> Also, it does seem redundant to have the components that are
>>>> available
>>>> in the referenced JIRA issue again in the message, but then it’s
>>>> not
>>>> exactly trivial to join the log messages with the components in
>>>> JIRA
>>>> (unless both are available in AsterixDB ;) )
>>>>
>>>> Alternatively, we could think about really short acronyms for the
>>>> components to make them fit.
>>>>
>>>> Thoughts?
>>>> Till
>>>>
>>>> [1]
>>>> https://cwiki.apache.org/confluence/display/ASTERIXDB/Formatting
>>>> [2] https://github.com/apache/spark/commits/master
>>>>
>>>>
>>>> On 15 Jun 2017, at 14:55, Mike Carey 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 <bu...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> +1!
>>>>>>
>>>>>>>
>>>>>>> Best,
>>>>>>> Yingyi
>>>>>>>
>>>>>>> On Wed, Jun 14, 2017 at 10:43 PM, Mike Carey <dt...@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´
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
Re: Commit messages
Posted by Yingyi Bu <bu...@gmail.com>.
How about ING?
Best,
Yingyi
On Thu, Jun 15, 2017 at 3:45 PM, Till Westmann <ti...@apache.org> wrote:
> Ok, we could also do "TXN" -> "TX" and "RTM" -> "RT" as I think that
> those 2-letter acronyms are quite common.
> The one that confuses me (but I don’t have a good alternative) is "IGS".
> Any other alternatives that come to mind?
>
> Cheers,
> Till
>
>
> On 15 Jun 2017, at 15:27, Yingyi Bu wrote:
>
> +1 for short acronyms:
>>
>> Here is a list of acronyms:
>> - API
>> - AQL
>> - CLUS (cluster management)
>> - COMP (compiler)
>> - CONF (configuration parameters/mgmt)
>> - DOC
>> - FAIL (failure handling)
>> - EXT (external)
>> - IDX
>> - IGS (ingestion)
>> - FUN (function)
>> - LIC
>> - MVN
>> - MTD (metadata)
>> - PERF (performance monitoring etc.)
>> - REPL
>> - RPC (cc/nc message)
>> - RTM (runtime)
>> - STAT (statistics etc.)
>> - SITE
>> - STR
>> - SQL
>> - TEST
>> - TXN (transaction)
>> - TYPE (data model)
>> - UDF (user defined function)
>> - UI
>>
>>
>> On Thu, Jun 15, 2017 at 3:23 PM, Till Westmann <ti...@apache.org> wrote:
>>
>> But the first line should also be below 50 characters [1]. That might
>>> become tricky with a single component and it becomes more difficult, if
>>> a change touches more than one component (the ellipsis in [2] show the
>>> reason).
>>>
>>> To include components into the commit message it might be better to do
>>> that in the body instead of the subject (and we might want to use the
>>> same name that we use in JIRA).
>>> Also, it does seem redundant to have the components that are available
>>> in the referenced JIRA issue again in the message, but then it’s not
>>> exactly trivial to join the log messages with the components in JIRA
>>> (unless both are available in AsterixDB ;) )
>>>
>>> Alternatively, we could think about really short acronyms for the
>>> components to make them fit.
>>>
>>> Thoughts?
>>> Till
>>>
>>> [1] https://cwiki.apache.org/confluence/display/ASTERIXDB/Formatting
>>> [2] https://github.com/apache/spark/commits/master
>>>
>>>
>>> On 15 Jun 2017, at 14:55, Mike Carey 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 <bu...@gmail.com> wrote:
>>>>>
>>>>> +1!
>>>>>
>>>>>>
>>>>>> Best,
>>>>>> Yingyi
>>>>>>
>>>>>> On Wed, Jun 14, 2017 at 10:43 PM, Mike Carey <dt...@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´
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
Re: Commit messages
Posted by Till Westmann <ti...@apache.org>.
Ok, we could also do "TXN" -> "TX" and "RTM" -> "RT" as I think that
those 2-letter acronyms are quite common.
The one that confuses me (but I don’t have a good alternative) is
"IGS".
Any other alternatives that come to mind?
Cheers,
Till
On 15 Jun 2017, at 15:27, Yingyi Bu wrote:
> +1 for short acronyms:
>
> Here is a list of acronyms:
> - API
> - AQL
> - CLUS (cluster management)
> - COMP (compiler)
> - CONF (configuration parameters/mgmt)
> - DOC
> - FAIL (failure handling)
> - EXT (external)
> - IDX
> - IGS (ingestion)
> - FUN (function)
> - LIC
> - MVN
> - MTD (metadata)
> - PERF (performance monitoring etc.)
> - REPL
> - RPC (cc/nc message)
> - RTM (runtime)
> - STAT (statistics etc.)
> - SITE
> - STR
> - SQL
> - TEST
> - TXN (transaction)
> - TYPE (data model)
> - UDF (user defined function)
> - UI
>
>
> On Thu, Jun 15, 2017 at 3:23 PM, Till Westmann <ti...@apache.org>
> wrote:
>
>> But the first line should also be below 50 characters [1]. That might
>> become tricky with a single component and it becomes more difficult,
>> if
>> a change touches more than one component (the ellipsis in [2] show
>> the
>> reason).
>>
>> To include components into the commit message it might be better to
>> do
>> that in the body instead of the subject (and we might want to use the
>> same name that we use in JIRA).
>> Also, it does seem redundant to have the components that are
>> available
>> in the referenced JIRA issue again in the message, but then it’s
>> not
>> exactly trivial to join the log messages with the components in JIRA
>> (unless both are available in AsterixDB ;) )
>>
>> Alternatively, we could think about really short acronyms for the
>> components to make them fit.
>>
>> Thoughts?
>> Till
>>
>> [1] https://cwiki.apache.org/confluence/display/ASTERIXDB/Formatting
>> [2] https://github.com/apache/spark/commits/master
>>
>>
>> On 15 Jun 2017, at 14:55, Mike Carey 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 <bu...@gmail.com>
>>>> wrote:
>>>>
>>>> +1!
>>>>>
>>>>> Best,
>>>>> Yingyi
>>>>>
>>>>> On Wed, Jun 14, 2017 at 10:43 PM, Mike Carey <dt...@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´
>>>>>>>
>>>>>>>
>>>>>>
Re: Commit messages
Posted by Yingyi Bu <bu...@gmail.com>.
+1 for short acronyms:
Here is a list of acronyms:
- API
- AQL
- CLUS (cluster management)
- COMP (compiler)
- CONF (configuration parameters/mgmt)
- DOC
- FAIL (failure handling)
- EXT (external)
- IDX
- IGS (ingestion)
- FUN (function)
- LIC
- MVN
- MTD (metadata)
- PERF (performance monitoring etc.)
- REPL
- RPC (cc/nc message)
- RTM (runtime)
- STAT (statistics etc.)
- SITE
- STR
- SQL
- TEST
- TXN (transaction)
- TYPE (data model)
- UDF (user defined function)
- UI
On Thu, Jun 15, 2017 at 3:23 PM, Till Westmann <ti...@apache.org> wrote:
> But the first line should also be below 50 characters [1]. That might
> become tricky with a single component and it becomes more difficult, if
> a change touches more than one component (the ellipsis in [2] show the
> reason).
>
> To include components into the commit message it might be better to do
> that in the body instead of the subject (and we might want to use the
> same name that we use in JIRA).
> Also, it does seem redundant to have the components that are available
> in the referenced JIRA issue again in the message, but then it’s not
> exactly trivial to join the log messages with the components in JIRA
> (unless both are available in AsterixDB ;) )
>
> Alternatively, we could think about really short acronyms for the
> components to make them fit.
>
> Thoughts?
> Till
>
> [1] https://cwiki.apache.org/confluence/display/ASTERIXDB/Formatting
> [2] https://github.com/apache/spark/commits/master
>
>
> On 15 Jun 2017, at 14:55, Mike Carey 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 <bu...@gmail.com> wrote:
>>>
>>> +1!
>>>>
>>>> Best,
>>>> Yingyi
>>>>
>>>> On Wed, Jun 14, 2017 at 10:43 PM, Mike Carey <dt...@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´
>>>>>>
>>>>>>
>>>>>
Re: Commit messages
Posted by Till Westmann <ti...@apache.org>.
But the first line should also be below 50 characters [1]. That might
become tricky with a single component and it becomes more difficult, if
a change touches more than one component (the ellipsis in [2] show the
reason).
To include components into the commit message it might be better to do
that in the body instead of the subject (and we might want to use the
same name that we use in JIRA).
Also, it does seem redundant to have the components that are available
in the referenced JIRA issue again in the message, but then it’s not
exactly trivial to join the log messages with the components in JIRA
(unless both are available in AsterixDB ;) )
Alternatively, we could think about really short acronyms for the
components to make them fit.
Thoughts?
Till
[1] https://cwiki.apache.org/confluence/display/ASTERIXDB/Formatting
[2] https://github.com/apache/spark/commits/master
On 15 Jun 2017, at 14:55, Mike Carey 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 <bu...@gmail.com>
>> wrote:
>>
>>> +1!
>>>
>>> Best,
>>> Yingyi
>>>
>>> On Wed, Jun 14, 2017 at 10:43 PM, Mike Carey <dt...@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´
>>>>>
>>>>
Re: Commit messages
Posted by Mike Carey <dt...@gmail.com>.
+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 <bu...@gmail.com> wrote:
>
>> +1!
>>
>> Best,
>> Yingyi
>>
>> On Wed, Jun 14, 2017 at 10:43 PM, Mike Carey <dt...@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´
>>>>
>>>
Re: Commit messages
Posted by Yingyi Bu <bu...@gmail.com>.
>> 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 <bu...@gmail.com> wrote:
> +1!
>
> Best,
> Yingyi
>
> On Wed, Jun 14, 2017 at 10:43 PM, Mike Carey <dt...@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´
>>>
>>
>>
>
Re: Commit messages
Posted by Yingyi Bu <bu...@gmail.com>.
+1!
Best,
Yingyi
On Wed, Jun 14, 2017 at 10:43 PM, Mike Carey <dt...@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´
>>
>
>
Re: Commit messages
Posted by Mike Carey <dt...@gmail.com>.
+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´