From fedora-devel-list Wed Aug 10 11:33:29 2016 From: Helio Chissini de Castro Date: Wed, 10 Aug 2016 11:33:29 +0000 To: fedora-devel-list Subject: Re: Pending ACLs Message-Id: X-MARC-Message: https://marc.info/?l=fedora-devel-list&m=147082883327362 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============3184771503955489817==" --===============3184771503955489817== Content-Type: multipart/alternative; boundary=001a114b4120c070b60539b60477 --001a114b4120c070b60539b60477 Content-Type: text/plain; charset=UTF-8 First of all sorry if i looks like rude on my answers, was not the intention. On Tue, Aug 9, 2016 at 5:34 PM, Dennis Gilmore wrote: > On Monday, August 8, 2016 10:36:11 AM CDT Helio Chissini de Castro wrote: > > Not works. > > I do not understand what does not work > > > You need then talk with the requester and then decide to deny or not. > > And if he tries again, do the process again. > > What you can' t do is letting anyone waiting or making the package > hostage. > Sometimes talking does not get anywhere and you reach an impase and you > should > just leave the acls be pending. The package is not held hostage in anyway > shape or form. I honestly think you are attacking this from the wrong > angle. > I know, but still, i strongly believe that if this deadlock situation happens, then i think is ok to deny it with a polite reasoning that we're not ready to agree on rights over the package. We can change our mind later, or even the requester decides not going further, but it's life. We just can't let things hanging. > > About the notifications, yes, everyone get notifications if set your > email > > properly or use @fedoraproject, and is working well as delivering. > > So increase the amount of notifications or do it in public lists will not > > fix the issue that is really is, the package > > owner. Would even piss of more the maintainers or other users ( in case > of > > public ) > not sure what this is dirrected at > Is just because people complaining that we need improve the package acls notification, but more notifications would not solve the issue, would just be "more" I can be wrong on that and something really was not efficient, but i personally would not like to have more and more regular notifications beyond the first one. > > > > If he decide to ignore or just not reading, then all efforts to " > increase" > > or " improve" notifications system is useless. > > > > Packages should have at least two lead owners and one group that can take > > equal decisions over it. > why? please give some reasoning > The reasoning on have two maintainers is, unless we have someone paid for maintaining the packages, the reality is that we're community bounded. And sometime the so called "life" will take our free time for do this things, or any other reasoning that could prevent us to get active more often. With two persons, would be easy to avoid a package became hostage in general and then have all the unresponsive maintainers requests we've been seen often. But then, the two can disappear as well, so that's comes from the groups. The group is the more important thing, since give powers over a package with some trusted people, not specific one, so it can be moving from time to time the crew, and never been a hostage package for a single point of contact. KDE and Qt packages are this way, they are not my or any other responsibility alone, but to @kdesig group, and any guys that enters in this group are effectively a new admin to the packages, granted as is in the group and we trusted to be working with us. --001a114b4120c070b60539b60477 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

First of all sorry if i looks like rude on my answers, was not the in= tention.

On Tue, Aug 9, 2016 at 5:34 PM, Dennis Gilmore <dennis@ausil.us> wrote:
On Monday, = August 8, 2016 10:36:11 AM CDT Helio Chissini de Castro wrote:
> Not works.

I do not understand what=C2=A0 does not work

> You need then talk with the requester and then decide to deny or not.<= br> > And if he tries again, do the process again.
> What you can' t do is letting anyone waiting or making the package= hostage.
Sometimes talking does not get anywhere and you reach an impase and you sho= uld
just leave the acls be pending. The package is not held hostage in anyway shape or form. I honestly think you are attacking this from the wrong angle= .

I know, but still, i strongly believe= that if this deadlock situation happens, then i think
is ok to d= eny it with a polite reasoning that we're not ready to agree on rights = over the package.
We can change our mind later, or even the reque= ster decides not going further, but it's life.
We just can= 9;t let things hanging.=C2=A0

=C2=A0
> About the notifications, yes, everyone get notifications if set your e= mail
> properly or use @fedoraproject, and is working well as delivering.
> So increase the amount of notifications or do it in public lists will = not
> fix the issue that is really is, the package
> owner. Would even piss of more the maintainers or other users ( in cas= e of
> public )
not sure what this is dirrected at

Is j= ust because people complaining that we need improve the package acls notifi= cation, but more notifications=C2=A0
would not solve the issue, w= ould just be "more"
I can be wrong on that and somethin= g really was not efficient, but i personally would not like to=C2=A0
<= div>have more and more regular notifications beyond the first one.

=C2=A0
>
> If he decide to ignore or just not reading, then all efforts to "= increase"
> or " improve" notifications system is useless.
>
> Packages should have at least two lead owners and one group that can t= ake
> equal decisions over it.
why?=C2=A0 please give some reasoning

T= he reasoning on have two maintainers is, unless we have someone paid for ma= intaining the packages, the reality is that we're=C2=A0
c= ommunity bounded. And sometime the so called "life" will take our= free time for do this things, or any other reasoning that could
= prevent us to get active more often.
With two persons, would be e= asy to avoid a package became hostage in general and then have all the unre= sponsive maintainers requests
we've been seen often.=C2=A0

But then, the two can disappear as well, so that'= ;s comes from the groups.
The group is the more important thing, = since give powers over a package with some trusted people, not specific one= , so it can be moving from time to=C2=A0
time the crew, and = =C2=A0never been a hostage package for a single point of contact.=C2=A0
KDE and Qt packages are this way, they are not my or any other respo= nsibility alone, but to @kdesig group, and any guys that enters in this gro= up=C2=A0
are effectively a new admin to the packages, granted as = is in the group and we trusted to be working with us.
=C2=A0
--001a114b4120c070b60539b60477-- --===============3184771503955489817== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline LS0KZGV2ZWwgbWFpbGluZyBsaXN0CmRldmVsQGxpc3RzLmZlZG9yYXByb2plY3Qub3JnCmh0dHBz Oi8vbGlzdHMuZmVkb3JhcHJvamVjdC5vcmcvYWRtaW4vbGlzdHMvZGV2ZWxAbGlzdHMuZmVkb3Jh cHJvamVjdC5vcmcK --===============3184771503955489817==--