2019. 08. 16, péntek keltezéssel 15.19-kor Jean Lucas via aur-general ezt írta:

If I were accepted to become a TU, I'd like to adopt and move the following packages (all having over 10 votes in the AUR) from the AUR into [community]:

anydesk, downgrade, exercism, flutter, godot, itch, mattermost- desktop, nvm, reaper, spotify, teamviewer, thermald, unity-editor, and unityhub, for starters!

anydesk, reaper, spotify, teamviewer, unity-editor and unityhub are proprietary software with restrictive license. I don't think that you can legally distribute them. -- György Balló Trusted User

I'm currently maintaining unity-editor and unityhub and I don't think they will allow redistribution of binaries. They even dropped the official Ubuntu packages in favor of their custom installers. And honestly it makes more sense to do it this way because the engine is a big self contained blob and users usually need to have several different versions installed at the same time to patch old projects etc. On Fri, Aug 16, 2019, 22:20 Sven-Hendrik Haase via aur-general < aur-general@archlinux.org> wrote:

On Fri, Aug 16, 2019, 22:06 Balló György via aur-general < aur-general@archlinux.org> wrote:

...

2019. 08. 16, péntek keltezéssel 15.19-kor Jean Lucas via aur-general ezt írta:

...

If I were accepted to become a TU, I'd like to adopt and move the following packages (all having over 10 votes in the AUR) from the AUR into [community]:

anydesk, downgrade, exercism, flutter, godot, itch, mattermost- desktop, nvm, reaper, spotify, teamviewer, thermald, unity-editor, and unityhub, for starters!

anydesk, reaper, spotify, teamviewer, unity-editor and unityhub are proprietary software with restrictive license. I don't think that you can legally distribute them.

-- György Balló Trusted User

Well, you can always ask upstream. So far, we received exceptions for redistribution of more software than we got rejections for, I think.

...

On August 16, 2019 9:19:56 PM GMT+02:00, Jean Lucas via aur-general wrote:

If I were accepted to become a TU, I'd like to adopt and move the following packages (all having over 10 votes in the AUR) from the AUR into [community]:

... , downgrade,...

It's never been official in the past as that's per definition partial upgrade when using anything but the version from the repo. We do not support partial upgrades and we should not officially provide an application whose very purpose is to deviate from the current repo state to any arbitrary version in the past.

On Fri, 2019-08-16 at 22:40 +0200, Sven-Hendrik Haase via aur-general wrote:

On Fri, 16 Aug 2019 at 22:35, Oscar wrote:

...

I'm currently maintaining unity-editor and unityhub and I don't think they will allow redistribution of binaries.

They even dropped the official Ubuntu packages in favor of their custom installers. And honestly it makes more sense to do it this way because the engine is a big self contained blob and users usually need to have several different versions installed at the same time to patch old projects etc.

On Fri, Aug 16, 2019, 22:20 Sven-Hendrik Haase via aur-general < aur-general@archlinux.org> wrote:

...

On Fri, Aug 16, 2019, 22:06 Balló György via aur-general < aur-general@archlinux.org> wrote:

...

2019. 08. 16, péntek keltezéssel 15.19-kor Jean Lucas via aur- general ezt írta:

...

If I were accepted to become a TU, I'd like to adopt and move the following packages (all having over 10 votes in the AUR) from the AUR into [community]:

anydesk, downgrade, exercism, flutter, godot, itch, mattermost- desktop, nvm, reaper, spotify, teamviewer, thermald, unity-editor, and unityhub, for starters!

anydesk, reaper, spotify, teamviewer, unity-editor and unityhub are proprietary software with restrictive license. I don't think that you can legally distribute them.

-- György Balló Trusted User

Well, you can always ask upstream. So far, we received exceptions for redistribution of more software than we got rejections for, I think.

Never hurts to ask. :)

Asking should also be done in the case of all the packages Jean mentioned.

I would definitely be willing to very politely ask the five respective companies for redistribution permissions for Arch Linux.

On Fri, 2019-08-16 at 17:47 -0400, Eli Schwartz via aur-general wrote:

On 8/16/19 3:19 PM, Jean Lucas via aur-general wrote:

...

Hi all,

My name is Jean Lucas, and I'm sending this email to submit my candidacy for Trusted User member. As per the latest TU bylaws, I'm being sponsored by both Alexander Rødseth and Sergej Pupykin.

