Hey devs,
we currently tag commits with the JIRA issue and component(s), like: [FLINK-3943] [table] Add support for EXCEPT operator I was wondering whether it makes sense to write down a set of common commit tags for new contributors. The set of commit tags is quite unregulated right now and I think different people follow different strategies. I used to stick to the "main" Maven module that the change affects, e.g. [runtime] if main changes are in flink-runtime. Spellings also vary, e.g. [table] vs. [tableAPI] etc. With the newly organized components, we might want to stick to those components for the tags and set a standard tag for each. What do you think about this? I think it will be a valuable addition. – Ufuk |
Hi Ufuk,
I also saw these inconsistencies in the tagging too, but I'm not sure if fixing this is worth the effort. As long as the tag somehow transports the intended message ("a change at the runtime <https://github.com/apache/flink/commit/2477161352e12e75e2f0f85b5833ad04dc6d31f2>"), its good enough. Having such a rule in place would mean that people would need to look up the appropriate tag before writing a commit message. If we would use an automated system to evaluate commits, I would agree to fix this. On Fri, Jul 15, 2016 at 10:57 AM, Ufuk Celebi <[hidden email]> wrote: > Hey devs, > > we currently tag commits with the JIRA issue and component(s), like: > > [FLINK-3943] [table] Add support for EXCEPT operator > > I was wondering whether it makes sense to write down a set of common > commit tags for new contributors. > > The set of commit tags is quite unregulated right now and I think > different people follow different strategies. I used to stick to the > "main" Maven module that the change affects, e.g. [runtime] if main > changes are in flink-runtime. Spellings also vary, e.g. [table] vs. > [tableAPI] etc. > > With the newly organized components, we might want to stick to those > components for the tags and set a standard tag for each. > > What do you think about this? I think it will be a valuable addition. > > – Ufuk > |
I agree with Robert that it would be a nice to have but not strictly
required. I think it would help to have a list of preferred tags so that new community members have a place to look them up. Cheers, Till On Fri, Jul 15, 2016 at 11:41 AM, Robert Metzger <[hidden email]> wrote: > Hi Ufuk, > > I also saw these inconsistencies in the tagging too, but I'm not sure if > fixing this is worth the effort. As long as the tag somehow transports the > intended message ("a change at the runtime > < > https://github.com/apache/flink/commit/2477161352e12e75e2f0f85b5833ad04dc6d31f2 > >"), > its good enough. Having such a rule in place would mean that people would > need to look up the appropriate tag before writing a commit message. > If we would use an automated system to evaluate commits, I would agree to > fix this. > > > > > On Fri, Jul 15, 2016 at 10:57 AM, Ufuk Celebi <[hidden email]> wrote: > > > Hey devs, > > > > we currently tag commits with the JIRA issue and component(s), like: > > > > [FLINK-3943] [table] Add support for EXCEPT operator > > > > I was wondering whether it makes sense to write down a set of common > > commit tags for new contributors. > > > > The set of commit tags is quite unregulated right now and I think > > different people follow different strategies. I used to stick to the > > "main" Maven module that the change affects, e.g. [runtime] if main > > changes are in flink-runtime. Spellings also vary, e.g. [table] vs. > > [tableAPI] etc. > > > > With the newly organized components, we might want to stick to those > > components for the tags and set a standard tag for each. > > > > What do you think about this? I think it will be a valuable addition. > > > > – Ufuk > > > |
It was intended as Till said... a list of preferred tags.
On Fri, Jul 15, 2016 at 6:52 PM, Till Rohrmann <[hidden email]> wrote: > I agree with Robert that it would be a nice to have but not strictly > required. I think it would help to have a list of preferred tags so that > new community members have a place to look them up. > > Cheers, > Till > > On Fri, Jul 15, 2016 at 11:41 AM, Robert Metzger <[hidden email]> > wrote: > >> Hi Ufuk, >> >> I also saw these inconsistencies in the tagging too, but I'm not sure if >> fixing this is worth the effort. As long as the tag somehow transports the >> intended message ("a change at the runtime >> < >> https://github.com/apache/flink/commit/2477161352e12e75e2f0f85b5833ad04dc6d31f2 >> >"), >> its good enough. Having such a rule in place would mean that people would >> need to look up the appropriate tag before writing a commit message. >> If we would use an automated system to evaluate commits, I would agree to >> fix this. >> >> >> >> >> On Fri, Jul 15, 2016 at 10:57 AM, Ufuk Celebi <[hidden email]> wrote: >> >> > Hey devs, >> > >> > we currently tag commits with the JIRA issue and component(s), like: >> > >> > [FLINK-3943] [table] Add support for EXCEPT operator >> > >> > I was wondering whether it makes sense to write down a set of common >> > commit tags for new contributors. >> > >> > The set of commit tags is quite unregulated right now and I think >> > different people follow different strategies. I used to stick to the >> > "main" Maven module that the change affects, e.g. [runtime] if main >> > changes are in flink-runtime. Spellings also vary, e.g. [table] vs. >> > [tableAPI] etc. >> > >> > With the newly organized components, we might want to stick to those >> > components for the tags and set a standard tag for each. >> > >> > What do you think about this? I think it will be a valuable addition. >> > >> > – Ufuk >> > >> |
Then +1 :-)
On Fri, Jul 15, 2016 at 7:07 PM, Ufuk Celebi <[hidden email]> wrote: > It was intended as Till said... a list of preferred tags. > > On Fri, Jul 15, 2016 at 6:52 PM, Till Rohrmann <[hidden email]> > wrote: > > I agree with Robert that it would be a nice to have but not strictly > > required. I think it would help to have a list of preferred tags so that > > new community members have a place to look them up. > > > > Cheers, > > Till > > > > On Fri, Jul 15, 2016 at 11:41 AM, Robert Metzger <[hidden email]> > > wrote: > > > >> Hi Ufuk, > >> > >> I also saw these inconsistencies in the tagging too, but I'm not sure if > >> fixing this is worth the effort. As long as the tag somehow transports > the > >> intended message ("a change at the runtime > >> < > >> > https://github.com/apache/flink/commit/2477161352e12e75e2f0f85b5833ad04dc6d31f2 > >> >"), > >> its good enough. Having such a rule in place would mean that people > would > >> need to look up the appropriate tag before writing a commit message. > >> If we would use an automated system to evaluate commits, I would agree > to > >> fix this. > >> > >> > >> > >> > >> On Fri, Jul 15, 2016 at 10:57 AM, Ufuk Celebi <[hidden email]> wrote: > >> > >> > Hey devs, > >> > > >> > we currently tag commits with the JIRA issue and component(s), like: > >> > > >> > [FLINK-3943] [table] Add support for EXCEPT operator > >> > > >> > I was wondering whether it makes sense to write down a set of common > >> > commit tags for new contributors. > >> > > >> > The set of commit tags is quite unregulated right now and I think > >> > different people follow different strategies. I used to stick to the > >> > "main" Maven module that the change affects, e.g. [runtime] if main > >> > changes are in flink-runtime. Spellings also vary, e.g. [table] vs. > >> > [tableAPI] etc. > >> > > >> > With the newly organized components, we might want to stick to those > >> > components for the tags and set a standard tag for each. > >> > > >> > What do you think about this? I think it will be a valuable addition. > >> > > >> > – Ufuk > >> > > >> > |
How about we use the components that we also defined for the shepherds as
tags? On Mon, Jul 18, 2016 at 3:24 PM, Till Rohrmann <[hidden email]> wrote: > Then +1 :-) > > On Fri, Jul 15, 2016 at 7:07 PM, Ufuk Celebi <[hidden email]> wrote: > > > It was intended as Till said... a list of preferred tags. > > > > On Fri, Jul 15, 2016 at 6:52 PM, Till Rohrmann <[hidden email]> > > wrote: > > > I agree with Robert that it would be a nice to have but not strictly > > > required. I think it would help to have a list of preferred tags so > that > > > new community members have a place to look them up. > > > > > > Cheers, > > > Till > > > > > > On Fri, Jul 15, 2016 at 11:41 AM, Robert Metzger <[hidden email]> > > > wrote: > > > > > >> Hi Ufuk, > > >> > > >> I also saw these inconsistencies in the tagging too, but I'm not sure > if > > >> fixing this is worth the effort. As long as the tag somehow transports > > the > > >> intended message ("a change at the runtime > > >> < > > >> > > > https://github.com/apache/flink/commit/2477161352e12e75e2f0f85b5833ad04dc6d31f2 > > >> >"), > > >> its good enough. Having such a rule in place would mean that people > > would > > >> need to look up the appropriate tag before writing a commit message. > > >> If we would use an automated system to evaluate commits, I would agree > > to > > >> fix this. > > >> > > >> > > >> > > >> > > >> On Fri, Jul 15, 2016 at 10:57 AM, Ufuk Celebi <[hidden email]> wrote: > > >> > > >> > Hey devs, > > >> > > > >> > we currently tag commits with the JIRA issue and component(s), like: > > >> > > > >> > [FLINK-3943] [table] Add support for EXCEPT operator > > >> > > > >> > I was wondering whether it makes sense to write down a set of common > > >> > commit tags for new contributors. > > >> > > > >> > The set of commit tags is quite unregulated right now and I think > > >> > different people follow different strategies. I used to stick to the > > >> > "main" Maven module that the change affects, e.g. [runtime] if main > > >> > changes are in flink-runtime. Spellings also vary, e.g. [table] vs. > > >> > [tableAPI] etc. > > >> > > > >> > With the newly organized components, we might want to stick to those > > >> > components for the tags and set a standard tag for each. > > >> > > > >> > What do you think about this? I think it will be a valuable > addition. > > >> > > > >> > – Ufuk > > >> > > > >> > > > |
Free forum by Nabble | Edit this page |