Le 2012-03-01 03:47, Peter Lewis a écrit :

Hi Ike,

Thanks for applying :-)

...

Currently I'm using Archlinux as my primary operating system for over 6 years and for several years I'm maintaining a small number of packages in AUR[1]. I also keep a repository with arch packages for everyone to use[2] and view the pkgbuilds on github[3]. Originally the repository got created so i could easily install some non-{core,extra,community}-packages on my different computers. I had a quick look, and these packages all look pretty good to me. It seems

On Thursday 01 Mar 2012 08:33:17 Ike Devolder wrote: that you know your way around.

...

I would like to become a TU for several reasons:

- bring in some packages from AUR to community - apper (kde packagekit frontend, the gnome/gtk ones are already in) - lcdproc (drive your lcd displays) - closure-{compiler,linter} (googles javascript toys) - vim-qt (or provide a patch for addition to the extra package) It would be nice to see another TU interested in KDE / Qt things :-)

...

Last but not least, my sponsor is Stéphane Gaudreault. This is a bit picky of me, but technically the sponsor is supposed to be a TU and as far as I can tell Stéphane is a dev rather than a TU... So ... Following this logic I have the power to break everything on your system ... but not to sponsor a future member of our trusted users team ? (Just kidding :D ).

Good luck with the application!

Pete. I had the oportunity to collaborate with Ike a few time. He showed very good technical skills and a good attitude. For these reasons, I think he would be a good addition to our TUs team.

Cheers, Stéphane

Am 01.03.2012 15:31, schrieb Peter Lewis:

On Thursday 01 Mar 2012 07:51:47 Stéphane Gaudreault wrote:

...

...

This is a bit picky of me, but technically the sponsor is supposed to be a TU and as far as I can tell Stéphane is a dev rather than a TU...

So ... Following this logic I have the power to break everything on your system ... but not to sponsor a future member of our trusted users team ? (Just kidding :D ).

Heh, quite. I didn't claim to have logic on my side, I was just highlighting what our byelaws currently say.

I said it was picky, but if we're happy for Devs to sponsor TU-ship, then we should just change the rules. I didn't want to create a big discussion out of this (unless of course people do disagree with devs being sponsors), so if there aren't any reasons contra, I'll put in a proposal to amend the byelaws. I guess this came from an original idea that the group of TUs are self- governing, independently of the developers.

I always highlight that the Arch core developers usually don't interfere with the affairs of the TU group. In that sense, the bylaws make sense by saying you need to TU to sponsor him. However, the important part (voting) is done by TUs only. Personally, I always considered the "sponsor" requirement an unnecessary formality anyway.

On Fri, Mar 02, 2012 at 07:09:36AM -0500, Stéphane Gaudreault wrote:

Le 2012-03-02 07:03, Thomas Bächler a écrit :

...

Am 01.03.2012 15:31, schrieb Peter Lewis:

...

On Thursday 01 Mar 2012 07:51:47 Stéphane Gaudreault wrote:

...

...

This is a bit picky of me, but technically the sponsor is supposed to be a TU and as far as I can tell Stéphane is a dev rather than a TU... So ... Following this logic I have the power to break everything on your system ... but not to sponsor a future member of our trusted users team ? (Just kidding :D ). Heh, quite. I didn't claim to have logic on my side, I was just highlighting what our byelaws currently say.

I said it was picky, but if we're happy for Devs to sponsor TU-ship, then we should just change the rules. I didn't want to create a big discussion out of this (unless of course people do disagree with devs being sponsors), so if there aren't any reasons contra, I'll put in a proposal to amend the byelaws. I guess this came from an original idea that the group of TUs are self- governing, independently of the developers. I always highlight that the Arch core developers usually don't interfere with the affairs of the TU group. In that sense, the bylaws make sense by saying you need to TU to sponsor him. However, the important part (voting) is done by TUs only. Personally, I always considered the "sponsor" requirement an unnecessary formality anyway.

I thought about it andI have nointention to participate to the vote as I do not want to interfere with the required quorum. I am only sponsoring here and the final choice will be made by TUs only.

Stéphane

In general i'm sure Stéphane will do a great job sponsoring (which in most of the cases means, guarantee that the packages i will deliver have the required quality), but on the other hand i think this whole TU group "should" support newly accepted TU's in learning and improving their skills. Sponsored by this whole ArchLinux community i would like to help improve the overall ArchLinux experience. thx -- Ike

Le 2012-03-02 09:00, Peter Lewis a écrit :

On Friday 02 Mar 2012 13:03:47 Thomas Bächler wrote:

...