I've been an Arch Linux user since around a little before I registered my AUR account (January 2015, username "flacks" [1]), and I've recently had a few of my packages adopted into [community], namely "cage", "coturn", and "swaybg".

I'm currently a computer science student with a particular interest in software engineering ranging from low-level (with a few contributions to projects like coreboot and postmarketOS) all the way up to web development (my current focus), and as such, would love to help maintain Arch's [community] repo in an official capacity to be part of the team that gives Arch users a robust, high-quality Linux software experience; as well as to help maintain, manage, and watch over the operation of the AUR and it's vast sea of software packaging recipes.

If I were accepted to become a TU, I'd like to adopt and move the following packages (all having over 10 votes in the AUR) from the AUR into [community]:

anydesk, downgrade, exercism, flutter, godot, itch, mattermost- desktop, nvm, reaper, spotify, teamviewer, thermald, unity-editor, and unityhub, for starters!

In the case of Spotify specifically, the AUR maintainer is already a TU, and had you asked him before being eager to move it to community he'd have probably told you that you're not the first or even the second (or third? I lose track) person to propose moving it. I think someone may have also suggested it in a TU application before...

Understood. My apologies for not having researched this well enough beforehand.

Either way you should definitely ask the maintainer if it is okay to move it to community. If that maintainer is a TU, and they haven't moved it to community on their own, there is probably a reason.

Understood. My intention was to open a dialogue with the maintainer of any owned package before taking any action.

downgrade:

I'm quite hesitant to have "downgrade" in the repos, it seems to be an immense antipattern -- not quite as bad as an AUR helper in[community], but nearly. Also isn't even well written as it does a ton of parsing HTML files and pacman.conf in sed, instead of using either pacman- conf or an HTML parser. I really wish that people who wrote complex integrations around pacman/makepkg would follow pacman development -- in fact, many of the current crop of AUR helpers do exactly that, which is why I would even dare use some of them.

If we *were* going to add a program to pander to the desire to have partially updated systems, I would prefer to create a new tool from scratch.

