[aur-general] TU Application - Konstantin Gizdov

Sun Oct 28 11:36:35 UTC 2018

On 28/10/2018 01:40, Eli Schwartz via aur-general wrote:
> On 10/14/18 4:34 PM, Konstantin Gizdov wrote:
>> Thus, a couple of years ago, I decide to get more involved and
>> contribute. I took on the task to maintain CERN's ROOT package [7] and
>> since then I've involved myself heavily into that, I'm a contributor to
>> the project and I use it daily in my work. I have been providing this
>> package for many colleagues in the field, including all of its stack &
>> complementary tools (Pythia, XRootD & other Python tools). I have
>> enabled a lot of new features and worked with upstream towards new
>> functionality, bug fixes, etc. On top of that I have shipped several
>> other related projects - machine learning packages, SciKit-HEP packages
>> like uproot, Docker images, GitLab CIs and so on.
>>
>> I have also been able to develop and publish a machine learning project
>> me and colleague came up with [4]. This is soon going to be a package in
>> SciKit-HEP and I will aim to make it package here too. Arch Linux was a
>> great platform for all of this. I was able to install & configure
>> up-to-date software easily and what I did not find, I provided for me &
>> others on the AUR without too much hassle.
>>
>> Overall, I have to say Arch Linux (and its community) have played a key
>> role in me being able to do all of these things. I have found the OS
>> itself to be stable and flexible and the users & maintainers
>> approachable and direct, which I appreciate a lot. I have met a lot of
>> people through the Arch Linux community - forums, AUR and just saying 'I
>> use Arch, too!', haha.
>>
>> The reason for applying to become a TU is to get even more involved and
>> give back to the community. If you accept me, I would like to continue
>> maintaining and improving my current packages as well as bring new
>> packages. As an AUR maintainer I basically consider it an on-going duty
>> already.
>>
>> I would like to maintain/contribute/adopt the following:
>>
>>   * Packages I would like to co-maintain:
>>       o python-awkward
>>       o libafterimage
>>       o xxhash
>>       o unuran
>>   * Packages I already maintain and intend to move from AUR:
>>       o root & root-extra
>>       o xrootd
>>       o simpletools
>>       o root5
>>       o python-root_numpy
>>       o python-uproot
>>       o python-uproot-methods
>>       o python-hep_ml
>>       o pythia
>>       o llvm50
>>       o llvm50-libs
>>       o clang50
>>   * New packages I would like to add/move from AUR:
>>       o cern-vdt
>>       o cvmfs
>>       o HepDrone [4]
>>       o python-keras
>>       o root_pandas (new)
>>       o histbook (new)
>>       o decaylanguage (new)
>>       o pyjet (new)
>>       o vegascope (new)
>>       o root_ufunc (new)
>>       o formulate (new)
> Hi Konstantin,
>
> As is customary when someone applies as a TU, I try to review their
> PKGBUILDs.
>
> $ ./ztrawhcse -Wall -Werror -Wpedantic
> Segmentation fault (core dumped)
>
> Uh-oh -- I'm not sure what to do with this?
> https://aur.archlinux.org/cgit/aur.git/commit/PKGBUILD?h=python-awkward-array&id=59bfa242560e113a39bd630d20d21eee45954dd7
>
> This actually came up on [aur-general] before:
> https://lists.archlinux.org/pipermail/aur-general/2018-September/034286.html
>
> In summary, this is invalid PKGBUILD syntax for two reasons
> - makedepends cannot be specified in build() functions
> - there is no such thing as split build_*() functions
>
> When I asked you about why you uploaded invalid PKGBUILDs, you responded
> that "it was added 2 weeks ago in a rush to push a new version upstream,
> because I maintain my packages well".
>
> I'm afraid I completely disagree. It's not maintaining packages well to
> upload things without checking that they work, and a good packager
> focuses on getting something to work properly, rather than slipping on
> quality in the rush to update other packages as soon as possible --
> maybe in order to claim that Arch is always up to date? I don't know,
> but if that's the reason, then I for one would much prefer less
> bleeding-edge packages as long as they at least work.
>
> i.e. "bleeding edge", not "hemorrhaging edge".
>
> You also said the package needs a complete rewrite "which I'm well aware
> of". Does this mean you knew it didn't work when you uploaded it, but
> you uploaded it anyway?
Forgot to mention in my previous email - the [community]
`python-awkward` does not provide python2 variant, so I can't actually
delete my AUR package. (This was one of my original bug reports.) I
would have to keep that up to date, I guess.
>
> You also said that "this particular style of package was copied from
> another [community] package a long time ago, things have changed as it
> was pointed out to me here in the AUR".
>
> Can you please refer me to which community package you refer to? I can
> state with some authority that nothing has ever changed, and this was
> never correct. I asked you about this a month ago, but you never
> responded to me.
>
> ...
>
> On the topic of this package, you never fixed it until the 14th of this
> month, two weeks later, right around the time you submitted your TU
> application. I'm hoping that this isn't because you don't have time to
> fix things unless you're actively trying to apply for a TU position, but
> this *was* a very easy thing to fix...
>
> That being said, I'm not sure why you tried to fix it at all, since the
> package is a duplicate of python-awkward in [community], as you very
> well know since you submitted a pretty rapid bug report asking why the
> package in [community] does not include some optdepends of the package.
>
> You've meanwhile updated it to a version that currently out of date and
> lagging behind the version in [community], something that is only
> possible because the AUR blacklist bans packages already in the official
> repos, but not packages that provide the exact same software under a
> different name. You apparently had enough time to do so, but not enough
> time to update the two packages in the AUR which depend on
> python-awkward-array to depend on python-awkward instead -- nor to even
> add provides/conflicts on your AUR duplicate since they install the same
> files.
>
> (The optdepends are still there, even though the bug tracker resolution
> was that they shouldn't be, and aren't in the official community
> repository.)
>
> ...
>
> I'm afraid I got too discouraged by this immediate result, and did not
> end up looking at any of your other packages.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20181028/d841aafe/attachment.asc>