The "Removing a package" section still shows an example with the "Gentoo-bug" tag, that should be "Bug: <url>" instead.
Created attachment 509562 [details, diff] 0001-ebuild-maintenance-update-Gentoo-bug-tag-in-an-examp.patch
LGTM
Why not this, kensington is truly a stream of examples :) ``` commit b97eb6d43f45dfd5b739638928db22d3f3392685 Author: Michael Palimaka <kensington@gentoo.org> Date: Tue Oct 3 21:43:03 2017 +1100 dev-qt/qtphonon: remove last rited package Closes: https://bugs.gentoo.org/629144 ``` My original intent was that people can take the commit hash, look at what has been removed if they wanted to etc. That begs the question, Bug: vs Closes:, which one?
(In reply to Göktürk Yüksek from comment #3) > Why not this, kensington is truly a stream of examples :) Makes no difference to me, but then you'd have to change the paragraphs and example above it. > That begs the question, Bug: vs Closes:, which one? I actually gave that some thought. The list of steps says, 5. Remove from the git tree unless the reason for removal has been fixed 6. Remove package.mask entry I reasoned that "Bug:" should be used for (5) while "Closes:" would happen with (6).
Created attachment 509934 [details, diff] Proposed fix Here's the version with the previous paragraph updated. What do you think? wrt Bug vs. Closes, I would argue the opposite. The package is removed when the ebuilds are removed, not when the mask is removed. It makes more sense if you think in reverse: after step 5, a user forcibly unmasking the package using package.unmask would still not be able to install because it's removed.
(In reply to Göktürk Yüksek from comment #5) > wrt Bug vs. Closes, I would argue the opposite. The package is removed when > the ebuilds are removed, not when the mask is removed. It makes more sense > if you think in reverse: after step 5, a user forcibly unmasking the package > using package.unmask would still not be able to install because it's removed. I guess it depends on what the subject of the bug is. Mine are usually something like "app-cat/pkg: mask for removal." In that case, the bug is not completely resolved when the package is removed, but only after you've cleaned up (removed the mask). However in your example, the bug cited is bug 629144 -- a security vulnerability. In that case the bug could be considered resolved as soon as the package has been removed, regardless of whatever else took place. > Here's the version with the previous paragraph updated. What do you think? I'm happy with your version, too.
Created attachment 509972 [details, diff] Updated proposal I've added the following paragraph below the example: ``` Note that the choice between the Bug: and Closes: tags depends on the nature of the bug(s) associated with the removal and the individual developer workflow. See Git Commit Message Format for more info on tags. ``` Does this clarify it better?
(In reply to Göktürk Yüksek from comment #7) > > Does this clarify it better? To be honest, that extra paragraph will probably just confuse the hell out of anyone who isn't a party to this conversation. Since "Closes:" is appropriate for the bug in the example, I don't think you need to explain yourself.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=74b1623b6414166c1091c08ee90f2d5a509c3da8 commit 74b1623b6414166c1091c08ee90f2d5a509c3da8 Author: Göktürk Yüksek <gokturk@gentoo.org> AuthorDate: 2017-12-13 18:06:09 +0000 Commit: Göktürk Yüksek <gokturk@gentoo.org> CommitDate: 2018-01-03 05:05:41 +0000 ebuild-maintenance: remove the Gentoo-Bug tag in the package removal subsection Per GLEP 66, the tags Bug and Closes should be used when referring to bugs. The example only illustrates the use of Closes per the commit message. Acked-by: Michael Orlitzky <mjo@gentoo.org> Closes: https://bugs.gentoo.org/640788 ebuild-maintenance/maintenance-tasks/text.xml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
