Update Revision History with GitHub Issues/PR links#31
Conversation
mdkinney
requested review from
ardbiesheuvel,
leiflindholm and
makubacki
as code owners
mdkinney
force-pushed
the
Update_Revision_History_Github_Issues_And_Proposed_2_5
branch
from
79ceebf to
2538df9
Compare
mdkinney
changed the title
|
Made update to combine history under proposed 2.4 release |
mdkinney
force-pushed
the
Update_Revision_History_Github_Issues_And_Proposed_2_5
branch
from
2538df9 to
c7a5bca
Compare
|
Did one more push to clarify when the start of new content for next spec starts in the Revision History. All lines that follow that start line for spec revision are included in that revision. Can be a bit confusing because the dates are the dates the changes were merged into the repo. The revision history does not show the date that the spec was published. That information is only available from the title page. |
|
@leiflindholm @ardbiesheuvel @makubacki I send an email to devel mailing list proposing an April 3 release date for 2.4. Let me know if there is a better process to get community approval for an official release from documents maintained in tianocore-docs that are not necessarily monitored well. |
Bugzilla server is no longer available. Update revision history with GitHub Issue link when available. Preserve the Bugzilla ID# if available. Add link to PR# if available. If PR# link is not available, then provide link to commit. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
mdkinney
force-pushed
the
Update_Revision_History_Github_Issues_And_Proposed_2_5
branch
from
c7a5bca to
3179fc5
Compare
|
Added line to revision history for this PR. Should be standard practice for each PR in docs to do content change and extend revision history. Otherwise, we have to do cleanup PR like this one. A bit odd, because you do not know the PR number until PR is opened, so at least one revision to PR has to be done to follow this process. |
Sending a notification to the mailing list seems good in any case. Though, I think that we should start trying to use GitHub milestones to show intention for an upcoming release and associate changes (issues and pull requests) that target that release. It also makes release notes much easier to generate with automatic references. I'll write up some details in a small RFC on it. |
2 participants
Description
Bugzilla server is no longer available. Update revision history with GitHub Issue link when available. Preserve the Bugzilla ID# if available. Add link to PR# if available. If PR# link is not available, then provide link to commit.
Contributed-under: TianoCore Contribution Agreement 1.1