Also "downgrade" indexing archive.archlinux.org (with sed or anything else) is problematic due to the fact that we no longer store many versions of packages but upload them to archive.org and delete them from our own server (and use rewrite rules to let users download the files, but that doesn't help to build an HTML index). So I'm decidedly unsure how useful it's supposed to be even at fulfilling its desired goal.

Understood. downgrade can be scratched until a better solution everyone agrees with comes along.

...

Additionally, I would express my willingness to help co-maintain "firejail" (already in [community]), as its a project I have a higher interest in and contribute to occasionally; as well as to help get "ghidra" in good enough shape to propose moving it into [community], since I've had lots of fun building it [2], its a phenomenal piece of open-source software, and it'd be nice to have it officially supported by the Arch community (it also has a nice number of votes in the AUR)!

Thank you for your time, and thank you to all who help make Arch a great OS!

Best regards,

Jean Lucas

[1] https://aur.archlinux.org/account/flacks [2] https://aur.archlinux.org/cgit/aur.git/log/?h=ghidra-git

On Sat, 17 Aug 2019 at 01:35, Josef Miegl wrote:

On August 16, 2019 10:05:54 PM GMT+02:00, "Balló György via aur-general" < aur-general@archlinux.org> wrote:

...

anydesk, reaper, spotify, teamviewer, unity-editor and unityhub are proprietary software with restrictive license. I don't think that you can legally distribute them

Even if we could, is there a reason to flood arch repositories with these proprietary programs? In my opinion proprietary programs should be an exception, not the norm.

Josef Miegl

Whether they are proprietary or not has never been a large concern for Arch. What concerns us is whether they are useful or not and whether they'd actually be used by any amount of people. Arch is all about pragmatism. Sometimes, binary blobs are inconvenient for us because if they break we can't fix them. However, that's an entirely separate can of worms which I don't want to open in this thread. Bottom line: If it's legal to package and it's useful and popular software, there's really no reason not to package it.

On 8/16/19 9:19 PM, Jean Lucas via aur-general wrote:

Hi all,

My name is Jean Lucas, and I'm sending this email to submit my candidacy for Trusted User member. As per the latest TU bylaws, I'm being sponsored by both Alexander Rødseth and Sergej Pupykin.

How many TUs did you ask for sponsorship, and how many declined? For the record, flacks has approached me a few weeks ago and asked for sponsorship. I had reviewed his PKGBUILDs and suggested many fixes at the time, and also explained that I do not think it is time yet to move forward with a TU application. I offered reviewing his future things, and helping with general mentoring, however it seems like my offer was not taken - instead you just found someone else to sponsor you without batting an eye... Off to a great start.

If I were accepted to become a TU, I'd like to adopt and move the following packages (all having over 10 votes in the AUR) from the AUR into [community]:

anydesk, downgrade, exercism, flutter, godot, itch, mattermost-desktop, nvm, reaper, spotify, teamviewer, thermald, unity-editor, and unityhub, for starters!

As explained by others, most of these cannot be moved. Have you talked to your sponsors about this? What have they said about this?

Best regards,

Jean Lucas

[1] https://aur.archlinux.org/account/flacks [2] https://aur.archlinux.org/cgit/aur.git/log/?h=ghidra-git

xyproto, sergej - have you reviewed this application before? Given that there hasn't been an ACK from any of you guys after the application was posted, i doubt it... -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On 8/17/19 8:49 PM, Jean Lucas wrote:

Hi Robin,

On Sat, 2019-08-17 at 10:13 +0200, Robin Broda via aur-general wrote:

...

On 8/16/19 9:19 PM, Jean Lucas via aur-general wrote:

...

My name is Jean Lucas, and I'm sending this email to submit my candidacy for Trusted User member. As per the latest TU bylaws, I'm being sponsored by both Alexander Rødseth and Sergej Pupykin.

How many TUs did you ask for sponsorship, and how many declined?

In totality, I asked 4 TUs - Alexander, Sergej, Alad, and you.

Why did you not make this clear in your application? I'm sure you've read the wiki article on Trusted Users[1] -

*Note*: Should the TU you contact decline to sponsor your application, you should make this fact known if you seek sponsorship from another TU.

Have you at least told xyproto & sergej that you have approached alad and me, and the reason for me declining sponsorship?

after a follow-up, you declined sponsorship for the moment.

Indeed, I did however offer to review any new things.

I tried reaching out to you over IRC last Sunday, but alas, I probably should have done so over email instead.

This is the last i received from you, FWIW

0507201 9:00:00 <flacks> thank you for your feedback! all good points

That said, I think its a bit unfair to say that I went off and found another sponsor without batting an eye - asking Alexander and Sergej seemed appropriate as they'd both adopted one of my packages, I had worked with you to resolve some of my issues, I've gone over all of my packages with a fine-toothed comb many times now, and got more help as needed. I didn't suppose that having you decline sponsorship should deter me from eventually applying until getting your approval. I regret that we didn't have better communication, though.

I don't think that's how it's supposed to work.

...

As explained by others, most of these cannot be moved. Have you talked to your sponsors about this? What have they said about this?

I did not discuss the moving of those packages with my sponsors. I was hoping to get the community's feedback on the ideas.

But they're the perfect people to talk to about this!

...

xyproto, sergej - have you reviewed this application before?

They did not review my application. I composed it all myself, for which I take full responsibility. I had worked on their willingness to sponsor me and sent what I considered to be a fair application ready for community feedback.

Welp, we cannot really move forward with this unless your sponsors are willing to sign off on your application, anyways. All in all I'm fairly disappointed in how rushed you are with this. You went through 4 people, and at least one has brought up concerns, the others likely being unaware... [1] https://wiki.archlinux.org/index.php/Trusted_Users -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

I reached out to Alad sometime in between, but he never responded to my profile review request;

While I don't claim to be the most apt in responding to emails, I see no Jean Lucas orjean@4ray.co in my mailbox. I guess that's why I did not respond then.

That said, I think its a bit unfair to say that I went off and found another sponsor without batting an eye

That doesn't really matter - the admission guidelines [1] cleary say that you should mention any previous sponsors you've contacted. ]1]https://wiki.archlinux.org/index.php/Trusted_Users#How_do_I_become_a_TU?

On Fri, Aug 16, 2019 at 03:19:56PM -0400, Jean Lucas via aur-general wrote:

Hi all,

Thank you for your time, and thank you to all who help make Arch a great OS!

