[aur-general] TU Application - Konstantin Gizdov

[Eli Schwartz]

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?

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.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

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