[arch-dev-public] [RFC] Removing maintainer/contributor lines from PKGBUILDs
I am not sure these serve any purpose. The maintainer line duplicates information available from the archweb or aur interfaces and could also be outdated. The contributor lines are mostly redundant with svn or git history, can take up several lines in the PKGBUILD and can become irrelevant after significant refactoring. What are your thoughts on dropping all these seemingly unnecessary lines from our official PKGBUILDs? Anyone feel strongly about keeping them (and why)?
On Tue, 25 Aug 2020 at 15:58:40, Evangelos Foutras via arch-dev-public wrote:
I am not sure these serve any purpose. The maintainer line duplicates information available from the archweb or aur interfaces and could also be outdated. The contributor lines are mostly redundant with svn or git history, can take up several lines in the PKGBUILD and can become irrelevant after significant refactoring.
What are your thoughts on dropping all these seemingly unnecessary lines from our official PKGBUILDs? Anyone feel strongly about keeping them (and why)?
I don't feel strongly and would welcome a better system. One of the reasons against such a change that was brought in earlier conversations around this topic is that original contributors are hard to reconstruct after a package has been moved from the AUR to the official repositories or vice versa.
On Tue, Aug 25, 2020 at 04:46:36PM -0400, Public mailing list for Arch Linux development wrote:
On Tue, 25 Aug 2020 at 15:58:40, Evangelos Foutras via arch-dev-public wrote:
I am not sure these serve any purpose. The maintainer line duplicates information available from the archweb or aur interfaces and could also be outdated. The contributor lines are mostly redundant with svn or git history, can take up several lines in the PKGBUILD and can become irrelevant after significant refactoring.
What are your thoughts on dropping all these seemingly unnecessary lines from our official PKGBUILDs? Anyone feel strongly about keeping them (and why)?
I don't feel strongly and would welcome a better system.
One of the reasons against such a change that was brought in earlier conversations around this topic is that original contributors are hard to reconstruct after a package has been moved from the AUR to the official repositories or vice versa.
Lukas' opinion pretty much reflects my opinion. I just want to add, that other distributions use our PKGBUILDs (Manjaro, ALARM, etc). Having a contributor/maintainer history is the least thing, people can do to 'honor' work related to PKGBUILDs. Maintainer/Contributor lines are also interesting with respect to licensing. This is a difficult topic with no clear answer. Smaller PKGBUILDs are somewhat trivial, but what about bigger ones? I would really like to further read my name in a PKGBUILD in foreign repos like Manjaro, If I have invested hours of work into it (the vault PKGBUILD is one of these examples). Chris
On Tue, Aug 25, 2020, 21:59 Evangelos Foutras via arch-dev-public < arch-dev-public@archlinux.org> wrote:
I am not sure these serve any purpose. The maintainer line duplicates information available from the archweb or aur interfaces and could also be outdated. The contributor lines are mostly redundant with svn or git history, can take up several lines in the PKGBUILD and can become irrelevant after significant refactoring.
What are your thoughts on dropping all these seemingly unnecessary lines from our official PKGBUILDs? Anyone feel strongly about keeping them (and why)?
I agree with your reasoning and am all in favor. Sven
On 8/25/20 3:58 PM, Evangelos Foutras via arch-dev-public wrote:
I am not sure these serve any purpose. The maintainer line duplicates information available from the archweb or aur interfaces and could also be outdated. The contributor lines are mostly redundant with svn or git history, can take up several lines in the PKGBUILD and can become irrelevant after significant refactoring.
What are your thoughts on dropping all these seemingly unnecessary lines from our official PKGBUILDs? Anyone feel strongly about keeping them (and why)?
If they ever leave the git repository, they do become somewhat useful... "someday" it would be nice for pacman/repo-add to support "source repositories" containing `makepkg --source` artifacts. We also have a bunch of these in https://sources.archlinux.org/sources/ Certain downstream distros (Parabola, ALARM) sync the PKGBUILDs and check them into their own version control, with modifications. There's no git log there to point at the maintainers/contributors of the parts that were synced from us. As Lukas mentioned, your points only really touch on the Maintainer line, the Contributor lines aren't at all covered due to not actually being recorded in svn or git history at all: - svn *can't* store it - people in the AUR are as likely to pastebin a PKGBUILD update (with their name added to the Contributor: lines) as to submit a git patch - official repos <--> AUR don't have any links and probably will not even without svn as a factor, since they have different requirements like .SRCINFO I don't know whether it's actually a matter of care and concern to be able to tell, historically, who the old maintainer was, but I wouldn't actually assume that "the person who committed the change is the maintainer", it's often non-maintainer updates for various reasons. tl;dr The information cannot be replaced and is not redundant. But it might be that no one actually cares about the information. On the other hand, is it bothersome to have it there anyway? -- Eli Schwartz Bug Wrangler and Trusted User
On Wed, 26 Aug 2020 at 01:11, Eli Schwartz via arch-dev-public
The information cannot be replaced and is not redundant. But it might be that no one actually cares about the information. On the other hand, is it bothersome to have it there anyway?
All right, I'm withdrawing my proposal based on Lukas' feedback and yours. Thank you both for bringing up the lack of contributor information when packages move from or to the AUR (or even outside of Arch). While I have never found a use for the maintainer and contributor lines, they may matter to some people either as recognition of their contribution or for some practical application I can't think of.
participants (5)
-
Christian Rebischke
-
Eli Schwartz
-
Evangelos Foutras
-
Lukas Fleischer
-
Sven-Hendrik Haase