[2010-11-16 21:29:52 -0500] Kaiting Chen:

That being said I looked at the PKGBUILD. It needs to be cleaned up before it can enter [community]. Please try to support as many plugins as you can using makedepends (remove things like hddtemp from depends), and place them instead in optdepends along with a note so that users know which dependencies they need to use the plugin configuration that they want.

Of course. (I didn't want to do that in AUR to prevent everybody from having to recompile all plugins and pull lots of dependencies since my feeling is that most people only use the "core" features.) -- Gaetan

On 17 November 2010 13:15, Imanol Celaya wrote:

...

pyopencl http://aur.archlinux.org/packages.php?ID=31416

Cheers,

Stéphane

problem with packages which use opencl(at least with nvidia) is that it requires the cuda toolkit, a binary package that I'm not sure about the redistribution rights(should read the license)

and then look how to handle the opencl dependiencies as both amd and nvidia provide icd and in theory both can cohexist(so maybe a provides=('opencl') ?)

so, yes, opencl maybe better to wait

Imanol

I don't think they need cuda toolkit. I'm using OpenCL on nvidia with just nvidia-utils and opencl-headers installed.

On 17 November 2010 13:29, Imanol Celaya wrote:

2010/11/17 Lukáš Jirkovský :

...

On 17 November 2010 13:15, Imanol Celaya wrote:

...

...

pyopencl http://aur.archlinux.org/packages.php?ID=31416

Cheers,

Stéphane

problem with packages which use opencl(at least with nvidia) is that it requires the cuda toolkit, a binary package that I'm not sure about the redistribution rights(should read the license)

and then look how to handle the opencl dependiencies as both amd and nvidia provide icd and in theory both can cohexist(so maybe a provides=('opencl') ?)

so, yes, opencl maybe better to wait

Imanol

I don't think they need cuda toolkit. I'm using OpenCL on nvidia with just nvidia-utils and opencl-headers installed.

and compiling is fine? I used to have segfaults

Yep, I never had any problems with compiling nor running.

and then look how to handle the opencl dependiencies as both amd and nvidia provide icd and in theory both can cohexist(so maybe a provides=('opencl') ?)

so, yes, opencl maybe better to wait

Imanol

This is a part of the reason why I said I will wait before uploading. See FS#20558 Stéphane

Le mercredi 17 novembre 2010 12:59:48, Ionuț Bîru a écrit :

On 11/17/2010 03:03 AM, Gaetan Bisson wrote:

...

Dear TUs,

I'm Gaetan, a (discreet) junior dev, mentored by Allan. I recently got access to sigurd and thought I would use that opportunity to maintain in [community] a few packages I have been maintaining on the AUR so far,

...

but which are just a bit too unpopular to go to [extra]: the main idea is that you are a junior dev without pushing rights on the mirrors. Now you got access on sigurd will full privileges.

Do you guys (TUs) have some concern regarding this? Do we need to start a new applications to join our TU team?

No problems for me, a developper can maintain community packages also doing TU work. Regards, Laurent

On 11/17/2010 02:22 PM, Allan McRae wrote:

On 17/11/10 21:59, Ionuț Bîru wrote:

...

On 11/17/2010 03:03 AM, Gaetan Bisson wrote:

...

Dear TUs,

I'm Gaetan, a (discreet) junior dev, mentored by Allan. I recently got access to sigurd and thought I would use that opportunity to maintain in [community] a few packages I have been maintaining on the AUR so far, but which are just a bit too unpopular to go to [extra]:

the main idea is that you are a junior dev without pushing rights on the mirrors. Now you got access on sigurd will full privileges.

Do you guys (TUs) have some concern regarding this? Do we need to start a new applications to join our TU team?

Just as an FYI, I would not have suggested these guys have access if I had any concerns. They both have actually managed packages in the [extra] repo for a few months now without breaking anything.

New TUs are provided full access to the [community] with zero total experience on our systems. If you are really concerned then we should restrict new TUs from pushing packages as well...

Allan

sure. i'm just raising some concerns. I do know both of them well enough but mostly because i'm in this junior dev program. Majority of TUs doesn't even know if we have pick junior devs. In the future i would like to have this more public. Does Loui know about the new users or everything was done privately between you and they? -- Ionuț

On Wed 17 Nov 2010 22:22 +1000, Allan McRae wrote:

On 17/11/10 21:59, Ionuț Bîru wrote:

...

On 11/17/2010 03:03 AM, Gaetan Bisson wrote:

...

Dear TUs,

I'm Gaetan, a (discreet) junior dev, mentored by Allan. I recently got access to sigurd and thought I would use that opportunity to maintain in [community] a few packages I have been maintaining on the AUR so far, but which are just a bit too unpopular to go to [extra]:

the main idea is that you are a junior dev without pushing rights on the mirrors. Now you got access on sigurd will full privileges.

Do you guys (TUs) have some concern regarding this? Do we need to start a new applications to join our TU team?

Just as an FYI, I would not have suggested these guys have access if I had any concerns. They both have actually managed packages in the [extra] repo for a few months now without breaking anything.

New TUs are provided full access to the [community] with zero total experience on our systems. If you are really concerned then we should restrict new TUs from pushing packages as well...

That's not really the issue. Someone might be bothered by apparent circumvention of the established system of sponsorship and voting to gain those privileges. Historically devs have access to community if they choose. Arch Linux provides all the resources to host the AUR and community, and even mirroring. I don't see anything wrong with that arrangement. I think we can trust the junior devs the same as devs.

You are Devs (kinda), I assume from that, that you are a trustworthy person as the people we all trust(devs) trust you.

I see no problem with you maintaining a few packages in [community] as long as you - like this - say what you want to move in or out to/of the repository and wait at least 24h for feedback from TU side. If nothing happens, pick 2 or 3 directly and ask them, they shall just send a public yes or no, the reason can be kept private as long as you know it.

If you break something by accident we simply blame Allan as it's common.

I don't know either of these guys at all. From what I've heard I think they're capable of pushing these packages. If anyone has any concerns about Junior Dev's pushing binaries I'll be happy to audit all of their PKGBUILD's so long as they send me an email about it 12 hours in advance. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

... From what I've heard I think they're capable of pushing these packages. If anyone has any concerns about Junior Dev's pushing binaries I'll be happy to audit all of their PKGBUILD's so long as they send me an email about it 12 hours in advance. --Kaiting. ...

What ? 12 hours? audit their PKGBUILDS beurocracy? no thanks. They are dev juniors, they now how to use their tools, and we are a team, if they need any support or help, they surely will contact us to help them.

So I'd say +1 to give access to the jr devs who want to be more compromised

Like I said I don't have any concerns about them maintaining packages in [extra] or [community]. Other people seem to have concerns though which is why I offered to look over their PKGBUILD's. Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

2010/11/18 Ángel Velásquez :

2010/11/17 Kaiting Chen :

...

...

You are Devs (kinda), I assume from that, that you are a trustworthy person as the people we all trust(devs) trust you.

I see no problem with you maintaining a few packages in [community] as long as you - like this - say what you want to move in or out to/of the repository and wait at least 24h for feedback from TU side. If nothing happens, pick 2 or 3 directly and ask them, they shall just send a public yes or no, the reason can be kept private as long as you know it.

If you break something by accident we simply blame Allan as it's common.

I don't know either of these guys at all. From what I've heard I think they're capable of pushing these packages. If anyone has any concerns about Junior Dev's pushing binaries I'll be happy to audit all of their PKGBUILD's so long as they send me an email about it 12 hours in advance. --Kaiting.

What ? 12 hours? audit their PKGBUILDS beurocracy? no thanks. They are dev juniors, they now how to use their tools, and we are a team, if they need any support or help, they surely will contact us to help them.

So I'd say +1 to give access to the jr devs who want to be more compromised

+1 This is no different from a new TU. There's no need for an audit or even for them to ask us when they deem something suitable for [community] (it should be in accordance to the TU Packaging Guidelines; > 10 votes || 1% usage anyway).

On 18 November 2010 04:14, Kaiting Chen wrote:

...

+1

This is no different from a new TU. There's no need for an audit or even for them to ask us when they deem something suitable for [community] (it should be in accordance to the TU Packaging Guidelines; > 10 votes || 1% usage anyway).

I'm confused as to the difference between a Trusted User and a Junior Developer. Wouldn't it make more sense to promote Junior Developers to Trusted Users after a while? --Kaiting.

Oh, [community] is separate, and so is its team. A package maintainer of [core] and/or [extra] may or may not have any business in [community]. If she doesn't have any business, she doesn't need access to the server. Granted, this is a little different since it's the first time we've had something like a "Junior Developer", AFAICR. However, I believe we should give them benefit of the doubt when recommended by a developer. If anything (bad) happens, the brokeit panic button sends a jolt up someone by default. We need not worry :)