Re: Use semantic pull request

We have similar labels that we can reuse. * kind:bug * kind:feature * kind:documentation https://github.com/apache/airflow/labels?q=kind Do we want to do this? On Wed, Apr 29, 2020 at 12:31 AM Kaxil Naik wrote: > > Ekk yeah, I agree, you are right, I definitely planned to do it without > spaces

Re: Use semantic pull request

Ekk yeah, I agree, you are right, I definitely planned to do it without spaces, missed it in the email. Thanks for pointing that out though. Regards, Kaxil On Tue, Apr 28, 2020 at 10:40 PM Kamil Breguła wrote: > They look very sensible. I would just ask you not to add a space after the > colon

Re: Use semantic pull request

They look very sensible. I would just ask you not to add a space after the colon. Instead of "type: bug-fix" I would prefer "type:bug-fix". This makes searching easier. On Tue, Apr 28, 2020, 23:30 Kaxil Naik wrote: > > > > I like this! Why don't we change our bot to make sure that one of those

Re: Use semantic pull request

> > I like this! Why don't we change our bot to make sure that one of those is > applied before we merge? I think that fits very well the "review time" > categorisation and we can indeed expect that committers can properly > assign one of those. I agree that before 2.0 it's not a good idea to > int

Re: Use semantic pull request

> > While doing this I tried to come up with some labels that we can add to the > PRs (in-line with what we had on JIRA and our Changelog sections): > > >- type: bug-fix >- type: new-feature >- type: doc-change >- type: improvement >- type: internal [For all CI & tests related

Re: Use semantic pull request

Hi all, re: *Changelog with GH PR/issues*: Until 1.10.9 the script in dev folder worked fine for generating Changelog and like Ash mentioned they were categorized based on the Jira issue (which

Re: Use semantic pull request

We probably can try to add proper labels using a semantic prefix. As per irrelevant (from changelog point of view) we can use ci or dev prefixes. T. On Sun, Apr 26, 2020 at 6:48 PM Jarek Potiuk wrote: > Reno sounds like it's there to handle the corporate environment with > multiple teams workin

Re: Use semantic pull request

Reno sounds like it's there to handle the corporate environment with multiple teams working on different features. A bit too much overhead if you ask me :). There is a reason why I am not working for a big corporation :D I agree that Updating.md is fine as it is now. Also, I think often Updating.m

Re: Use semantic pull request

Random other thoughts about changelog: Sometimes we get the type wrong (say it's a new feature when it's a fix) Some commits just don't need to be included in the changelog as they aren't relevant to users of Airflow. - Either it's a bug fix to a new feature that hasn't yet been released - or i

Re: Use semantic pull request

Yes thank you, that's the one! On 26 April 2020 16:44:50 BST, "Kamil Breguła" wrote: >Reno was developed by OpenStack: >https://docs.openstack.org/reno/latest/ > >On Sun, Apr 26, 2020 at 5:39 PM Ash Berlin-Taylor >wrote: >> >> Yeah, probably is overly complex for general changelog. >> >> The ma

Re: Use semantic pull request

Reno was developed by OpenStack: https://docs.openstack.org/reno/latest/ On Sun, Apr 26, 2020 at 5:39 PM Ash Berlin-Taylor wrote: > > Yeah, probably is overly complex for general changelog. > > The main thing updating.md needs is some concept of knowing which release it > is in when the commit a

Re: Use semantic pull request

Yeah, probably is overly complex for general changelog. The main thing updating.md needs is some concept of knowing which release it is in when the commit appears in multiple branches (but with different commit IDs because of cherry picking.) Sure we could write the tooling for that, but someon

Re: Use semantic pull request

> > > For changelog there is another option, which is a more formal/complex > system which works better with our backport/release branch process. (Can't > find the specific tool I'm thinking of from my phone. It involves each > change note in a separate file, and then a script to compile it. Roughl

Re: Use semantic pull request

Then I think then this might be a great opportunity to codify what we want and also write down the rules and make all the committers aware of that. and agree on that. We can, of course, do it regardless, but having it stored in a configuration and verifying the presence of the prefix might be a goo

Re: Use semantic pull request

Actually that's something I hadn't twigged yet (blame disturbed night due to toddler nightmares) - previously we were generating the sections of the changelog based on the Jira issue type, not possible anymore with GitHub! So either a prefix or label is needed. So I guess I'm just arguing over w

Re: Use semantic pull request

I've done the changelog too don't forget :) My view on that: the main problem is that people (commiters and PR authors both) don't think about changelog when writing the PR/commit title - often there isn't enough context in the title to make it useful enough to know what the commit actual chang

Re: Use semantic pull request

I agree with Ash that it's a committer's task to check the commit name. But I personally was deceived by a discrepancy between PR name and commit title and merged the PR with "wrong" commit message. That's where I agree with Jarek: we should help ourselves. If "red check" will make people correct

Re: Use semantic pull request

I think you pointed out the exact things I thought are important and could be automated. I think those are the very things committing checks for. I think we could benefit from 1, 2, 3, 4, 6 (6. with exceptions indeed but a warning or a way to mark an exception would be nice - similarly as we do wi

Re: Use semantic pull request

My main objection is this is trying to apply a technical solution to a people+English problem. This feels like just one extra step to have commiters to do, when we as committers can very easily correct this in Github whilst reviewing/before merging. That said, can you point at any examples of rece

Re: Use semantic pull request

I think it's a very good idea to use it. We already discussed that we should have some improvements in the way we write commits - and why to come up with our own conventions if we can adopt one that already exists and has set of nice tools available. As usual, I think automation is a key - as it m

Re: Use semantic pull request

I agree that many commit messages are often lacking but I'm not a fan of that the prefix style that app requires, - plus I think it would still be possible to have unhelpful PR titles just with 'fix:' prefixed. Is rather we as commiters updated the pr subjects when reviewing. The rule I try to

Use semantic pull request

Hi all! Sometimes it happens that pull requests or commits have not so meaningful messages and it's hard to say what's exactly going on. So I am wondering if we would like to consider using semantic pull request: https://github.com/zeke/semantic-pull-requests Since we are using Github it should b