Always happy to help! :) It's customary to review PKGBUILDS for new applicants. This is somewhat of a quick/cursory review over 3 random packages as I've been in conferences for the whole week. == Overall == - It appears you need quote strings way more everywhere, from deps, to licenses to variables.... - Consider that base-devel is assumed to exist for makedepends and (iirc). == Beaker == - This depends array has to be wrong - This makedepends array too. you should make sure things aren't depending on py2 anymore - I'm also a little confused, did you take over the namespace of another project called beaker? Why not just call this beaker browser? == Oxy == - I think you should document why you're cherry-picking that commit rather than using a tag. Admittedly this is probably upstream's fault, but still, better to be clear. - Again, I think your depends are either too verbose or wrong. == stf == - This appears to me it's a -bin package - npm -i -g --prefix seems like a good way to overwrite a bunch of system files and/or cause a bunch of file conflicts - I think you can use $pkgname more often, namely when resolving the url and resolving the tgz file - I'm curious to know where you got those depends arays, they seem to be a little off... do you really need python, graphicksmagic and protobuf to basically extract a tarball? - I'm also not sure why *everything* is just blindly put on /usr == Conclusion == - I think you are on the right path, but some decisions made me wonder whether your sponsors actually reviewed the PKGBUILDS with you. Hope this helps, -Santiago

On 8/17/19 10:51 PM, Santiago Torres-Arias via aur-general wrote:

On Fri, Aug 16, 2019 at 03:19:56PM -0400, Jean Lucas via aur-general wrote:

...

Hi all,

Thank you for your time, and thank you to all who help make Arch a great OS!

Always happy to help! :)

It's customary to review PKGBUILDS for new applicants. This is somewhat of a quick/cursory review over 3 random packages as I've been in conferences for the whole week.

I haven't looked at Jean's packages myself, but I'm not sure some of these things you point to are actually problems.

== Overall ==

- It appears you need quote strings way more everywhere, from deps, to licenses to variables....

Quote strings are only necessary for variable expansions which could potentially undergo word splitting. For declaring an array (deps, licenses) it's completely unnecessary as you know when writing the PKGBUILD if there are spaces (and most makepkg fields don't permit spaces anyway). Admittedly I think single-quoting array keys looks prettier. That's a personal opinion though.

- Consider that base-devel is assumed to exist for makedepends and (iirc).

This is not great if it is in makedepends, but honestly we still haven't fully fixed the official repos for this.

== Beaker ==

- This depends array has to be wrong - This makedepends array too. you should make sure things aren't depending on py2 anymore

What's necessarily wrong with this? I don't like py2 either, but just because something uses it doesn't mean it has no reason to. What specifically made you think it isn't needed? What is wrong with the dependencies that it "must" be wrong? From a cursory inspection it seems to be some sort of electron thingy, which would hopefully use community/electron but life isn't perfect. Depending on glibc and gcc-libs is a bikeshed topic that TUs/Devs don't agree on. The rest of the dependencies could plausibly be linked to by whichever version of prebuilt electron is being downloaded by the build system.

- I'm also a little confused, did you take over the namespace of another project called beaker? Why not just call this beaker browser?

== Oxy ==

- I think you should document why you're cherry-picking that commit rather than using a tag. Admittedly this is probably upstream's fault, but still, better to be clear.

Upstream is amazing and doesn't use git tag. The cherry-picked commit has the commit message "Call it a version". This is obvious enough causes that I don't actually feel bad about the lack of comments. :)

- Again, I think your depends are either too verbose or wrong.

There's exactly one depends, which is gcc-libs. Again, a bikeshed topic. I will loudly proclaim my own belief in not depending on gcc-libs or anything else in *base*, but I won't tell anyone they are *wrong* for doing so themselves. (Obviously makedepends on base-devel is still against the packaging guidelines.)

== stf ==

- This appears to me it's a -bin package

Why? It looks like some sort of standard js-based source package on the NPM registry.

- npm -i -g --prefix seems like a good way to overwrite a bunch of system files and/or cause a bunch of file conflicts

