Hi ArchLinux community, I like to apply as TU, sponsored by Lukas Fleischer (aka CryptoCrack), since my passion and work for ArchLinux continues since half a decade and I really would like to get more involved into development and package maintaining. My name is Jonas (my public key [1]), I'm 23 years old, computer science student in Karlsruhe, Germany. I switched to Linux in school while working voluntarily on a school server [2] and school internet cafe together with a class mate in our free time. Hacking on fun projects became on of my big hobbies and some of them are documented in my blog [3]. I get a lot of inspiration and exchange in my local hacker space, the Entropia e.V. [4] which is part of the CCC (Chaos Computer Club) [5] but also at work as a network administrator at the architecture faculty of my university. I love ArchLinux, using it on my servers (with several ArchLinux vms) and on my laptop, because it's simple, basic and fast. The wiki is also one of my favorite places in the community, because all the documentation is pragmatic and to the point. I constantly write new how-to's or improve instructions on other pages [6]. In my opinion, a well written Wiki/Doku, also for all the third-party software, is very important and one reason why I don't want to use Debian anymore for my projects. I learned how to write clean and sometimes complex PKGBUILDs over time and now maintaining up to 150 AUR packages [7]. Some of them are really important to me (using them on my server or integrated them to my projects) and I think also important to the community, so I would like to put them into the community repository. For example: archivemount, btar, dmtcp, etherpad-lite, freecad, gallery, gitlab, hlds, joomla, opentracker, pyload, python-libtorrent-rasterbar, sslstrip, etc. For other packages, I adopted them just to fix broken PKGBUILDs or I tried to port non-supported software to ArchLinux like Zenoss, oVirt or Kolab while working with their developers to improve ArchLinux support. At least, here are some of my experimental projects you can look at: p2pacman [8], pkgcheck [9], wikidict [10], carpc based on ArchLinux [11]. For further questions, you can find me on #archlinux at freenode or just ask them here on the mailinglist. Best regards, Jonas
[1] http://onny.project-insanity.org/files/gpg.asc [2] http://www.project-insanity.org/blog/2010/06/03/dokumentation-zur-einrichtun... (text unfortunately in German) [3] http://project-insanity.org [4] https://entropia.de [5] https://en.wikipedia.org/wiki/Chaos_Computer_Club [6] https://wiki.archlinux.org/index.php/Special:Contributions/Onny [7] https://aur.archlinux.org/packages/?K=onny&SeB=m [8] https://bbs.archlinux.org/viewtopic.php?id=163362 [9] https://bbs.archlinux.org/viewtopic.php?id=162816 [10] https://git.morbi-happens.de/onny/wikidict [11] http://www.project-insanity.org/blog/2012/10/10/archlinux-touchscreen-carpc-...
----------------------------------------
Date: Mon, 20 Jan 2014 23:32:08 +0000 From: onny@project-insanity.org To: aur-general@archlinux.org Subject: [aur-general] TU application, sponsored by Lukas Fleischer
Hi ArchLinux community, I like to apply as TU, sponsored by Lukas Fleischer (aka CryptoCrack), since my passion and work for ArchLinux continues since half a decade and I really would like to get more involved into development and package maintaining. My name is Jonas (my public key [1]), I'm 23 years old, computer science student in Karlsruhe, Germany. I switched to Linux in school while working voluntarily on a school server [2] and school internet cafe together with a class mate in our free time. Hacking on fun projects became on of my big hobbies and some of them are documented in my blog [3]. I get a lot of inspiration and exchange in my local hacker space, the Entropia e.V. [4] which is part of the CCC (Chaos Computer Club) [5] but also at work as a network administrator at the architecture faculty of my university. I love ArchLinux, using it on my servers (with several ArchLinux vms) and on my laptop, because it's simple, basic and fast. The wiki is also one of my favorite places in the community, because all the documentation is pragmatic and to the point. I constantly write new how-to's or improve instructions on other pages [6]. In my opinion, a well written Wiki/Doku, also for all the third-party software, is very important and one reason why I don't want to use Debian anymore for my projects. I learned how to write clean and sometimes complex PKGBUILDs over time and now maintaining up to 150 AUR packages [7]. Some of them are really important to me (using them on my server or integrated them to my projects) and I think also important to the community, so I would like to put them into the community repository. For example: archivemount, btar, dmtcp, etherpad-lite, freecad, gallery, gitlab, hlds, joomla, opentracker, pyload, python-libtorrent-rasterbar, sslstrip, etc. For other packages, I adopted them just to fix broken PKGBUILDs or I tried to port non-supported software to ArchLinux like Zenoss, oVirt or Kolab while working with their developers to improve ArchLinux support. At least, here are some of my experimental projects you can look at: p2pacman [8], pkgcheck [9], wikidict [10], carpc based on ArchLinux [11]. For further questions, you can find me on #archlinux at freenode or just ask them here on the mailinglist. Best regards, Jonas
[1] http://onny.project-insanity.org/files/gpg.asc [2] http://www.project-insanity.org/blog/2010/06/03/dokumentation-zur-einrichtun... (text unfortunately in German) [3] http://project-insanity.org [4] https://entropia.de [5] https://en.wikipedia.org/wiki/Chaos_Computer_Club [6] https://wiki.archlinux.org/index.php/Special:Contributions/Onny [7] https://aur.archlinux.org/packages/?K=onny&SeB=m [8] https://bbs.archlinux.org/viewtopic.php?id=163362 [9] https://bbs.archlinux.org/viewtopic.php?id=162816 [10] https://git.morbi-happens.de/onny/wikidict [11] http://www.project-insanity.org/blog/2012/10/10/archlinux-touchscreen-carpc-...
I'm a nobody, so my opinion probably doesn't count, but if you can't properly maintain the package you already have the AUR, why do you want to take on more responsibility? A quick look shows packages marked out of date, one for nearly 10 months (flamerobin), packages with fixes posted in the comments months ago that you haven't implemented (libappindicator), VCS packages with useless pkgver() functions (most of your -git packages), and packages with no package() function (vim-paster and others). So help me out here, what would make you a good TU?
On 01-20 17:55, Doug Newgard wrote:
Date: Mon, 20 Jan 2014 23:32:08 +0000 From: onny@project-insanity.org To: aur-general@archlinux.org Subject: [aur-general] TU application, sponsored by Lukas Fleischer
Hi ArchLinux community, I like to apply as TU, sponsored by Lukas Fleischer (aka CryptoCrack), since my passion and work for ArchLinux continues since half a decade and I really would like to get more involved into development and package maintaining. My name is Jonas (my public key [1]), I'm 23 years old, computer science student in Karlsruhe, Germany. I switched to Linux in school while working voluntarily on a school server [2] and school internet cafe together with a class mate in our free time. Hacking on fun projects became on of my big hobbies and some of them are documented in my blog [3]. I get a lot of inspiration and exchange in my local hacker space, the Entropia e.V. [4] which is part of the CCC (Chaos Computer Club) [5] but also at work as a network administrator at the architecture faculty of my university. I love ArchLinux, using it on my servers (with several ArchLinux vms) and on my laptop, because it's simple, basic and fast. The wiki is also one of my favorite places in the community, because all the documentation is pragmatic and to the point. I constantly write new how-to's or improve instructions on other pages [6]. In my opinion, a well written Wiki/Doku, also for all the third-party software, is very important and one reason why I don't want to use Debian anymore for my projects. I learned how to write clean and sometimes complex PKGBUILDs over time and now maintaining up to 150 AUR packages [7]. Some of them are really important to me (using them on my server or integrated them to my projects) and I think also important to the community, so I would like to put them into the community repository. For example: archivemount, btar, dmtcp, etherpad-lite, freecad, gallery, gitlab, hlds, joomla, opentracker, pyload, python-libtorrent-rasterbar, sslstrip, etc. For other packages, I adopted them just to fix broken PKGBUILDs or I tried to port non-supported software to ArchLinux like Zenoss, oVirt or Kolab while working with their developers to improve ArchLinux support. At least, here are some of my experimental projects you can look at: p2pacman [8], pkgcheck [9], wikidict [10], carpc based on ArchLinux [11]. For further questions, you can find me on #archlinux at freenode or just ask them here on the mailinglist. Best regards, Jonas
[1] http://onny.project-insanity.org/files/gpg.asc [2] http://www.project-insanity.org/blog/2010/06/03/dokumentation-zur-einrichtun... (text unfortunately in German) [3] http://project-insanity.org [4] https://entropia.de [5] https://en.wikipedia.org/wiki/Chaos_Computer_Club [6] https://wiki.archlinux.org/index.php/Special:Contributions/Onny [7] https://aur.archlinux.org/packages/?K=onny&SeB=m [8] https://bbs.archlinux.org/viewtopic.php?id=163362 [9] https://bbs.archlinux.org/viewtopic.php?id=162816 [10] https://git.morbi-happens.de/onny/wikidict [11] http://www.project-insanity.org/blog/2012/10/10/archlinux-touchscreen-carpc-...
I'm a nobody, so my opinion probably doesn't count, but if you can't properly maintain the package you already have the AUR, why do you want to take on more responsibility? A quick look shows packages marked out of date, one for nearly 10 months (flamerobin), packages with fixes posted in the comments months ago that you haven't implemented (libappindicator), VCS packages with useless pkgver() functions (most of your -git packages), and packages with no package() function (vim-paster and others). So help me out here, what would make you a good TU?
Most of the packages get better over time and in my case, it's not possible to have 140 packages in perfect state at once. So I can perfectly update or fix 4 packages/day (sometimes more if I automatically scan for new releases with pkgcheck :)), but some require community feedback/discussion, some need upstream fixes or further time for debugging. For the most part, the packages were in a much worse state than today. In my opinion the AUR is something like a incubator for new, experimental or less popular packages. If I havent put an early unfinished version of Gitlab [1] into the AUR, I wouldn't have been able to get that many constructive feedback and at the same time write an instruction at the wiki [2]. I guess the diversity is the reason, why the AUR is such a popular feature of ArchLinux. Of course there are more stable, less experimental packages which I want to see in the community repository.
[1] https://aur.archlinux.org/packages/gitlab/ [2] https://wiki.archlinux.org/index.php/Gitlab
----------------------------------------
Date: Tue, 21 Jan 2014 07:38:25 +0000 From: onny@project-insanity.org To: aur-general@archlinux.org Subject: Re: [aur-general] TU application, sponsored by Lukas Fleischer
On 01-20 17:55, Doug Newgard wrote:
Date: Mon, 20 Jan 2014 23:32:08 +0000 From: onny@project-insanity.org To: aur-general@archlinux.org Subject: [aur-general] TU application, sponsored by Lukas Fleischer
Hi ArchLinux community, I like to apply as TU, sponsored by Lukas Fleischer (aka CryptoCrack), since my passion and work for ArchLinux continues since half a decade and I really would like to get more involved into development and package maintaining. My name is Jonas (my public key [1]), I'm 23 years old, computer science student in Karlsruhe, Germany. I switched to Linux in school while working voluntarily on a school server [2] and school internet cafe together with a class mate in our free time. Hacking on fun projects became on of my big hobbies and some of them are documented in my blog [3]. I get a lot of inspiration and exchange in my local hacker space, the Entropia e.V. [4] which is part of the CCC (Chaos Computer Club) [5] but also at work as a network administrator at the architecture faculty of my university. I love ArchLinux, using it on my servers (with several ArchLinux vms) and on my laptop, because it's simple, basic and fast. The wiki is also one of my favorite places in the community, because all the documentation is pragmatic and to the point. I constantly write new how-to's or improve instructions on other pages [6]. In my opinion, a well written Wiki/Doku, also for all the third-party software, is very important and one reason why I don't want to use Debian anymore for my projects. I learned how to write clean and sometimes complex PKGBUILDs over time and now maintaining up to 150 AUR packages [7]. Some of them are really important to me (using them on my server or integrated them to my projects) and I think also important to the community, so I would like to put them into the community repository. For example: archivemount, btar, dmtcp, etherpad-lite, freecad, gallery, gitlab, hlds, joomla, opentracker, pyload, python-libtorrent-rasterbar, sslstrip, etc. For other packages, I adopted them just to fix broken PKGBUILDs or I tried to port non-supported software to ArchLinux like Zenoss, oVirt or Kolab while working with their developers to improve ArchLinux support. At least, here are some of my experimental projects you can look at: p2pacman [8], pkgcheck [9], wikidict [10], carpc based on ArchLinux [11]. For further questions, you can find me on #archlinux at freenode or just ask them here on the mailinglist. Best regards, Jonas
[1] http://onny.project-insanity.org/files/gpg.asc [2] http://www.project-insanity.org/blog/2010/06/03/dokumentation-zur-einrichtun... (text unfortunately in German) [3] http://project-insanity.org [4] https://entropia.de [5] https://en.wikipedia.org/wiki/Chaos_Computer_Club [6] https://wiki.archlinux.org/index.php/Special:Contributions/Onny [7] https://aur.archlinux.org/packages/?K=onny&SeB=m [8] https://bbs.archlinux.org/viewtopic.php?id=163362 [9] https://bbs.archlinux.org/viewtopic.php?id=162816 [10] https://git.morbi-happens.de/onny/wikidict [11] http://www.project-insanity.org/blog/2012/10/10/archlinux-touchscreen-carpc-...
I'm a nobody, so my opinion probably doesn't count, but if you can't properly maintain the package you already have the AUR, why do you want to take on more responsibility? A quick look shows packages marked out of date, one for nearly 10 months (flamerobin), packages with fixes posted in the comments months ago that you haven't implemented (libappindicator), VCS packages with useless pkgver() functions (most of your -git packages), and packages with no package() function (vim-paster and others). So help me out here, what would make you a good TU?
Most of the packages get better over time and in my case, it's not possible to have 140 packages in perfect state at once. So I can perfectly update or fix 4 packages/day (sometimes more if I automatically scan for new releases with pkgcheck :)), but some require community feedback/discussion, some need upstream fixes or further time for debugging. For the most part, the packages were in a much worse state than today. In my opinion the AUR is something like a incubator for new, experimental or less popular packages. If I havent put an early unfinished version of Gitlab [1] into the AUR, I wouldn't have been able to get that many constructive feedback and at the same time write an instruction at the wiki [2]. I guess the diversity is the reason, why the AUR is such a popular feature of ArchLinux. Of course there are more stable, less experimental packages which I want to see in the community repository.
[1] https://aur.archlinux.org/packages/gitlab/ [2] https://wiki.archlinux.org/index.php/Gitlab
Ok, so let's look at just that one.
What are "Unconfirmed makedeps"? Are they makedeps or aren't they?
You set the backup array based on what is installed at build time, which has little to do with what is installed at install/run time. This works (somewhat) in the AUR but not at all in binary repos. Not only that, but you then set a new backup array right after it making the whole thing moot.
You pull a bunch of files directly from master of a git repo. Very fragile.
Your quoting of paths containing variables is very inconsistent, some are quoted then not quoted in the next line.
Your use of curly braces is inconsistent.
Sometimes you use mv, sometimes cp, and sometimes install. Why?
Again, you're installing things based on what is installed at build time.
That's from a cursory reading of your given example, without looking into it in detail or looking at the install file at all. You see what I mean? Many TUs have as many or more packages than you're talking about, and they're all expected to be in good shape.
On Tue, 21 Jan 2014 at 09:31:41, Doug Newgard wrote:
[...] Ok, so let's look at just that one.
I must admit that I only had a look at very few packages before agreeing to the sponsorship. However I did advice Jonas to have a look at his packages and update the one's that are flagged out-of-date before submitting his application which he obviously did not do for some reason... :/
I won't comment on any of the following questions and give Jonas a chance to reply.
What are "Unconfirmed makedeps"? Are they makedeps or aren't they?
You set the backup array based on what is installed at build time, which has little to do with what is installed at install/run time. This works (somewhat) in the AUR but not at all in binary repos. Not only that, but you then set a new backup array right after it making the whole thing moot.
You pull a bunch of files directly from master of a git repo. Very fragile.
Your quoting of paths containing variables is very inconsistent, some are quoted then not quoted in the next line.
Your use of curly braces is inconsistent.
Sometimes you use mv, sometimes cp, and sometimes install. Why?
Again, you're installing things based on what is installed at build time.
That's from a cursory reading of your given example, without looking into it in detail or looking at the install file at all. You see what I mean? Many TUs have as many or more packages than you're talking about, and they're all expected to be in good shape.
Looking at more packages, I also noticed that some even still use "$startdir" and some seem to have the "return" hack in build() that the AUR required ages ago. It would be nice if you could clean those up soon.
On 2014-01-21 02:31 -0600 Doug Newgard wrote:
Most of the packages get better over time and in my case, it's not possible to have 140 packages in perfect state at once. So I can perfectly update or fix 4 packages/day (sometimes more if I automatically scan for new releases with pkgcheck :)), but some require community feedback/discussion, some need upstream fixes or further time for debugging. For the most part, the packages were in a much worse state than today. In my opinion the AUR is something like a incubator for new, experimental or less popular packages. If I havent put an early unfinished version of Gitlab [1] into the AUR, I wouldn't have been able to get that many constructive feedback and at the same time write an instruction at the wiki [2]. I guess the diversity is the reason, why the AUR is such a popular feature of ArchLinux. Of course there are more stable, less experimental packages which I want to see in the community repository.
[1] https://aur.archlinux.org/packages/gitlab/ [2] https://wiki.archlinux.org/index.php/Gitlab
Ok, so let's look at just that one.
What are "Unconfirmed makedeps"? Are they makedeps or aren't they?
You set the backup array based on what is installed at build time, which has little to do with what is installed at install/run time. This works (somewhat) in the AUR but not at all in binary repos. Not only that, but you then set a new backup array right after it making the whole thing moot.
You pull a bunch of files directly from master of a git repo. Very fragile.
Your quoting of paths containing variables is very inconsistent, some are quoted then not quoted in the next line.
Your use of curly braces is inconsistent.
Sometimes you use mv, sometimes cp, and sometimes install. Why?
Again, you're installing things based on what is installed at build time.
That's from a cursory reading of your given example, without looking into it in detail or looking at the install file at all. You see what I mean? Many TUs have as many or more packages than you're talking about, and they're all expected to be in good shape.
I'm randomly scanning your AUR packages and so far I keep seeing things that I don't like just as the previous posters have mentioned (missing package functions, outdated PKGBUILD templates, lack of quotes, cd'ing into the SRCDEST directory (why?), etc.).
There are some nice PKGBUILDs there but so far the majority of what I have seen has been of poor quality. Most of us (the TUs) probably have at least one or two sub-standard PKGBUILDs lying around waiting to get flagged and updated, but overall there should be consistent quality.
You should have made an effort to correct at least the trivial PKGBUILDs prior to submitting your application. You should also have addressed the flagged packages (as you allegedly agreed you would with your sponsor).
I don't want to discourage you from further contribution but I do not think that you are ready to be a TU. You should take some time to address the issues raised in this thread and then spend at least a few more months maintaining your packages. Orphan some if you cannot adequately manage all of them. Quality counts for far more than quantity.
Regards, Xyne
2014/1/22 Xyne xyne@archlinux.ca:
On 2014-01-21 02:31 -0600 Doug Newgard wrote:
Most of the packages get better over time and in my case, it's not possible to have 140 packages in perfect state at once. So I can perfectly update or fix 4 packages/day (sometimes more if I automatically scan for new releases with pkgcheck :)), but some require community feedback/discussion, some need upstream fixes or further time for debugging. For the most part, the packages were in a much worse state than today. In my opinion the AUR is something like a incubator for new, experimental or less popular packages. If I havent put an early unfinished version of Gitlab [1] into the AUR, I wouldn't have been able to get that many constructive feedback and at the same time write an instruction at the wiki [2]. I guess the diversity is the reason, why the AUR is such a popular feature of ArchLinux. Of course there are more stable, less experimental packages which I want to see in the community repository.
[1] https://aur.archlinux.org/packages/gitlab/ [2] https://wiki.archlinux.org/index.php/Gitlab
Ok, so let's look at just that one.
What are "Unconfirmed makedeps"? Are they makedeps or aren't they?
You set the backup array based on what is installed at build time, which has little to do with what is installed at install/run time. This works (somewhat) in the AUR but not at all in binary repos. Not only that, but you then set a new backup array right after it making the whole thing moot.
You pull a bunch of files directly from master of a git repo. Very fragile.
Your quoting of paths containing variables is very inconsistent, some are quoted then not quoted in the next line.
Your use of curly braces is inconsistent.
Sometimes you use mv, sometimes cp, and sometimes install. Why?
Again, you're installing things based on what is installed at build time.
That's from a cursory reading of your given example, without looking into it in detail or looking at the install file at all. You see what I mean? Many TUs have as many or more packages than you're talking about, and they're all expected to be in good shape.
I'm randomly scanning your AUR packages and so far I keep seeing things that I don't like just as the previous posters have mentioned (missing package functions, outdated PKGBUILD templates, lack of quotes, cd'ing into the SRCDEST directory (why?), etc.).
There are some nice PKGBUILDs there but so far the majority of what I have seen has been of poor quality. Most of us (the TUs) probably have at least one or two sub-standard PKGBUILDs lying around waiting to get flagged and updated, but overall there should be consistent quality.
You should have made an effort to correct at least the trivial PKGBUILDs prior to submitting your application. You should also have addressed the flagged packages (as you allegedly agreed you would with your sponsor).
I don't want to discourage you from further contribution but I do not think that you are ready to be a TU. You should take some time to address the issues raised in this thread and then spend at least a few more months maintaining your packages. Orphan some if you cannot adequately manage all of them. Quality counts for far more than quantity.
Regards, Xyne
I agree with Xyne. You have to learn some more things and clean up your packages before you are ready.
I commented some of your packages in AUR. E.g. libzrtp, zfone and zfoned install files into the /usr/local directory, which is forbidden by a package.
-- György Balló Trusted User
Am 22.01.2014 23:56, schrieb Balló György: [...]
2014/1/22 Xyne xyne@archlinux.ca:
I don't want to discourage you from further contribution but I do not think that you are ready to be a TU. You should take some time to address the issues raised in this thread and then spend at least a few more months maintaining your packages. Orphan some if you cannot adequately manage all of them. Quality counts for far more than quantity.
[...]
I agree with Xyne. You have to learn some more things and clean up your packages before you are ready.
[...]
After reading this thread I want to add something that bugged me (arch power user for 4 years) for quite some time now: When is the time someone is "ready" to be a TU? Maybe at some point I or others intend to become one as well... I mean yes, there are some information on the Wiki[1] and the minimum requirements say clearly "maintain a few packages in AUR with clean, high-quality PKGBUILDs", which is what was already mentioned in this thread a few times. But as I roam the AUR nearly every day, I often see PKGBUILDs, that are maintained by TUs and not "clean, high quality". Most of them are older than 2 or 3 years, but there are also exceptions.
Short excursion: Lets take for example the TUs speps[2] and Dragonlord[3] (picked at random, no offense, we all have skeletons in the closet): speps has ~650 packages, ~50 marked as outdated, thats both quite a few. Dragonlord has ~250, 6 marked as outdated. Also a lot of packages that have fixes, patches or improvements in the comments for months or _years_ for both of them. We have 2014 now, pacman/makepkg changes that deprecate PKGBUILDs without build() function, "|| return 1" and stuff have been there since the mid of 2010. Now, lets filter it a bit using ack[4]: In the AUR git mirror (I know this is not representative, but I did not want to scrape the AUR website) are 734 packages, that have speps in a Maintainer tag, 30 are missing a package() function, 17 have return statements. There are 210 packages, that have dragonlord in a Maintainer tag, ~40 with return statements and ~50 without package() function. I know there are some false-positives, but bear with me. Dragonlord sometimes only adds himself to Contributors rather than Maintainer. Also there are packages with new maintainers forgetting to change the tag. This cases are not easy to parse though. There are also a lot of packages that do not use quoting for $srcdir and $pkgdir, but this is just bad practice, not wrong per se. If I look further there are a lot of PKGBUILDs with the old way of checking out sources in VCS, this feature is available since pacman/makepkg 4.1, considering this is available for more than half a year and the TUs _should_ set good examples for others to follow, this is also not like it should be. You do not have to believe my numbers, just randomly choose some packages and see for yourself. End of excursion, back on topic.
I think onny *can* be a good TU as well, as long as he learns from the problems that have been pointed out. He will likely learn from the others as well and get better in time.
@onny: Discussion period is not over yet, hurry up and fix/orphan the packages you maintain and your chances will increase.
@speps and all others with too many packages to maintain themselves: *Just orphan* packages you do not actually use or want to maintain. For you it is just one click in the AUR webinterface, but others will be hindered in fixing them. What is the reason to have packages that are marked out-of-date and broken for months[5] and years[6]? I do not get it. Fire and forget, maybe?
closing words: I know this reads in parts like a rant, but it is just to show you that also current TUs are not better in some aspects. Again it is not meant to blame speps (but seriously, just orphan some packages! :P) or Dragonlord. Just my two cents.
best regards, carstene1ns
[1]: https://wiki.archlinux.org/index.php/Trusted_Users [2]: https://aur.archlinux.org/packages/?K=speps&SeB=m [3]: https://aur.archlinux.org/packages/?K=Dragonlord&SeB=m [4]: http://beyondgrep.com/ [5]: https://aur.archlinux.org/packages/lib32-freealut/ [6]: https://aur.archlinux.org/packages/skencil/
On 25 January 2014 02:53, carstene1ns arch@carsten-teibes.de wrote:
closing words: I know this reads in parts like a rant, but it is just to show you that also current TUs are not better in some aspects. Again it is not meant to blame speps (but seriously, just orphan some packages! :P) or Dragonlord. Just my two cents.
If you're saying that neither these TUs nor the applicant are doing too many things wrong, then I have to agree with you. Personally, I'm not a fan of cherry-picking bad habits when there are enough good things to talk about, but questions should be raised to clarify certain practices. So, you bring up a good point there, but I'm sure all three of them can explain.
----------------------------------------
Date: Fri, 24 Jan 2014 19:53:19 +0100 From: arch@carsten-teibes.de To: aur-general@archlinux.org Subject: Re: [aur-general] TU application, sponsored by Lukas Fleischer
Am 22.01.2014 23:56, schrieb Balló György: [...]
2014/1/22 Xyne xyne@archlinux.ca:
I don't want to discourage you from further contribution but I do not think that you are ready to be a TU. You should take some time to address the issues raised in this thread and then spend at least a few more months maintaining your packages. Orphan some if you cannot adequately manage all of them. Quality counts for far more than quantity.
[...]
I agree with Xyne. You have to learn some more things and clean up your packages before you are ready.
[...]
I think onny *can* be a good TU as well, as long as he learns from the problems that have been pointed out. He will likely learn from the others as well and get better in time.
[...]
And if that is the case, fine. But let's again take a look at the example he held up, gitlab. The package was updated two days ago, addressed none of the concerns I and other commenters raised. His response is: "Sorry but I don't have the time now to look at all your changes. I'll do that later." Nothing yet, not to mention that it wouldn't even build at the time he uploaded it because of a bad checksum.
And this isn't the first time, he adopted some other packages I orphaned but kept an eye on. It took people emailing him directly to get him to update a package that had been marked out of date for a month.
Maybe it is just a matter of not enough time, but does that really change anything?
I think it is a wrong assumption to say that having "bad" packages at time of application as no different that having those as an established user. Amount of attention spent to such stuff inevitably goes down as amount of load increases (and it stops being interesting/satisfying) so if there are some issues right now I'd generally assume situation will become even worse after approval, not better. Point of application is identical to point of theoretical perfection in my opinion.
On 01-22 21:59, Xyne wrote:
[...] There are some nice PKGBUILDs there but so far the majority of what I have seen has been of poor quality. Most of us (the TUs) probably have at least one or two sub-standard PKGBUILDs lying around waiting to get flagged and updated, but overall there should be consistent quality.
You are absolutely right Xyne. I orphaned about 100 packages that I adopted over time but never really used. I should really stick to the important packages that I use for myself on daily basis. Actually I'm aware of the basic packaging standards and I never used outdated syntax like return-statements or srcdest variables, but I had a lot of them in broken packages I adopted. On the one side, quality counts but on the other site I'm often frustrated to see that many dysfunctional packages ...
On 01-24 21:22, Doug Newgard wrote:
And if that is the case, fine. But let's again take a look at the example he held up, gitlab. The package was updated two days ago, addressed none of the concerns I and other commenters raised. His response is: "Sorry but I don't have the time now to look at all your changes. I'll do that later." Nothing yet, not to mention that it wouldn't even build at the time he uploaded it because of a bad checksum.
I must say that the Gitlab packages is a very difficult one and it's not that easy to fix certain things because they need a lot of testing. Also friends told me that they invested a lot of time setting it up on Debian or Ubuntu, following the very complex official installation instruction. Earlier versions of Gitlab had a lot of errors and Ruby is not that easy to debug. I managed to ease the installation a lot and also rewrote the installation instructions on the wiki (before that, it was just a copy and paste of the official instruction which didn't really fit to ArchLinux systems). Unfortunately the interest in this package went up over the last days and exactly at this time I'm getting a cold :( I really want to address the concerns as soon I'm back on track ;)
On 01-22 23:56, Balló György wrote:
I agree with Xyne. You have to learn some more things and clean up your packages before you are ready.
I'll recheck my packages and than you have to decide. I'm still motivated to improve my contributions :)
On 2014-01-24 19:53 +0100 carstene1ns wrote:
*snip*
several good points
*snip*
Becoming a TU is not like joining Cosa Nostra... it's not always for life. Some TUs inevitably find that real-life obligations eliminate the free time they once had to maintain packages and so the quality drops. We are supposed to keep an eye on each other and discuss problems that we see. In the worst case we also have removal procedures. Unfortunately, nobody ever really wants to be the bad guy calling out others on bad habits.
TUs are not exempt from having their packages orphaned either. If a package has been flagged out-of-date for weeks/months and the TU fails to respond via email then you can send an orphan request to this list. It should also incite a discussion about the TU in question.
I hope that Dragonlord and speps will respond to your points and either fix or orphan their flagged packages.
I can also honestly say that I would oppose an application from someone with 51 flagged packages, so I do not believe that I am inconsistent in my remarks about the current application.
Regards, Xyne
On Tue, 21 Jan 2014 at 00:32:08, Jonas Heinrich wrote:
Hi ArchLinux community, I like to apply as TU, sponsored by Lukas Fleischer (aka CryptoCrack), since my passion and work for ArchLinux continues since half a decade and I really would like to get more involved into development and package maintaining. [...]
I confirm my sponsorship, let the discussion period begin.
Hi,
On Monday 20 January 2014 23:32:08 Jonas Heinrich wrote:
Hi ArchLinux community, I like to apply as TU, sponsored by Lukas Fleischer (aka CryptoCrack), since my passion and work for ArchLinux continues since half a decade and I really would like to get more involved into development and package maintaining. My name is Jonas (my public key [1]), I'm 23 years old, computer science student in Karlsruhe, Germany. I switched to Linux in school while working voluntarily on a school server [2] and school internet cafe together with a class mate in our free time. Hacking on fun projects became on of my big hobbies and some of them are documented in my blog [3]. I get a lot of inspiration and exchange in my local hacker space, the Entropia e.V. [4] which is part of the CCC (Chaos Computer Club) [5] but also at work as a network administrator at the architecture faculty of my university. I love ArchLinux, using it on my servers (with several ArchLinux vms) and on my laptop, because it's simple, basic and fast. The wiki is also one of my favorite places in the community, because all the documentation is pragmatic and to the point. I constantly write new how-to's or improve instructions on other pages [6]. In my opinion, a well written Wiki/Doku, also for all the third-party software, is very important and one reason why I don't want to use Debian anymore for my projects. I learned how to write clean and sometimes complex PKGBUILDs over time and now maintaining up to 150 AUR packages [7]. Some of them are really important to me (using them on my server or integrated them to my projects) and I think also important to the community, so I would like to put them into the community repository. For example: archivemount, btar, dmtcp, etherpad-lite, freecad, gallery, gitlab, hlds, joomla, opentracker, pyload, python-libtorrent-rasterbar, sslstrip, etc. For other packages, I adopted them just to fix broken PKGBUILDs or I tried to port non-supported software to ArchLinux like Zenoss, oVirt or Kolab while working with their developers to improve ArchLinux support. At least, here are some of my experimental projects you can look at: p2pacman [8], pkgcheck [9], wikidict [10], carpc based on ArchLinux [11]. For further questions, you can find me on #archlinux at freenode or just ask them here on the mailinglist. Best regards, Jonas
I have looked quickly at your packages. Some of this has been said before.
1) For some packages you use bsdtar/tar in the package() function. It is not an error, but source files already unpacked into $srcdir. Maybe is it a better way to use "cp" (or "install") instead of "bsdtar"? 2) For some packages you don't use double quotes for $srcdir and/or $pkgdir variables. 3) PKGBUILDs for "ausweisapp", "centrafuseauto-beta", some of "courier-" and other packages may be less than it is. (If you will use "find -exec" for example.) But it isn't an error too. 4) Some of PKGBUILDs have "| return 1" function. 5) Some of your packages are out-of-date. 6) Why you do not use patches for some of your packages and use giant sed script? 7) Some of your packages have old VCS standart. 8) vim-paster really had not package() function.
But some others look pretty. I understand that it is difficult to maintain a large number of packages. But it is a reason to disown some of them.
I want ask you what are packages groups that you want maintain and why? Or have you no any general idea?
On Tue, 21 Jan 2014 at 00:32:08, Jonas Heinrich wrote:
Hi ArchLinux community, I like to apply as TU, sponsored by Lukas Fleischer (aka CryptoCrack), since my passion and work for ArchLinux continues since half a decade and I really would like to get more involved into development and package maintaining. [...]
The discussion period is over. Please cast your votes now [1].
On Mon, 27 Jan 2014 at 19:07:19, Lukas Fleischer wrote:
On Tue, 21 Jan 2014 at 00:32:08, Jonas Heinrich wrote:
Hi ArchLinux community, I like to apply as TU, sponsored by Lukas Fleischer (aka CryptoCrack), since my passion and work for ArchLinux continues since half a decade and I really would like to get more involved into development and package maintaining. [...]
The discussion period is over. Please cast your votes now [1].
Voting is closed. The results are:
* Yes: 1 * No: 24 * Abstain: 7
Unfortunately, this means that the application has been rejected. Sorry, Jonas! Some rather general tips from me (to you and to other future applicants):
* Check whether your PKGBUILDs are up-to-date and in good shape. Usually, sponsors will have a look at your AUR packages (which I clearly did not do carefully enough in this case) but it is a good idea to have a look at your packages yourself (maybe even ask someone to have a look at them if you are not sure) and polish stuff before asking a TU to sponsor your application.
* Heed the advice of your sponsor! If the sponsor recommends doing some preparatory work before submitting the application, do it. There is no point in submitting the application over-hasty. If the sponsor gives you an advice during the application period, don't simply ignore it. If you think you cannot accept the advice for whatever reasons, you should at least reply and say you can't.
* Discuss. During the discussion period, it is generally a good idea react to questions and criticism. Not taking part in the discussion usually is a sign of lack of interest and a sign of not being able to take criticism and is likely to have a negative impact on the voting.
Jonas, sadly, the TU bylaws prohibit you to reapply for three months. However, you can take advantage of the remaining time and work on your packages. Feel free to resubmit (don't take this literally) your application anytime as of mid-May.
Regards, Lukas
aur-general@lists.archlinux.org