[aur-general] Trusted user application: Drew DeVault

[Eli Schwartz]

On 2/28/19 8:58 AM, Jerome Leclanche wrote:
> On Thu, Feb 28, 2019 at 12:51 PM Josef Miegl <josef at miegl.cz> wrote:
>> Although I don't have high expectations when dealing with AUR packages, it is absolutely the maintainers job to keep track of upstream updates. This mindset is probably the reason why there is so much out of date stuff on the AUR. It strikes me that a maintainer who doesn't keep track of his own packages wants to become a TU.
> 
> No, it is not, and please don't expect this of volunteers. The
> responsibility goes as far as security (being made aware ASAP of
> security issues in packages), but knowing in general when a release
> happens is not (and/or shouldn't be) the TU's responsibility.
> Most TUs do know when a release happens in at least a portion of their
> packages, by nature of often maintaining packages they have some
> working relationship with. But the flagging system is very useful in
> crowdsourcing the non-security-sensitive portion of package
> maintenance.
> 
> As for being frustrated with the OOD packages on the AUR, I encourage
> you to make use of the flagging system yourself. It's present there as
> well. And if you think you can do better than the package's
> maintainer, ask to co-maintain it, or adopt it if it's abandoned. And
> in the mean time, you get to be able to download the PKGBUILD and
> modify it to your liking, that's the whole point of that system.
> If this sounds pointed, that's because I'm not amused by this idea
> that anyone who puts a package on the AUR should be at the service of
> those who download it. Arch philosophy goes above and beyond to drive
> in people's heads that the AUR is unsupported, to the point of
> rejecting any AUR helper in official packages. Expectations should be
> set accordingly.

I'm less concerned about people who don't keep track of OOD packages in
the AUR, and more concerned about:

"I respectfully disagree. The barrier to entry for the AUR is almost
nonexistent and there's no expectation of support or quality - from Arch
Linux or from the maintainers."

This would be because I, um, respectfully disagree and believe that the
memetic lack of quality in the AUR is something to be overcome by a
community working together, not something to brag about.

It is generally assumed that someone maintains a package because they
care about it at least somewhat. An out od date package in the official
repos *or* in the AUR, probably at least still works, right?
-ENOTENOUGHTIME is an understandable issue to have. Quality of the
package is a different story, though, and it likewise (IMO) applies in
all cases.

- Do we actually *want* people to say "I don't dare trust AUR packages
  to even build correctly without personal scrutiny"?
- One of the purposes of the AUR is to serve as an initial testing
  ground so good, popular packages can be elevated to community. It's
  depressing when in order to move nice software to community, the AUR
  PKGBUILD needs to be thrown in the dumpster and rewritten from
  scratch. It is, contrarily, pleasant when the PKGBUILD is well-written
  and can be copied to community intact (with #Contributor lines etc.).

Moreover, TUs are meant to be an example to the community: what does it
say if a TU candidate has packages that are a bad example, not because
they are a constantly-improving work in progress and one or two mistakes
were made across most packages, but because:

"I take some degree of personal pride in having nice AUR packages, but I
also have a limited amount of time. Of course, I take my responsibility
as maintainer much more seriously when working with packages in official
repos."

This feels like totally the wrong attitude to approach anything. It
reads as though the limited amount of time has resulted in a belief that
"I feel proud if my packages are quality, but if they're not, I won't
try to make them better without being bugged by someone else, because I
have better things to do with my time".

Disclaimer: when I initially mentioned I generally admire Drew's
open-source work, this did not take into account his AUR packaging
standards, as I had not looked at any of them. I can 100% see why people
are looking at this and wondering if maybe his impressive work elsewhere
in the Linux community is only impressive elsewhere, where he feels his
time is a worthwhile investment.

I'm sure most if not all Devs and TUs can tell similar stories about
being overworked. I would hope that we all still invested in devoting at
least some of that time to improving our packages even when they're not
official repo candidates. After all, packaging, and being a good example
of it, is ostensibly one of the jobs of a TU. There is a reason the job
description includes "people who oversee the AUR".

> On Thu, Feb 28, 2019 at 2:16 PM alad via aur-general
> <aur-general at archlinux.org> wrote:
>> Generally, while expectations are naturally not as high as with
>> community packages, lacking quality of PKGBUILDs in AUR remains
>> problematic when trying to promote AUR packages to community. Due to
>> this, a complete rewrite of the PKGBUILD is usually required, rather
>> than making some minor adjustments.
>>
>> https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html
> 
> OT: We should maybe have the AUR lint PKGBUILDs on git push (and
> reject really bad ones) if we want to improve that situation.

I would eagerly welcome any way to reliably do exactly that in an
automated fashion, with the caveat that doing so more or less inevitably
involves arbitrary code execution -- this is the reason why we in fact
do not read the PKGBUILD at all, but created the .SRCINFO instead.

I see no reason why we should allow packages that do not actually build
correctly at the time of submission, except the fact that it has thus
far proven to be programmatically infeasible.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20190228/6369c927/attachment-0001.sig>