npm install -g --prefix="$pkgdir" is actually how you are supposed to install npm stuff -- it "globally" installs it to the packaging directory so that pacman will install it to /usr, so it should never conflict with anything. This seems fine to me. (I have personal issues with npm as a technology, and prefer to npm install into $srcdir then use cp because it feels at least mildly cleaner -- see my rapydscript-ng package -- but stf doesn't seem any less valid and some official packages do the same thing he does).

- I think you can use $pkgname more often, namely when resolving the url and resolving the tgz file

I've seen it both ways extremely often. I think some people actually insist on hardcoding $pkgname everywhere, because they want to preserve the possibility of users forking the PKGBUILD, modifying the pkgname, and still have everything work without having to fix up all pkgname references.

- I'm curious to know where you got those depends arays, they seem to be a little off... do you really need python, graphicksmagic and protobuf to basically extract a tarball?

Not to extract a tarball. This is npm. It's not just extracting a tarball, it is also probably downloading half the internet during build, and maybe compiling G-d-knows-what after the unauthenticated download. Because npm. And npm sucks. But the package itself seems fine, and I'd need to actually look in depth at the build in order to decide if those makedepends raise a red flag.

- I'm also not sure why *everything* is just blindly put on /usr

It's not? npm install (like make install except that npm is obviously terrible because javascript desktop programming) is responsible when given --prefix="$pkgdir/usr" to place "everything" in the places where npm thinks they should go. It's like passing DESTDIR="$PKGDIR" PREFIX=/usr to a Makefile. It seems totally like the correct thing to do for an npm project.

== Conclusion ==

- I think you are on the right path, but some decisions made me wonder whether your sponsors actually reviewed the PKGBUILDS with you.

If this is the worst that the applicant has, then that's not very bad at all. :D :D -- Eli Schwartz Bug Wrangler and Trusted User

On 8/18/19 12:26 AM, Santiago Torres-Arias wrote:

...

...

- This appears to me it's a -bin package

Why? It looks like some sort of standard js-based source package on the NPM registry.

well, judging from the lack of build() I'd assume so. I'm not too familiar with npm, but if t is running build commands (as you concede down in the email it may be happening) then that probably should happen inside of build()?

That's what I do for rapydscript-ng. If you try to npm install in build() and then npm install --prefix="$pkgdir/usr" in package(), I'm pretty sure it will just build a second copy all over again, during the package() step. Repeat after me: "curse you, npm". It is very, very, very difficult to provide meaningful criticism of an npm PKGBUILD. There aren't a lot of options when it comes to packaging this language. -- Eli Schwartz Bug Wrangler and Trusted User

I would definitely be willing to very politely ask the five respective companies for redistribution permissions for Arch Linux. In the case of reaper, I've already been in contact with Cockos to try and move that to [community] and they didn't reply to multiple requests

On 2019-08-16 17:10:41 (-0400), Jean Lucas via aur-general wrote: through several channels. On its own, I have not been able to make sense out of the OEM distribution license [1] for that matter either. "... but I'm not a lawyer (TM)." Best, David [1] https://www.reaper.fm/dist-agreement.php -- https://sleepmap.de

On Sat, 2019-08-17 at 22:51 -0400, Santiago Torres-Arias wrote:

On Fri, Aug 16, 2019 at 03:19:56PM -0400, Jean Lucas via aur-general wrote:

...

Hi all,

Thank you for your time, and thank you to all who help make Arch a great OS!

Always happy to help! :)

It's customary to review PKGBUILDS for new applicants. This is somewhat of a quick/cursory review over 3 random packages as I've been in conferences for the whole week.

Thank you for the review!

== Overall ==

- It appears you need quote strings way more everywhere, from deps, to licenses to variables.... - Consider that base-devel is assumed to exist for makedepends and (iirc).

As Eli explained, the quotes are unnecessary unless you need to do variable expansion, and makepkg yells at you if you include a space somewhere. As for array keys, I think that no quotes looks way prettier

:)

And yes, I've been working on the assumption that base-devel is installed for makedepends.

== Beaker ==

- This depends array has to be wrong

I've been working on parsing namcap output to make my life a little easier, so I'm basically throwing what namcap outputs w.r.t. deps at a script I wrote that looks up the missing libraries and spits out the needed packages, and I throw that into the depends of pkgbuilds. I do know that some dependencies are subdependencies of more higher-level packages (i.e. the higher-level packages already pull the subdependencies in) but I haven't yet scripted a way to intelligently omit those subdependencies. I don't think it is harmful to be very verbose on those dependencies, but I do make sure I work from an empty depends array to exactly what namcap tells me, as well as interpreting readmes and reading through the actual software being packaged. Then I test all my packages in clean chroots (especially graphical applications) to ensure I have the minimal amount of deps needed. As for depending on Electron, Beaker builds a self-contained Electron app, hence the specific need for all the dynamic dependencies (that something like wire-desktop can leave for community/electron to resolve, since it does not bundle Electron). As for glibc/gcc-libs, yes this seems like quite an involved topic with a lot of angles. Arch is glibc-based, they're both in base, so they could *probably* be omitted - I'm working on the fact that namcap tells me I need them :X

