Create pull_request_template.md #36
Conversation
There was a problem hiding this comment.
Please add note at top for commit owner to add a proper title tag before their descriptive title such as:
[Fix]- Bug Fix
[Feature]- for new feature
[Style]- Grammar or branding fix
[Update]-For an update to an existing feature
Adding this will allow customers to filter through the commits and determine if it is something they need to look at or not.
Adding title rules to PR template
|
That is how github workflows work. |
Added! |
| @@ -0,0 +1,11 @@ | |||
| *PR Title should start with one of the following tags: [Fix]/[Feature]/[Style]/[Update]* | |||
|
|
|||
There was a problem hiding this comment.
I might state:
Pull request Title must start with commit tag. Below shows examples of when to use each tag:
[Fix]: A bug fix in the document
[Feat]: New feature description added in document
[Style]: Grammar or branding fix
[Update]: Release update; updating Quartus versioning, tools, etc.
There was a problem hiding this comment.
this will help team to know when to use each
There was a problem hiding this comment.
I think this is self explanatory, as the primary descriptor is in the explanation, but I have added it to the PR template ensure no ambiguity with PRs.
There was a problem hiding this comment.
Should we add some commit types to directly address the commit history, like cherry-picking?
There was a problem hiding this comment.
Hi Tamim, I know the team uses cherry-picking to create a release branch. How would you see the customer using the info on what was cherry-picked?
There was a problem hiding this comment.
Cherry-picked commits will inherit the commit message it was cherry-picked from by default; I'd suggest we take advantage of that to follow the template guidelines.
I think it's useful, however, to notate in the cherry-picked commit message that it is a cherry pick from another branch. There's a number of ways to do it, but git commit --amend immediately after the [singular] git cherry-pick operation is probably the easiest for folks to remember.
There was a problem hiding this comment.
Okay -- then let's not complicate things further by adding any more commit "types".
| *Describe the issue, update, change or fix and notable **why*** | ||
|
|
||
| ### Collateral (docs, reports, design examples, case IDs): | ||
|
|
There was a problem hiding this comment.
Add:
- Add the IPS case # or HSD # that corresponds to this fix or feature. Additionally, if you believe this feature needs to be documented in customer facing collateral, please note: "Documentation required" and area affected, for example:
FIM- Documentation Required
AFU- Documentation Required
Scripts- Documentation Required
If there are customer facing/external tests or reports or documentation that you have modified, please note.
"I don't believe we want to give links to HAS or internal reports here since we may make commit public at some point"
There was a problem hiding this comment.
I already added case IDs that covers this
There was a problem hiding this comment.
I can add a section on document required however
There was a problem hiding this comment.
A pox to anyone putting private issue tracker numbers on "open source" public development materials.
To anyone consuming the repository who's not an Intel employee, it's at best of zero value. You're hiding the context that brought about the change.
There was a problem hiding this comment.
Have we considered what kind of public bug tracking we will have for open-source projects? Would we move to using GitHub's "Issues"?
adding review fb
|
Examination of the commit history is often used to track changes and features. I’m not quite sure how this should be documented, but it’s one of the things that makes the commit history into swiss cheese – holes in the commit history makes it tough to figure out what happened. I was thinking maybe we can come up with a tag for these kinds of things so that there is some way we can document what happened.
From: cohensus ***@***.***>
Sent: Tuesday, August 22, 2023 7:58 PM
To: OFS/oneapi-asp ***@***.***>
Cc: Hofioni, Tamim ***@***.***>; Comment ***@***.***>
Subject: Re: [OFS/oneapi-asp] Create pull_request_template.md (PR #36)
@cohensus commented on this pull request.
________________________________
In .github/pull_request_template.md<#36 (comment)>:
@@ -0,0 +1,11 @@
+*PR Title should start with one of the following tags: [Fix]/[Feature]/[Style]/[Update]*
+
Hi Tamim, I know the team uses cherry-picking to create a release branch. How would you see the customer using the info on what was cherry-picked?
—
Reply to this email directly, view it on GitHub<#36 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AS2TSFAEQ34JRUM6GTH3PI3XWVWULANCNFSM6AAAAAAZJS2PWU>.
You are receiving this because you commented.Message ID: ***@***.******@***.***>>
|
Adding a PR template to ensure consistent context for every PR