I always highlight that the Arch core developers usually don't interfere with the affairs of the TU group. In that sense, the bylaws make sense by saying you need to TU to sponsor him. However, the important part (voting) is done by TUs only. Sure, that is probably the important thing. But we should at least ensure the rules are consistent with our practice (or vice versa).

...

Personally, I always considered the "sponsor" requirement an unnecessary formality anyway.

Well, if that is a widely held view, then an alternative would be to remove this sponsorship thing all together and just allow direct applications to the list. Presumably it is designed to provide some sort of pre-application vetting of candidates, to not waste everyone's time?

Pete.

I think it is a good pratice to have sponsorhip from a TU or a dev, to do a first screening and to separate the wheat from the chaff. As I said before, I have no problem if only TUs vote. Cheers, Stéphane

On Fri, Mar 02, 2012 at 10:15:32AM -0300, Angel Velásquez wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 01/03/12 05:47, Peter Lewis wrote:

...

Hi Ike,

Thanks for applying :-)

On Thursday 01 Mar 2012 08:33:17 Ike Devolder wrote:

...

Currently I'm using Archlinux as my primary operating system for over 6 years and for several years I'm maintaining a small number of packages in AUR[1]. I also keep a repository with arch packages for everyone to use[2] and view the pkgbuilds on github[3]. Originally the repository got created so i could easily install some non-{core,extra,community}-packages on my different computers.

Hi Ike!

I didn't get you by your name but by your nickname, oh yeah, as Allan said I had a good memory about you, so this is good ;).

...

I had a quick look, and these packages all look pretty good to me. It seems that you know your way around.

...

I would like to become a TU for several reasons:

- bring in some packages from AUR to community - apper (kde packagekit frontend, the gnome/gtk ones are already in) - lcdproc (drive your lcd displays) - closure-{compiler,linter} (googles javascript toys) - vim-qt (or provide a patch for addition to the extra package)

It would be nice to see another TU interested in KDE / Qt things :-)

Good you have your goals.

...

...

Last but not least, my sponsor is Stéphane Gaudreault.

This is a bit picky of me, but technically the sponsor is supposed to be a TU and as far as I can tell Stéphane is a dev rather than a TU...

Good luck with the application!

Pete.

About this, as an ex-TU and ex-DEV I thought for Devs this should be unnecesary, I mean Trusted Users are Trusted by the community but first by the Devs (or nobody of TU would have access to our servers). So if we trust you, and we doesn't oppose against your decitions of who bring to the TU land, why TUs have to untrust Devs? IMHO TUs should trust devs by default, and that means, no complains about TU applications, have more sense to me. But please, I don't want to start a debate in this thread, I don't was to make noise on the Ike's application, if somebody want to reply me about it and start a brainstorming, discussion or whatever please do it other thread.

That said, good luck with your application Ike, you have been an impressive work and you're a good candidate.

- -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909 http://www.angvp.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPUMf0AAoJEEKh2xXsEzutuVsH/3rXPY8mMWKaOmo4KAJtKXYE U7KPLzZ8g9Bh1+ZmC6zAPyLP/CYR3n6jGv3EcePx68M/ULFOwuDl4utg0phyEKto eb91DwO+VT/lA3jSxlUxnTJ9qDKmp8nyCegicgEYoi5xqRsB9xQnFWr3iNE6dLX7 QR3fYqox/Y47r5BKmYNeg0AcwcRaaUp9lfc1QsnaCpJj8FJvhg6Md0xpyB2elJZO qdJHj/CkfY5N5y28HAt4N5y5dxBR66vx3xvgVFy3A40uu+F+kQEu+XjUJ1+/FdVo u3gGk57cubpJ8Mb83pp4bZOaBlx694tos91eE8JBuBvk6M9Yxq7xTS63ruGlpQM= =w7Pi -----END PGP SIGNATURE-----

thanks, i hope i can live up to all of your expectations -- Ike

2012/3/2 Angel Velásquez :

Hi Ike!

I didn't get you by your name but by your nickname, oh yeah, as Allan said I had a good memory about you, so this is good ;).

I've seen the nickname around as well, but not sure about what really. But that should be good after looking at a couple PKGBUILDs :) -- GPG/PGP ID: C0711BF1

2012/3/1 Thomas Bächler

Am 01.03.2012 08:33, schrieb Ike Devolder:

...

Hi,

Currently I'm using Archlinux as my primary operating system for over 6 years and for several years I'm maintaining a small number of packages in AUR[1]. I also keep a repository with arch packages for everyone to use[2] and view the pkgbuilds on github[3]. Originally the repository got created so i could easily install some non-{core,extra,community}-packages on my different computers.