- This makedepends array too. you should make sure things aren't depending on py2 anymore

Py2 isn't officially EOL *yet* - that's in January 2020 :) but I prefer to let upstream switch their dependency to Py3 because - I'm not a Python expert here so please correct me if I'm wrong - there could be some form of incompatibility when manually hacking in a Py3 build, especially for something as complex as a browser.

- I'm also a little confused, did you take over the namespace of another project called beaker? Why not just call this beaker browser?

I don't have an airtight answer for this - I liked the named beaker more, and saw it used officially just about everywhere except the domain name and the GitHub user name. I also followed the train of logic that Firefox isn't named firefox-browser, nor Chromium chromium- browser - but then again, I was also unaware of the existence of an existing project called Beaker. I didn't see it in the AUR nor the official repos, so I went ahead and solicited the namespace change.

== Oxy ==

- I think you should document why you're cherry-picking that commit rather than using a tag. Admittedly this is probably upstream's fault, but still, better to be clear.

You're right - better to be clear. I will document my cherry-picks from now on. But yeah, not tagging your releases is kind of annoying.

- Again, I think your depends are either too verbose or wrong.

This goes back to the glibc/gcc-libs point above :)

== stf ==

- This appears to me it's a -bin package

I use this package every day - its definitely not a bin / it builds the platform.

- npm -i -g --prefix seems like a good way to overwrite a bunch of system files and/or cause a bunch of file conflicts

As Eli mentioned, this is basically the standard way of building NPM packages. I customarily check the file tree of my packages and make sure things are neat and don't collide.

- I think you can use $pkgname more often, namely when resolving the url and resolving the tgz file

After reading Eli's reply to this point, I can see a point for why one would want to hardcore $pkgname everywhere (for namespace changes). I basically use $pkgname if its shorter than typing the actual pkgname, haha. But I really think a package maintainer should always be reviewing build/packaging instructions, and a $pkgname change, as normally glacial/infrequent as that is, should be very obvious to a maintainer during rebuild. For URLs - those can change a lot, and be radically different e.g. switching from PyPI to GitHub, so hardcoding $pkgname there is IMO a bad idea, and should be evaluated on a case-by-case basis. For source naming schemas, you do want the source tarball to be $pkgname, so I could see the usage there.

- I'm curious to know where you got those depends arays, they seem to be a little off... do you really need python, graphicksmagic and protobuf to basically extract a tarball?

So yes, since this is a full build and not just a tarball extraction, those are precisely the minimal amount of dependencies needed for build.

- I'm also not sure why *everything* is just blindly put on /usr

So this is basically the only pattern I've seen for Arch NPM packages, it seems correct to me because system-wide node_modules go in /lib. As Eli mentioned, its basically akin to the DESTDIR="$pkgdir" PREFIX=/usr for Makefile pattern. Either way, as mentioned, I check my packages in case of any lingering other-Linux-distro-specific files or otherwise, although thats not so common IME, especially for NPM packages.

== Conclusion ==

- I think you are on the right path, but some decisions made me wonder whether your sponsors actually reviewed the PKGBUILDS with you.

I believe that my profile was posted for review among the TUs when I solicited Alexander's sponsorship, and he and Robin (although later confirmed not a sponsor) relayed to me one package with more obvious errors - generating keys which affected reproducible builds, as well as grepping the system for a binary which was considered questionable from a security POV - in searx-git. Robin also relayed to me a few other less troublesome issues (like removing -git/-bin package variants from conflicts, source naming and pkgver schema fixes). I believe Sergej went over a few of my packages at least before giving an OK for sponsorship, but that was 2 weeks after I had requested sponsorship, at which point I had cleaned up a lot of the errors that were raised :) Still - I do acknowledge that I could've had much better communication with everyone involved, and if I don't get accepted for TU this time around, if I try again later, I'll be sure to do my best to not commit the same mistakes again.

