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