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
signature.asc
Description: OpenPGP digital signature
