[aur-general] TU Application - Konstantin Gizdov

Sun Oct 28 11:33:13 UTC 2018

Hi Eli,

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?
>
> 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".

The `python-uproot` package required `python-uproot-methods` in a new
upstream release. This in turn required `python-awkward-array`. Then,
`python-awkward-array` listed as requirements (on their page, discussed
at length and addressed later in the bug tracker as you pointed out) at
the time `numba`, `dask`, `bcolz`, `arrow`. I wanted to provide the
update so I had to push/find all these. The problem appeared when I
tried to create the python2 version of the relevant ones (as I provide
the uproot variant of this). `bcolz` does not have a python2 variant
still and at the time neither did `dask`. I asked on the relevant pages
for the maintainers to add them. In the meantime, I wanted to still
update `python-uproot`. Considering all these were optional, I was able
to push a new release. This is why it was rushed and this is why it
needs a rewrite - it could not, at the time, be complete because of the
constraints. Yes, in principle I could have also tried to provide
`python2-bcolz` and `python2-dask`, but I thought the current
maintainers will do a better job at this.

As it was picked up in [community], I have not tried to keep it up to
date. I think it was mentioned by you on the bug tracker that
`python-awkward` in [community] derives its name from the pypi.org page,
rather than the project page (`awkward-array`). Thus, I discovered a few
weeks back, that the AUR blacklisting was not taking care of it, at
least for me. So pushed a small temporary update, thinking since it was
mentioned, it was being taken care of and in due time a
`provides=('python-awkward-array')` is going to appear in the official
binary. I do not presume to know if that's how these things are
addressed, but this is why `python-awkward-array` is in this (meta-)state.

I am guessing at this stage the correct action from my side is to
request deletion of my AUR variant and change `python-uproot-methods` to
point to `python-awkward`, but I did want to give it time to see where
things are going. Now I see where they are going and will correct it, if
you agree with this resolution.

I think that should give responses to all your concerns (including
below), since I couldn't find a nice way to structure it under each of
your paragraphs.

>
> 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.

I did respond to question:

https://lists.archlinux.org/pipermail/aur-general/2018-September/034290.html

>
> ...
>
> 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.

I'm sorry to hear that. I think I have good reasons (listed above) for
the current state of this specific package. My other ones should be
better I hope. In any case, I would appreciate the feedback whatever it is.

Regards,

Konstantin

-------------- 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/48d0567e/attachment-0001.asc>