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.