Re: [aur-general] TU application sponsored by David Reisner
Hi On 2/3/14, 9:29 PM, Anatol Pomozov wrote: Hi On Mon, Feb 3, 2014 at 11:26 AM, Anatol Pomozov anatol.pomo...@gmail.com wrote: Hi everyone I would like to apply for a Arch Trusted User position. It is sponsored by my co-worker and bright engineer David Reisner. My name is Anatol Pomozov, I grew up in Belarus but live in USA now. I am an open-source enthusiast who uses Linux since about 2005. I've been using several distros mostly Debian based. About 2.5 years ago, when Ubuntu in-place upgrade killed my system once again, I've decided to give a try to a rolling-release distro. I had heard that Arch was difficult to use and unstable so I've been skeptical that Arch would survive at my computers for a long time. At my surprise Arch installation was easy and system was fast and stable. Documentation is clean and very helpful. And package manager is *FAST*! Yeah! I fell in love with Arch from the very first day. A few months later all my home computers were moved to Arch. And despite that I usually do crazy experiments at my home machines I've never had serious problems with Arch. Well, the only problem with Arch was in systemd-207 that prevented my btrfs-root machine from booting. About a year ago I started playing more active role in Arch community. I adopted a lot of broken and out-of-date packages. Currently I own 350+ packages [1]. A lot of packages are for ruby gems that previously were out-of-date or had broken dependencies. I improved existing gem2arch tool [2] and it helps me with ruby packages herding. At my day job I work on Linux kernel development/support at a large server farm. My daily activity includes a lot of debugging, performance profiling, code archaeology both for linux kernel and in-house userspace code. Some of my linux changes went upstream, here are few of them: https://lkml.org/lkml/2013/4/12/391 http://marc.info/?l=linux-fsdevelm=134750749009884w=2 https://lkml.org/lkml/2013/4/1/171 Google Chromebook developers reported that my last patch fixed one of their top kernel crashes! Recently me and my 6 y/o son started learning microelectronics and digital design. Maybe some day we'll create MIPS-like CPU. Why do I want to become a TU? I like Arch and would like to keep it improving. It means making packages better, participate in important discussions that define where the distro moves. The short/mid terms plans for me are: - move some of my aur packages to community: rethinkdb, codespell, tup, mldonkey, v8. There are some other aur packages that I use and would also like to see in [community]: fatsort, digital design related tools, ... - add android-sdk-* packages. Current AUR packages download binaries and install binaries to /opt/bin. The binaries are 32-bit. Instead we should build SDK from sources and provide proper 64/32-bit binaries. This might be tricky as Android build system is complicated. - request moving Apache to [community] and finally update this package to 2.4 I can help with linux kernel issues, especially if they are related to storage/block subsystem. I also have experience with Ruby. This is my favorite scripting language that I use for 10 years now and I'll be glad to help with Ruby in Arch as well. [1] aur.archlinux.org/packages/?SeB=mK=anatolik [2] https://github.com/anatol/gem2arch Dave asked me to share my public GPG key. Here it is http://pgp.mit.edu/pks/lookup?op=getsearch=0xB02854ED753E0F1F The key is 753E0F1F D'oh, gmail web UI ate my gpg signature. Let me sign it once again, this time with Thunderbird. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU application sponsored by David Reisner
Dave Reisner wrote: On Mon, Feb 03, 2014 at 02:49:48PM -0500, Daniel Micay wrote: On Mon, Feb 3, 2014 at 2:46 PM, Dave Reisner d...@falconindy.com wrote: On Mon, Feb 03, 2014 at 11:26:22AM -0800, Anatol Pomozov wrote: Hi everyone I would like to apply for a Arch Trusted User position. It is sponsored by my co-worker and bright engineer David Reisner. My name is Dave and I approve this message. Nice try, David. My GPG signature says you're wrong. Nitpick: the current by-laws require the sponsor to be a TU. Do we override Hal to open the hatch?
Re: [aur-general] TU application sponsored by David Reisner
Sébastien Luttringer wrote: I do not mind to change it to the longer version $srcdir/foo if this is a recommended way to do, but first I want to know why it is recommended. Although it's not strictly recommended (we lack of official recommendation?), this way works in all cases. I have to confess that I have smoothly switched all my relative path to full path since I got the previous issue. Cheers, $srdcir/foo is explicit and independent of the nesting of source files. That is unreservedly worth 5 extra bytes. Regards, Xyne
Re: [aur-general] TU application sponsored by David Reisner
On Wed, 05 Feb 2014 at 00:12:49, Xyne wrote: Dave Reisner wrote: On Mon, Feb 03, 2014 at 02:49:48PM -0500, Daniel Micay wrote: On Mon, Feb 3, 2014 at 2:46 PM, Dave Reisner d...@falconindy.com wrote: On Mon, Feb 03, 2014 at 11:26:22AM -0800, Anatol Pomozov wrote: Hi everyone I would like to apply for a Arch Trusted User position. It is sponsored by my co-worker and bright engineer David Reisner. My name is Dave and I approve this message. Nice try, David. My GPG signature says you're wrong. Nitpick: the current by-laws require the sponsor to be a TU. Do we override Hal to open the hatch? Technically, that is correct. However, I am sure there are many other TUs volunteering to be the sponsor after having read the application and the discussion (me, for example). So I don't think it is a problem. If it makes feel anyone better, please run sed 's/David Reisner/Lukas Fleischer/g' on your inbox (the misspelling of Dave's name comes in useful here!)
Re: [aur-general] TU application sponsored by David Reisner
Lukas Fleischer wrote: Technically, that is correct. However, I am sure there are many other TUs volunteering to be the sponsor after having read the application and the discussion (me, for example). So I don't think it is a problem. If it makes feel anyone better, please run sed 's/David Reisner/Lukas Fleischer/g' on your inbox (the misspelling of Dave's name comes in useful here!) I'm not opposed to the application (it looks very promising to me). I just wanted to mention this issue because there is no point in having by-laws if we ignore them every time we assume that there is a tacit consensus to do so.
Re: [aur-general] TU application sponsored by David Reisner
On 05/02/2014 00:34, Xyne wrote: Lukas Fleischer wrote: Technically, that is correct. However, I am sure there are many other TUs volunteering to be the sponsor after having read the application and the discussion (me, for example). So I don't think it is a problem. If it makes feel anyone better, please run sed 's/David Reisner/Lukas Fleischer/g' on your inbox (the misspelling of Dave's name comes in useful here!) I'm not opposed to the application (it looks very promising to me). I just wanted to mention this issue because there is no point in having by-laws if we ignore them every time we assume that there is a tacit consensus to do so. I strongly support that we follow our by-laws. If Anatol agrees, Lukas will become his new sponsor and we will continue to discuss this new promising application. Cheers, -- Sébastien Seblu Luttringer https://seblu.net GPG: 0x2072D77A signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU application sponsored by David Reisner
Hi On 2/4/14, 5:27 PM, Sébastien Luttringer wrote: On 05/02/2014 00:34, Xyne wrote: Lukas Fleischer wrote: Technically, that is correct. However, I am sure there are many other TUs volunteering to be the sponsor after having read the application and the discussion (me, for example). So I don't think it is a problem. If it makes feel anyone better, please run sed 's/David Reisner/Lukas Fleischer/g' on your inbox (the misspelling of Dave's name comes in useful here!) I'm not opposed to the application (it looks very promising to me). I just wanted to mention this issue because there is no point in having by-laws if we ignore them every time we assume that there is a tacit consensus to do so. I strongly support that we follow our by-laws. If Anatol agrees, Lukas will become his new sponsor and we will continue to discuss this new promising application. I am fine with this. Although it's not strictly recommended (we lack of official recommendation?), this way works in all cases. Ok, I've updated 14 packages where I found relative path usage. PTAL. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU application sponsored by David Reisner
Hi On 2/4/14, 5:27 PM, Sébastien Luttringer wrote: On 05/02/2014 00:34, Xyne wrote: Lukas Fleischer wrote: Technically, that is correct. However, I am sure there are many other TUs volunteering to be the sponsor after having read the application and the discussion (me, for example). So I don't think it is a problem. If it makes feel anyone better, please run sed 's/David Reisner/Lukas Fleischer/g' on your inbox (the misspelling of Dave's name comes in useful here!) I'm not opposed to the application (it looks very promising to me). I just wanted to mention this issue because there is no point in having by-laws if we ignore them every time we assume that there is a tacit consensus to do so. I strongly support that we follow our by-laws. If Anatol agrees, Lukas will become his new sponsor and we will continue to discuss this new promising application. I am fine with this. I still need to understand why Arch community is split into two groups 'developers' and 'trusted users'. They seems have similar responsibilities: maintaining packages and developing Arch toolset. Although it's not strictly recommended (we lack of official recommendation?), this way works in all cases. Ok, I've updated 14 packages where I found relative path usage. PTAL. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU application sponsored by David Reisner
On 5 February 2014 12:57, Anatol Pomozov anatol.pomo...@gmail.com wrote: I still need to understand why Arch community is split into two groups 'developers' and 'trusted users'. They seems have similar responsibilities: maintaining packages and developing Arch toolset. For historical reasons: https://wiki.archlinux.org/index.php/Community_repository#History The [community] repository began as a binary repository for the AUR. It still retains that function, but the split is no longer as pronounced. Basically, slightly popular packages go into [community], and very popular ones into [extra]. The [extra] repo has a tighter control over what goes in, whereas [community] is almost open. Both groups have useful people: the pacman, core and early userspace folks, and the AUR back-end folks. -- GPG/PGP ID: C0711BF1
[aur-general] TU application sponsored by David Reisner
Hi everyone I would like to apply for a Arch Trusted User position. It is sponsored by my co-worker and bright engineer David Reisner. My name is Anatol Pomozov, I grew up in Belarus but live in USA now. I am an open-source enthusiast who uses Linux since about 2005. I've been using several distros mostly Debian based. About 2.5 years ago, when Ubuntu in-place upgrade killed my system once again, I've decided to give a try to a rolling-release distro. I had heard that Arch was difficult to use and unstable so I've been skeptical that Arch would survive at my computers for a long time. At my surprise Arch installation was easy and system was fast and stable. Documentation is clean and very helpful. And package manager is *FAST*! Yeah! I fell in love with Arch from the very first day. A few months later all my home computers were moved to Arch. And despite that I usually do crazy experiments at my home machines I've never had serious problems with Arch. Well, the only problem with Arch was in systemd-207 that prevented my btrfs-root machine from booting. About a year ago I started playing more active role in Arch community. I adopted a lot of broken and out-of-date packages. Currently I own 350+ packages [1]. A lot of packages are for ruby gems that previously were out-of-date or had broken dependencies. I improved existing gem2arch tool [2] and it helps me with ruby packages herding. At my day job I work on Linux kernel development/support at a large server farm. My daily activity includes a lot of debugging, performance profiling, code archaeology both for linux kernel and in-house userspace code. Some of my linux changes went upstream, here are few of them: https://lkml.org/lkml/2013/4/12/391 http://marc.info/?l=linux-fsdevelm=134750749009884w=2 https://lkml.org/lkml/2013/4/1/171 Google Chromebook developers reported that my last patch fixed one of their top kernel crashes! Recently me and my 6 y/o son started learning microelectronics and digital design. Maybe some day we'll create MIPS-like CPU. Why do I want to become a TU? I like Arch and would like to keep it improving. It means making packages better, participate in important discussions that define where the distro moves. The short/mid terms plans for me are: - move some of my aur packages to community: rethinkdb, codespell, tup, mldonkey, v8. There are some other aur packages that I use and would also like to see in [community]: fatsort, digital design related tools, ... - add android-sdk-* packages. Current AUR packages download binaries and install binaries to /opt/bin. The binaries are 32-bit. Instead we should build SDK from sources and provide proper 64/32-bit binaries. This might be tricky as Android build system is complicated. - request moving Apache to [community] and finally update this package to 2.4 I can help with linux kernel issues, especially if they are related to storage/block subsystem. I also have experience with Ruby. This is my favorite scripting language that I use for 10 years now and I'll be glad to help with Ruby in Arch as well. [1] aur.archlinux.org/packages/?SeB=mK=anatolik [2] https://github.com/anatol/gem2arch
Re: [aur-general] TU application sponsored by David Reisner
On Mon, Feb 3, 2014 at 2:26 PM, Anatol Pomozov anatol.pomo...@gmail.com wrote: - add android-sdk-* packages. Current AUR packages download binaries and install binaries to /opt/bin. The binaries are 32-bit. Instead we should build SDK from sources and provide proper 64/32-bit binaries. This might be tricky as Android build system is complicated. This is indeed a huge pain. Cloning the sources alone takes ages and a ridiculous amount of disk space. There are at least two trusted users interested in doing this, but it hasn't happened yet. It would be *great* if you got it working :).
Re: [aur-general] TU application sponsored by David Reisner
On 03.02.2014 20:29, Daniel Micay wrote: On Mon, Feb 3, 2014 at 2:26 PM, Anatol Pomozov anatol.pomo...@gmail.com wrote: - add android-sdk-* packages. Current AUR packages download binaries and install binaries to /opt/bin. The binaries are 32-bit. Instead we should build SDK from sources and provide proper 64/32-bit binaries. This might be tricky as Android build system is complicated. This is indeed a huge pain. Cloning the sources alone takes ages and a ridiculous amount of disk space. There are at least two trusted users interested in doing this, but it hasn't happened yet. It would be *great* if you got it working :). That would be awesome! Mad props if you indeed managed to make the android-sdk from source. Also please note that we binary sdk provided by google is not redistributable so careful with that. +1
Re: [aur-general] TU application sponsored by David Reisner
On Mon, Feb 03, 2014 at 11:26:22AM -0800, Anatol Pomozov wrote: Hi everyone I would like to apply for a Arch Trusted User position. It is sponsored by my co-worker and bright engineer David Reisner. My name is Dave and I approve this message.
Re: [aur-general] TU application sponsored by David Reisner
On Mon, Feb 03, 2014 at 11:26:22AM -0800, Anatol Pomozov wrote: At my day job I work on Linux kernel development/support at a large server farm. My daily activity includes a lot of debugging, performance profiling, code archaeology both for linux kernel and in-house userspace code. Some of my linux changes went upstream, here are few of them: https://lkml.org/lkml/2013/4/12/391 http://marc.info/?l=linux-fsdevelm=134750749009884w=2 https://lkml.org/lkml/2013/4/1/171 I can vouch for Anatol's kernel submissions and great bugfixes over the years, they have been much appreciated. thanks, greg k-h
Re: [aur-general] TU application sponsored by David Reisner
On Mon, Feb 03, 2014 at 02:49:48PM -0500, Daniel Micay wrote: On Mon, Feb 3, 2014 at 2:46 PM, Dave Reisner d...@falconindy.com wrote: On Mon, Feb 03, 2014 at 11:26:22AM -0800, Anatol Pomozov wrote: Hi everyone I would like to apply for a Arch Trusted User position. It is sponsored by my co-worker and bright engineer David Reisner. My name is Dave and I approve this message. Nice try, David. My GPG signature says you're wrong. pgpiGg0H55Ccv.pgp Description: PGP signature
Re: [aur-general] TU application sponsored by David Reisner
On Mon, Feb 3, 2014 at 2:46 PM, Dave Reisner d...@falconindy.com wrote: On Mon, Feb 03, 2014 at 11:26:22AM -0800, Anatol Pomozov wrote: Hi everyone I would like to apply for a Arch Trusted User position. It is sponsored by my co-worker and bright engineer David Reisner. My name is Dave and I approve this message. Nice try, David.
Re: [aur-general] TU application sponsored by David Reisner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Mon, Feb 3, 2014 at 11:26 AM, Anatol Pomozov anatol.pomo...@gmail.com wrote: Hi everyone I would like to apply for a Arch Trusted User position. It is sponsored by my co-worker and bright engineer David Reisner. My name is Anatol Pomozov, I grew up in Belarus but live in USA now. I am an open-source enthusiast who uses Linux since about 2005. I've been using several distros mostly Debian based. About 2.5 years ago, when Ubuntu in-place upgrade killed my system once again, I've decided to give a try to a rolling-release distro. I had heard that Arch was difficult to use and unstable so I've been skeptical that Arch would survive at my computers for a long time. At my surprise Arch installation was easy and system was fast and stable. Documentation is clean and very helpful. And package manager is *FAST*! Yeah! I fell in love with Arch from the very first day. A few months later all my home computers were moved to Arch. And despite that I usually do crazy experiments at my home machines I've never had serious problems with Arch. Well, the only problem with Arch was in systemd-207 that prevented my btrfs-root machine from booting. About a year ago I started playing more active role in Arch community. I adopted a lot of broken and out-of-date packages. Currently I own 350+ packages [1]. A lot of packages are for ruby gems that previously were out-of-date or had broken dependencies. I improved existing gem2arch tool [2] and it helps me with ruby packages herding. At my day job I work on Linux kernel development/support at a large server farm. My daily activity includes a lot of debugging, performance profiling, code archaeology both for linux kernel and in-house userspace code. Some of my linux changes went upstream, here are few of them: https://lkml.org/lkml/2013/4/12/391 http://marc.info/?l=linux-fsdevelm=134750749009884w=2 https://lkml.org/lkml/2013/4/1/171 Google Chromebook developers reported that my last patch fixed one of their top kernel crashes! Recently me and my 6 y/o son started learning microelectronics and digital design. Maybe some day we'll create MIPS-like CPU. Why do I want to become a TU? I like Arch and would like to keep it improving. It means making packages better, participate in important discussions that define where the distro moves. The short/mid terms plans for me are: - move some of my aur packages to community: rethinkdb, codespell, tup, mldonkey, v8. There are some other aur packages that I use and would also like to see in [community]: fatsort, digital design related tools, ... - add android-sdk-* packages. Current AUR packages download binaries and install binaries to /opt/bin. The binaries are 32-bit. Instead we should build SDK from sources and provide proper 64/32-bit binaries. This might be tricky as Android build system is complicated. - request moving Apache to [community] and finally update this package to 2.4 I can help with linux kernel issues, especially if they are related to storage/block subsystem. I also have experience with Ruby. This is my favorite scripting language that I use for 10 years now and I'll be glad to help with Ruby in Arch as well. [1] aur.archlinux.org/packages/?SeB=mK=anatolik [2] https://github.com/anatol/gem2arch Dave asked me to share my public GPG key. Here it is http://pgp.mit.edu/pks/lookup?op=getsearch=0xB02854ED753E0F1F The key is 753E0F1F -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJS8HrXAAoJELAoVO11Pg8f9pIP/2ZHDY5Dpu3bMBb48uqxOB++ SCpqR6nJ5WXRlnLrjZJMSssOhqGungTc7Pw1O1fg5hT72siZXYv40rPFXkF1/HrN T6WrM8CClPCMnWvBsJ2UWDLRkstHJncm4yrFtkbz26RBiTpzVK3bIC4BDvW6FrXM HqLsGwQmSYP+WqmWIyCjpyxx+MX+NxPGsTVHsNaSjGWsRaLK6A5ele+XNBr+T3Z5 S/PZAz4A7pKOL1n0bNBEtGuIm//fPXneC4xe5W4sVsSWD+lVdHfbQ6ewTXDLshQQ mdAEJVB/NHdMG9pZeNyu6FXm/znm3r5lhKZoSVmRmxkaLHgAR+KoODgVsE8m3Az0 YLzoY7BpBR/1E2LxudFrYvI1JASyi4/XZ4XUMoFBc8uCa7qtE1jw8G1MwbM1xP1M GoEPQLzDelV/oPUpw3uBPk8GRDY/H/f2kyMfyZJQF7cwYIazc2SfvKqzmuDlI0Pp WcsPiCmigh8RHFXklkKz+Q5OgYUZ9GBKvh0q6jZZfNEZHNlqXbAxxjGpH2qbmoGS hTtt1ebcWUtFwtYkATuyR32muZzPpTqImvSLDRYUQmF8KrQEibx11FInb99y2tEq 5plWSo1tmNxjOy9vjLibUxvTsO6KZVkYSoMMhwKeO+KZweRmldTilG0CjA7ZiSuI t/8Z4WFCdPKO7RljKVVu =3GwC -END PGP SIGNATURE-
Re: [aur-general] TU application, sponsored by Lukas Fleischer
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]. [1] https://aur.archlinux.org/tu/?id=74
Re: [aur-general] TU application, sponsored by Lukas Fleischer
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
Re: [aur-general] TU application, sponsored by Lukas Fleischer
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.
Re: [aur-general] TU application, sponsored by Lukas Fleischer
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 :) pgpeEcW2EOy0M.pgp Description: PGP signature
Re: [aur-general] TU application, sponsored by Lukas Fleischer
Am 22.01.2014 23:56, schrieb Balló György: [...] 2014/1/22 Xyne x...@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=spepsSeB=m [3]: https://aur.archlinux.org/packages/?K=DragonlordSeB=m [4]: http://beyondgrep.com/ [5]: https://aur.archlinux.org/packages/lib32-freealut/ [6]: https://aur.archlinux.org/packages/skencil/ signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU application, sponsored by Lukas Fleischer
On 25 January 2014 02:53, carstene1ns a...@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. -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU application, sponsored by Lukas Fleischer
Date: Fri, 24 Jan 2014 19:53:19 +0100 From: a...@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 x...@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?
Re: [aur-general] TU application, sponsored by Lukas Fleischer
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
Re: [aur-general] TU application, sponsored by Lukas Fleischer
2014/1/22 Xyne x...@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
Re: [aur-general] TU application, sponsored by Lukas Fleischer
Date: Tue, 21 Jan 2014 07:38:25 + From: o...@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 + From: o...@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-einrichtung-des-schulserver-fur-die-freie-waldorfschule-vaihingenenz/ (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=onnySeB=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-mit-xbmc-frontend/ 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
Re: [aur-general] TU application, sponsored by Lukas Fleischer
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.
Re: [aur-general] TU application, sponsored by Lukas Fleischer
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.
Re: [aur-general] TU application, sponsored by Lukas Fleischer
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? -- С уважением, Е.Алексеев. Sincerely yours, E.Alekseev. e-mail: darkarca...@mail.ru ICQ: 407-398-235 Jabber: arca...@jabber.ru signature.asc Description: This is a digitally signed message part.
[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-einrichtung-des-schulserver-fur-die-freie-waldorfschule-vaihingenenz/ (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=onnySeB=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-mit-xbmc-frontend/ pgpozGwAMp9Mi.pgp Description: PGP signature
Re: [aur-general] TU application, sponsored by Lukas Fleischer
Date: Mon, 20 Jan 2014 23:32:08 + From: o...@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-einrichtung-des-schulserver-fur-die-freie-waldorfschule-vaihingenenz/ (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=onnySeB=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-mit-xbmc-frontend/ 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?
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 + From: o...@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-einrichtung-des-schulserver-fur-die-freie-waldorfschule-vaihingenenz/ (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=onnySeB=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-mit-xbmc-frontend/ 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
Re: [aur-general] TU application - Sponsored by Balló György
Welcome, congrats, merry Christmas and a happy New Year. :) - Alexander / xyproto
Re: [aur-general] TU resignation
Thanks for your contributions to Arch Linux and best of luck to you! -- Sincerely, Alexander Rødseth xyproto / TU
Re: [aur-general] TU application - Sponsored by Balló György
On 23/12/2013 22:41, Martin Wimpress wrote: Hi, That's great news :-) I've got a lot on until December 29th but after that I will be able to complete the initial TU tasks. Looking forward to working with you all soon. Balló György ballog...@gmail.com wrote: The vote is over and the results are: Yes: 26 No: 2 Abstain: 1 This means that Martin is now a TU! Martin, welcome to the team, and happy holidays! :) Welcome to the team, please down post, and merry Christmas. -- Sébastien Seblu Luttringer https://www.seblu.net GPG: 0x2072D77A signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU application - Sponsored by Balló György
On Monday, December 23, 2013 21:41:59 Martin Wimpress wrote: Hi, That's great news :-) I've got a lot on until December 29th but after that I will be able to complete the initial TU tasks. Looking forward to working with you all soon. Welcome and Merry Christmas :) Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [aur-general] TU application - Sponsored by Balló György
The vote is over and the results are: Yes: 26 No: 2 Abstain: 1 This means that Martin is now a TU! Martin, welcome to the team, and happy holidays! :) -- György Balló Trusted User
Re: [aur-general] TU application - Sponsored by Balló György
Hi, That's great news :-) I've got a lot on until December 29th but after that I will be able to complete the initial TU tasks. Looking forward to working with you all soon. Balló György ballog...@gmail.com wrote: The vote is over and the results are: Yes: 26 No: 2 Abstain: 1 This means that Martin is now a TU! Martin, welcome to the team, and happy holidays! :) -- György Balló Trusted User
Re: [aur-general] TU application - Sponsored by Balló György
On Mon, Dec 23, 2013 at 10:41 PM, Martin Wimpress martin+a...@flexion.orgwrote: Hi, That's great news :-) I've got a lot on until December 29th but after that I will be able to complete the initial TU tasks. Looking forward to working with you all soon. Balló György ballog...@gmail.com wrote: The vote is over and the results are: Yes: 26 No: 2 Abstain: 1 This means that Martin is now a TU! Martin, welcome to the team, and happy holidays! :) -- György Balló Trusted User Welcome aboard Martin! See you next year on IRC then :) Also happy Xmas/New Year all. Cheers, -- Maxime
Re: [aur-general] TU resignation
On Sat, Dec 21, 2013 at 09:21:58AM +1300, Jonathan Conder wrote: Hi everyone, I've been pretty busy lately and haven't been able to find the time to fix bugs and keep my packages up-to-date. Lately I haven't actually been using any of the packages I maintain, so I think the time has come to pass them on to someone with the time and motivation to maintain them. So, without further ado, I hereby tender my resignation as a TU. I wish you all the best and hope you continue doing the things which make Arch so great. Best, Jonathan P.S. I've had trouble getting GPG and gmail to play together, so I've attached the contents of this message and signed that instead of signing the email itself. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I've been pretty busy lately and haven't been able to find the time to fix bugs and keep my packages up-to-date. Lately I haven't actually been using any of the packages I maintain, so I think the time has come to pass them on to someone with the time and motivation to maintain them. So, without further ado, I hereby tender my resignation as a TU. I wish you all the best and hope you continue doing the things which make Arch so great. Best, Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJStKaEAAoJEK9+94c8/Uu26OYIAIlPKg7TbXCLmpFlwgsE3i/h wBCzQnx7MCGNgBAZ3eDdFJR4txhZOtt740aO8O4ZhihUed/YR0lJwb72C6qP4dcf u5OIFFEdHF+iZqJ+34hPD7QkmVJUYxs+f5xeBlK4ETYNo3mtOU/SreyLLj7yviLG jz2e20tFK0sfOyeglKKJpMC8EOzn2ARufLPlZxV8TFUj0pN2uSOoT2Gm6Ifj2KRn SNv3PpZDitRwMfWRbxMOCSvHl8+KAKZwzKloEThSPFAzrjuSWyWb2+poDwE4YcRL McMBEyqC6jQNA0BTpZ6R3XYNbwgwFllkHij+ONKn4xd5R5Nrq7sRYzgGrZNUplA= =dxpV -END PGP SIGNATURE- Sad to see you leave, thanks for all the great things you have done for Archlinux. Enjoy what the future brings you :) -- Ike pgpWxUJUMEap_.pgp Description: PGP signature
Re: [aur-general] TU resignation
On 12/21/2013 01:12 PM, Balló György wrote: Sad news. You did a great job on maintaining PackageKit's alpm backend in the recent years. Thanks for your work, and good luck! If nobody step up porting the alpm backend to PackageKit version 0.8 (huge work!), I'll drop the following packages from the [community] repository in the next days: - apper - gnome-settings-daemon-updates - gnome-packagekit - packagekit - packagekit-qt2 - python2-packagekit -- György Balló Trusted User Hi guys, I am planning to complete the porting of the alpm backend to packagekit 0.8+ I reached out to Jonathan a few weeks ago and he was very helpful in bring me up to speed on what's left to be done. Sadly, I have not had the time to get it done yet. Things at work are going to slow down a lot for me once the holiday season is over and getting the port finished is definitely high up on my to do list. This thread caught my eye as I was scanning through email so I thought I should take a second to make my plans known :) Happy Holidays! -- *Dustin Falgout* Antergos Dev Team E-Mail: dus...@falgout.us mailto:dus...@falgout.us Google/Skype: dustinfalgout IRC Chat: #antergos http://webchat.freenode.net/?channels=antergosuio=d4 http://antergos.com/
Re: [aur-general] TU resignation
On 12/22/2013 03:15 PM, Ike Devolder wrote: On Sat, Dec 21, 2013 at 08:12:10PM +0100, Balló György wrote: Sad news. You did a great job on maintaining PackageKit's alpm backend in the recent years. Thanks for your work, and good luck! If nobody step up porting the alpm backend to PackageKit version 0.8 (huge work!), I'll drop the following packages from the [community] repository in the next days: - apper - gnome-settings-daemon-updates - gnome-packagekit - packagekit - packagekit-qt2 - python2-packagekit -- György Balló Trusted User Why the rush to drop these packages ? Currently it is working, when none of the TU/DEV are willing/able to continue the development of the alpm backend for packagekit and at some point things break, then it would be a good time to drop those packages from community. I didnt see this message before but wanted to add that I agree. The 0.7x branch of packagekit is still supported upstream so there is no need to hastly drop the packages. Of course thats only my opinion, it's obviously up to you guys as TU's. Regards, -- *Dustin Falgout* Antergos Dev Team E-Mail: dus...@falgout.us mailto:dus...@falgout.us Google/Skype: dustinfalgout IRC Chat: #antergos http://webchat.freenode.net/?channels=antergosuio=d4 http://antergos.com/
Re: [aur-general] TU resignation
2013/12/23 Dustin Falgout dus...@falgout.us: On 12/22/2013 03:15 PM, Ike Devolder wrote: On Sat, Dec 21, 2013 at 08:12:10PM +0100, Balló György wrote: Sad news. You did a great job on maintaining PackageKit's alpm backend in the recent years. Thanks for your work, and good luck! If nobody step up porting the alpm backend to PackageKit version 0.8 (huge work!), I'll drop the following packages from the [community] repository in the next days: - apper - gnome-settings-daemon-updates - gnome-packagekit - packagekit - packagekit-qt2 - python2-packagekit -- György Balló Trusted User Why the rush to drop these packages ? Currently it is working, when none of the TU/DEV are willing/able to continue the development of the alpm backend for packagekit and at some point things break, then it would be a good time to drop those packages from community. I didnt see this message before but wanted to add that I agree. The 0.7x branch of packagekit is still supported upstream so there is no need to hastly drop the packages. Of course thats only my opinion, it's obviously up to you guys as TU's. Regards, -- *Dustin Falgout* Antergos Dev Team E-Mail: dus...@falgout.us mailto:dus...@falgout.us Google/Skype: dustinfalgout IRC Chat: #antergos http://webchat.freenode.net/?channels=antergosuio=d4 http://antergos.com/ Good to hear that you'll work on this, so we can keep the packages. It's an important task, because the latest version of Apper and GNOME Software depend on the 0.8 branch now. Ike, then go ahead, and adopt these packages. -- György Balló Trusted User
Re: [aur-general] TU resignation
On Sun, Dec 22, 2013 at 05:32:19PM -0600, Dustin Falgout wrote: On 12/21/2013 01:12 PM, Balló György wrote: Sad news. You did a great job on maintaining PackageKit's alpm backend in the recent years. Thanks for your work, and good luck! If nobody step up porting the alpm backend to PackageKit version 0.8 (huge work!), I'll drop the following packages from the [community] repository in the next days: - apper - gnome-settings-daemon-updates - gnome-packagekit - packagekit - packagekit-qt2 - python2-packagekit -- György Balló Trusted User Hi guys, I am planning to complete the porting of the alpm backend to packagekit 0.8+ I reached out to Jonathan a few weeks ago and he was very helpful in bring me up to speed on what's left to be done. Sadly, I have not had the time to get it done yet. Things at work are going to slow down a lot for me once the holiday season is over and getting the port finished is definitely high up on my to do list. This thread caught my eye as I was scanning through email so I thought I should take a second to make my plans known :) Happy Holidays! -- *Dustin Falgout* Antergos Dev Team E-Mail: dus...@falgout.us mailto:dus...@falgout.us Google/Skype: dustinfalgout IRC Chat: #antergos http://webchat.freenode.net/?channels=antergosuio=d4 http://antergos.com/ Hi Dustin, Feel free to contact me related to packagekit. Thanks for stepping up to complete the alpm backend for packagekit 0.8+ -- Ike pgpwLRNlolHQJ.pgp Description: PGP signature
Re: [aur-general] TU resignation
Sad news. You did a great job on maintaining PackageKit's alpm backend in the recent years. Thanks for your work, and good luck! If nobody step up porting the alpm backend to PackageKit version 0.8 (huge work!), I'll drop the following packages from the [community] repository in the next days: - apper - gnome-settings-daemon-updates - gnome-packagekit - packagekit - packagekit-qt2 - python2-packagekit -- György Balló Trusted User
[aur-general] TU resignation
Hi everyone, I've been pretty busy lately and haven't been able to find the time to fix bugs and keep my packages up-to-date. Lately I haven't actually been using any of the packages I maintain, so I think the time has come to pass them on to someone with the time and motivation to maintain them. So, without further ado, I hereby tender my resignation as a TU. I wish you all the best and hope you continue doing the things which make Arch so great. Best, Jonathan P.S. I've had trouble getting GPG and gmail to play together, so I've attached the contents of this message and signed that instead of signing the email itself. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I've been pretty busy lately and haven't been able to find the time to fix bugs and keep my packages up-to-date. Lately I haven't actually been using any of the packages I maintain, so I think the time has come to pass them on to someone with the time and motivation to maintain them. So, without further ado, I hereby tender my resignation as a TU. I wish you all the best and hope you continue doing the things which make Arch so great. Best, Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJStKaEAAoJEK9+94c8/Uu26OYIAIlPKg7TbXCLmpFlwgsE3i/h wBCzQnx7MCGNgBAZ3eDdFJR4txhZOtt740aO8O4ZhihUed/YR0lJwb72C6qP4dcf u5OIFFEdHF+iZqJ+34hPD7QkmVJUYxs+f5xeBlK4ETYNo3mtOU/SreyLLj7yviLG jz2e20tFK0sfOyeglKKJpMC8EOzn2ARufLPlZxV8TFUj0pN2uSOoT2Gm6Ifj2KRn SNv3PpZDitRwMfWRbxMOCSvHl8+KAKZwzKloEThSPFAzrjuSWyWb2+poDwE4YcRL McMBEyqC6jQNA0BTpZ6R3XYNbwgwFllkHij+ONKn4xd5R5Nrq7sRYzgGrZNUplA= =dxpV -END PGP SIGNATURE-
Re: [aur-general] TU resignation
Thanks for all you did and all the best for whatever you do now. PS: I've created a ticket for key revocation and disabled the ssh account. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU application - Sponsored by Balló György
2013/12/15 Martin Wimpress martin+a...@flexion.org: Hi, On Wed, 2013-12-11 at 02:16 +0100, Balló György wrote: I'm confirming my sponsorship. I think that the MATE desktop environment will be a great addition for Arch Linux, and Martin will be a great addition for the team. :) A discussion period of 5 days has been started now. I've updated the MATE packages in the AUR and refreshed the builds in the unofficial MATE package repository based on the feedback provided here and comments in the AUR. I've also updated my other non-MATE packages in the AUR based on the feedback I've had from TUs. Is there anything else I should be doing during this discussion period? It's fine. Nothing else needed now. The discussion period is over, and the voting period is started now. Please vote: https://aur.archlinux.org/tu/?id=73 -- György Balló Trusted User
Re: [aur-general] TU application - Sponsored by Balló György
Hi, On Wed, 2013-12-11 at 02:16 +0100, Balló György wrote: I'm confirming my sponsorship. I think that the MATE desktop environment will be a great addition for Arch Linux, and Martin will be a great addition for the team. :) A discussion period of 5 days has been started now. I've updated the MATE packages in the AUR and refreshed the builds in the unofficial MATE package repository based on the feedback provided here and comments in the AUR. I've also updated my other non-MATE packages in the AUR based on the feedback I've had from TUs. Is there anything else I should be doing during this discussion period? -- Regards, Martin. signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU application - Sponsored by Balló György
Hi, Every package I maintain has been updated today taking into to account the feedback that has been provided in this discussion and the feedback Balló has sent to me directly. On Tue, 2013-12-10 at 23:18 +, Martin Wimpress wrote: Your PKGBUILDs look good overall but I noticed two things. The first is the absence of quoted variables (e.g $srcdir), but you mentioned that you wrote a script to generate PKGBUILDs so perhaps that is a single, central fault? Balló has pointed that out too and it will be resolved in the next few days. I've added variable quoting, where appropriate, to all my packages in the AUR including the MATE packages. The second is the absence of prepare functions. There are numerous packages that modify existing source files in the build and/or package functions (e.g. several replace python with python2). All such modifications should be done in a separate prepare function when possible. Also recently pointed out and I have actually started the transition, see the mate-file-archiver PKGBUILD below. prepare() functions have been added, where appropriate, to all my packages in the AUR including the MATE packages. Beyond that there were just a few niggles. For example, I wonder why you check if the CARCH variable is empty in the brother-mfc7360n-lpr package [1]. The arch array restricts available architectures to x86_64 and i686, so the warning doesn't make sense to me. The `brother-mfc7360n-*` packages have been cleaned up. There are also some apparently inherited PKGBUILD issues, e.g. the missing package function in nullmailer [2] but I presume those will be fixed whenever the next update happens. The `nullmailer` package has been updated accordingly. Thank you all for your input. -- Regards, Martin. signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU application - Sponsored by Balló György
Hi Martin, Thanks for applying! I think it's positive that you've got some experience under your belt. The randomly chosen AUR packages you maintain that I inspected looks well crafted, sound and healthy to me. Just from quickly browsing the Arch Installer on github, it looks promising too. I won't ask about vim vs emacs so... what's your favorite git command? -- Best of luck, Alexander Rødseth xyproto / TU
Re: [aur-general] TU application - Sponsored by Balló György
Hi, I am fond of all the `git` commands mentioned in my blog about migrating Bazaar to Git. * http://flexion.org/posts/2012-10-migrating-bzr-to-git.html If I had to pick an absolute favourite `git` command then `git commit` but `git stash` is pretty handy. -- Regards, Martin. On Tue, 2013-12-10 at 22:08 +0100, Alexander Rødseth wrote: Hi Martin, Thanks for applying! I think it's positive that you've got some experience under your belt. The randomly chosen AUR packages you maintain that I inspected looks well crafted, sound and healthy to me. Just from quickly browsing the Arch Installer on github, it looks promising too. I won't ask about vim vs emacs so... what's your favorite git command? signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU application - Sponsored by Balló György
git commit sounds like a fine choice of to me. :) But what's with the top posting? Is it a statement, or due to the choice of email client? I know some mobile email clients makes it hard not to top post. In any case, I think you have a fine application and wish you the best of luck in the rest of the discussion period and in the following vote. - Alexander / xyproto
Re: [aur-general] TU application - Sponsored by Balló György
On 2013-12-10 18:27 + Martin Wimpress wrote: a great application Regards, Martin. Hi, That is a very nice application. It leaves no doubt concerning your skill and dedication (assuming that it's all true... Balló left carrying rubber gloves, so I expect that he was thorough in vetting you). Having someone from upstream maintain the MATE ecosystem would ensure a great user experience, and you are clearly capable of maintaining the packages in a repo. Your PKGBUILDs look good overall but I noticed two things. The first is the absence of quoted variables (e.g $srcdir), but you mentioned that you wrote a script to generate PKGBUILDs so perhaps that is a single, central fault? The second is the absence of prepare functions. There are numerous packages that modify existing source files in the build and/or package functions (e.g. several replace python with python2). All such modifications should be done in a separate prepare function when possible. Beyond that there were just a few niggles. For example, I wonder why you check if the CARCH variable is empty in the brother-mfc7360n-lpr package [1]. The arch array restricts available architectures to x86_64 and i686, so the warning doesn't make sense to me. There are also some apparently inherited PKGBUILD issues, e.g. the missing package function in nullmailer [2] but I presume those will be fixed whenever the next update happens. Regards, Xyne Btw, if anyone is interested, I have added a maintainer option to pbget because I wanted to grep all of the PKGBUILDs (e.g. $ pbget --maintainer flexiondotorg; grep -r --color -C 3 sed). [1] https://aur.archlinux.org/packages/br/brother-mfc7360n-lpr/PKGBUILD [2] https://aur.archlinux.org/packages/nullmailer/
Re: [aur-general] TU application - Sponsored by Balló György
Hi, On Tue, 2013-12-10 at 23:10 +0100, Alexander Rødseth wrote: git commit sounds like a fine choice of to me. :) But what's with the top posting? Is it a statement, or due to the choice of email client? I know some mobile email clients makes it hard not to top post. Not a statement. It was due to the defaults and a new install that hadn't been configured. In any case, I think you have a fine application and wish you the best of luck in the rest of the discussion period and in the following vote. Thanks. -- Regards, Martin. signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU application - Sponsored by Balló György
Hi, On Tue, 2013-12-10 at 22:14 +, Xyne wrote: That is a very nice application. It leaves no doubt concerning your skill and dedication (assuming that it's all true... Balló left carrying rubber gloves, so I expect that he was thorough in vetting you). Having someone from upstream maintain the MATE ecosystem would ensure a great user experience, and you are clearly capable of maintaining the packages in a repo. Thanks for your kind words. If you want to find out if my background is genuine you can ask over at #mate-dev@freenode Balló has also been very helpful over the last week or so. Your PKGBUILDs look good overall but I noticed two things. The first is the absence of quoted variables (e.g $srcdir), but you mentioned that you wrote a script to generate PKGBUILDs so perhaps that is a single, central fault? Balló has pointed that out too and it will be resolved in the next few days. The second is the absence of prepare functions. There are numerous packages that modify existing source files in the build and/or package functions (e.g. several replace python with python2). All such modifications should be done in a separate prepare function when possible. Also recently pointed out and I have actually started the transition, see the mate-file-archiver PKGBUILD below. * https://github.com/mate-desktop/archlinux-packages/blob/master/mate-file-archiver/PKGBUILD The other PKGBUILDs that require prepare() will be updated in the next few days. Beyond that there were just a few niggles. For example, I wonder why you check if the CARCH variable is empty in the brother-mfc7360n-lpr package [1]. The arch array restricts available architectures to x86_64 and i686, so the warning doesn't make sense to me. I based the PKGBUILD on another in the AUR. I needed to get a new printer working for my in-laws (who also run Arch Linux) and only did the bare minimum to get the packages working. I'll clean them up at some point. There are also some apparently inherited PKGBUILD issues, e.g. the missing package function in nullmailer [2] but I presume those will be fixed whenever the next update happens. Partly an inheritance issue and partly that I've learnt a hell of a lot in the past few months sorting out the MATE packages for Arch Linux and haven't applied all I have learnt to the other packages. I'll get the `nullmailer` package sorted ASAP. Thanks for the feedback, it is all very useful. -- Regards, Martin. signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU application - Sponsored by Balló György
2013. 12. 10, kedd keltezéssel 18.27-kor Martin Wimpress ezt írta: Hi, I'd like to submit my application to become a Trusted User. I've been sponsored by Balló György (aka City-busz). You can find my public key here: * http://pool.sks-keyservers.net/pks/lookup?op=getsearch=0x654B877A0864983E I'm a forty something information technology professional and Linux enthusiast. I live in Hampshire, England, with my wife and daughter. I have some grey hair, a beer belly and I'm a killer systems administrator. I'd like to join the team because I'd really like to bring MATE to the official Arch Linux [community] repository. I've been a member of the MATE team for some months now and in that time I've: * Become the principle Arch Linux package maintainer * Got MATE 1.6 stable on Arch Linux * Created a new build script to automate package builds * Created new build hosts to build MATE packages for i686 and x86_64 * Created new build hosts to build MATE packages for armv6h and armv7h * Signed the unofficial MATE package repositories * Been given root shell accounts on all the MATE infrastructure servers * Created a new website for the MATE project (http://mate-desktop.org) * Become a MATE Forum moderator and administrator * Taken ownership of every MATE package in the AUR * Started MATE 1.7 packaging for Arch Linux * Gone on many bug hunting expeditions Here are all the relevant links regarding my work with the MATE team. * http://mate-desktop.org * http://mate-desktop.org/blog/2013-11-16-mate-1.6-packages-for-arch-linux/ * https://github.com/mate-desktop/archlinux-packages * https://github.com/mate-desktop/mate-desktop.org * http://forums.mate-desktop.org/viewforum.php?f=4 * http://wiki.mate-desktop.org/archlinux_custom_repo * http://repo.mate-desktop.org/archlinux/ Here's some additional background about myself. I've been running Linux distributions since 1995, I've transitioned through Slackware, Redhat, Crux, Debian/Ubuntu and settled on Arch Linux nearly 2 years ago. I dev using Shell, Python, PHP, SQL, HTML/CSS and know enough C/C++ to bug hunt. I started using CVS in the late 1990s and moved to Subversion then Bazaar and now Git. Some examples of my personal projects. * https://github.com/flexiondotorg/ArchInstaller * https://github.com/flexiondotorg/oab-java6 * https://github.com/flexiondotorg/nullserv By day I work for Flight Data Services. I'm the technical lead and created the business plan that led to us Open Sourcing most of our technologies. * https://github.com/FlightDataServices * http://www.flightdatacommunity.com/ Most of my contribution to Arch Linux has been through the AUR and you'll find me lurking in #archlinux@freenode. I contributed my first package to the AUR on the first week I started using Arch Linux. Since then I've adopted a few packages and added a selection of my own. * https://aur.archlinux.org/packages/?SeB=mK=flexiondotorg In addition to MATE I'd be interested in migrating some of my other packages to [community], for example: * https://aur.archlinux.org/packages/bzr-fastimport/ * https://aur.archlinux.org/packages/finalterm-git/ (when stable) * https://aur.archlinux.org/packages/lib32-nss-mdns/ * https://aur.archlinux.org/packages/lib32-xulrunner/ * https://aur.archlinux.org/packages/libaacs/ * https://aur.archlinux.org/packages/nullmailer/ I've contributed to countless Open Source projects over the years and I am a member of my local LUG. When I'm not geeking out I play with my daughter and go running. Like all great Open Source contributors I scuba dive ;-) Oh yeah, I love Arch Linux. I'm confirming my sponsorship. I think that the MATE desktop environment will be a great addition for Arch Linux, and Martin will be a great addition for the team. :) A discussion period of 5 days has been started now. -- György Balló Trusted User signature.asc Description: This is a digitally signed message part
Re: [aur-general] [tu-bylaws][PATCH] Voting Period
The proposed changes have been accepted. Final tally: yes: 27 no: 0 abstain: 4
Re: [aur-general] [tu-bylaws] [PATCH 2/2] Add details on patch submissions
On 2013-08-20 18:14 +0200 Lukas Fleischer wrote: +SVP is commenced at the time of the motion, with a discussion period of 5 days, +a quorum of 75%, and a voting period of 7 days. Use the same formulation as the Removal of a TU section: Following the motion, standard voting procedure commences with a discussion period of 5 days, a quorum of 75%, and a voting period of 7 days. You can also replace standard voting procedure with SVP throughout the document after its definition. +be sent inline (i.e. using `git send-email`) so that other TUs can easily I would change i.e. to e.g. as I see no reason to mandate that users actually send the message with git directly (as this requires sendmail configuration, and some users may only have access to webmail). The formatting of the message itself is what matters. To be honest, I don't see the problem with accepting the resulting document either. Copying over a single document is no more work than applying a patch. Perhaps we could also add an additional minor change to this patchset to say that the SVP voting period ends either after the designated time OR after all TUs have voted. With the upcoming changes to the AUR this will be apparent, and the AUR can stop the vote itself an possibly send an email to the list.
Re: [aur-general] [tu-bylaws] [PATCH 2/2] Add details on patch submissions
On Wed, Aug 21, 2013 at 12:07:47PM +, Xyne wrote: On 2013-08-20 18:14 +0200 Lukas Fleischer wrote: +SVP is commenced at the time of the motion, with a discussion period of 5 days, +a quorum of 75%, and a voting period of 7 days. Use the same formulation as the Removal of a TU section: Following the motion, standard voting procedure commences with a discussion period of 5 days, a quorum of 75%, and a voting period of 7 days. You can also replace standard voting procedure with SVP throughout the document after its definition. Note that I did not touch this sentence apart from formatting changes. +be sent inline (i.e. using `git send-email`) so that other TUs can easily I would change i.e. to e.g. as I see no reason to mandate that users actually send the message with git directly (as this requires sendmail configuration, and some users may only have access to webmail). The formatting of the message itself is what matters. Git does not require sendmail. It requires an MTA but something simple and lightweight like msmtp(1) does the job. It takes about 5 minutes to setup. Around 90% of all patches that are sent by Git rookie without using `git send-email` are broken in some way. Most common errors are: * Wrong patch format. Patches created with diff(1) or something else. * Patch is not sent inline. This makes it damn hard to comment on specific parts. * Broken indentation and line wraps. This often happens when patches are sent using webmail. Webmail should never be used to send patches unless you know exactly what you are doing. When applying your patch, I had to export your proposal mail to an mbox file, edit that mbox file and remove the parts that do not belong to the patch, save the resulting file and apply it using `git am`. This is why I came up with this... If there is a generally accepted format which is very convenient, why not use it? Also, the document says should be sent -- not must be sent. Everyone who knows what he/she is doing can send the patch using another tool and hardly anyone will notice. To be honest, I don't see the problem with accepting the resulting document either. Copying over a single document is no more work than applying a patch. 1. Most people want to see a diff. Hardly anyone wants to read the whole document over and over again and scan for minor wording changes every time. Sending a document means that every TU has to clone the tu-bylaws Git repository, save the attachment, copy it to the working directory of the clone and invoke `git diff`. Why? 2. Attaching a document makes it a lot harder to comment on specific parts by using the quote function of the mail client, like you did when replying to my patch :) 3. The committer will have to write a commit message and adjust the author's e-mail address (and maybe also change the author date). Perhaps we could also add an additional minor change to this patchset to say that the SVP voting period ends either after the designated time OR after all TUs have voted. With the upcoming changes to the AUR this will be apparent, and the AUR can stop the vote itself an possibly send an email to the list. Ok, I can add this. But I doubt that there will ever be such a situation. Did we ever have a voting with a participation of 100%? :)
Re: [aur-general] [tu-bylaws] [PATCH 2/2] Add details on patch submissions
On Wed, Aug 21, 2013 at 05:45:50PM +0200, Lukas Fleischer wrote: On Wed, Aug 21, 2013 at 12:07:47PM +, Xyne wrote: On 2013-08-20 18:14 +0200 Lukas Fleischer wrote: +SVP is commenced at the time of the motion, with a discussion period of 5 days, +a quorum of 75%, and a voting period of 7 days. Use the same formulation as the Removal of a TU section: Following the motion, standard voting procedure commences with a discussion period of 5 days, a quorum of 75%, and a voting period of 7 days. You can also replace standard voting procedure with SVP throughout the document after its definition. Note that I did not touch this sentence apart from formatting changes. +be sent inline (i.e. using `git send-email`) so that other TUs can easily I would change i.e. to e.g. as I see no reason to mandate that users actually send the message with git directly (as this requires sendmail configuration, and some users may only have access to webmail). The formatting of the message itself is what matters. Git does not require sendmail. It requires an MTA but something simple and lightweight like msmtp(1) does the job. It takes about 5 minutes to setup. It doesn't even require an MTA. git is able to send directly to an SMTP server via the perl script that manages mail. See the --smtp-* options in 'git-send-email(1)'. Specifically, the --smtp-server option defaults to 'localhost' which means that it defaults to using a locally found MTA. Around 90% of all patches that are sent by Git rookie without using `git send-email` are broken in some way. Most common errors are: * Wrong patch format. Patches created with diff(1) or something else. * Patch is not sent inline. This makes it damn hard to comment on specific parts. * Broken indentation and line wraps. This often happens when patches are sent using webmail. Webmail should never be used to send patches unless you know exactly what you are doing. When applying your patch, I had to export your proposal mail to an mbox file, edit that mbox file and remove the parts that do not belong to the patch, save the resulting file and apply it using `git am`. This is why I came up with this... If there is a generally accepted format which is very convenient, why not use it? Also, the document says should be sent -- not must be sent. Everyone who knows what he/she is doing can send the patch using another tool and hardly anyone will notice. To be honest, I don't see the problem with accepting the resulting document either. Copying over a single document is no more work than applying a patch. 1. Most people want to see a diff. Hardly anyone wants to read the whole document over and over again and scan for minor wording changes every time. Sending a document means that every TU has to clone the tu-bylaws Git repository, save the attachment, copy it to the working directory of the clone and invoke `git diff`. Why? 2. Attaching a document makes it a lot harder to comment on specific parts by using the quote function of the mail client, like you did when replying to my patch :) 3. The committer will have to write a commit message and adjust the author's e-mail address (and maybe also change the author date). Perhaps we could also add an additional minor change to this patchset to say that the SVP voting period ends either after the designated time OR after all TUs have voted. With the upcoming changes to the AUR this will be apparent, and the AUR can stop the vote itself an possibly send an email to the list. Ok, I can add this. But I doubt that there will ever be such a situation. Did we ever have a voting with a participation of 100%? :)
[aur-general] [tu-bylaws] [PATCH 0/2] TU bylaws amendment
Ok, sending this before the voting period for Xyne's proposal is over since it is already clear that it will be accepted. More than 65% of all TUs voted yes and there are zero no votes so far :) The first patch is a follow-up to Xyne's proposal and is something he simply forgot when writing the patch. The second patch adds some information on how to submit patches for TU bylaws amendments. It answers following questions and solves following issues: * Where is the official bylaws Git repository? * Proposals with bad formatting that are hard to comment on. * How to submit formatting changes and actual changes at once without creating messy patches. Let the discussion period begin. Lukas Fleischer (2): Add note on when the number of TUs is recorded Add details on patch submissions tu-bylaws.txt | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) -- 1.8.4.rc3.500.gc3113b0
[aur-general] [tu-bylaws] [PATCH 2/2] Add details on patch submissions
* Mention the tu-bylaws.git repository. * Mention Git-formatted patches and subject keywords. * Promote `git send-email`. * Add note on submitting several patches at once. Signed-off-by: Lukas Fleischer archli...@cryptocrack.de --- tu-bylaws.txt | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/tu-bylaws.txt b/tu-bylaws.txt index 2faecda..c7a376e 100644 --- a/tu-bylaws.txt +++ b/tu-bylaws.txt @@ -165,10 +165,25 @@ These bylaws may be amended at any time. A TU must motion for an amendment by sending an announcement to https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general]. -The message must either contain, or have attached, a patch against this -document which accomplishes the suggested change. SVP is commenced at the time -of the motion, with a discussion period of 5 days, a quorum of 75%, and a -voting period of 7 days. + +The message must either contain, or have attached, a Git-formatted patch +against this document which accomplishes the suggested change. The patch should +be based on the master branch of the official +https://projects.archlinux.org/tu-bylaws.git/[tu-bylaws repository] and should +be sent inline (i.e. using `git send-email`) so that other TUs can easily +comment on specific parts. The strings `[PATCH]` and `[tu-bylaws]` should be +included in the subject. `git send-email --annotate` can be used to edit a +patch before sending it to the mailing list. + +Sending multiple patches is generally discouraged and should only be done if no +more than one of the patches are subject for debate (the remaining patches +might be formatting changes or minor wording changes). If multiple patches are +sent as part of one proposal, a cover letter describing the changes must be +included. The `--cover-letter` option of `git send-email` can be used to +achieve this. + +SVP is commenced at the time of the motion, with a discussion period of 5 days, +a quorum of 75%, and a voting period of 7 days. SVP( amend_bylaws, 5, 0.75, 7); -- 1.8.4.rc3.500.gc3113b0
Re: [aur-general] [tu-bylaws][PATCH] Voting Period
On Thu, Aug 15, 2013 at 03:15:27PM +, Xyne wrote: Hi, The discussion period has ended. Please cast your votes: https://aur.archlinux.org/tu/?id=70 I know that it is a bit late for comments on the proposal but I just noticed that your patch doesn't seem to change the sentence mentioning that TUs are counted at the end of a vote. Is that intentional or did you just miss that? Also, I just wondered whether it is okay to accept a proposal before the voting period ends? Currently, there are 19 yes votes, 37 TUs and there is no way the number of TUs can increase until the end of the proposal. Regards, Xyne
Re: [aur-general] [tu-bylaws][PATCH] Voting Period
On 16.08.2013 11:00, Lukas Fleischer wrote: Also, I just wondered whether it is okay to accept a proposal before the voting period ends? Currently, there are 19 yes votes, 37 TUs and there is no way the number of TUs can increase until the end of the proposal. No, people should be allowed to vote no if they feel the change is wrong just for the sake of letting the others know. (IMHO) I'm not sure if we have any rule about that though. In case you can't find one assume we can't accept it before the end. signature.asc Description: OpenPGP digital signature
Re: [aur-general] [tu-bylaws][PATCH] Voting Period
On 2013-08-16 11:00 +0200 Lukas Fleischer wrote: On Thu, Aug 15, 2013 at 03:15:27PM +, Xyne wrote: Hi, The discussion period has ended. Please cast your votes: https://aur.archlinux.org/tu/?id=70 I know that it is a bit late for comments on the proposal but I just noticed that your patch doesn't seem to change the sentence mentioning that TUs are counted at the end of a vote. Is that intentional or did you just miss that? I did indeed forget to add a statement that TUs should be counted at the beginning of the voting period. I can't find any clause that states the quorum is counted at the end, only participation. I suggest the following additional change, which adds a clause to the SVP section and patches the current Quorum section: Only those TUs who are counted towards quorum may participate in the vote. [[Q]] Quorum -- Quorums ensure that all matters decided by vote are representative of the TU group. All TUs are expected to participate in all votes and the preceding discussions whenever possible. Quorum shall be 66% of all TUs at the start of the voting period and participation shall be measured by the sum of YES, NO and ABSTAIN votes, UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. Given that this was part of the discussion I doubt that anyone who voted yes would object to the changes, but I do not know how to proceed. On 2013-08-16 13:10 +0200 Florian Pritz wrote: On 16.08.2013 11:00, Lukas Fleischer wrote: Also, I just wondered whether it is okay to accept a proposal before the voting period ends? Currently, there are 19 yes votes, 37 TUs and there is no way the number of TUs can increase until the end of the proposal. No, people should be allowed to vote no if they feel the change is wrong just for the sake of letting the others know. (IMHO) I'm not sure if we have any rule about that though. In case you can't find one assume we can't accept it before the end. We have encountered this situation before. The consensus was that it is better to wait and let everyone cast their vote, even if acceptance is guaranteed. By our own bylaws, the votes are tallied at the end of the voting period anyway. Regards, Xyne
Re: [aur-general] [tu-bylaws][PATCH] Voting Period
Hi, The discussion period has ended. Please cast your votes: https://aur.archlinux.org/tu/?id=70 Regards, Xyne
Re: [aur-general] [tu-bylaws][PATCH]
On Sun, Aug 11, 2013 at 10:29:42AM +, Xyne wrote: [...] Patch follows: I put that patch on a separate branch (proposal-70) in the official TU bylaws repository [1], so that it is easier for people to extract the actual commit and review the changes in the way they prefer. I think it is a good idea to include both the discussion and a link to the proposal branch in the AUR proposal description. Xyne, could you please remember this when the voting period starts? I think we should also update the bylaws and complete the Amendment of Bylaws section with instructions on how to submit future proposals. Mention the Git repository, mention `git send-email`. Mention that every proposal will be merged into a separate branch so that TUs can easily review the latest version when voting. I will submit a proposal after the end of the voting period for this one. [1] https://projects.archlinux.org/tu-bylaws.git/?h=proposal-70
Re: [aur-general] [tu-bylaws][PATCH]
Lukas Jirkovsky wrote: I can't obviously comment on grammar as I'm not a native speaker, so I have just a single comment. I think it may be better to split this into two commits, one containing the little changes like referring to trusted users as TUs or explicitly mentioning the aur-general and the other one containing the recently discussed changes regarding the voting procedure and TU removal. I have considered that but at this point it would just require more work for no real benefit. I would prefer to leave the proposal as-is. If it is rejected then I or someone else can extract the linguistic changes. Regards, Xyne
Re: [aur-general] [tu-bylaws][PATCH]
Rashif Ray Rahman wrote: On 9 August 2013 19:29, Xyne x...@archlinux.ca wrote: ... * remove distinction between active and inactive TUs So now what happens when so-called active or inactive TUs do not vote and prevent quorum from being established? No action is taken? I see these changes cover disappearing TUs, but not non-participating TUs. I may also just be missing something. +OR who has not voted in a consecutive series of voting periods, the starting How many consecutive series? The full phrase is who has not voted in a consecutive series of voting periods, the starting dates of which span 2 months or more, shall be brought up for special removal due to inactivity. The sub-clause thus specifies that the length of the series is determined by time, not by number of votes. So, any TU that misses all votes during a period of 2 months falls under the special case for removals. This replaces the old clause specifying 3 votes, as they could easily occur in the same week. Being inactive for a week should not be grounds for special removal. Remember though, this is just for invocation of the special case. If any TU notices that any other TU habitually misses votes then we can start a discussion about it and motion for that TU's removal if deemed appropriate. The other thread contained a suggestion for a TU status page that would show vote participation over some fixed period of time to facilitate the determination of participation. The current by-laws try to automate a process that requires human discretion. This version retains automation for extreme cases and relies on human discretion for the rest. In either case, someone still has to monitor activity of other TUs to determine if there are grounds for removal, but this way will avoid silly edge cases. It is our responsibility to keep an eye on each other, rather than simply induct new TUs and then forget about them until some special case occurs. +A motion must be made by at least two TUs for the removal of a +TU. The motion must be sent to -removal of a +removal of another There is no reason to prevent a TU from motioning for his own removal, even if it would be silly to do so. I have reworded the clause in a more natural way: +A motion for the removal of a TU must be made by at least 2 TUs. The motion must +be sent to Patch follows: From abf7664c2b8c99a2e14b8aff8e37b727fdce7d9b Mon Sep 17 00:00:00 2001 From: Xyne x...@archlinux.ca Date: Wed, 7 Aug 2013 13:55:37 + Subject: [PATCH] Following discussion on aur-general (https://mailman.archlinux.org/pipermail/aur-general/2013-August/024745.html): * remove distinction between active and inactive TUs * update all clauses affected by this change, most importantly the definition of quorum * update conditions for special removal of a TU * use abbreviations consistently through the document * add missing links to instances of aur-general * various changes to correct or improve English throughout the document --- tu-bylaws.txt | 139 ++ 1 file changed, 61 insertions(+), 78 deletions(-) diff --git a/tu-bylaws.txt b/tu-bylaws.txt index 991d683..4e8c5e2 100644 --- a/tu-bylaws.txt +++ b/tu-bylaws.txt @@ -1,7 +1,7 @@ Trusted User Bylaws === Trusted Users aur-general@archlinux.org -1.2, 18 January 2011 +1.3, 2013-08-07 Summary --- @@ -12,7 +12,7 @@ duties. Mission --- -The Trusted Users serve the following purposes: +The Trusted Users (TUs) serve the following purposes: 1. Maintain +[community]+ as an intermediary between Archlinux's official repositories and the +unsupported+ package collection in the AUR. @@ -22,10 +22,10 @@ repositories and the +unsupported+ package collection in the AUR. Bylaws -- -The bylaws are written to be consistent with the mission of the Trusted Users, -and to ensure that Trusted Users continue to be *Trusted* in the future. They -are also written with the intent to keep the Trusted User organization a -thriving one, fulfilling their purpose. +The bylaws are written to be consistent with the mission of the TUs, +and to ensure that TUs continue to be *Trusted* in the future. They +are also written with the intent to keep the TU organization a +thriving one, fulfilling its purpose. Standard Voting Procedure - @@ -35,31 +35,28 @@ accept or reject proposals regarding TU affairs. SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on -the aur-general mailing list (aur-general). The proposal must also be worded -unambiguously, and such that a YES or NO answer may be given. +the https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general +mailing list] (aur-general). The proposal must also be worded unambiguously, +such that a YES or NO answer may be given. -The discussion period begins when the proposal is
Re: [aur-general] [tu-bylaws][PATCH]
On 11 August 2013 18:29, Xyne x...@archlinux.ca wrote: The current by-laws try to automate a process that requires human discretion. This version retains automation for extreme cases and relies on human discretion for the rest. Alright, this justifies those changes. Good to go on the rest, AFAICS. -- GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws][PATCH]
On 9 August 2013 13:29, Xyne x...@archlinux.ca wrote: Hi, Here's a patch for the TU-bylaws that resulted from discussion in the previous thread: I can't obviously comment on grammar as I'm not a native speaker, so I have just a single comment. I think it may be better to split this into two commits, one containing the little changes like referring to trusted users as TUs or explicitly mentioning the aur-general and the other one containing the recently discussed changes regarding the voting procedure and TU removal. Lukas
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
Xyne wrote: done In case anyone is wondering, the message seems to still be awaiting moderation. I had attached the resulting docs for those who like to read plaintext. My system reported them as under 40k so I thought it would go through, but the encoding bumped it up to 42k. Sorry for the delay.
[aur-general] [tu-bylaws][PATCH]
Hi, Here's a patch for the TU-bylaws that resulted from discussion in the previous thread: https://mailman.archlinux.org/pipermail/aur-general/2013-August/024745.html I hope this is in the correct format. I haven't used git send-email because I still haven't configured it and didn't want to risk doing something stupid in a hurry. For those of you who prefer reading the resulting document, I have attached the source file and the generated HTML file. Please read through the previous thread for an explanation of the changes. Let the discussion period begin! From 8328526fc0fef469d9edb1abf0f0448c2f440e90 Mon Sep 17 00:00:00 2001 From: Xyne x...@archlinux.ca Date: Wed, 7 Aug 2013 13:55:37 + Subject: [PATCH] Following discussion on aur-general (https://mailman.archlinux.org/pipermail/aur-general/2013-August/024745.html): * remove distinction between active and inactive TUs * update all clauses affected by this change, most importantly the definition of quorum * update conditions for special removal of a TU * use abbreviations consistently through the document * add missing links to instances of aur-general * various changes to correct or improve English throughout the document --- tu-bylaws.txt | 122 -- 1 file changed, 50 insertions(+), 72 deletions(-) diff --git a/tu-bylaws.txt b/tu-bylaws.txt index 991d683..4c0699b 100644 --- a/tu-bylaws.txt +++ b/tu-bylaws.txt @@ -1,7 +1,7 @@ Trusted User Bylaws === Trusted Users aur-general@archlinux.org -1.2, 18 January 2011 +1.3, 2013-08-07 Summary --- @@ -12,7 +12,7 @@ duties. Mission --- -The Trusted Users serve the following purposes: +The Trusted Users (TUs) serve the following purposes: 1. Maintain +[community]+ as an intermediary between Archlinux's official repositories and the +unsupported+ package collection in the AUR. @@ -22,10 +22,10 @@ repositories and the +unsupported+ package collection in the AUR. Bylaws -- -The bylaws are written to be consistent with the mission of the Trusted Users, -and to ensure that Trusted Users continue to be *Trusted* in the future. They -are also written with the intent to keep the Trusted User organization a -thriving one, fulfilling their purpose. +The bylaws are written to be consistent with the mission of the TUs, +and to ensure that TUs continue to be *Trusted* in the future. They +are also written with the intent to keep the TU organization a +thriving one, fulfilling its purpose. Standard Voting Procedure - @@ -35,31 +35,23 @@ accept or reject proposals regarding TU affairs. SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on -the aur-general mailing list (aur-general). The proposal must also be worded +the https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general mailing list] (aur-general). The proposal must also be worded unambiguously, and such that a YES or NO answer may be given. -The discussion period begins when the proposal is posted on aur-general. The +The discussion period begins when the proposal is posted on https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general]. The duration of the discussion period shall be 5 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. Official discussion -shall take place on aur-general. During the discussion period, votes shall not +shall take place on https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general]. During the discussion period, votes shall not be cast. The voting period begins when the discussion period ends. The duration of the voting period shall be 7 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. During the voting period, TUs may vote YES, -NO or ABSTAIN. Votes shall be cast under the Trusted User section of the AUR -homepage. At the end of the voting period, all votes shall be tallied. - -In the context of SVP, TUs are considered active if they are marked as active -when the voting period ends. - -Quorum shall be 66% of all active TUs and participation shall be measured by -the sum of YES, NO and ABSTAIN votes, UNLESS otherwise stated in a section of -the bylaws pertaining to the proposal. +NO or ABSTAIN. Votes shall be cast under the Trusted User section of the https://aur.archlinux.org/[AUR website]. At the end of the voting period, all votes shall be tallied. The proposal is accepted if EITHER -1. the number of YES votes is greater than half the number of active TUs OR +1. the number of YES votes is greater than half the number of TUs OR 2. quorum has been established and the number of YES votes is greater than the number of NO votes @@ -68,8 +60,7 @@ UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is rejected if EITHER -1. the number
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On 08/10/2013 09:15 AM, Xyne wrote: In case anyone is wondering, the message seems to still be awaiting moderation. This list is not activly moderated afaik. I'm just letting through your messages whenever you post about them so this discussion can go on. I'm not going to do any more moderation apart from that. signature.asc Description: OpenPGP digital signature
Re: [aur-general] [tu-bylaws][PATCH]
On 9 August 2013 19:29, Xyne x...@archlinux.ca wrote: ... * remove distinction between active and inactive TUs So now what happens when so-called active or inactive TUs do not vote and prevent quorum from being established? No action is taken? I see these changes cover disappearing TUs, but not non-participating TUs. I may also just be missing something. ... * various changes to correct or improve English throughout the document While you're at it: ... mailing list] (aur-general). The proposal must also be worded unambiguously, and such that a YES or NO answer may be given. -and such that +such that ... 2. quorum was established and the number of NO votes is greater than or equal to the number of YES votes -quorum was established +quorum has been established ... +Quorums were established to ensure that all matters decided by vote are +representative of the TU group. All TUs are expected to participate in all The terms quorum and established are already used in the document with a different meaning, so different wording could be used here, e.g.: +Quorums ensure that matters decided by vote are +representative of the voters as a group. All TUs are expected to participate in all +A motion must be made by at least two TUs for the removal of a +TU. The motion must be sent to -removal of a +removal of another https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general], and contain a detailed and valid reason that the TU in question should be removed. -that the +why the +OR who has not voted in a consecutive series of voting periods, the starting How many consecutive series? +is followed by a discussion period of three days, a quorum of 66%, and a voting -three days +3 days -- GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On Thu, Aug 08, 2013 at 02:16:56PM +, Xyne wrote: Lukas Fleischer wrote: Ok. The first idea is simple to implement: When a new proposal (the proposal type doesn't really matter) is created, generate a list of current TUs and save it. If an applicant/TU is added to the proposal, this user will be excluded from the list. Only users in that list are allowed to vote. By added to the proposal, do you mean accepted as a TU? added to the proposal as in adding a user to the Applicant/TU field on the Add Proposal page. For the second idea, we would need to store every participant's vote. This has the downside that an AUR administrator could theoretically peek into the ballot box. Are those restrictions really necessary? What would be the downside of just allowing everyone with TUs powers (except the applicant/TU) to vote? If a TU resignes after the vote starts then the TU is still counted towards quorum, and quorum may fail if the TU doesn't vote. We can always encourage TUs to vote before they resign, but in general I do not think that the future of any organization should be determined by outgoing members on their way out the door. This is not an important issue for me. I also agree that it is better not to associate votes with TUs, but I do not expect that to be an issue if it is only for the duration of the vote. An AUR admin who wants to peek would modify the code if he really wanted. Ok, agreed. What does this mean in practice? :) Let's say that the discussion period for a TU application begins and the vote is scheduled to start on Monday. A motion is made for the removal of a TU during this period and the vote should normally start on Tuesday. I think the application vote should be suspended until the removal vote is finished. It affects quorum and the outcome of the vote. If two removal votes are scheduled then they occur in the usual order. Sounds good. I think that this is something that doesn't need to be implemented in the AUR, though. Just a guideline for people adding proposals. [...] I think that's it. I have attached up updated version of my previous submission. Take a look and let me know what you think. +1 from me. I think you should start a new proposal. Please send this as an inline patch, adding [tu-bylaws] to the subject line -- like I did. People usually do not want to re-read the whole bylaws and exporting the attached file just to create a diff is unnecessary work. Also, sending an inline patch allows people for replying and adding comments to specific sections of the patch. Sending the proposal as an inline patch can be easily done using $ git send-email --annotate HEAD^ after committing the changes and adding a short commit message that summarize the changes. Thanks! [...]
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On 2013-08-09 10:26 +0200 Lukas Fleischer wrote: +1 from me. I think you should start a new proposal. Please send this as an inline patch, adding [tu-bylaws] to the subject line -- like I did. People usually do not want to re-read the whole bylaws and exporting the attached file just to create a diff is unnecessary work. Also, sending an inline patch allows people for replying and adding comments to specific sections of the patch. Sending the proposal as an inline patch can be easily done using $ git send-email --annotate HEAD^ after committing the changes and adding a short commit message that summarize the changes. Thanks! done
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On Wed, Aug 07, 2013 at 06:50:36PM +, Xyne wrote: [...] The distinction between active and inactive TUs is meaningless and should be removed from the bylaws, including the definition of quorum. Quorum will therefore be some fixed percent of all TUs. As stated in this thread, up to 1 in 3 can skip the vote, and omitting inactive TUs defeats the purpose of quorum. There will therefore be no need for an active flag on TU user accounts on the AUR. +1. I still like my own suggestion for amending the removal section to add the special case for TUs who have not touched [community], AUR or the mailing list in 2 months. I believe that accomplishes the real goals of the current clauses regarding unannounced inactivity and quorum blocking. All other cases in which a TU is perceived to be avoiding his or her duties can be handled by the standard removal procedure. +1. However, I would like to retain the repeated quorum offense condition. If there are a couple of TUs that work on the AUR (as in uploading, updating and deleting packages) and do not participate in SVPs, they might block decisions. I think that it is important to make sure every TU votes, especially when the new quorum comes into effect. Maybe we should also start a removal procedure (due to undeclared inactivity) if someone didn't participate in any of the latest SVPs, where the start time of the first SVP and the start time of the last SVP differ by more than two months. This could be auto-detected by the AUR. With the removal of the distinction between active and inactive, I also like the idea of establishing quorum when the vote is opened. TUs who are added during the voting period (due to a parallel vote) will not be allowed to participate in the ongoing vote. Ok, agreed. However, TU removals and resignations must be addressed. TUs who are up for removal must not be allowed to vote on their own removal, and maybe not on other votes either. TUs who resign (before the vote ends) should be removed from the quorum calculation. If they have voted, their vote should also be removed. For the former, a removal vote type that bars the removal candidate from voting and quorum calculations should be easy enough to implement. For resignations, a hook would be needed when a TU account is reset to a normal user account. The hook would simply check ongoing votes, remove the TU from the quorum list, and remove the vote if one has been cast. I don't know if the vote itself is stored in the table though, so that might require more work. If it has to be implemented, I would like it to be temporary. When the vote ends, the association of participants to their votes should be removed, an only the list of participants and the final tally should be retained. Ok. The first idea is simple to implement: When a new proposal (the proposal type doesn't really matter) is created, generate a list of current TUs and save it. If an applicant/TU is added to the proposal, this user will be excluded from the list. Only users in that list are allowed to vote. For the second idea, we would need to store every participant's vote. This has the downside that an AUR administrator could theoretically peek into the ballot box. Are those restrictions really necessary? What would be the downside of just allowing everyone with TUs powers (except the applicant/TU) to vote? Some thought must be given to whether TUs who are up for removal may participate in other votes. With the current bylaws, any 2 TUs can remove all other TUs by motioning for their removal. Only those 2 TUs would be able to vote so they would be able to pass all the motions with 100% participation and 100% yes votes. It might be enough to modify the voting restriction to forbid a TU from voting on his or her own removal only. Perhaps we could even add some clause that suspends other votes until the removal vote has passed. For the bylaws that would require the addition of a clause to the SVP section. Programmatically, all new vote proposals would be blocked if a removal vote is running. I don't think this is needed. As you said before, restricting the TU from voting on his or her own removal is enough. I don't think we should make this overly complicated unless a simple solution has any real disadvantages. The clause should probably also specify that removal votes take precedence over any other pending votes except removal votes. What does this mean in practice? :) Regards, Xyne Thank for for coming up with this. I like most of the suggestions. To sum up, a patch to the bylaws would (assumed that we decide for the simple voting restriction approach): * Change the notion of inactivity to what you suggested above. * Change the automated removal condition to inactivity for 2 months. * Make the quorum a fixed percentage of all TUs. * Exclude a TU from votes affecting himself. Am I right? Did I miss anything? p.s. you can stop CC'ing
Re: [aur-general] TU application
On Sat, Jul 27, 2013 at 09:33:34AM +0200, Ralf Mardorf wrote: [...] It's a German idiom. http://www.dict.cc/?s=nicht+so+hei%C3%9F+gegessen A recent research I made on this topic made it pretty clear to me that the German idiom is a well-integrated Hungarian import. cheers! mar77i
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
Lukas Fleischer wrote: +1. However, I would like to retain the repeated quorum offense condition. If there are a couple of TUs that work on the AUR (as in uploading, updating and deleting packages) and do not participate in SVPs, they might block decisions. I think that it is important to make sure every TU votes, especially when the new quorum comes into effect. Maybe we should also start a removal procedure (due to undeclared inactivity) if someone didn't participate in any of the latest SVPs, where the start time of the first SVP and the start time of the last SVP differ by more than two months. This could be auto-detected by the AUR. At first I didn't like this idea, but the more I think about it the more it seems to be the best solution. As long as it is done by the span of time rather than the number of votes, I think it is fair, so +1 for me. Otherwise, if we wish to stick to standard removals, we could create a page that lists all TUs who have missed one or more votes, starting from the most recent, e.g. Foo has missed 2 votes: StartEnd -mm-dd - -mm-dd -mm-dd - -mm-dd That would make it readily apparent to a human who has been skipping votes. With the removal of the distinction between active and inactive, I also like the idea of establishing quorum when the vote is opened. TUs who are added during the voting period (due to a parallel vote) will not be allowed to participate in the ongoing vote. However, TU removals and resignations must be addressed. TUs who are up for removal must not be allowed to vote on their own removal, and maybe not on other votes either. TUs who resign (before the vote ends) should be removed from the quorum calculation. If they have voted, their vote should also be removed. For the former, a removal vote type that bars the removal candidate from voting and quorum calculations should be easy enough to implement. For resignations, a hook would be needed when a TU account is reset to a normal user account. The hook would simply check ongoing votes, remove the TU from the quorum list, and remove the vote if one has been cast. I don't know if the vote itself is stored in the table though, so that might require more work. If it has to be implemented, I would like it to be temporary. When the vote ends, the association of participants to their votes should be removed, an only the list of participants and the final tally should be retained. Ok. The first idea is simple to implement: When a new proposal (the proposal type doesn't really matter) is created, generate a list of current TUs and save it. If an applicant/TU is added to the proposal, this user will be excluded from the list. Only users in that list are allowed to vote. By added to the proposal, do you mean accepted as a TU? For the second idea, we would need to store every participant's vote. This has the downside that an AUR administrator could theoretically peek into the ballot box. Are those restrictions really necessary? What would be the downside of just allowing everyone with TUs powers (except the applicant/TU) to vote? If a TU resignes after the vote starts then the TU is still counted towards quorum, and quorum may fail if the TU doesn't vote. We can always encourage TUs to vote before they resign, but in general I do not think that the future of any organization should be determined by outgoing members on their way out the door. This is not an important issue for me. I also agree that it is better not to associate votes with TUs, but I do not expect that to be an issue if it is only for the duration of the vote. An AUR admin who wants to peek would modify the code if he really wanted. Some thought must be given to whether TUs who are up for removal may participate in other votes. With the current bylaws, any 2 TUs can remove all other TUs by motioning for their removal. Only those 2 TUs would be able to vote so they would be able to pass all the motions with 100% participation and 100% yes votes. It might be enough to modify the voting restriction to forbid a TU from voting on his or her own removal only. Perhaps we could even add some clause that suspends other votes until the removal vote has passed. For the bylaws that would require the addition of a clause to the SVP section. Programmatically, all new vote proposals would be blocked if a removal vote is running. I don't think this is needed. As you said before, restricting the TU from voting on his or her own removal is enough. I don't think we should make this overly complicated unless a simple solution has any real disadvantages. Agreed. The clause should probably also specify that removal votes take precedence over any other pending votes except removal votes. What does this mean in practice? :) Let's say that the discussion period for a TU application begins and the vote is scheduled to start on Monday. A motion is made for the removal of a TU
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
Xyne wrote: Lukas Fleischer wrote: The clause should probably also specify that removal votes take precedence over any other pending votes except removal votes. What does this mean in practice? :) Let's say that the discussion period for a TU application begins and the vote is scheduled to start on Monday. A motion is made for the removal of a TU during this period and the vote should normally start on Tuesday. I think the application vote should be suspended until the removal vote is finished. It affects quorum and the outcome of the vote. If two removal votes are scheduled then they occur in the usual order. I think that's it. I have attached up updated version of my previous submission. Take a look and let me know what you think. That version does not include any mention of removal votes preceding other votes.
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On Wed, Aug 7, 2013 at 12:06 AM, Lukas Fleischer archli...@cryptocrack.de wrote: On Wed, Aug 07, 2013 at 04:54:41AM +0800, Rashif Ray Rahman wrote: On 6 August 2013 20:19, Lukas Fleischer archli...@cryptocrack.de wrote: On Tue, Aug 06, 2013 at 01:12:32PM +0200, Sébastien Luttringer wrote: On Tue, Aug 6, 2013 at 11:45 AM, Lukas Fleischer archli...@cryptocrack.de wrote: On Tue, Aug 06, 2013 at 08:24:20AM +0800, Rashif Ray Rahman wrote: On 6 August 2013 05:53, Lukas Fleischer archli...@cryptocrack.de wrote: The total number of TUs isn't fixed. It changes from time to time and it might change during a SVP. I agree that it is a rare case but why not find a proper way to handle that while we're talking about it... I do support finding a proper way to have this case handled. Between the 4 proposals, I see the 3rd as the best. Although, the discussion is public and everybody can argue, the number of voters should be finite and known at the beginning. It also simplify the vote, by having a list of allowed voters. Reading again the bylaws, I feel that we miss an important point. The SVP starts when the proposal is sent to aur-general. So to continue on the idea of the point 3, should we consider the begging of the SVP (and choosing the allowed voters) at this time or when the vote is registered in AUR? Maybe we can automate the mail sending when creating the proposal? This would enforce all deadlines and respect of the discuss and voting time. I think we need more opinions. Xyne? Anyway, if anyone's looking for some bylaw amendment history: https://mailman.archlinux.org/pipermail/aur-general/2007-December/000127.html https://mailman.archlinux.org/pipermail/aur-general/2010-December/012196.html https://mailman.archlinux.org/pipermail/aur-general/2010-December/012534.html [...] Thanks for the references. The last one is an advanced hijack of the quorum. The question we have to answer is : How many TU are necessary to have a motion pass. Set the quorum to this value and _stop_ cheating by : - creating more valid voters than others (the active) - find ways to ignore the quorum is not reach (so the vote has no meaning) Cheers, -- Sébastien Seblu Luttringer https://www.seblu.net GPG: 0x2072D77A
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
Sébastien Luttringer wrote: The question we have to answer is : How many TU are necessary to have a motion pass. Set the quorum to this value and _stop_ cheating by : - creating more valid voters than others (the active) - find ways to ignore the quorum is not reach (so the vote has no meaning) Cheers, Hi, Sorry for starting a new thread with my own proposal. I wrote it before reading through the rest of my inbox. Now that I have, I'll summarize my own suggestions, which have changed since reading through this thread, and which re-iterate the general consensus that you are already approaching. The distinction between active and inactive TUs is meaningless and should be removed from the bylaws, including the definition of quorum. Quorum will therefore be some fixed percent of all TUs. As stated in this thread, up to 1 in 3 can skip the vote, and omitting inactive TUs defeats the purpose of quorum. There will therefore be no need for an active flag on TU user accounts on the AUR. I still like my own suggestion for amending the removal section to add the special case for TUs who have not touched [community], AUR or the mailing list in 2 months. I believe that accomplishes the real goals of the current clauses regarding unannounced inactivity and quorum blocking. All other cases in which a TU is perceived to be avoiding his or her duties can be handled by the standard removal procedure. With the removal of the distinction between active and inactive, I also like the idea of establishing quorum when the vote is opened. TUs who are added during the voting period (due to a parallel vote) will not be allowed to participate in the ongoing vote. However, TU removals and resignations must be addressed. TUs who are up for removal must not be allowed to vote on their own removal, and maybe not on other votes either. TUs who resign (before the vote ends) should be removed from the quorum calculation. If they have voted, their vote should also be removed. For the former, a removal vote type that bars the removal candidate from voting and quorum calculations should be easy enough to implement. For resignations, a hook would be needed when a TU account is reset to a normal user account. The hook would simply check ongoing votes, remove the TU from the quorum list, and remove the vote if one has been cast. I don't know if the vote itself is stored in the table though, so that might require more work. If it has to be implemented, I would like it to be temporary. When the vote ends, the association of participants to their votes should be removed, an only the list of participants and the final tally should be retained. Some thought must be given to whether TUs who are up for removal may participate in other votes. With the current bylaws, any 2 TUs can remove all other TUs by motioning for their removal. Only those 2 TUs would be able to vote so they would be able to pass all the motions with 100% participation and 100% yes votes. It might be enough to modify the voting restriction to forbid a TU from voting on his or her own removal only. Perhaps we could even add some clause that suspends other votes until the removal vote has passed. For the bylaws that would require the addition of a clause to the SVP section. Programmatically, all new vote proposals would be blocked if a removal vote is running. The clause should probably also specify that removal votes take precedence over any other pending votes except removal votes. Regards, Xyne p.s. you can stop CC'ing me now ;)
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On Tue, Aug 06, 2013 at 08:24:20AM +0800, Rashif Ray Rahman wrote: On 6 August 2013 05:53, Lukas Fleischer archli...@cryptocrack.de wrote: Instead of counting the number of active TUs when a vote begins, update the number whenever a TU becomes active/inactive during a voting period. What happens when a TU becomes inactive after casting a vote? Would her vote be invalidated? If so, no change is needed to the bylaws. I think we shouldn't invalidate such votes. Everyone who is active and becomes inactive (or inactive and becomes active) during the voting period has to login into the AUR, click on a link in the navigation bar, uncheck a checkbox and click on a button. I don't see why they shouldn't be able to click another two links and another button :) Otherwise, another line of explanation would help prevent ambiguity... In the context of SVP, TUs are considered active if they are marked as active -when the voting period ends. +at some point in time during the voting period. In the context of SVP, TUs are considered active if they are marked as active -when the voting period ends. +at any point during the voting period. TUs who become inactive during the +voting period are not considered inactive until the end of the running SVP. Sounds good to me. Any other opinions? -- GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On Tue, Aug 6, 2013 at 11:45 AM, Lukas Fleischer archli...@cryptocrack.de wrote: On Tue, Aug 06, 2013 at 08:24:20AM +0800, Rashif Ray Rahman wrote: On 6 August 2013 05:53, Lukas Fleischer archli...@cryptocrack.de wrote: Any other opinions? Yes, we should drop completely the active statement. This will simplify computation and restore the purpose of the quorum! requirement for a quorum is protection against totally unrepresentative action in the name of the body by an unduly small number of persons. (c) Wikipedia If you think the quorum is too high, it's better to reduce it (or remove it). Currently it's 66%, that means 33% of voters can be in holidays, in hospital, in travels and don't have in a 2 weeks time frame a way to read some mails and vote. In absolute it means : 12 TUs on 36 doesn't have time to vote. So, to take a decision we need at least 13 voters ((36-12)/2+1) on 36 TUs. That means we need a bit more than 33% of the total TUs to have a motion pass. I'm not sure it's necessary to change this. What you suggest is automatic hijacking of the quorum, in purpose to reducing the number of voters. With the new system, we can have a motion pass with 1 voters if every TU goes a the next fosdem :) Cheers, -- Sébastien Seblu Luttringer https://www.seblu.net GPG: 0x2072D77A
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On Tue, Aug 06, 2013 at 01:12:32PM +0200, Sébastien Luttringer wrote: On Tue, Aug 6, 2013 at 11:45 AM, Lukas Fleischer archli...@cryptocrack.de wrote: On Tue, Aug 06, 2013 at 08:24:20AM +0800, Rashif Ray Rahman wrote: On 6 August 2013 05:53, Lukas Fleischer archli...@cryptocrack.de wrote: Any other opinions? Yes, we should drop completely the active statement. This will simplify computation and restore the purpose of the quorum! requirement for a quorum is protection against totally unrepresentative action in the name of the body by an unduly small number of persons. (c) Wikipedia If you think the quorum is too high, it's better to reduce it (or remove it). Currently it's 66%, that means 33% of voters can be in holidays, in hospital, in travels and don't have in a 2 weeks time frame a way to read some mails and vote. In absolute it means : 12 TUs on 36 doesn't have time to vote. So, to take a decision we need at least 13 voters ((36-12)/2+1) on 36 TUs. That means we need a bit more than 33% of the total TUs to have a motion pass. I'm not sure it's necessary to change this. What you suggest is automatic hijacking of the quorum, in purpose to reducing the number of voters. With the new system, we can have a motion pass with 1 voters if every TU goes a the next fosdem :) I didn't think of it like that but I tend to agree now... Does anybody disagree? Anyway, we still need to find a way to count the total number of TUs. That number needs to be recorded at some point of time during the vote. Options: * Record at the beginning, do not update if new TUs appear. * Record at the beginning, fix if TUs are added/removed during the SVP. * Record at the beginning, exclude new TUs from running votes. * Record at the end. The first and last option might yield bogus results. If there this one TU when the SVP starts and another one is added during the SVP, there might be a quorum of 2 / 1 = 200%. Same if the number is recorded at the end and a TU is removed during the SVP. The second option means that we record the total number of users that have had TU status at some point of time during the voting period. What do you think? Cheers, -- Sébastien Seblu Luttringer https://www.seblu.net GPG: 0x2072D77A
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On 6 August 2013 20:19, Lukas Fleischer archli...@cryptocrack.de wrote: On Tue, Aug 06, 2013 at 01:12:32PM +0200, Sébastien Luttringer wrote: On Tue, Aug 6, 2013 at 11:45 AM, Lukas Fleischer archli...@cryptocrack.de wrote: On Tue, Aug 06, 2013 at 08:24:20AM +0800, Rashif Ray Rahman wrote: On 6 August 2013 05:53, Lukas Fleischer archli...@cryptocrack.de wrote: Any other opinions? Yes, we should drop completely the active statement. This requires a separate proposal. This will simplify computation and restore the purpose of the quorum! requirement for a quorum is protection against totally unrepresentative action in the name of the body by an unduly small number of persons. (c) Wikipedia If you think the quorum is too high, it's better to reduce it (or remove it). Currently it's 66%, that means 33% of voters can be in holidays, in hospital, in travels and don't have in a 2 weeks time frame a way to read some mails and vote. In absolute it means : 12 TUs on 36 doesn't have time to vote. So, to take a decision we need at least 13 voters ((36-12)/2+1) on 36 TUs. That means we need a bit more than 33% of the total TUs to have a motion pass. I'm not sure it's necessary to change this. What you suggest is automatic hijacking of the quorum, in purpose to reducing the number of voters. With the new system, we can have a motion pass with 1 voters if every TU goes a the next fosdem :) I didn't think of it like that but I tend to agree now... Does anybody disagree? +0 The hypothetical one-TU-rules-all case has been brought up before, but I can't cite any discussion or conclusion. Anyway, we still need to find a way to count the total number of TUs. That number needs to be recorded at some point of time during the vote. The total number of TUs is a recorded statistic in the AUR, AFAICS. Or are you referring to something else? Options: * Record at the beginning, do not update if new TUs appear. * Record at the beginning, fix if TUs are added/removed during the SVP. * Record at the beginning, exclude new TUs from running votes. * Record at the end. The first and last option might yield bogus results. If there this one TU when the SVP starts and another one is added during the SVP, there might be a quorum of 2 / 1 = 200%. Same if the number is recorded at the end and a TU is removed during the SVP. The second option means that we record the total number of users that have had TU status at some point of time during the voting period. By new and added, do you mean newly appointed, or newly active? This is an important distinction. If we're still talking about active/inactive and this proposal: * Record active at start, add newly active, ignore newly inactive, ignore newly added, ignore newly removed What do you think? I think we need more opinions. Xyne? Anyway, if anyone's looking for some bylaw amendment history: https://mailman.archlinux.org/pipermail/aur-general/2007-December/000127.html https://mailman.archlinux.org/pipermail/aur-general/2010-December/012196.html https://mailman.archlinux.org/pipermail/aur-general/2010-December/012534.html Cheers, -- Sébastien Seblu Luttringer https://www.seblu.net GPG: 0x2072D77A -- GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On 7 August 2013 04:54, Rashif Ray Rahman sc...@archlinux.org wrote: I think we need more opinions. Xyne? Anyway, if anyone's looking for some bylaw amendment history: https://mailman.archlinux.org/pipermail/aur-general/2007-December/000127.html https://mailman.archlinux.org/pipermail/aur-general/2010-December/012196.html https://mailman.archlinux.org/pipermail/aur-general/2010-December/012534.html Sorry, this was somewhat off-topic to the discussion, in reference to Seblu's suggestion to drop the term 'active'. -- GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On Wed, Aug 07, 2013 at 04:54:41AM +0800, Rashif Ray Rahman wrote: On 6 August 2013 20:19, Lukas Fleischer archli...@cryptocrack.de wrote: On Tue, Aug 06, 2013 at 01:12:32PM +0200, Sébastien Luttringer wrote: On Tue, Aug 6, 2013 at 11:45 AM, Lukas Fleischer archli...@cryptocrack.de wrote: On Tue, Aug 06, 2013 at 08:24:20AM +0800, Rashif Ray Rahman wrote: On 6 August 2013 05:53, Lukas Fleischer archli...@cryptocrack.de wrote: Any other opinions? Yes, we should drop completely the active statement. This requires a separate proposal. Of course. We are just trying to make sure nobody raises immediate objections before submitting a new patch and restarting the whole discussion process. I will resubmit a new proposal tomorrow. [...] I didn't think of it like that but I tend to agree now... Does anybody disagree? +0 The hypothetical one-TU-rules-all case has been brought up before, but I can't cite any discussion or conclusion. It is not just the one-TU-rules-all case. As Sébastien already mentioned, establishing a quorum means that the result is representative among all eligible voters. It doesn't just mean that enough TUs who happen to be online at the right time care. Anyway, we still need to find a way to count the total number of TUs. That number needs to be recorded at some point of time during the vote. The total number of TUs is a recorded statistic in the AUR, AFAICS. Or are you referring to something else? The total number of TUs isn't fixed. It changes from time to time and it might change during a SVP. I agree that it is a rare case but why not find a proper way to handle that while we're talking about it... [...] * Record active at start, add newly active, ignore newly inactive, ignore newly added, ignore newly removed So we're ignoring the fact that adding/removing a TU during the SVP distorts the results? Because it is a corner case? What do you think? I think we need more opinions. Xyne? Anyway, if anyone's looking for some bylaw amendment history: Agreed. Added Xyne to Cc. https://mailman.archlinux.org/pipermail/aur-general/2007-December/000127.html https://mailman.archlinux.org/pipermail/aur-general/2010-December/012196.html https://mailman.archlinux.org/pipermail/aur-general/2010-December/012534.html [...]
[aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
Instead of counting the number of active TUs when a vote begins, update the number whenever a TU becomes active/inactive during a voting period. This is a more accurate measure since everyone who is active at some point in time during the voting period is (technically) able to vote. Signed-off-by: Lukas Fleischer archli...@cryptocrack.de --- Rationale: The AUR soon supports automated computation of voting results. This change is needed in order to get a proper measurement for the number of active TUs. There will probably be another amendment as soon as the next AUR release is out. Let the discussion period begin! tu-bylaws.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tu-bylaws.txt b/tu-bylaws.txt index 991d683..7d5139f 100644 --- a/tu-bylaws.txt +++ b/tu-bylaws.txt @@ -51,7 +51,7 @@ NO or ABSTAIN. Votes shall be cast under the Trusted User section of the AUR homepage. At the end of the voting period, all votes shall be tallied. In the context of SVP, TUs are considered active if they are marked as active -when the voting period ends. +at some point in time during the voting period. Quorum shall be 66% of all active TUs and participation shall be measured by the sum of YES, NO and ABSTAIN votes, UNLESS otherwise stated in a section of -- 1.8.4.rc1.383.g13e9f3f
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On 6 August 2013 05:53, Lukas Fleischer archli...@cryptocrack.de wrote: Instead of counting the number of active TUs when a vote begins, update the number whenever a TU becomes active/inactive during a voting period. What happens when a TU becomes inactive after casting a vote? Would her vote be invalidated? If so, no change is needed to the bylaws. Otherwise, another line of explanation would help prevent ambiguity... In the context of SVP, TUs are considered active if they are marked as active -when the voting period ends. +at some point in time during the voting period. In the context of SVP, TUs are considered active if they are marked as active -when the voting period ends. +at any point during the voting period. TUs who become inactive during the +voting period are not considered inactive until the end of the running SVP. -- GPG/PGP ID: C0711BF1
Re: [aur-general] TU application
Hi, I sneak-voted with a mobile phone while temporarily inactive and on vacation. - Alexander / xyproto
Re: [aur-general] TU application
Martti Kühne wrote: things won't be eaten as hot as they were cooked here. Off-topic: I thought that was a really nice expression. Is it idiomatic where you're from? Regards, Xyne
Re: [aur-general] TU application
On Sat, 2013-07-27 at 07:04 +, Xyne wrote: Martti Kühne wrote: things won't be eaten as hot as they were cooked here. Off-topic: I thought that was a really nice expression. Is it idiomatic where you're from? It's a German idiom. http://www.dict.cc/?s=nicht+so+hei%C3%9F+gegessen
Re: [aur-general] TU application
On 2013-07-27 09:33 +0200 Ralf Mardorf wrote: On Sat, 2013-07-27 at 07:04 +, Xyne wrote: Martti Kühne wrote: things won't be eaten as hot as they were cooked here. Off-topic: I thought that was a really nice expression. Is it idiomatic where you're from? It's a German idiom. http://www.dict.cc/?s=nicht+so+hei%C3%9F+gegessen Danke!
Re: [aur-general] TU application
On 20.07.2013 15:48, Sven-Hendrik Haase wrote: On 15.07.2013 22:31, Dicebot wrote: [sponsor : Sven-Hendrik Haase] [AUR account : https://aur.archlinux.org/account/Dicebot] [IRC : Dicebot @ irc.freenode.net] Hello, Long story short - I am insterested in becoming a Trusted User and taking care of packages related to D programming language. I have been using Arch Linux for last ~5 years but that does not really matter as I have never spent any considerable time maintaining packages. What does matter though is that I am quite active member of D community and familiar with minor details about its current infrastructure and have personal interest in improving user experience in that domain. I have been maintaing reference D compiler package (dmd2) in AUR before its inclusion into main repositories and kept contacting Sven-Hendrik with various improvement proposals after. At some point in the relatively long mail thread he has suggested to make a TU application so that I can take over those packages and maintain them directly - which is the primary motivating reason behind this mail. As my general competence level as a packager relatively low I am planning to solely focus on domain I am proficient with - D compilers, libraries and notable applications. Also contacting with D maintainers in other distros to ensure reasonable consistency. Regards, Dicebot Discussion period has ended. Start the voting: https://aur.archlinux.org/tu/?id=69 Le voting period has ended. Dicebot-san is now officially Dicebot-sama! Let's perform our ritual new-TU-group-hug. Congratulations! signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU application
On Saturday, July 27, 2013 18:31:23 Sven-Hendrik Haase wrote: On 20.07.2013 15:48, Sven-Hendrik Haase wrote: On 15.07.2013 22:31, Dicebot wrote: [sponsor : Sven-Hendrik Haase] [AUR account : https://aur.archlinux.org/account/Dicebot] [IRC : Dicebot @ irc.freenode.net] Hello, Long story short - I am insterested in becoming a Trusted User and taking care of packages related to D programming language. I have been using Arch Linux for last ~5 years but that does not really matter as I have never spent any considerable time maintaining packages. What does matter though is that I am quite active member of D community and familiar with minor details about its current infrastructure and have personal interest in improving user experience in that domain. I have been maintaing reference D compiler package (dmd2) in AUR before its inclusion into main repositories and kept contacting Sven-Hendrik with various improvement proposals after. At some point in the relatively long mail thread he has suggested to make a TU application so that I can take over those packages and maintain them directly - which is the primary motivating reason behind this mail. As my general competence level as a packager relatively low I am planning to solely focus on domain I am proficient with - D compilers, libraries and notable applications. Also contacting with D maintainers in other distros to ensure reasonable consistency. Regards, Dicebot Discussion period has ended. Start the voting: https://aur.archlinux.org/tu/?id=69 Le voting period has ended. Dicebot-san is now officially Dicebot-sama! Let's perform our ritual new-TU-group-hug. Congratulations! Congrats! Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [aur-general] TU application
On Sat, Jul 27, 2013 at 6:44 PM, Felix Yan felixonm...@gmail.com wrote: On Saturday, July 27, 2013 18:31:23 Sven-Hendrik Haase wrote: On 20.07.2013 15:48, Sven-Hendrik Haase wrote: On 15.07.2013 22:31, Dicebot wrote: [sponsor : Sven-Hendrik Haase] [AUR account : https://aur.archlinux.org/account/Dicebot] [IRC : Dicebot @ irc.freenode.net] Hello, Long story short - I am insterested in becoming a Trusted User and taking care of packages related to D programming language. I have been using Arch Linux for last ~5 years but that does not really matter as I have never spent any considerable time maintaining packages. What does matter though is that I am quite active member of D community and familiar with minor details about its current infrastructure and have personal interest in improving user experience in that domain. I have been maintaing reference D compiler package (dmd2) in AUR before its inclusion into main repositories and kept contacting Sven-Hendrik with various improvement proposals after. At some point in the relatively long mail thread he has suggested to make a TU application so that I can take over those packages and maintain them directly - which is the primary motivating reason behind this mail. As my general competence level as a packager relatively low I am planning to solely focus on domain I am proficient with - D compilers, libraries and notable applications. Also contacting with D maintainers in other distros to ensure reasonable consistency. Regards, Dicebot Discussion period has ended. Start the voting: https://aur.archlinux.org/tu/?id=69 Le voting period has ended. Dicebot-san is now officially Dicebot-sama! Let's perform our ritual new-TU-group-hug. Congratulations! Congrats! Regards, Felix Yant Omedeto gozaimasu ( ^ ω ^ ) -- Maxime