Hope this helps, -Santiago

My name is Jean Lucas, and I'm sending this email to submit my candidacy for Trusted User member. As per the latest TU bylaws, I'm being sponsored by both Alexander Rødseth and Sergej Pupykin.

I have nothing against this application. I use parsedmarc package (slightly modified for my needs) which maintained by Jean.

Giancarlo Razzolini via aur-general wrote:

Having nothing against is not the same as actively sponsoring it. All this discussion is kind of pointless until we hear from both sponsors telling us they actively sponsor Jean's application. Then the discussion period can begin.

Ok, I am not sure about "actively" :) but I want to see parsedmarc package bundle in community. As well as ghidra and coturn (which is already in community), so I sponsor him.

Hi Jean Lucas, I've been reading your TU application and I wish you the best of luck. However, I can't seem to find the GPG key you're using on any keyservers. Did you happen to forget to submit it somewhere? Best, Bert.

Em agosto 20, 2019 13:16 Jean Lucas via aur-general escreveu:

Hi Bert, and thank you!

My (latest) key can be found at https://keys.openpgp.org/search?q=jean%404ray.co and https://pool.sks-keyservers.net/pks/lookup?search=jean%404ray.co&fingerprint=on&op=vindex (as well as the servers SKS Keyservers gossips with).

On SKS Keyservers, I had originally submitted 2 keys in 2015, and they've both since been revoked. So my latest, active key has fingerprint 553C C0A1 134A 2E77 145B E12D 7416 2644 B297 6F6C, as posted on my AUR profile at https://aur.archlinux.org/account/flacks/.

Hi Jean, Can you as your second sponsor to reply to this thread so we can start the discussion period? Ideally, Alexander should also sign his email, like Sergej did. Our bylaws unfortunately do not mention this, neither does our wiki. Regards, Giancarlo Razzolini

On Sunday, September 1, 2019 9:39:37 AM EDT Xyne wrote:

The lackadaisical approach to sponsorship is one of the main reasons that we've moved to a system with two sponsors. Maybe I missed the joke, but having nothing against someone and wanting to see a particular package in community is not a good enough reason to sponsor someone. A TU application may not be a matter of life and death but the process should be taken somewhat seriously nevertheless given how many people could be potentially impacted if a malicious candidate is accepted.

We need to agree to set the bar a little higher.

That kinda speaks to the 'trust' in 'Trusted User'. It's not just "Oh hey, I want to contribute, give me the keys to the kingdom". You need to be vetted and checked out. Not just because of the potential for bad actors, but I think you also need to show you're actually capable of doing the job being asked of you. Sponsoring a TU applicant that you're friendly with, but has no real experience in packaging or any sort of development background, does a disservice to the community. It's not just, "Does the sponsor Trust this person" But "Can the community Trust this person?" I'm not saying that this is the case for this application, but that's the reason, I feel, why the process is involved as it is. Heck, it could be more intensive and I'd still say "Yeah, that's appropriate." Like Xyne said, not commenting on the TU application at all. Just responding with my thoughts to his comments.

Em setembro 4, 2019 9:54 Alexander Rødseth via aur-general escreveu:

I did agree to sponsor the TU application of Jean Lucas, provided he found another sponsor, but was not aware that he had sent his application without any mentoring on my part.

Well, I think it should be the other way around, you first mentor someone and look with them into their packages and then decided about sponsorship.

I am not in favor of how the TU application process turned out, nor the idea of moving proprietary software packages to [community], but I'll stand by my word and sponsor him if there is another sponsor.

Sergej already confirmed sponsorship. But it seems neither of you actually mentored the applicant.

In general, we need more TUs and Devs and I think we should have a process that feels less judgemental on the applicants (ref. the application from Drew DeVault that sadly did not join us as a TU).

While I agree that we should have a more on point discussion with less bikeshedding regarding other stuff, I don't think that simply foregoing the discussion period is the way to go.

If someone dislikes a TU application, it's easy to vote "no" in the vote that follows.

That's not how this should be faced. Ideally all the applications should have two sponsors that are actively mentoring the applicant and are vested into their success. If we had that, applications would be voted "yes". ps: I'm not making any judgment on the applicant here. I've talked with him privately regarding this application process. While he failed to disclose that he had asked another TU before, I don't think it was in bad faith. Regards, Giancarlo Razzolini

