Re: [aur-general] Trusted user application: Drew DeVault
Am 27.02.2019 um 07:56 schrieb Eli Schwartz via aur-general: On 2/27/19 1:37 AM, Brett Cornwall via aur-general wrote: On 2019-02-27 02:09, alad via aur-general wrote: Considering some recent issues regarding team behavior [1] in Arch, I'm going to have to ask on some of your previous interactions with the community, and open-source in general. I had two examples in particular, the MineTest community [2], and interaction with other Arch users on ArchWiki [3]. [1] https://lists.archlinux.org/pipermail/aur-general/2018-October/034461.html [2] https://news.ycombinator.com/item?id=18156980 [3] https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=prev&oldid=391411 By definition, a TU has to interact with users of community packages (bug reports, emails, coordination with the rest of the Arch team, ...), and users of the AUR in general (AUR requests, peace-keeping, interactions with previous maintainers when promoting packages, ...). This means that if aggressive behavior such as the above is part of some general theme, there is a clear problematic. Note that this is _not_ meant as a witch-hunt of any sort - nor do I have any kind of personal involvement here. I do however value healthy communication in the Arch community, and believe any TU candidate should value it as well. I would also chip in with the following from early 2017: https://github.com/swaywm/sway/issues/1227 (I am also not in any sort of witch hunt, just thought this would be relevant.) If the only thing we can find to complain about is his attitude towards Manjaro, then we obviously cannot find anything to complain about. :) It's not about the _what_, but about the _how_. The issue could have been easily closed with "I don't support Manjaro", rather than a series of insults. What if a Manjaro user files a bug on the bugtracker for one of the Arch packages? I hope no package maintainer in Arch would act the same. I get that emotions fly high whenever Manjaro gets involved, but I just don't see the point in addressing (public!) bug reports like this.
Re: [aur-general] Trusted user application: Drew DeVault
Em fevereiro 27, 2019 3:56 Eli Schwartz via aur-general escreveu: If the only thing we can find to complain about is his attitude towards Manjaro, then we obviously cannot find anything to complain about. :) I was surprised by this attitude since all my interactions with Drew in the past were quite friendly. Most (all?) were on IRC. I don't recall him being this aggressive on IRC. Having said that, I don't think we should ever treat anyone like this, regardless of distro. I have very little to say on the AUR packages that has not been said, but those interactions with users are something we need to also take in consideration. Regards, Giancarlo Razzolini pgp4X5r5V6QrH.pgp Description: PGP signature
Re: [aur-general] Trusted user application: Drew DeVault
On Wed, Feb 27, 2019 at 11:47 AM Giancarlo Razzolini via aur-general wrote: > > Em fevereiro 27, 2019 3:56 Eli Schwartz via aur-general escreveu: > > > > If the only thing we can find to complain about is his attitude towards > > Manjaro, then we obviously cannot find anything to complain about. :) > > > > I was surprised by this attitude since all my interactions with Drew in the > past were quite friendly. Most (all?) were on IRC. I don't recall him being > this aggressive on IRC. > > Having said that, I don't think we should ever treat anyone like this, > regardless > of distro. I have very little to say on the AUR packages that has not been > said, > but those interactions with users are something we need to also take in > consideration. > > Regards, > Giancarlo Razzolini I'll chime in to say that having known Drew for several years, I've experienced some friction in the past but I would not be sponsoring this application if I thought his attitude hadn't changed. J. Leclanche
Re: [aur-general] Trusted user application: Drew DeVault
On Wed, Feb 27, 2019 at 4:47 AM Giancarlo Razzolini via aur-general < aur-general@archlinux.org> wrote: > Em fevereiro 27, 2019 3:56 Eli Schwartz via aur-general escreveu: > > > > If the only thing we can find to complain about is his attitude towards > > Manjaro, then we obviously cannot find anything to complain about. :) > > > > I was surprised by this attitude since all my interactions with Drew in the > past were quite friendly. Most (all?) were on IRC. I don't recall him being > this aggressive on IRC. > > Having said that, I don't think we should ever treat anyone like this, > regardless > of distro. I have very little to say on the AUR packages that has not been > said, > but those interactions with users are something we need to also take in > consideration. > > Regards, > Giancarlo Razzolini I'd like to say this, be careful not to get into a "I'm perfect, I can do no wrong" attitude. Be mindful that everyone makes mistakes in their pasts and they can change, Yes, Consider the past, but also consider the present. Has the person changed for the better? If so, then base the application on that merit. No one is perfect, but don't let Drew's past sins affect his application for trusted user. Let his recent interactions speak louder than his past interactions. Very Respectfully, Taylor Lookabaugh
Re: [aur-general] Trusted user application: Drew DeVault
On 2019-02-26 11:37 PM, Brett Cornwall via aur-general wrote: > I would also chip in with the following from early 2017: > > https://github.com/swaywm/sway/issues/1227 > > (I am also not in any sort of witch hunt, just thought this would be > relevant.) It should go without saying that I regret what I said here as well. I was going some stressful financial problems when those comments were written. Doesn't excuse anything, and I'm sure we could find examples of my jerkitude that I can't say the same for. Instead I'd like to ask this: if I'm to be damned by my past behaviors, is there a path to redemption? Is there any criteria we could establish for demonstrating good behavior? Or, would I have to live with a forever vague sense of unease among the voters? Not to say that the unease isn't justified - it may in fact by the right answer to reject applications based on that unease. If any concerned can think of more tangible criteria, though, it would make it easier for me to dispell your concerns or give me some personal development goals to meet.
Re: [aur-general] Trusted user application: Drew DeVault
As a complete newbie I might not have the rights to chime in here. But isn't it never too late if Mr. DeVault may add an apologetic comment to @noobpurple under https://github.com/swaywm/sway/issues/1227 now? Sincerely yours, Darren Wu On Wed, Feb 27, 2019, 21:53 Drew DeVault via aur-general < aur-general@archlinux.org> wrote: > On 2019-02-26 11:37 PM, Brett Cornwall via aur-general wrote: > > I would also chip in with the following from early 2017: > > > > https://github.com/swaywm/sway/issues/1227 > > > > (I am also not in any sort of witch hunt, just thought this would be > > relevant.) > > It should go without saying that I regret what I said here as well. I > was going some stressful financial problems when those comments were > written. Doesn't excuse anything, and I'm sure we could find examples > of my jerkitude that I can't say the same for. > > Instead I'd like to ask this: if I'm to be damned by my past behaviors, > is there a path to redemption? Is there any criteria we could establish > for demonstrating good behavior? Or, would I have to live with a forever > vague sense of unease among the voters? Not to say that the unease isn't > justified - it may in fact by the right answer to reject applications > based on that unease. If any concerned can think of more tangible > criteria, though, it would make it easier for me to dispell your > concerns or give me some personal development goals to meet. >
Re: [aur-general] Trusted user application: Drew DeVault
On 2/27/19 3:10 PM, Darren Wu via aur-general wrote: > As a complete newbie I might not have the rights to chime in here. As a member of the community, regardless of how long you've been around, you are absolutely entitled to post to threads on aur-general :) All we ask is everyone keeps things civil in nature ;) > > But isn't it never too late if Mr. DeVault may add an apologetic comment to > @noobpurple under https://github.com/swaywm/sway/issues/1227 now? > > Sincerely yours, > Darren Wu >I honestly think Necroposting on that GitHub issue would not be a good idea. In reading this thread so far it's clear to me that Drew just lost his temper, as we all sometimes do. By observing his efforts to explain, acknowledge (the first step towards correcting something undesirable in oneself), and take actions to adjust his behavior, I'd say I'm personally okay with his current demeanor. It goes without saying that there is an expectation amongst Dev's and TU's to be professional with user requests, bug reports, etc. I am of the opinion that if Drew decides to "turn" and revert back, then we as TU's address it then. However, until then, I think the behavior in the application should represent who he is now. Regards, Andrew > On Wed, Feb 27, 2019, 21:53 Drew DeVault via aur-general < > aur-general@archlinux.org> wrote: > >> On 2019-02-26 11:37 PM, Brett Cornwall via aur-general wrote: >>> I would also chip in with the following from early 2017: >>> >>> https://github.com/swaywm/sway/issues/1227 >>> >>> (I am also not in any sort of witch hunt, just thought this would be >>> relevant.) >> >> It should go without saying that I regret what I said here as well. I >> was going some stressful financial problems when those comments were >> written. Doesn't excuse anything, and I'm sure we could find examples >> of my jerkitude that I can't say the same for. >> >> Instead I'd like to ask this: if I'm to be damned by my past behaviors, >> is there a path to redemption? Is there any criteria we could establish >> for demonstrating good behavior? Or, would I have to live with a forever >> vague sense of unease among the voters? Not to say that the unease isn't >> justified - it may in fact by the right answer to reject applications >> based on that unease. If any concerned can think of more tangible >> criteria, though, it would make it easier for me to dispell your >> concerns or give me some personal development goals to meet. >> signature.asc Description: OpenPGP digital signature
Re: [aur-general] Trusted user application: Drew DeVault
Hey, let me just quickly thank all people who have participated in this thread thus far. I'm seeing a very polite, respectful and constructive discussion from all sides, which I very much enjoyed reading. On 27.02.19 08:53, Drew DeVault via aur-general wrote: > Instead I'd like to ask this: if I'm to be damned by my past behaviors, > is there a path to redemption? Is there any criteria we could establish > for demonstrating good behavior? Or, would I have to live with a forever > vague sense of unease among the voters? Not to say that the unease isn't > justified - it may in fact by the right answer to reject applications > based on that unease. If any concerned can think of more tangible > criteria, though, it would make it easier for me to dispell your > concerns or give me some personal development goals to meet. Personally I think that you have already shown in this thread, that you are capable of handling criticism and that you are willing to improve in areas where there are concerns. When I was a fresh TU I had some minor frictions with some of the long-term devs and TUs, which affected my mood and motivation. Fortunately, after talking to the people in question and expressing my displease, this situation improved very quickly and there were no hurt feelings. Just seeing that you are actively seeking out ways to improve your attitude and social behaviour seems like a very good sign to me. We are all human individuals and certainly not perfect. Communication is both cause and solution to most issues, thus we should always just try to be open to ideas, be respectful and polite to others and be willing to make compromises. Most of the time someone is not even aware that their phrasing might offend someone and just needs to made aware of that. I'm looking forward to further replies in this thread and you possibly being voted in. :) Cheers, Thore -- Thore Bödecker GPG ID: 0xD622431AF8DB80F3 GPG FP: 0F96 559D 3556 24FC 2226 A864 D622 431A F8DB 80F3 signature.asc Description: PGP signature
Re: [aur-general] Trusted user application: Drew DeVault
Em fevereiro 27, 2019 10:53 Drew DeVault via aur-general escreveu: On 2019-02-26 11:37 PM, Brett Cornwall via aur-general wrote: I would also chip in with the following from early 2017: https://github.com/swaywm/sway/issues/1227 (I am also not in any sort of witch hunt, just thought this would be relevant.) It should go without saying that I regret what I said here as well. I was going some stressful financial problems when those comments were written. Doesn't excuse anything, and I'm sure we could find examples of my jerkitude that I can't say the same for. Instead I'd like to ask this: if I'm to be damned by my past behaviors, is there a path to redemption? Is there any criteria we could establish for demonstrating good behavior? Or, would I have to live with a forever vague sense of unease among the voters? Not to say that the unease isn't justified - it may in fact by the right answer to reject applications based on that unease. If any concerned can think of more tangible criteria, though, it would make it easier for me to dispell your concerns or give me some personal development goals to meet. I don't think that's needed, you have proven so far that you can handle criticism, which is a good indicative. As I said, I was just surprised. You never know, sometime you might get someone on a bad mood or something like that. I stand by what I said though, that everything should be taken into consideration. Including past behavior and present, which doesn't mean to focus on the bad stuff, or just wash it away with good stuff. After all, we're all a sum of all that, good or bad. I appreciate that your sponsors are also backing you up in this, not just technically. Thanks and I wish you luck. Regards, Giancarlo Razzolini pgp8FCZAVasBq.pgp Description: PGP signature
Re: [aur-general] Trusted user application: Drew DeVault
On 2/25/19 5:55 PM, Drew DeVault wrote: > Thanks for all the feedback! I went through and cleaned up all of my AUR > packages - something a wiser man would have done before submitting the > TU application. > You're welcome, but from me this was just the travel version... here comes the full unleashed feature set of xxarhtna For now reduced to python only and some random picks, If i find time I will take a look at the other packages as well. > >> Out of curiosity, what kind of upstream watch are you using to be made >> aware of new releases? > > For the AUR I don't keep up with upstream releases, I just wait for > someone to mark the package as outdated. For Alpine Linux I use a > combination of subscribing to the upstream -announce mailing list and > subscribing to GitHub releases as appropriate; would do something > similar for Arch Linux community. > Well, to be honest its the maintainers responsibility to keep track of upstream and not outsource out of date flagging to someone else. There is no difference between [community] and AUR for something that is a maintainer responsibility. Back to packages: Really no offense, but I really had high expectations and got very surprised: At some point I started wondering if you read error and log output while trying to package or run tests? Some of this findings indicates you don't (when you change some stuff) or at least stop any investigation if f.e. a test suite doesn't run straight. I would like to see more investigative behavior of a maintainer in getting things sorted out the correct way instead of just abandon if it requires a bit of patience and thinking plus time. Also i encountered some examples of non working pkg build of very recent changes that make me think changes are pushed straight to the AUR before any build/test ever happened. If there is stuff to rule out and you need ideas and another pair of eyes, just ask for it... that's what a team and a community should be for, nobody knows everything. Also some of the packages don't work as they are not python 3.7 compatible at all so i wonder if anyone uses them a all? Also i noticed you may maybe not know 'namcap' because of so many missing licenses plus stuff like Non-FHS man page violations. patchrom: - Non-FHS man page in /usr/man/man1 mktiupgrade: - Non-FHS man page in /usr/man/man1 mkrom: - Non-FHS man page in /usr/man/man1 kpack: - Non-FHS man page in /usr/man/man1 genkfs: - Non-FHS man page in /usr/man/man1 sass: - did you test building this package before pushing an added LICENSE dist line 2 days ago? Because this indicates something went wrong: install: cannot stat 'LICENSE': No such file or directory ==> ERROR: A failure occurred in package(). python-sshpubkeys: - what does the 1.0.5 do in the URL? :P - do you use proper clean environments for building? asking because: ==> ERROR: A failure occurred in build(). ModuleNotFoundError: No module named 'setuptools'et This packages requires setuptools makedepends doesn't your CI or AUR testing use clean/isolated and non polluted environments for building? - what does check() do, build the package? that should be 'test' instead of 'build' Btw: please use github sources, the pypi re-distribution doesn't contain any tests in the first place PS: to avoid setuptools download checkdepends it needs: cffi, asn1crypto, pycparser (take a look on log output) - this package doesn't provide LICENSE.txt as github contains, please use github sources and include it PS: do you use namcap on your packages to find some frequent mistakes? python-spam-blocklists: - what does the 0.9.3 do in the URL? - what does the comment mean about "only py2"? if you run the tests reality shows it just doesn't work at all: ModuleNotFoundError: No module named 'urlparse' sources show from urlparse import urlparse which can't be fulfilled anywhere nice indicator: Latest commit on Jun 15, 2012, this stuff is just dead, nuke python-pystache: - doesnt distribute the MIT license which exists in the sources - there is a test runner using python ./test_pystache.py which pretty much shows this is dead non working stuff as well: File "/build/python-pystache/src/pystache-0.5.4/pystache/parser.py", line 15 NON_BLANK_RE = re.compile(ur'^(.)', re.M) SyntaxError: invalid syntax Latest commit 17a5dfd on Sep 30, 2014 python-patreon: - license is wrong, if you look at upstream its apache2 - this projects depends on python-six to run - must depend on setuptools as makedepends instead of distribute as thats the correct module it requires - no tests run, by adding checkdepends for python-mock python-pytest python-pytest-cov you can easily run a check() via python setup.py test which successfully runs 52 passed in 0.82 seconds python-lark: - misses python-js2py depends - "# upstream tests fail due to path resolution errors" what exactly do you mean by that? If you investiate the files
Re: [aur-general] Trusted user application: Drew DeVault
On 2019-02-28 2:22 AM, Levente Polyak via aur-general wrote: > > For the AUR I don't keep up with upstream releases, I just wait for > > someone to mark the package as outdated. For Alpine Linux I use a > > combination of subscribing to the upstream -announce mailing list and > > subscribing to GitHub releases as appropriate; would do something > > similar for Arch Linux community. > > Well, to be honest its the maintainers responsibility to keep track of > upstream and not outsource out of date flagging to someone else. There > is no difference between [community] and AUR for something that is a > maintainer responsibility. 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. 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. > Really no offense, but I really had high expectations and got very > surprised: At some point I started wondering if you read error and log > output while trying to package or run tests? > Some of this findings indicates you don't (when you change some stuff) > or at least stop any investigation if f.e. a test suite doesn't run > straight. I would like to see more investigative behavior of a > maintainer in getting things sorted out the correct way instead of just > abandon if it requires a bit of patience and thinking plus time. > > Also i encountered some examples of non working pkg build of very recent > changes that make me think changes are pushed straight to the AUR before > any build/test ever happened. > > If there is stuff to rule out and you need ideas and another pair of > eyes, just ask for it... that's what a team and a community should be > for, nobody knows everything. > Also some of the packages don't work as they are not python 3.7 > compatible at all so i wonder if anyone uses them a all? Hmm, sorry to disappoint. I definitely built and did at least a basic sanity test on every package. I did update a whole bunch of packages at once, so it's possible I missed a few things... many of which I presume are the problems you pointed out. Also, note that I haven't yet taken the time to clean up my sr.ht-pkgbuilds packages, if you were reviewing those. Many of those are also adoptions from the AUR where I imported someone else's package so I could build a binary package - and left their PKGBUILD intact to make pulling down updates easier. Might rethink that policy. > Also i noticed you may maybe not know 'namcap' because of so many > missing licenses plus stuff like Non-FHS man page violations. Aye, this is first I've heard of namcap. Is there a reason that this isn't included with makepkg by default? I updated several of the packages you mentioned to address your feedback, and ran namcap on them. Can you take another look when you have time? Regarding your Python feedback in particular, I appreciate the tips - I have a lot of Python packages I need to make but have found resources for making Arch Linux packages for Python software to be somewhat lacking. I put a note on my todo list to take the feedback on these AUR packages and summarize them for the Arch Wiki. https://wiki.archlinux.org/index.php/Python_package_guidelines > patchrom mktiupgrade mkrom kpack genkfs > - Non-FHS man page in /usr/man/man1 I could fix this in the package, but this is an upstream bug, so I filed a ticket... on my own project. https://github.com/KnightOS/KnightOS/issues/381 > sass: > > - did you test building this package before pushing > an added LICENSE dist line 2 days ago? Because this > indicates something went wrong: > install: cannot stat 'LICENSE': No such file or directory > ==> ERROR: A failure occurred in package(). Ah, I had thought I did, but it seems I only tested scas. sass is legacy software, and scas is its replacement. I think I just got mixed up. > - do you use proper clean environments for building? asking because: > ==> ERROR: A failure occurred in build(). > ModuleNotFoundError: No module named 'setuptools'et > This packages requires setuptools makedepends > doesn't your CI or AUR testing use clean/isolated and non polluted > environments for building? My CI uses fresh build environments, but my AUR packages aren't built with it. Just finished setting up makechrootpkg so I can do this locally. > Btw: please use github sources, the pypi re-distribution doesn't > contain any tests in the first place Damn, I was really happy to have a consistent sources URL I could reuse for Python packages. > python-spam-blocklists: > nice indicator: Latest commit on Jun 15, 2012, this stuff is just > dead, nuke Agreed, and I don't even remember what I needed this for. Filed a deletion request. > python-pystache: > - there is a test runner using python ./te
Re: [aur-general] Trusted user application: Drew DeVault
On 2/27/19 10:25 PM, Drew DeVault via aur-general wrote: > Aye, this is first I've heard of namcap. Is there a reason that this > isn't included with makepkg by default? It brings a hard dependency on python, and its output is often useful but also often not -- for example when it tries to calculate "needed dependencies", it will more or less accurately tell you what you need for shared library linkage, then tell you that all other dependencies are "unnecessary" (this does not work out remotely well for any python software). However, devtools does utilize namcap as an optional post-build step in makechrootpkg, and enforces it when using the extra-x86_64 build wrapper (so you will always see namcap warnings when building official repository packages). There are also thoughts about reimplementing it as libmakepkg extensions. > I updated several of the packages you mentioned to address your > feedback, and ran namcap on them. Can you take another look when you > have time? > > Regarding your Python feedback in particular, I appreciate the tips - I > have a lot of Python packages I need to make but have found resources > for making Arch Linux packages for Python software to be somewhat > lacking. I put a note on my todo list to take the feedback on these AUR > packages and summarize them for the Arch Wiki. > > https://wiki.archlinux.org/index.php/Python_package_guidelines It can often be difficult to know from an inside perspective, what needs to be documented -- I thought that that Python page was pretty decent though. It definitely mentions the setuptools bit. I guess the difference between PyPI and Github sources could be clarified, but really I'd much rather upstreams would get in the habit of using a MANIFEST.in which ensured the license and testsuite was correctly included in the source dist. Maybe it would help to add a section on how to parse dependencies from a setup.py or requirements.txt? > It may be abandoned but I actually do remember why I need this package - > and I still do. The test suite runs on Python 3 but you have to jump > through some hoops - setup.py runs the whole codebase through 2to3 > before installing. Jumped through said hoops and updated the package. Ancient software written back when people thought 2to3 was a good idea is the bane of us all. :D -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] Trusted user application: Drew DeVault
On 2019-02-27 10:42 PM, Eli Schwartz via aur-general wrote: > I guess the difference between PyPI and Github sources could be > clarified, but really I'd much rather upstreams would get in the habit > of using a MANIFEST.in which ensured the license and testsuite was > correctly included in the source dist. This is the main bit that I feel can be clarified. The wiki page today is written like there's One True Way to specify sources=() for a Python package, and that way has some serious defects (lack of tests, license file, etc) - to the point where if you can get the package another way, you probably should.
Re: [aur-general] Trusted user application: Drew DeVault
On February 27, 2019 10:47:59 PM EST, Drew DeVault via aur-general wrote: >On 2019-02-27 10:42 PM, Eli Schwartz via aur-general wrote: >> I guess the difference between PyPI and Github sources could be >> clarified, but really I'd much rather upstreams would get in the >habit >> of using a MANIFEST.in which ensured the license and testsuite was >> correctly included in the source dist. > >This is the main bit that I feel can be clarified. The wiki page today >is written like there's One True Way to specify sources=() for a Python >package, and that way has some serious defects (lack of tests, license >file, etc) - to the point where if you can get the package another way, >you probably should. All the upstreams for my Python packages have agreed to merge these additions, though there were those that took a bit of convincing. I still have to use non-PyPI sources for some as they haven't yet made new releases, don't manage their own PyPI pages (and one could wait indefinitely for the release), or use PGP signing. Apparently there's a way to sign PyPI packages, but I haven't really looked into that yet. -- Best, polyzen
