Re: [arch-dev-public] TU application process
On 11/6/18 8:49 PM, Gaetan Bisson via arch-dev-public wrote: > [2018-11-06 12:13:54 +0100] Bruno Pagani via arch-dev-public: >> Le 06/11/2018 à 11:37, Allan McRae a écrit : >>> But because you asked my opinion, I think a TU council is >>> a really, really, really bad idea. No need to set some TUs above >>> others. >> Well some already are, because they are devs too. > I do not understand this. When TUs vote, those who also happen to be > devs only have one ballot each, just as any other TU. So how are they > "set above" others? Being a dev does not grant you any extra TU powers, > does it? > >>> We have never had a formal hierarchy in the developers (apart >>> from our glorious leader), >> Here again I would argue that they are devs that have [core] pushing >> rights, as well as devs that are Master Key holders. So even if you >> don’t want to write this black on white, this actually means a small >> group of people have the real control over the distro (technically, >> Master Key holders could revoke everyone else). > I personally see the holding of master keys as a bureaucratic chore > which I'm glad to have other people doing. Likewise, any dev with > nonzero experience on the team can have access to [core] by just asking. > > Contrast this false hierarchies with the fact that anyone can send an > email to arch-dev-public saying "I'm going to do this; any objections?" > and a lack of replies from the community means "Feel free to go ahead." > > So there really is no hierarchy in the sense that no specific people > decide what others can and cannot do. Like Allan said, I think this > system has worked very well for Arch. > >>> and are instead run by those who step up to >>> lead what needs done. I believe that this is what makes Arch work, and >>> governance would be detrimental to the distribution as a whole. >> Because you think Arch work, we (as some TUs/devs) think they are a >> number of issues. > We have certainly not run out of things to improve, but I seriously > doubt that more bureaucracy will do anything to help. > > Cheers. Can we please (again) move this discussion to aur-general, I see enough bureaucracy already, no need for it to be part of the development list as well... Alad signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] TU application process
[2018-11-06 12:13:54 +0100] Bruno Pagani via arch-dev-public: > Le 06/11/2018 à 11:37, Allan McRae a écrit : > > But because you asked my opinion, I think a TU council is > > a really, really, really bad idea. No need to set some TUs above > > others. > Well some already are, because they are devs too. I do not understand this. When TUs vote, those who also happen to be devs only have one ballot each, just as any other TU. So how are they "set above" others? Being a dev does not grant you any extra TU powers, does it? > > We have never had a formal hierarchy in the developers (apart > > from our glorious leader), > Here again I would argue that they are devs that have [core] pushing > rights, as well as devs that are Master Key holders. So even if you > don’t want to write this black on white, this actually means a small > group of people have the real control over the distro (technically, > Master Key holders could revoke everyone else). I personally see the holding of master keys as a bureaucratic chore which I'm glad to have other people doing. Likewise, any dev with nonzero experience on the team can have access to [core] by just asking. Contrast this false hierarchies with the fact that anyone can send an email to arch-dev-public saying "I'm going to do this; any objections?" and a lack of replies from the community means "Feel free to go ahead." So there really is no hierarchy in the sense that no specific people decide what others can and cannot do. Like Allan said, I think this system has worked very well for Arch. > > and are instead run by those who step up to > > lead what needs done. I believe that this is what makes Arch work, and > > governance would be detrimental to the distribution as a whole. > Because you think Arch work, we (as some TUs/devs) think they are a > number of issues. We have certainly not run out of things to improve, but I seriously doubt that more bureaucracy will do anything to help. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] TU application process
On 11/6/18 7:32 AM, Bartłomiej Piotrowski via arch-dev-public wrote: >> Here again I would argue that they are devs that have [core] pushing >> rights, as well as devs that are Master Key holders. So even if you >> don’t want to write this black on white, this actually means a small >> group of people have the real control over the distro (technically, >> Master Key holders could revoke everyone else). > > You can argue, but it's simply not true. Any developer has access to > [core]. Master key holders aren't considered any better than other > developers besides having more duties and no one has ever refused to > sign new TU; for every master key holder, there is someone else holding > revocation certificate. There is no hierarchy. I guess in addition it should be pointed out there's no technical measure stopping *any* Dev from pushing a new keyring package that deletes/revokes/disables all master keys and current packaging keys and replaces the entire keyring with their own key alone. It's just yet another package... -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] TU application process
On 06/11/2018 12.13, Bruno Pagani via arch-dev-public wrote: > Yeah, but [community] used to be something completely separated from > [extra]. This is less and less the case (numerous packages were moved > from [extra] to [community] so that TUs could maintain them for > instance). The line between devs and TUs has become quite blurried, and > in my opinion who we accept as TU is highly depending on the meaning we > have for those repos and roles. I think devs should thus be concerned by > the quality of what we have in [community]. Or we should start caring about repo hierarchy again, and keep [core] and [extra] independent. > Here again I would argue that they are devs that have [core] pushing > rights, as well as devs that are Master Key holders. So even if you > don’t want to write this black on white, this actually means a small > group of people have the real control over the distro (technically, > Master Key holders could revoke everyone else). You can argue, but it's simply not true. Any developer has access to [core]. Master key holders aren't considered any better than other developers besides having more duties and no one has ever refused to sign new TU; for every master key holder, there is someone else holding revocation certificate. There is no hierarchy. > Because you think Arch work, we (as some TUs/devs) think they are a > number of issues. Any sort of council would be a big turn-off for me not just now, but also years ago when I joined TU ranks first. > Thanks for your input, and this is the kind of opinions for which I said > we should have this discussion here. Personally I'm not interested in this either and I find it difficult to find anything substantial in Christian's message indicating that discussion should take place on arch-dev-public and not aur-general. I know anthraxx is preparing actual outline but it's really bad way to start off. Bartłomiej
Re: [arch-dev-public] TU application process
Le 06/11/2018 à 11:37, Allan McRae a écrit : > On 6/11/18 8:15 pm, Bruno Pagani wrote: >> Le 06/11/2018 à 11:12, Christian Rebischke via arch-dev-public a écrit : >>> On Tue, Nov 06, 2018 at 08:09:03PM +1000, Allan McRae wrote: On 6/11/18 7:54 pm, Christian Rebischke via arch-dev-public wrote: > Hello everybody, > > First of all, the following mail has nothing to do with the last two TU > applications, it's a general view on the current TU application process. > > I would like to propose a new process for TU applications due to several > reasons: > Read the TU bylaws. It has specific instructions of where proposals must be posted (hint: not here...). A >>> Hi Allan, >>> >>> This mail wasn't meant as proposal. It's just a general discussion about >>> this topic and people said in the TU IRC channel yesterday, that >>> arch-dev-public would be the >>> right mailinglist for such discussion. >>> >>> chris >> Specifically, we are also interested in the input of devs, not just TUs. > Strange, given TUs are set-up to be an independently governed group from > developers... Yeah, but [community] used to be something completely separated from [extra]. This is less and less the case (numerous packages were moved from [extra] to [community] so that TUs could maintain them for instance). The line between devs and TUs has become quite blurried, and in my opinion who we accept as TU is highly depending on the meaning we have for those repos and roles. I think devs should thus be concerned by the quality of what we have in [community]. > But because you asked my opinion, I think a TU council is > a really, really, really bad idea. No need to set some TUs above > others. Well some already are, because they are devs too. > We have never had a formal hierarchy in the developers (apart > from our glorious leader), Here again I would argue that they are devs that have [core] pushing rights, as well as devs that are Master Key holders. So even if you don’t want to write this black on white, this actually means a small group of people have the real control over the distro (technically, Master Key holders could revoke everyone else). > and are instead run by those who step up to > lead what needs done. I believe that this is what makes Arch work, and > governance would be detrimental to the distribution as a whole. Because you think Arch work, we (as some TUs/devs) think they are a number of issues. > Personally, I'd get rid of all quorum for electing a TU, and make > inactive TUs be measured purely on the basis of package updating. Most > TU application discussions are inane beyond the customary package > review. And when someone applies and their packages are very bad, their > sponsor should be held in shame. > > Finally, I don't want to hear what the minions are up to! Get back to > your own mailing list. :) Thanks for your input, and this is the kind of opinions for which I said we should have this discussion here. Regards, Bruno signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] TU application process
On Tue, Nov 06, 2018 at 08:37:42PM +1000, Allan McRae wrote: > On 6/11/18 8:15 pm, Bruno Pagani wrote: > > Le 06/11/2018 à 11:12, Christian Rebischke via arch-dev-public a écrit : > >> On Tue, Nov 06, 2018 at 08:09:03PM +1000, Allan McRae wrote: > >>> On 6/11/18 7:54 pm, Christian Rebischke via arch-dev-public wrote: > Hello everybody, > > First of all, the following mail has nothing to do with the last two TU > applications, it's a general view on the current TU application process. > > I would like to propose a new process for TU applications due to several > reasons: > > >>> Read the TU bylaws. It has specific instructions of where proposals > >>> must be posted (hint: not here...). > >>> > >>> A > >> Hi Allan, > >> > >> This mail wasn't meant as proposal. It's just a general discussion about > >> this topic and people said in the TU IRC channel yesterday, that > >> arch-dev-public would be the > >> right mailinglist for such discussion. > >> > >> chris > > Specifically, we are also interested in the input of devs, not just TUs. > > Strange, given TUs are set-up to be an independently governed group from > developers... But because you asked my opinion, I think a TU council is > a really, really, really bad idea. No need to set some TUs above > others. We have never had a formal hierarchy in the developers (apart > from our glorious leader), and are instead run by those who step up to > lead what needs done. I believe that this is what makes Arch work, and > governance would be detrimental to the distribution as a whole. > > Personally, I'd get rid of all quorum for electing a TU, and make > inactive TUs be measured purely on the basis of package updating. Most > TU application discussions are inane beyond the customary package > review. And when someone applies and their packages are very bad, their > sponsor should be held in shame. > > Finally, I don't want to hear what the minions are up to! Get back to > your own mailing list. :) > > A Ok, but nevertheless thanks for your opinion. I will move this to aur-general now. chris signature.asc Description: PGP signature
Re: [arch-dev-public] TU application process
On 6/11/18 8:15 pm, Bruno Pagani wrote: > Le 06/11/2018 à 11:12, Christian Rebischke via arch-dev-public a écrit : >> On Tue, Nov 06, 2018 at 08:09:03PM +1000, Allan McRae wrote: >>> On 6/11/18 7:54 pm, Christian Rebischke via arch-dev-public wrote: Hello everybody, First of all, the following mail has nothing to do with the last two TU applications, it's a general view on the current TU application process. I would like to propose a new process for TU applications due to several reasons: >>> Read the TU bylaws. It has specific instructions of where proposals >>> must be posted (hint: not here...). >>> >>> A >> Hi Allan, >> >> This mail wasn't meant as proposal. It's just a general discussion about >> this topic and people said in the TU IRC channel yesterday, that >> arch-dev-public would be the >> right mailinglist for such discussion. >> >> chris > Specifically, we are also interested in the input of devs, not just TUs. Strange, given TUs are set-up to be an independently governed group from developers... But because you asked my opinion, I think a TU council is a really, really, really bad idea. No need to set some TUs above others. We have never had a formal hierarchy in the developers (apart from our glorious leader), and are instead run by those who step up to lead what needs done. I believe that this is what makes Arch work, and governance would be detrimental to the distribution as a whole. Personally, I'd get rid of all quorum for electing a TU, and make inactive TUs be measured purely on the basis of package updating. Most TU application discussions are inane beyond the customary package review. And when someone applies and their packages are very bad, their sponsor should be held in shame. Finally, I don't want to hear what the minions are up to! Get back to your own mailing list. :) A
Re: [arch-dev-public] TU application process
Le 06/11/2018 à 11:12, Christian Rebischke via arch-dev-public a écrit : > On Tue, Nov 06, 2018 at 08:09:03PM +1000, Allan McRae wrote: >> On 6/11/18 7:54 pm, Christian Rebischke via arch-dev-public wrote: >>> Hello everybody, >>> >>> First of all, the following mail has nothing to do with the last two TU >>> applications, it's a general view on the current TU application process. >>> >>> I would like to propose a new process for TU applications due to several >>> reasons: >>> >> Read the TU bylaws. It has specific instructions of where proposals >> must be posted (hint: not here...). >> >> A > Hi Allan, > > This mail wasn't meant as proposal. It's just a general discussion about > this topic and people said in the TU IRC channel yesterday, that > arch-dev-public would be the > right mailinglist for such discussion. > > chris Specifically, we are also interested in the input of devs, not just TUs. Regards, Bruno signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] TU application process
On Tue, Nov 06, 2018 at 08:09:03PM +1000, Allan McRae wrote: > On 6/11/18 7:54 pm, Christian Rebischke via arch-dev-public wrote: > > Hello everybody, > > > > First of all, the following mail has nothing to do with the last two TU > > applications, it's a general view on the current TU application process. > > > > I would like to propose a new process for TU applications due to several > > reasons: > > > > Read the TU bylaws. It has specific instructions of where proposals > must be posted (hint: not here...). > > A Hi Allan, This mail wasn't meant as proposal. It's just a general discussion about this topic and people said in the TU IRC channel yesterday, that arch-dev-public would be the right mailinglist for such discussion. chris signature.asc Description: PGP signature
Re: [arch-dev-public] TU application process
On 6/11/18 7:54 pm, Christian Rebischke via arch-dev-public wrote: > Hello everybody, > > First of all, the following mail has nothing to do with the last two TU > applications, it's a general view on the current TU application process. > > I would like to propose a new process for TU applications due to several > reasons: > Read the TU bylaws. It has specific instructions of where proposals must be posted (hint: not here...). A
[arch-dev-public] TU application process
Hello everybody, First of all, the following mail has nothing to do with the last two TU applications, it's a general view on the current TU application process. I would like to propose a new process for TU applications due to several reasons: 1. I have the feeling that most sponsors are not aware of the responsibility of sponsoring a new TU candidate. There is more to do than just approving their application. Candidates should get advice for and after the application process. This includes: * learning how to sign mails * getting feedback for their PKGBUILDs from their sponsoree * getting advice for building packages correctly via makechrootpkg wrappers * getting help for the post-application-process, when the candidate has been accepted. * directing the new candidates to our IRC channels or mailinglist for community intergration. 2. I have the feeling that most TUs only vote, because of our new stricter bylaws. 3. I miss more TU contribution in TU application processes as well. I guess the reasons for the points above are missing time or missing mood for actively participating in the discussion. Therefore I would like to suggest some modifications to our TU application process. Here are some ideas from a discussion we had last night in the TU IRC channel: 1. Establishing a TU council, that get elected a certain time slot. The members of this council are responsible for accepting or rejecting a TU. Every TU can still sponsor or suggest a candidate, but the voting process will be done in this council only. The council should consist out of very active TUs and devs, who are known for a good package quality. 2. Establishing a 2-sponsors-rule instead of the current policy of one sponsor. 3. Best regards from Germany chris / shibumi signature.asc Description: PGP signature