Hi, Giancarlo wrote:

Well, I think it should be the other way around, you first mentor someone and look with them into their packages and then decided about sponsorship.

That's your opinion, and here's mine: I don't think that's important. If a candidate looks promising and there is an intention to both sponsor (confirming by e-mail that the applicant is sponsored when they apply) and an intention to mentor (at least look through the AUR packages and give them helpful hints), I don't think the order matters, as long as everyone is honest with each other and both things happens before the application is sent. That's not what happened in this case, though, since the application was sent before there were any mentoring.

Sergej already confirmed sponsorship.

I read his reply twice, but I could not see a confirmation of sponsorship. Sergej, could you please clarify?

But it seems neither of you actually mentored the applicant.

It did not happen. I explicitly wrote that I was not aware that he had sent his application without any mentoring on my part.

I don't think that simply foregoing the discussion period is the way to go.

If Sergej also confirms his sponsorship, the discussion period can begin.

...

If someone dislikes a TU application, it's easy to vote "no" in the vote that follows.

That's not how this should be faced. Ideally all the applications should have two sponsors that are actively mentoring the applicant and are vested into their success.If we had that, applications would be voted "yes".

Not judging here by any means about the applicant himself, but I consider

This is disregarding that I was first on vacation and then didn't have the time to do any mentoring. I did not know that an application was sent. Please, be more generous in your interpretations. Levente wrote: the current state as void as we frankly did not go through long discussions and bylaw changes to implement two sponsors if at the end it doesn't provide more value than having a bigger number and "having nothing against because someone wants a package in the repo". Have Sergej confirmed his sponsorship, though? -- Sincerely, Alexander F Rødseth / xyproto

On 9/5/19 3:21 PM, Aaron Laws via aur-general wrote:

On Thu, Sep 5, 2019 at 3:45 AM Alexander F Rødseth via aur-general < aur-general@archlinux.org> wrote:

...

...

Sergej already confirmed sponsorship. I read his reply twice, but I could not see a confirmation of sponsorship. Sergej, could you please clarify?

...

...

Have Sergej confirmed his sponsorship, though?

For the record, it looks like Sergej has explicitly stated that he will sponsor in a signed message:

On Mon, Aug 19, 2019 at 9:49 AM Sergej Pupykin wrote:

...

Giancarlo Razzolini via aur-general wrote:

...

Having nothing against is not the same as actively sponsoring it. All this discussion is kind of pointless until we hear from both sponsors telling us they actively sponsor Jean's application. Then the discussion period can begin.

Ok, I am not sure about "actively" :) but I want to see parsedmarc package bundle in community. As well as ghidra and coturn (which is already in community), so I sponsor him.

I believe this marks the beginning of the discussion period.

Regardless of when the discussion period begins - the TU bylaws are not exactly clear about this - I'm not sure what's left to discuss. Concerns with this application have already been raised, and the applicant's packages have already been reviewed. Alad

...

Well, I think it should be the other way around, you first mentor someone

and look with them into their packages and then decided about sponsorship.

That's your opinion, and here's mine: I don't think that's important. If a candidate looks promising and there is an intention to both sponsor (confirming by e-mail that the applicant is sponsored when they apply) and an intention to mentor (at least look through the AUR packages and give them helpful hints), I don't think the order matters, as long as everyone is honest with each other and both things happens before the application is sent.

That's not what happened in this case, though, since the application was sent before there were any mentoring.

Through work, I've had the chance to train about ten employees and interns. I've also mentored two peers of mine. All of these people *looked* promising. They all either got through the job application process or struck me as someone I wanted to mentor. Furthermore, all of them professed a great interest in learning about QE, virtualization, software engineering, and whatever other topics were relevant to them. However, there have been a broad spectrum of outcomes. I'm going to be intentionally vague and say that some were brilliantly successful; others struggled but succeeded after *years* of intense efforts; others realized that they weren't actually that interested in the topic at hand, but only after investing much time and effort; and others failed due to incompetence and/or self-sabotage. Do I trust someone to be trustworthy and competent because they "[look] promising and there is an intention [...] to mentor"? Not at all. This is a comment on the sponsorship for this TU application, not a comment on this TU application itself (which has already been rescinded anyway).