[arch-dev-public] Decisions on AUR management - Was: RFC: Forbid dummy packages from AUR
Allan McRae
allan at archlinux.org
Thu Mar 24 11:24:03 UTC 2022
On 24/3/22 18:42, Brett Cornwall via arch-dev-public wrote:
> On 2022-03-24 13:23, Allan McRae via arch-dev-public wrote:
>> On 24/3/22 11:07, Brett Cornwall via arch-dev-public wrote:
>>> A new RFC (request for comment) has been opened here:
>>>
>>> https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/12
>>>
>>> Please visit the above link for discussion.
>>>
>>> Summary: Reject AUR packages that fulfill package dependencies
>>> without providing the files/binaries of the package in question.
>>
>>
>> Just a query if this crosses the line into to distro policy (i.e. RFC
>> Land) from TU self-governing policy land? I'm OK with this being
>> discussed as an RFC (openness and visibility is good), but my initial
>> reaction was this could have been discussed "internally" by the
>> maintainers of the AUR (TUs) using aur-general.
>
> This proposal was brought up on #archlinux-tu and I was encouraged to
> create an RFC. Perhaps I was mistaken in thinking that the AUR was a
> project of Arch:
>
>> A Request for Comment (RFC) is a way for Arch Linux contributors to
>> propose, design and discuss new features and changes in project
>> direction in a focused environment.
From:
https://github.com/archlinux/tu-bylaws/blob/master/tu-bylaws.adoc
Mission: #2
"Maintain, manage, and watch over the operation of the AUR."
This proposal sounds like a management of the AUR issue.
> I can withdraw this but I'd advise clarification that TUs should go
> huddle in another corner for future discussion. Perhaps another repo for
> TU rfcs would be welcome if this is the case.
Again, from the TU bylaws:
"Standard Voting Procedure (SVP) describes the formal procedure used by
TUs to accept or reject proposals regarding TU affairs."
TUs have a process to follow already. A separate RFC repo would require
TU Bylaw changes.
Currently, it is unclear to me whether accepting an RFC still requires a
TU vote for the policy to be accepted. With that uncertainty, I put
more weight on the side with formal bylaws.
As I said, I'm happy the discussion around this RFC is public and open.
But if this is a big enough change for an RFC, then it almost certainly
needs to go through the TU voting procedure.
Allan
More information about the arch-dev-public
mailing list