Just some random formal remarks:

1) Nowadays, your application should be a PGP-signed email. You should also somehow verify that you are who you say you are, for example, by uploading your PGP key or fingerprint to your server or github.

i'll do this tonight, i have no access to my keys because i'm at work 2) What are your user names on bbs, bugs and IRC, if any?

sorry i forgot those bbs,wiki,bugs : BlackEagle aur,irc : BlackIkeEagle -- Ike

On 01.03.2012 17:05, Ike Devolder wrote:

...

1) Nowadays, your application should be a PGP-signed email. You should also somehow verify that you are who you say you are, for example, by uploading your PGP key or fingerprint to your server or github.

...

i'll do this tonight, i have no access to my keys because i'm at work

voila,

fingerprint: 0xdb2277bcd500aa3825610bdddb323392796ca067 http://pgp.mit.edu:11371/pks/lookup?search=0xDB2277BCD500AA3825610BDDDB323392796CA067&op=vindex&fingerprint=on

Please also switch to PGP/MIME so the signature isn't part of the mail text, but rather an attachment. In thunderbird/enigmail it's under account settings -> opengpg security -- Florian Pritz

Op 01-03-12 19:44, Ionut Biru schreef:

On 03/01/2012 09:33 AM, Ike Devolder wrote:

...

Hi,

Hi,

...

Currently I'm using Archlinux as my primary operating system for over 6 years and for several years I'm maintaining a small number of packages in AUR[1]. I also keep a repository with arch packages for everyone to use[2] and view the pkgbuilds on github[3]. Originally the repository got created so i could easily install some non-{core,extra,community}-packages on my different computers.

You are my kind of man. I'm doing an awesome team with arch veterans to fight against systemd & co and keep arch in the way is it now. It will be cool to have it near me! :)

Big +1 from me

i would not want to start a flame war here, since this smells alot like: - vim vs emacs - kde vs gnome - ... everyone has his/her preferences and i would not have it any other way, since the diversity an the choice offered towards us (if you are, developer, tu, server end user, desktop end user) is what makes this distributions ecosystem worthwile. the drive for stability should not put a brake on new technologies. let us have a nice combined effort and have a choice, that is for me at least one of the reasons for using ArchLinux and for keep on using it.

...

Some personal stuff: born 1982, webdeveloper (php, with some jquery tricks), mad about all sorts of metal music, and loving to watch movies and sitcoms. I live in Belgium so I should speak at least Dutch, French and German but i speak and write Dutch, English, bad French, very bad German.

I would like to become a TU for several reasons:

- bring in some packages from AUR to community - apper (kde packagekit frontend, the gnome/gtk ones are already in) - lcdproc (drive your lcd displays) - closure-{compiler,linter} (googles javascript toys) - vim-qt (or provide a patch for addition to the extra package)

as reference, some packages i was maintaining in AUR were already picked up - clementine (picked up by Stéphane Gaudreault) - par2cmdline (picked up by Sébastien Luttringer)

