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