- pick up some orphans from community - v8 (this is the only one from the list i'm currently using)

- usualy i'm reading most of the issues reported so i could help sorting the "tickets" and assign them to their respective owners

Last but not least, my sponsor is Stéphane Gaudreault.

[1] http://aur.archlinux.org/packages.php?SeB=m&L=2&K=BlackIkeEagle [2] http://repo.herecura.be [3] https://github.com/BlackIkeEagle/herecura

-- Ike

On Fri, Mar 02, 2012 at 10:08:54PM +1000, Allan McRae wrote:

On 01/03/12 17:33, Ike Devolder wrote:

...

Hi,

Hey,

I recognise your name, and even better it is not in a bad way! That is my #1 criterion for recruiting new TUs. Even better is that you pass my #2 criterion, which is appearing competent.

Good luck, Allan

thank you a lot, i really appreciate this support and if i get accepted these kind of comments will make me strive for the best quality to the best of my abilities -- Ike

Hi Xyne, this is the noop listening your conversations ...

I too think that your PKGBUILDs look good. They're clean and well-structured. The only issue I see is the lack of variable quoting, e.g. I've seen this is many of them:

make DESTDIR=${pkgdir} install

That will not work if there is a space on the pkgdir path. For example:

$ mkdir 'foo bar' $ foo='foo bar' $ cd ${foo} bash: cd: foo: No such file or directory

I'd like to pick up the chance to clearify this for my personal record, because I had problem with the space in the pkgdir path. What do you suggest? Is this meant by "variable quoting"? $ cd "${foo}" What would be a apropriate solution in the PKGBUILD? This? make DESTDIR="${pkgdir}" install Best, Bjoern

On 04/03/12 06:02, Bjoern Lindig wrote:

Hi Xyne,

this is the noop listening your conversations ...

...

I too think that your PKGBUILDs look good. They're clean and well-structured. The only issue I see is the lack of variable quoting, e.g. I've seen this is many of them:

make DESTDIR=${pkgdir} install

That will not work if there is a space on the pkgdir path. For example:

$ mkdir 'foo bar' $ foo='foo bar' $ cd ${foo} bash: cd: foo: No such file or directory

I'd like to pick up the chance to clearify this for my personal record, because I had problem with the space in the pkgdir path. What do you suggest?

I suggest not building in directories with spaces...

On Sun, Mar 4, 2012 at 10:38 AM, Ike Devolder wrote:

Op 03-03-12 16:41, Xyne schreef:

...

Ike Devolder wrote:

/snip

...

[1] http://aur.archlinux.org/packages.php?SeB=m&L=2&K=BlackIkeEagle

Hi Ike,

I too think that your PKGBUILDs look good. They're clean and well-structured. The only issue I see is the lack of variable quoting, e.g. I've seen this is many of them:

make DESTDIR=${pkgdir} install

That will not work if there is a space on the pkgdir path. For example:

$ mkdir 'foo bar' $ foo='foo bar' $ cd ${foo} bash: cd: foo: No such file or directory

Everything else look good. Good luck!

Regards, Xyne

Hi Xyne,

In general i find it a mishap building in folders containing spaces.

but because it will give a failure here i'm currently updating all my PKGBUILDs to use the correct quoting, i'm also removing the unneeded ${}

thx for the note. In the end it is better practice

-- Ike

IMO, this is all just coding style that doesn't really affect any or 1 or 2 people in the whole distro that are insane enough to build with directory names with spaces in them.. Since it is coding style, I never judge anyone by it, but ideally would like it closely resembling mine :P I personally hate quoting in pkgbuilds and prefer ${variables} as I find this more readable although I sometimes deviate from this.

Thomas Dziedzic wrote:

On Sun, Mar 4, 2012 at 10:47 AM, Thomas Dziedzic wrote:

...

On Sun, Mar 4, 2012 at 10:38 AM, Ike Devolder wrote:

...

Op 03-03-12 16:41, Xyne schreef:

...

Ike Devolder wrote:

...

...

Hi Xyne,

In general i find it a mishap building in folders containing spaces.

but because it will give a failure here i'm currently updating all my PKGBUILDs to use the correct quoting, i'm also removing the unneeded ${}

thx for the note. In the end it is better practice

-- Ike

IMO, this is all just coding style that doesn't really affect any or 1 or 2 people in the whole distro that are insane enough to build with directory names with spaces in them..

Since it is coding style, I never judge anyone by it, but ideally would like it closely resembling mine :P

I personally hate quoting in pkgbuilds and prefer ${variables} as I find this more readable although I sometimes deviate from this.

Oops, I'm only talking about ${pkgdir}/${srcdir} in here, wasn't specific enough

There may not be many users who have paths with spaces in them, but they are perfectly valid. It is very bad practice to write code that fails in valid situations simply because the coder likes the way the code looks, and it is not a matter of coding style if it affects the code's behavior. As for Bash variables. there seems to be some common misconception that curly brackets do something special. They don't. They only provide a way to separate variables from surrounding text (e.g. ${foo}bar). Including them as a rule doesn't hurt and it provides consistency, but syntactically they are completely superfluous in most situations. Anyway, this isn't a major issue. I just think the argument "but I don't like the way the valid code looks" is a very bad and lazy one. Regards, Xyne

On Sun, Mar 4, 2012 at 11:48 AM, Xyne wrote:

Thomas Dziedzic wrote:

...

On Sun, Mar 4, 2012 at 10:47 AM, Thomas Dziedzic wrote:

...

On Sun, Mar 4, 2012 at 10:38 AM, Ike Devolder wrote:

...

Op 03-03-12 16:41, Xyne schreef:

...

Ike Devolder wrote:

...

...

...

Hi Xyne,

In general i find it a mishap building in folders containing spaces.

but because it will give a failure here i'm currently updating all my PKGBUILDs to use the correct quoting, i'm also removing the unneeded ${}

thx for the note. In the end it is better practice

-- Ike

IMO, this is all just coding style that doesn't really affect any or 1 or 2 people in the whole distro that are insane enough to build with directory names with spaces in them..

Since it is coding style, I never judge anyone by it, but ideally would like it closely resembling mine :P

I personally hate quoting in pkgbuilds and prefer ${variables} as I find this more readable although I sometimes deviate from this.

Oops, I'm only talking about ${pkgdir}/${srcdir} in here, wasn't specific enough

There may not be many users who have paths with spaces in them, but they are perfectly valid. It is very bad practice to write code that fails in valid situations simply because the coder likes the way the code looks, and it is not a matter of coding style if it affects the code's behavior.

In all my years of packaging, never has this been an issue.

As for Bash variables. there seems to be some common misconception that curly brackets do something special. They don't. They only provide a way to separate variables from surrounding text (e.g. ${foo}bar). Including them as a rule doesn't hurt and it provides consistency, but syntactically they are completely superfluous in most situations.

What lead you to believe there is a misconception? Unless this isn't a reply to my previous post then disregard this question.

Anyway, this isn't a major issue. I just think the argument "but I don't like the way the valid code looks" is a very bad and lazy one.

Regards, Xyne

Nobody really cares. Here's a test, try building all of [core] within a directory with a space in it. Here's a hint, you wont be able to. Unless you're going to tackle the main issue (which deserves another thread), I recommend to stop beating this dead horse. * no horses were harmed in the making of this post.

On Mon, Mar 05, 2012 at 07:51:20AM +1000, Allan McRae wrote:

On 05/03/12 04:53, Thomas Dziedzic wrote:

...

On Sun, Mar 4, 2012 at 11:48 AM, Xyne wrote:

...

Thomas Dziedzic wrote:

...

On Sun, Mar 4, 2012 at 10:47 AM, Thomas Dziedzic wrote:

...

On Sun, Mar 4, 2012 at 10:38 AM, Ike Devolder wrote:

...

Op 03-03-12 16:41, Xyne schreef: > Ike Devolder wrote:

...

...

...

Hi Xyne,

In general i find it a mishap building in folders containing spaces.

but because it will give a failure here i'm currently updating all my PKGBUILDs to use the correct quoting, i'm also removing the unneeded ${}

thx for the note. In the end it is better practice

-- Ike

IMO, this is all just coding style that doesn't really affect any or 1 or 2 people in the whole distro that are insane enough to build with directory names with spaces in them..

Since it is coding style, I never judge anyone by it, but ideally would like it closely resembling mine :P

I personally hate quoting in pkgbuilds and prefer ${variables} as I find this more readable although I sometimes deviate from this.

Oops, I'm only talking about ${pkgdir}/${srcdir} in here, wasn't specific enough

There may not be many users who have paths with spaces in them, but they are perfectly valid. It is very bad practice to write code that fails in valid situations simply because the coder likes the way the code looks, and it is not a matter of coding style if it affects the code's behavior.

In all my years of packaging, never has this been an issue.

...

As for Bash variables. there seems to be some common misconception that curly brackets do something special. They don't. They only provide a way to separate variables from surrounding text (e.g. ${foo}bar). Including them as a rule doesn't hurt and it provides consistency, but syntactically they are completely superfluous in most situations.

What lead you to believe there is a misconception? Unless this isn't a reply to my previous post then disregard this question.

...

Anyway, this isn't a major issue. I just think the argument "but I don't like the way the valid code looks" is a very bad and lazy one.

Regards, Xyne

Nobody really cares. Here's a test, try building all of [core] within a directory with a space in it. Here's a hint, you wont be able to.

I can guarantee at least 25% of [core] will fail because I hate quoting $srcdir/$pkgdir...

Allan

Well lets stop this discussion about the quoting please! I'll give my opinion about the issue and then let us close this topic. I find Xyne's comment valid, especially for AUR, but none the less it is also valid for the main repos {core,extra,community} (and all testing, unstable, ... repos). Why it has more impact on AUR: you cannot control what an enduser will be doing, using a helper building in a path with spaces. So by correct quoting it will introduce a better user experience for people living with this edgecases. You could say "you should not build in paths with spaces", but this is no restriction. AUR should be as robust as possible, so quoting is not a bad thing, this ensures that in most of the cases one can download the tarball, extract and run makepkg without any issue. Concerning the main repo's this is a lesser issue since those packages are built in a controlled environment. Users using abs are more experienced and if getting into trouble most will be able to fix it quickly. I would also like to call for more respect for each others opinions and stay away from the "Nobody cares", "it doesnt matter", "hate", ... Be constructive, help each other, all these harsh comments are brining a community in a downwards spiral of lesser respect, which could lead in the end to the decline of this whole distribution. Please don't do that. -- Ike

I like how Ike disarmed two potential flame war hijackings in one thread! Ike seems pretty cool. -- -Justin