Automating the NonResponsiveMaintainers policy

[Jóhann B. Guðmundsson]

I am a feature owner for a feature that involves components in the 
hundreds and is heavily depended on maintainers responsiveness.

For me to start enacting the non responsive maintainers policy is a 
tremendous work thus I'm wondering if there is something preventing us 
from automating the non responsive maintainer policy?

An bugzilla script that acts something like if maintainer has not 
responded to a bug report with the status new in a week ( or some other 
time ) the non responsive maintainers policy automatically starts taking 
effect.

To get out of that automatic non responsive process the maintainer would 
have to comment on the bug and set it's status assigned ( or something 
similar ).

JBG

[Marcela Mašláňová]

On 03/02/2012 11:20 AM, "Jóhann B. Guðmundsson" wrote:
>  I am a feature owner for a feature that involves components in the
>  hundreds and is heavily depended on maintainers responsiveness.
>  
>  For me to start enacting the non responsive maintainers policy is a
>  tremendous work thus I'm wondering if there is something preventing us
>  from automating the non responsive maintainer policy?
>  
>  An bugzilla script that acts something like if maintainer has not
>  responded to a bug report with the status new in a week ( or some other
>  time ) the non responsive maintainers policy automatically starts taking
>  effect. 
Ok, so you'll automatically start non-responsive maintainer process,
because maintainer didn't work on a one bug. But he might be working on
different component for whole month. He might be working on a new
upstream release and not paying attention to low priority bugzillas.

You should take more parameters than one bug to kick someone from Fedora.

Marcela

>  
>  To get out of that automatic non responsive process the maintainer would
>  have to comment on the bug and set it's status assigned ( or something
>  similar ).
>  
>  JBG

[Reindl Harald]

Am 02.03.2012 12:02, schrieb Marcela Mašláňová:
>  Ok, so you'll automatically start non-responsive maintainer
> process,
>  because maintainer didn't work on a one bug. But he might be working on
>  different component for whole month. He might be working on a new
>  upstream release and not paying attention to low priority bugzillas. 
define "working"

it is not too much "work" assign a bug of a owned package
to give a sign of life not at least to the submitter even
if we do not speak about any automatism

if you are working the whole month on a different component
and give no single feedback to a new reported bug you are
ending in frustrated submitters - if they get a "assigned"
they do not feel ignored

so such automatism does not enforce anything which
should not be mandatory for a package-owner to not
get frustrated users no longer submitting bugreports
because they feel ignored and wasted time do this

[Marcela Mašláňová]

On 03/02/2012 12:09 PM, Reindl Harald wrote:
>  
>  
>  Am 02.03.2012 12:02, schrieb Marcela Mašláňová:
> > Ok, so you'll automatically start non-responsive maintainer process,
> > because maintainer didn't work on a one bug. But he might be working on
> > different component for whole month. He might be working on a new
> > upstream release and not paying attention to low priority bugzillas.
>  
>  define "working"
>  
>  it is not too much "work" assign a bug of a owned package
>  to give a sign of life not at least to the submitter even
>  if we do not speak about any automatism
>  
>  if you are working the whole month on a different component
>  and give no single feedback to a new reported bug you are
>  ending in frustrated submitters - if they get a "assigned"
>  they do not feel ignored
>  
>  so such automatism does not enforce anything which
>  should not be mandatory for a package-owner to not
>  get frustrated users no longer submitting bugreports
>  because they feel ignored and wasted time do this
>   
Some developers prefer ignore it until they have time. Why should I
write yes, yes, it's broken, I'll look at it next month. That's not
helping anyway.

Marcela

[Reindl Harald]

Am 02.03.2012 12:47, schrieb Marcela Mašláňová:
>  Some developers prefer ignore it until they have time. Why should I
>  write yes, yes, it's broken, I'll look at it next month. That's not
>  helping anyway. 
IT DOES HELP

it is a hughe difference for a bugreporter if he feels
a month ignored or becomes a response "sorry needs time"

the devopers "perfering ignore" are the reason for frustrated
reporters, bad comments and losing reporters because THEY SPENT
TIME for writing a bugreport and should never feel ignored

[Jóhann B. Guðmundsson]

On 03/02/2012 11:47 AM, Marcela Mašláňová wrote:
>  Some developers prefer ignore it until they have time. Why should I
>  write yes, yes, it's broken, I'll look at it next month. That's not
>  helping anyway. 
I disagree it certainly does matter.

For example let's take these two [1] [2] bugs that are on my components 
list for my feature.

Bug 1 was filed 2011-11-16 and has absolutely no comments.

Which leaves me wondering..

A) is this package being actively maintained?
B) Is it planned for removal?
C) Is there something wrong with the submitted unit file?
D) Are upstream changes necessary for this component to be migrated?
E) Is it safe to flag the component to be package by proven packages?

Now let's look at bug 2 was also filed 2011-11-16 and has one comment 
from the maintainer which came 3 days later.

"Thanks, I'll test and apply it. Hoping to actually fix the deamon too."

Now I have the answer to A,B,C,D,E.

For bug 1 I have to initiate non responsive maintainers policy which 
takes 3+ weeks to finish....

For bug 2 I can just ping him with status if he has not yet packaged the 
submitted unit no later than week before the deadline to ship units comes.

So as you can see responses do indeed matter.

JBG

1. https://bugzilla.redhat.com/show_bug.cgi?id=754358
2. https://bugzilla.redhat.com/show_bug.cgi?id=754388

[Marcela Mašláňová]

On 03/02/2012 01:13 PM, "Jóhann B. Guðmundsson" wrote:
>  On 03/02/2012 11:47 AM, Marcela Mašláňová wrote:
> > Some developers prefer ignore it until they have time. Why should I
> > write yes, yes, it's broken, I'll look at it next month. That's not
> > helping anyway.
>  
>  I disagree it certainly does matter.
>  
>  For example let's take these two [1] [2] bugs that are on my components
>  list for my feature.
>  
>  Bug 1 was filed 2011-11-16 and has absolutely no comments.
>  
>  Which leaves me wondering..
>  
>  A) is this package being actively maintained?
>  B) Is it planned for removal?
>  C) Is there something wrong with the submitted unit file?
>  D) Are upstream changes necessary for this component to be migrated?
>  E) Is it safe to flag the component to be package by proven packages?
>  
>  Now let's look at bug 2 was also filed 2011-11-16 and has one comment
>  from the maintainer which came 3 days later.
>  
>  "Thanks, I'll test and apply it. Hoping to actually fix the deamon too."
>  
>  Now I have the answer to A,B,C,D,E.
>  
>  For bug 1 I have to initiate non responsive maintainers policy which
>  takes 3+ weeks to finish....
>  
>  For bug 2 I can just ping him with status if he has not yet packaged the
>  submitted unit no later than week before the deadline to ship units comes.
>  
>  So as you can see responses do indeed matter.
>  
>  JBG
>  
>  1. https://bugzilla.redhat.com/show_bug.cgi?id=754358
>  2. https://bugzilla.redhat.com/show_bug.cgi?id=754388 
Units again :)

Are you trying create some metrics because of units on whole
distribution? It simply won't fit to all groups.

Marcela

[Jóhann B. Guðmundsson]

On 03/02/2012 12:21 PM, Marcela Mašláňová wrote:
>  Units again:)
>
>  Are you trying create some metrics because of units on whole
>  distribution? It simply won't fit to all groups. 
No I'm only using units or rather the systemd migration process since 
i'm most familiar with it.
( been doing it for 3 release cycles now 4 if you count the initial 
systemd push which got rejected ).

It also deals with 500  - 600 components in total which gives it quite a 
measurable range to span I would believe.

JBG

[Pete Zaitcev]

On Fri, 02 Mar 2012 12:09:21 +0100
Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:

>  if you are working the whole month on a different component
>  and give no single feedback to a new reported bug you are
>  ending in frustrated submitters - if they get a "assigned"
>  they do not feel ignored 
This is going to end in counter-automation, with a script that
uploads "I'm busy, this bug is not to be used as an excuse to
initiate punitive automation" comment every 6 days.

-- Pete

[Jóhann B. Guðmundsson]

On 03/02/2012 11:02 AM, Marcela Mašláňová wrote:
>  Ok, so you'll automatically start non-responsive maintainer
> process,
>  because maintainer didn't work on a one bug. But he might be working on
>  different component for whole month. He might be working on a new
>  upstream release and not paying attention to low priority bugzillas.
>
>  You should take more parameters than one bug to kick someone from Fedora. 
This is based on more then one bug against one component and through 
observation in several release cycles.

If an maintainer does not want to be affected by the automatic non 
responsive process all he would have to do would simply be something 
like changing the report status from new to assigned and leave feed back 
on it.

JBG

[Marcela Mašláňová]

On 03/02/2012 12:12 PM, "Jóhann B. Guðmundsson" wrote:
>  On 03/02/2012 11:02 AM, Marcela Mašláňová wrote:
> > Ok, so you'll automatically start non-responsive maintainer process,
> > because maintainer didn't work on a one bug. But he might be working on
> > different component for whole month. He might be working on a new
> > upstream release and not paying attention to low priority bugzillas.
> >
> > You should take more parameters than one bug to kick someone from Fedora.
>  
>  This is based on more then one bug against one component and through
>  observation in several release cycles.
>  
>  If an maintainer does not want to be affected by the automatic non
>  responsive process all he would have to do would simply be something
>  like changing the report status from new to assigned and leave feed back
>  on it.
>  
>  JBG 
You didn't consider people or pseudousers, who are assigned to packages
with dozens of bugs. Also some developers are using NEW as their state
for something.

I'm afraid we end up with more bureaucracy than we have now. I'm not
against tracking some statistics, so you can look up who is active and
probably will answer in few days, but I'd rather not use it for the
unresponsive process.

Marcela

[Matthias Runge]

On 02/03/12 12:53, Marcela Mašláňová wrote:
>  I'm afraid we end up with more bureaucracy than we have now.
> I'm not
>  against tracking some statistics, so you can look up who is active and
>  probably will answer in few days, but I'd rather not use it for the
>  unresponsive process.
>  
>  Marcela 
I'm thinking about how to support Jóhann with a proven packager (or
two). Since it seems not wanted by Fesco, to give him the corresponding
rights to commit his changes directly? This final target (all services
are supported by systemd) seems to be clear to everyone.
-- 
Matthias Runge <mrunge(a)matthias-runge.de&gt;
               <mrunge(a)fedoraproject.org&gt;

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Matthias Runge" <mrunge(a)matthias-runge.de&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Friday, March 2, 2012 2:05:07 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  On 02/03/12 12:53, Marcela Mašláňová wrote:
>  > I'm afraid we end up with more bureaucracy than we have now. I'm
>  > not
>  > against tracking some statistics, so you can look up who is active
>  > and
>  > probably will answer in few days, but I'd rather not use it for the
>  > unresponsive process.
>  > 
>  > Marcela
>  
>  I'm thinking about how to support Jóhann with a proven packager (or
>  two). Since it seems not wanted by Fesco, to give him the
>  corresponding
>  rights to commit his changes directly? This final target (all
>  services
>  are supported by systemd) seems to be clear to everyone. 
This is a noble goal and I wish this finishes sooner. But attacking packagers by
threatening is not gaining any support for the efforts.
Most of us gained their commit rights by talking to the respective maintainers getting
them approve us as comaintainers, it's a lengthy process I agree. But it's not
that hard to ask for co-maintainership so one gets commit rights. I wonder whether someone
refused to give commit rights for someone wanting to add systemd support in his package?
People should finally understand that by threatening and over-bureaucracy nothing will
improve. When someone wants to see a feature done he should get his hands dirty in all
aspects - do the changes, find the maintainer, talk to them, get commit rights or get them
to push changes, do builds if needed. We ship a distribution so if someone do something
but doesn't integrate with the rest we have nothing. And integration is collaboration
it's not something one can enforce with bureacracy.

Alex

Alex

>  --
>  Matthias Runge <mrunge(a)matthias-runge.de&gt;
>                 <mrunge(a)fedoraproject.org&gt;
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Vít Ondruch]

Dne 2.3.2012 13:19, Aleksandar Kurtakov napsal(a):
>  ----- Original Message -----
> > From: "Matthias Runge"<mrunge(a)matthias-runge.de>
> > To: "Development discussions related to
> Fedora"<devel(a)lists.fedoraproject.org>
> > Sent: Friday, March 2, 2012 2:05:07 PM
> > Subject: Re: Automating the NonResponsiveMaintainers policy
> >
> > On 02/03/12 12:53, Marcela Mašláňová wrote:
> >> I'm afraid we end up with more bureaucracy than we have now. I'm
> >> not
> >> against tracking some statistics, so you can look up who is active
> >> and
> >> probably will answer in few days, but I'd rather not use it for the
> >> unresponsive process.
> >>
> >> Marcela
> > I'm thinking about how to support Jóhann with a proven packager (or
> > two). Since it seems not wanted by Fesco, to give him the
> > corresponding
> > rights to commit his changes directly? This final target (all
> > services
> > are supported by systemd) seems to be clear to everyone.
>  This is a noble goal and I wish this finishes sooner. But attacking packagers by
> threatening is not gaining any support for the efforts.
>  Most of us gained their commit rights by talking to the respective maintainers getting
> them approve us as comaintainers, it's a lengthy process I agree. But it's not
> that hard to ask for co-maintainership so one gets commit rights. I wonder whether someone
> refused to give commit rights for someone wanting to add systemd support in his package?
>  People should finally understand that by threatening and over-bureaucracy nothing will
> improve. When someone wants to see a feature done he should get his hands dirty in all
> aspects - do the changes, find the maintainer, talk to them, get commit rights or get them
> to push changes, do builds if needed. We ship a distribution so if someone do something
> but doesn't integrate with the rest we have nothing. And integration is collaboration
> it's not something one can enforce with bureacracy. 
Alex,

Don't be so touchy please. The truth is somewhere in between. There are 
maintainers who do not respond for whatever reason and there are others 
who are solving reported issue in a minute. I don't believe that it was 
meant to threaten anybody. You read the "Automating the 
NonResponsiveMaintainers policy" as "remove the original maintainer" or 
"punish him" but it might be very well read in opposite way, exactly as 
you proposed. There is no need for drama.


Vit


>  Alex
>
>  Alex
>
> > --
> > Matthias Runge<mrunge(a)matthias-runge.de>
> >                 <mrunge(a)fedoraproject.org&gt;
> > --
> > devel mailing list
> > devel(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Friday, March 2, 2012 2:37:53 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  Dne 2.3.2012 13:19, Aleksandar Kurtakov napsal(a):
>  >
>  > ----- Original Message -----
>  >> From: "Matthias Runge&quot;&lt;mrunge(a)matthias-runge.de&gt;
>  >> To: "Development discussions related to
>  >> Fedora&quot;&lt;devel(a)lists.fedoraproject.org&gt;
>  >> Sent: Friday, March 2, 2012 2:05:07 PM
>  >> Subject: Re: Automating the NonResponsiveMaintainers policy
>  >>
>  >> On 02/03/12 12:53, Marcela Mašláňová wrote:
>  >>> I'm afraid we end up with more bureaucracy than we have now. I'm
>  >>> not
>  >>> against tracking some statistics, so you can look up who is
>  >>> active
>  >>> and
>  >>> probably will answer in few days, but I'd rather not use it for
>  >>> the
>  >>> unresponsive process.
>  >>>
>  >>> Marcela
>  >> I'm thinking about how to support Jóhann with a proven packager
>  >> (or
>  >> two). Since it seems not wanted by Fesco, to give him the
>  >> corresponding
>  >> rights to commit his changes directly? This final target (all
>  >> services
>  >> are supported by systemd) seems to be clear to everyone.
>  > This is a noble goal and I wish this finishes sooner. But attacking
>  > packagers by threatening is not gaining any support for the
>  > efforts.
>  > Most of us gained their commit rights by talking to the respective
>  > maintainers getting them approve us as comaintainers, it's a
>  > lengthy process I agree. But it's not that hard to ask for
>  > co-maintainership so one gets commit rights. I wonder whether
>  > someone refused to give commit rights for someone wanting to add
>  > systemd support in his package?
>  > People should finally understand that by threatening and
>  > over-bureaucracy nothing will improve. When someone wants to see a
>  > feature done he should get his hands dirty in all aspects - do the
>  > changes, find the maintainer, talk to them, get commit rights or
>  > get them to push changes, do builds if needed. We ship a
>  > distribution so if someone do something but doesn't integrate with
>  > the rest we have nothing. And integration is collaboration it's
>  > not something one can enforce with bureacracy.
>  
>  Alex,
>  
>  Don't be so touchy please. The truth is somewhere in between. There
>  are
>  maintainers who do not respond for whatever reason and there are
>  others
>  who are solving reported issue in a minute. I don't believe that it
>  was
>  meant to threaten anybody. You read the "Automating the
>  NonResponsiveMaintainers policy" as "remove the original maintainer"
>  or
>  "punish him" but it might be very well read in opposite way, exactly
>  as
>  you proposed. There is no need for drama. 
This is not the first discussion on the topic I'm involved into. There are such
maintainers I agree. But what is the problem with the current NonResponsiveMaintainers
policy? How would you automate this? And asking to do it in a week? 
Every packager deserves at least the few steps described into the  current procedure. 

Alex

>  
>  
>  Vit
>  
>  
>  >
>  > Alex
>  >
>  > Alex
>  >
>  >> --
>  >> Matthias Runge&lt;mrunge(a)matthias-runge.de&gt;
>  >>                 <mrunge(a)fedoraproject.org&gt;
>  >> --
>  >> devel mailing list
>  >> devel(a)lists.fedoraproject.org
>  >> https://admin.fedoraproject.org/mailman/listinfo/devel
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Vít Ondruch]

Dne 2.3.2012 13:47, Aleksandar Kurtakov napsal(a):
>  ----- Original Message -----
> > From: "Vít Ondruch"<vondruch(a)redhat.com>
> > To: devel(a)lists.fedoraproject.org
> > Sent: Friday, March 2, 2012 2:37:53 PM
> > Subject: Re: Automating the NonResponsiveMaintainers policy
> >
> > Dne 2.3.2012 13:19, Aleksandar Kurtakov napsal(a):
> >> ----- Original Message -----
> >>> From: "Matthias Runge"<mrunge(a)matthias-runge.de>
> >>> To: "Development discussions related to
> >>> Fedora"<devel(a)lists.fedoraproject.org>
> >>> Sent: Friday, March 2, 2012 2:05:07 PM
> >>> Subject: Re: Automating the NonResponsiveMaintainers policy
> >>>
> >>> On 02/03/12 12:53, Marcela Mašláňová wrote:
> >>>> I'm afraid we end up with more bureaucracy than we have now. I'm
> >>>> not
> >>>> against tracking some statistics, so you can look up who is
> >>>> active
> >>>> and
> >>>> probably will answer in few days, but I'd rather not use it for
> >>>> the
> >>>> unresponsive process.
> >>>>
> >>>> Marcela
> >>> I'm thinking about how to support Jóhann with a proven packager
> >>> (or
> >>> two). Since it seems not wanted by Fesco, to give him the
> >>> corresponding
> >>> rights to commit his changes directly? This final target (all
> >>> services
> >>> are supported by systemd) seems to be clear to everyone.
> >> This is a noble goal and I wish this finishes sooner. But attacking
> >> packagers by threatening is not gaining any support for the
> >> efforts.
> >> Most of us gained their commit rights by talking to the respective
> >> maintainers getting them approve us as comaintainers, it's a
> >> lengthy process I agree. But it's not that hard to ask for
> >> co-maintainership so one gets commit rights. I wonder whether
> >> someone refused to give commit rights for someone wanting to add
> >> systemd support in his package?
> >> People should finally understand that by threatening and
> >> over-bureaucracy nothing will improve. When someone wants to see a
> >> feature done he should get his hands dirty in all aspects - do the
> >> changes, find the maintainer, talk to them, get commit rights or
> >> get them to push changes, do builds if needed. We ship a
> >> distribution so if someone do something but doesn't integrate with
> >> the rest we have nothing. And integration is collaboration it's
> >> not something one can enforce with bureacracy.
> > Alex,
> >
> > Don't be so touchy please. The truth is somewhere in between. There
> > are
> > maintainers who do not respond for whatever reason and there are
> > others
> > who are solving reported issue in a minute. I don't believe that it
> > was
> > meant to threaten anybody. You read the "Automating the
> > NonResponsiveMaintainers policy" as "remove the original maintainer"
> > or
> > "punish him" but it might be very well read in opposite way, exactly
> > as
> > you proposed. There is no need for drama.
>  This is not the first discussion on the topic I'm involved into. There are such
> maintainers I agree. But what is the problem with the current NonResponsiveMaintainers
> policy? How would you automate this? And asking to do it in a week?
>  Every packager deserves at least the few steps described into the  current procedure.
The current procedure is a pain ... and it happens that after month of 
waiting, maintainer suddenly appear and (s)he is really angry "how dare 
you can call me unresponsive when I am just busy with other 
projects/live". This is not good from opposite side. And that happened 
to me. So current procedure is at least pretty vague and there is no 
support in kind of some infrastructure. You have to check "hmm, is it 
already week since I last pinged somebody on BZ or ML? Hm, not yet. Ok, 
I'll wait".


Vit

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Friday, March 2, 2012 2:54:52 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  Dne 2.3.2012 13:47, Aleksandar Kurtakov napsal(a):
>  >
>  > ----- Original Message -----
>  >> From: "Vít Ondruch&quot;&lt;vondruch(a)redhat.com&gt;
>  >> To: devel(a)lists.fedoraproject.org
>  >> Sent: Friday, March 2, 2012 2:37:53 PM
>  >> Subject: Re: Automating the NonResponsiveMaintainers policy
>  >>
>  >> Dne 2.3.2012 13:19, Aleksandar Kurtakov napsal(a):
>  >>> ----- Original Message -----
>  >>>> From: "Matthias Runge&quot;&lt;mrunge(a)matthias-runge.de&gt;
>  >>>> To: "Development discussions related to
>  >>>> Fedora&quot;&lt;devel(a)lists.fedoraproject.org&gt;
>  >>>> Sent: Friday, March 2, 2012 2:05:07 PM
>  >>>> Subject: Re: Automating the NonResponsiveMaintainers policy
>  >>>>
>  >>>> On 02/03/12 12:53, Marcela Mašláňová wrote:
>  >>>>> I'm afraid we end up with more bureaucracy than we have now.
>  >>>>> I'm
>  >>>>> not
>  >>>>> against tracking some statistics, so you can look up who is
>  >>>>> active
>  >>>>> and
>  >>>>> probably will answer in few days, but I'd rather not use it for
>  >>>>> the
>  >>>>> unresponsive process.
>  >>>>>
>  >>>>> Marcela
>  >>>> I'm thinking about how to support Jóhann with a proven packager
>  >>>> (or
>  >>>> two). Since it seems not wanted by Fesco, to give him the
>  >>>> corresponding
>  >>>> rights to commit his changes directly? This final target (all
>  >>>> services
>  >>>> are supported by systemd) seems to be clear to everyone.
>  >>> This is a noble goal and I wish this finishes sooner. But
>  >>> attacking
>  >>> packagers by threatening is not gaining any support for the
>  >>> efforts.
>  >>> Most of us gained their commit rights by talking to the
>  >>> respective
>  >>> maintainers getting them approve us as comaintainers, it's a
>  >>> lengthy process I agree. But it's not that hard to ask for
>  >>> co-maintainership so one gets commit rights. I wonder whether
>  >>> someone refused to give commit rights for someone wanting to add
>  >>> systemd support in his package?
>  >>> People should finally understand that by threatening and
>  >>> over-bureaucracy nothing will improve. When someone wants to see
>  >>> a
>  >>> feature done he should get his hands dirty in all aspects - do
>  >>> the
>  >>> changes, find the maintainer, talk to them, get commit rights or
>  >>> get them to push changes, do builds if needed. We ship a
>  >>> distribution so if someone do something but doesn't integrate
>  >>> with
>  >>> the rest we have nothing. And integration is collaboration it's
>  >>> not something one can enforce with bureacracy.
>  >> Alex,
>  >>
>  >> Don't be so touchy please. The truth is somewhere in between.
>  >> There
>  >> are
>  >> maintainers who do not respond for whatever reason and there are
>  >> others
>  >> who are solving reported issue in a minute. I don't believe that
>  >> it
>  >> was
>  >> meant to threaten anybody. You read the "Automating the
>  >> NonResponsiveMaintainers policy" as "remove the original
>  >> maintainer"
>  >> or
>  >> "punish him" but it might be very well read in opposite way,
>  >> exactly
>  >> as
>  >> you proposed. There is no need for drama.
>  > This is not the first discussion on the topic I'm involved into.
>  > There are such maintainers I agree. But what is the problem with
>  > the current NonResponsiveMaintainers policy? How would you
>  > automate this? And asking to do it in a week?
>  > Every packager deserves at least the few steps described into the
>  >  current procedure.
>  
>  The current procedure is a pain ... and it happens that after month
>  of
>  waiting, maintainer suddenly appear and (s)he is really angry "how
>  dare
>  you can call me unresponsive when I am just busy with other
>  projects/live". This is not good from opposite side. And that
>  happened
>  to me. So current procedure is at least pretty vague and there is no
>  support in kind of some infrastructure. You have to check "hmm, is it
>  already week since I last pinged somebody on BZ or ML? Hm, not yet.
>  Ok,
>  I'll wait". 
You see, the maintainer is not unresponsive. Noone can expect
everyone to jump in immediately (week is close to that).
If you get your commit rights automatically, no problem for anyone, right?

Alex

>  
>  
>  Vit
>  
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Aleksandar Kurtakov" <akurtako(a)redhat.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Friday, March 2, 2012 3:08:26 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  
>  
>  ----- Original Message -----
>  > From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  > To: devel(a)lists.fedoraproject.org
>  > Sent: Friday, March 2, 2012 2:54:52 PM
>  > Subject: Re: Automating the NonResponsiveMaintainers policy
>  > 
>  > Dne 2.3.2012 13:47, Aleksandar Kurtakov napsal(a):
>  > >
>  > > ----- Original Message -----
>  > >> From: "Vít Ondruch&quot;&lt;vondruch(a)redhat.com&gt;
>  > >> To: devel(a)lists.fedoraproject.org
>  > >> Sent: Friday, March 2, 2012 2:37:53 PM
>  > >> Subject: Re: Automating the NonResponsiveMaintainers policy
>  > >>
>  > >> Dne 2.3.2012 13:19, Aleksandar Kurtakov napsal(a):
>  > >>> ----- Original Message -----
>  > >>>> From: "Matthias Runge&quot;&lt;mrunge(a)matthias-runge.de&gt;
>  > >>>> To: "Development discussions related to
>  > >>>> Fedora&quot;&lt;devel(a)lists.fedoraproject.org&gt;
>  > >>>> Sent: Friday, March 2, 2012 2:05:07 PM
>  > >>>> Subject: Re: Automating the NonResponsiveMaintainers policy
>  > >>>>
>  > >>>> On 02/03/12 12:53, Marcela Mašláňová wrote:
>  > >>>>> I'm afraid we end up with more bureaucracy than we have
> now.
>  > >>>>> I'm
>  > >>>>> not
>  > >>>>> against tracking some statistics, so you can look up who is
>  > >>>>> active
>  > >>>>> and
>  > >>>>> probably will answer in few days, but I'd rather not use
> it
>  > >>>>> for
>  > >>>>> the
>  > >>>>> unresponsive process.
>  > >>>>>
>  > >>>>> Marcela
>  > >>>> I'm thinking about how to support Jóhann with a proven
>  > >>>> packager
>  > >>>> (or
>  > >>>> two). Since it seems not wanted by Fesco, to give him the
>  > >>>> corresponding
>  > >>>> rights to commit his changes directly? This final target (all
>  > >>>> services
>  > >>>> are supported by systemd) seems to be clear to everyone.
>  > >>> This is a noble goal and I wish this finishes sooner. But
>  > >>> attacking
>  > >>> packagers by threatening is not gaining any support for the
>  > >>> efforts.
>  > >>> Most of us gained their commit rights by talking to the
>  > >>> respective
>  > >>> maintainers getting them approve us as comaintainers, it's a
>  > >>> lengthy process I agree. But it's not that hard to ask for
>  > >>> co-maintainership so one gets commit rights. I wonder whether
>  > >>> someone refused to give commit rights for someone wanting to
>  > >>> add
>  > >>> systemd support in his package?
>  > >>> People should finally understand that by threatening and
>  > >>> over-bureaucracy nothing will improve. When someone wants to
>  > >>> see
>  > >>> a
>  > >>> feature done he should get his hands dirty in all aspects - do
>  > >>> the
>  > >>> changes, find the maintainer, talk to them, get commit rights
>  > >>> or
>  > >>> get them to push changes, do builds if needed. We ship a
>  > >>> distribution so if someone do something but doesn't integrate
>  > >>> with
>  > >>> the rest we have nothing. And integration is collaboration it's
>  > >>> not something one can enforce with bureacracy.
>  > >> Alex,
>  > >>
>  > >> Don't be so touchy please. The truth is somewhere in between.
>  > >> There
>  > >> are
>  > >> maintainers who do not respond for whatever reason and there are
>  > >> others
>  > >> who are solving reported issue in a minute. I don't believe that
>  > >> it
>  > >> was
>  > >> meant to threaten anybody. You read the "Automating the
>  > >> NonResponsiveMaintainers policy" as "remove the original
>  > >> maintainer"
>  > >> or
>  > >> "punish him" but it might be very well read in opposite way,
>  > >> exactly
>  > >> as
>  > >> you proposed. There is no need for drama.
>  > > This is not the first discussion on the topic I'm involved into.
>  > > There are such maintainers I agree. But what is the problem with
>  > > the current NonResponsiveMaintainers policy? How would you
>  > > automate this? And asking to do it in a week?
>  > > Every packager deserves at least the few steps described into the
>  > >  current procedure.
>  > 
>  > The current procedure is a pain ... and it happens that after month
>  > of
>  > waiting, maintainer suddenly appear and (s)he is really angry "how
>  > dare
>  > you can call me unresponsive when I am just busy with other
>  > projects/live". This is not good from opposite side. And that
>  > happened
>  > to me. So current procedure is at least pretty vague and there is
>  > no
>  > support in kind of some infrastructure. You have to check "hmm, is
>  > it
>  > already week since I last pinged somebody on BZ or ML? Hm, not yet.
>  > Ok,
>  > I'll wait".
>  You see, the maintainer is not unresponsive. Noone can expect
>  everyone to jump in immediately (week is close to that).
>  If you get your commit rights automatically, no problem for anyone,
>  right? 
Probably extending the current process with give me commit rights step on the second week
via fesco/fpc ticket?

Alex


>  
>  Alex
>  
>  > 
>  > 
>  > Vit
>  > 
>  > 
>  > --
>  > devel mailing list
>  > devel(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/devel
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Jóhann B. Guðmundsson]

On 03/02/2012 12:37 PM, Vít Ondruch wrote:
>  Don't be so touchy please. The truth is somewhere in between. There 
>  are maintainers who do not respond for whatever reason and there are 
>  others who are solving reported issue in a minute. I don't believe 
>  that it was meant to threaten anybody. You read the "Automating the 
>  NonResponsiveMaintainers policy" as "remove the original maintainer" 
>  or "punish him" but it might be very well read in opposite way, 
>  exactly as you proposed. There is no need for drama.  
This was meant to be read as " Automating the NonResponsiveMaintainers 
policy" not as an threat not as anykind of changes to the 
NonResponsiveMaintainers policy itself ( other than the process being 
automated as in the steps having to be performed by the reporter which 
he currently can do with any bug btw ) and the week period I put in 
there was because I currently had weekly run cron job in mind and the 
fact that the NonResponsiveMaintainers policy takes 3 weeks to complete 
from the reporters point of view with announcement to this list but that 
"week" could easily be turned into a "month" instead which would make
it 
month +3weeks

JBG

[Ralf Corsepius]

On 03/02/2012 12:12 PM, "Jóhann B. Guðmundsson" wrote:
>  On 03/02/2012 11:02 AM, Marcela Mašláňová wrote:
> > Ok, so you'll automatically start non-responsive maintainer process,
> > because maintainer didn't work on a one bug. But he might be working on
> > different component for whole month. He might be working on a new
> > upstream release and not paying attention to low priority bugzillas.
> >
> > You should take more parameters than one bug to kick someone from Fedora. 
The real point is: There is no strict parameter set, because the reasons 
for why reports get not addressed are manifold.

>  This is based on more then one bug against one component and through
>  observation in several release cycles.
>
>  If an maintainer does not want to be affected by the automatic non
>  responsive process all he would have to do would simply be something
>  like changing the report status from new to assigned and leave feed back
>  on it. 
I other words, all is proposal would be doing is to cause bureaucratic 
churn.

Ralf

[Jóhann B. Guðmundsson]

On 03/02/2012 01:34 PM, Ralf Corsepius wrote:
>  I other words, all is proposal would be doing is to cause bureaucratic 
>  churn. 
Well it only causes bureaucratic churn or otherwise inconvenience for 
non responding maintainers as in maintainers that do not respond to a 
report in timely manner + there is absolutely nothing preventing an 
reporter to initiate the non responsive policy manually as is.

This would just automate that process and there are several advantage of 
doing that.

JBG

[Vít Ondruch]

Dne 2.3.2012 12:02, Marcela Mašláňová napsal(a):
>  On 03/02/2012 11:20 AM, "Jóhann B. Guðmundsson" wrote:
> > I am a feature owner for a feature that involves components in the
> > hundreds and is heavily depended on maintainers responsiveness.
> >
> > For me to start enacting the non responsive maintainers policy is a
> > tremendous work thus I'm wondering if there is something preventing us
> > from automating the non responsive maintainer policy?
> >
> > An bugzilla script that acts something like if maintainer has not
> > responded to a bug report with the status new in a week ( or some other
> > time ) the non responsive maintainers policy automatically starts taking
> > effect.
>  Ok, so you'll automatically start non-responsive maintainer process,
>  because maintainer didn't work on a one bug. But he might be working on
>  different component for whole month. He might be working on a new
>  upstream release and not paying attention to low priority bugzillas.
>
>  You should take more parameters than one bug to kick someone from Fedora.
>
>  Marcela 
Actually I support such initiative. We have also filled a few bugs 
against Ruby components which needs some love due to Ruby update and it 
happens that we have no response. If there would be tool that reports 
"yes, the maintainer was active in some Fedora project 3 days ago", then 
it would be meaningful to nag him again, because the BZ was probably 
somewhere lost/forgotten, but if you see that the maintainer have been 
non-active for last 6 months, you know that you should probably start 
"NonResponsiveMaintainer" process.


Vit
> > To get out of that automatic non responsive process the maintainer would
> > have to comment on the bug and set it's status assigned ( or something
> > similar ).
> >
> > JBG

[Jóhann B. Guðmundsson]

On 03/02/2012 11:16 AM, Vít Ondruch wrote:
> >
>
>  Actually I support such initiative. We have also filled a few bugs 
>  against Ruby components which needs some love due to Ruby update and 
>  it happens that we have no response. If there would be tool that 
>  reports "yes, the maintainer was active in some Fedora project 3 days 
>  ago", then it would be meaningful to nag him again, because the BZ was 
>  probably somewhere lost/forgotten, but if you see that the maintainer 
>  have been non-active for last 6 months, you know that you should 
>  probably start "NonResponsiveMaintainer" process.  
Yeah I suspected that I was not alone in this regard since I am just 
dealing with ca 5% of packages in the distribution.

This could be beneficial in various project processes although I'm not 
familiar with how FPC ensures that FPG is being followed and is updated 
each time changes are made to the guidelines but let's assume they are 
using this workflow.

FPC makes changes to FPG -->

They then generate a list of packages affected by the change to FPG -->

They then file a report against all the component on the list were they 
state that the relevant package is affected by the change made by FPG 
and the spec file should be updated accordingly and maintainers should 
comment if they would they require the assistant of proven packager do 
to those changes for them and those changes should preferable be 
completed by this $DATE -->

A week ( or some other time ) later the component gets hit by the 
automatic non responsive policy which would allow proven packager only 
have to walk through components that have not been flagged non 
responsive and check if maintainers have asked for their assistant thus 
focusing their available time and energy only on responsive and actively 
maintainer.

JBG

[Vít Ondruch]

Dne 2.3.2012 12:56, "Jóhann B. Guðmundsson" napsal(a):
>  On 03/02/2012 11:16 AM, Vít Ondruch wrote:
> >>
> >
> > Actually I support such initiative. We have also filled a few bugs 
> > against Ruby components which needs some love due to Ruby update and 
> > it happens that we have no response. If there would be tool that 
> > reports "yes, the maintainer was active in some Fedora project 3 days 
> > ago", then it would be meaningful to nag him again, because the BZ 
> > was probably somewhere lost/forgotten, but if you see that the 
> > maintainer have been non-active for last 6 months, you know that you 
> > should probably start "NonResponsiveMaintainer" process. 
>
>  Yeah I suspected that I was not alone in this regard since I am just 
>  dealing with ca 5% of packages in the distribution.
>
>  This could be beneficial in various project processes although I'm not 
>  familiar with how FPC ensures that FPG is being followed and is 
>  updated each time changes are made to the guidelines but let's assume 
>  they are using this workflow. 
Are the changes enforced? I don't think so ...


Vit

[Jóhann B. Guðmundsson]

On 03/02/2012 12:03 PM, Vít Ondruch wrote:
>  Are the changes enforced? I don't think so ...  
Interesting which begs the question to which purpose do the guideline 
serve if no one is actually making sure that it's being followed?

JBG

[Toshio Kuratomi]

On Fri, Mar 02, 2012 at 12:37:40PM +0000, "Jóhann B. Guðmundsson" wrote:
>  On 03/02/2012 12:03 PM, Vít Ondruch wrote:
>  >
>  >Are the changes enforced? I don't think so ...
>  
>  Interesting which begs the question to which purpose do the guideline
>  serve if no one is actually making sure that it's being followed?
>   
Process looks like this:

* Guidelines updated
* Someone notices that the package does not follow the guidelines (Note that
  this step does not require that the Guidelines were updated... the
  packaging bug could have been missed during review or been introduced
  later).
* That person files a bug.
* If the maintainer chooses to ignore the bug or refuse to fix it then the
  matter is escalated.
  - In an ideal world, it would probably go to FPC as a "can we change the
    guidelines?  I have this special case which I don't think you intended."
  - In a less ideal world, or in  the case where the FPC has already made
    clear that they did intend it to apply in that case, it would fall on
    FESCo to enforce the decision.

How would fesco enforce the decision?  That would depend on the arguments
being made and the maintainer attitude.  For instance, if the maintainer
said, I simply don't have time to fix this, "enforcement" would probably
that someone would fix it for them and apply the patch to the spec file.

OTOH, if the maintainer decided that they were going to revert any change
made to the package to fix the issue, FESCo would have to remove the
maintainer from the package and tell them they could not be a committer on
that package for a period of time.  They might even remove the packager from
the packager group if the maintainer was uncooperative enough.enough.

-Toshio

[Jóhann B. Guðmundsson]

On 03/02/2012 03:21 PM, Toshio Kuratomi wrote:
>  Process looks like this:
>
>  * Guidelines updated
>  * Someone notices that the package does not follow the guidelines (Note that
>     this step does not require that the Guidelines were updated... the
>     packaging bug could have been missed during review or been introduced
>     later).
>  * That person files a bug.
>  * If the maintainer chooses to ignore the bug or refuse to fix it then the
>     matter is escalated.
>     - In an ideal world, it would probably go to FPC as a "can we change the
>       guidelines?  I have this special case which I don't think you intended."
>     - In a less ideal world, or in  the case where the FPC has already made
>       clear that they did intend it to apply in that case, it would fall on
>       FESCo to enforce the decision.
>
>  How would fesco enforce the decision?  That would depend on the arguments
>  being made and the maintainer attitude.  For instance, if the maintainer
>  said, I simply don't have time to fix this, "enforcement" would probably
>  that someone would fix it for them and apply the patch to the spec file.
>
>  OTOH, if the maintainer decided that they were going to revert any change
>  made to the package to fix the issue, FESCo would have to remove the
>  maintainer from the package and tell them they could not be a committer on
>  that package for a period of time.  They might even remove the packager from
>  the packager group if the maintainer was uncooperative enough.enough. 
Does FPC have any process to measure how many packages are affected by a 
single change made to guidelines?

If so is it hard to implement the process I mentioned which hopefully 
should keep packages according to guidelines and up to date?

JBG

[Marcela Mašláňová]

On 03/02/2012 04:27 PM, "Jóhann B. Guðmundsson" wrote:
>  On 03/02/2012 03:21 PM, Toshio Kuratomi wrote:
> > Process looks like this:
> >
> > * Guidelines updated
> > * Someone notices that the package does not follow the guidelines
> > (Note that
> >    this step does not require that the Guidelines were updated... the
> >    packaging bug could have been missed during review or been introduced
> >    later).
> > * That person files a bug.
> > * If the maintainer chooses to ignore the bug or refuse to fix it then
> > the
> >    matter is escalated.
> >    - In an ideal world, it would probably go to FPC as a "can we
> > change the
> >      guidelines?  I have this special case which I don't think you
> > intended."
> >    - In a less ideal world, or in  the case where the FPC has already
> > made
> >      clear that they did intend it to apply in that case, it would
> > fall on
> >      FESCo to enforce the decision.
> >
> > How would fesco enforce the decision?  That would depend on the arguments
> > being made and the maintainer attitude.  For instance, if the maintainer
> > said, I simply don't have time to fix this, "enforcement" would
> probably
> > that someone would fix it for them and apply the patch to the spec file.
> >
> > OTOH, if the maintainer decided that they were going to revert any change
> > made to the package to fix the issue, FESCo would have to remove the
> > maintainer from the package and tell them they could not be a
> > committer on
> > that package for a period of time.  They might even remove the
> > packager from
> > the packager group if the maintainer was uncooperative enough.enough.
>  
>  Does FPC have any process to measure how many packages are affected by a
>  single change made to guidelines?
>  
>  If so is it hard to implement the process I mentioned which hopefully
>  should keep packages according to guidelines and up to date?
>  
>  JBG 
You are looking for re-review of packages mentioned many times before.
But we have problems to find reviewers for new one, so I don't believe
we would find enough people for this.

Marcela

[Jóhann B. Guðmundsson]

On 03/02/2012 03:45 PM, Marcela Mašláňová wrote:
>  You are looking for re-review of packages mentioned many times
> before.
>  But we have problems to find reviewers for new one, so I don't believe
>  we would find enough people for this. 
If it's an manual process sure I can understand why it's hard to recruit 
people to do that stuff.

JBG

[Toshio Kuratomi]

On Fri, Mar 02, 2012 at 03:27:24PM +0000, "Jóhann B. Guðmundsson" wrote:
>  On 03/02/2012 03:21 PM, Toshio Kuratomi wrote:
>  >Process looks like this:
>  >
>  >* Guidelines updated
>  >* Someone notices that the package does not follow the guidelines (Note that
>  >   this step does not require that the Guidelines were updated... the
>  >   packaging bug could have been missed during review or been introduced
>  >   later).
>  >* That person files a bug.
>  >* If the maintainer chooses to ignore the bug or refuse to fix it then the
>  >   matter is escalated.
>  >   - In an ideal world, it would probably go to FPC as a "can we change the
>  >     guidelines?  I have this special case which I don't think you
> intended."
>  >   - In a less ideal world, or in  the case where the FPC has already made
>  >     clear that they did intend it to apply in that case, it would fall on
>  >     FESCo to enforce the decision.
>  >
>  >How would fesco enforce the decision?  That would depend on the arguments
>  >being made and the maintainer attitude.  For instance, if the maintainer
>  >said, I simply don't have time to fix this, "enforcement" would
> probably
>  >that someone would fix it for them and apply the patch to the spec file.
>  >
>  >OTOH, if the maintainer decided that they were going to revert any change
>  >made to the package to fix the issue, FESCo would have to remove the
>  >maintainer from the package and tell them they could not be a committer on
>  >that package for a period of time.  They might even remove the packager from
>  >the packager group if the maintainer was uncooperative enough.enough.
>  
>  Does FPC have any process to measure how many packages are affected
>  by a single change made to guidelines?
>  
>  If so is it hard to implement the process I mentioned which hopefully
>  should keep packages according to guidelines and up to date?
>   
There is no one method for the FPC.  When we pass guidelines we usually
do think about how many packages are affected but there's no general method
that we follow.

However, for most (not all but most) guideline changes, we don't tell people
that there's a hurry to fix things.  They can be fixed as people file bugs
and propose patches.  There are a few changes that are fixes that we feel
are necessary enough that we want to be proactive about fixing when the
guidelines change.  For those we are more strict about figuring out how much
work is involved.

-Toshio

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Friday, March 2, 2012 12:20:10 PM
>  Subject: Automating the NonResponsiveMaintainers policy
>  
>  I am a feature owner for a feature that involves components in the
>  hundreds and is heavily depended on maintainers responsiveness.
>  
>  For me to start enacting the non responsive maintainers policy is a
>  tremendous work thus I'm wondering if there is something preventing
>  us
>  from automating the non responsive maintainer policy?
>  
>  An bugzilla script that acts something like if maintainer has not
>  responded to a bug report with the status new in a week ( or some
>  other
>  time ) the non responsive maintainers policy automatically starts
>  taking
>  effect. 
Well, this is plain nonsense. Do you know how many bug reports do a number of the
packagers have ? 
And speaking for "A WEEK" is something that is even offensive. People tend to
take 2 weeks of vacation still.

So I would make a contra-proposal. 

If a maintainer doesn't respond to a bug repord with the status new in a week - give
commit rights to the reporter in pkgdb so he/she can fix it himself.

I really think this is way more fare and people that tend to think that packagers are just
a bunch of lazy guys should step in do some of this dirty work to get an idea what we
speak about.

Alex

>  
>  To get out of that automatic non responsive process the maintainer
>  would
>  have to comment on the bug and set it's status assigned ( or
>  something
>  similar ).
>  
>  JBG
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Marcela Mašláňová]

On 03/02/2012 12:52 PM, Aleksandar Kurtakov wrote:
>  
>  
>  ----- Original Message -----
> > From: "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;
> > To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
> > Sent: Friday, March 2, 2012 12:20:10 PM
> > Subject: Automating the NonResponsiveMaintainers policy
> >
> > I am a feature owner for a feature that involves components in the
> > hundreds and is heavily depended on maintainers responsiveness.
> >
> > For me to start enacting the non responsive maintainers policy is a
> > tremendous work thus I'm wondering if there is something preventing
> > us
> > from automating the non responsive maintainer policy?
> >
> > An bugzilla script that acts something like if maintainer has not
> > responded to a bug report with the status new in a week ( or some
> > other
> > time ) the non responsive maintainers policy automatically starts
> > taking
> > effect.
>  
>  Well, this is plain nonsense. Do you know how many bug reports do a number of the
> packagers have ? 
>  And speaking for "A WEEK" is something that is even offensive. People tend to
> take 2 weeks of vacation still.
>  
>  So I would make a contra-proposal. 
>  
>  If a maintainer doesn't respond to a bug repord with the status new in a week - give
> commit rights to the reporter in pkgdb so he/she can fix it himself.
>  
>  I really think this is way more fare and people that tend to think that packagers are
> just a bunch of lazy guys should step in do some of this dirty work to get an idea what we
> speak about.
>  
>  Alex 
I would change week to longer period, but it sound better than previous
proposal.

Marcela
>  
> >
> > To get out of that automatic non responsive process the maintainer
> > would
> > have to comment on the bug and set it's status assigned ( or
> > something
> > similar ).
> >
> > JBG
> > --
> > devel mailing list
> > devel(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Marcela Mašláňová" <mmaslano(a)redhat.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Friday, March 2, 2012 1:57:11 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  On 03/02/2012 12:52 PM, Aleksandar Kurtakov wrote:
>  > 
>  > 
>  > ----- Original Message -----
>  >> From: "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;
>  >> To: "Development discussions related to Fedora"
>  >> <devel(a)lists.fedoraproject.org&gt;
>  >> Sent: Friday, March 2, 2012 12:20:10 PM
>  >> Subject: Automating the NonResponsiveMaintainers policy
>  >>
>  >> I am a feature owner for a feature that involves components in the
>  >> hundreds and is heavily depended on maintainers responsiveness.
>  >>
>  >> For me to start enacting the non responsive maintainers policy is
>  >> a
>  >> tremendous work thus I'm wondering if there is something
>  >> preventing
>  >> us
>  >> from automating the non responsive maintainer policy?
>  >>
>  >> An bugzilla script that acts something like if maintainer has not
>  >> responded to a bug report with the status new in a week ( or some
>  >> other
>  >> time ) the non responsive maintainers policy automatically starts
>  >> taking
>  >> effect.
>  > 
>  > Well, this is plain nonsense. Do you know how many bug reports do a
>  > number of the packagers have ?
>  > And speaking for "A WEEK" is something that is even offensive.
>  > People tend to take 2 weeks of vacation still.
>  > 
>  > So I would make a contra-proposal.
>  > 
>  > If a maintainer doesn't respond to a bug repord with the status new
>  > in a week - give commit rights to the reporter in pkgdb so he/she
>  > can fix it himself.
>  > 
>  > I really think this is way more fare and people that tend to think
>  > that packagers are just a bunch of lazy guys should step in do
>  > some of this dirty work to get an idea what we speak about.
>  > 
>  > Alex
>  
>  I would change week to longer period, but it sound better than
>  previous
>  proposal. 
I said a week to make it close enough to the original proposal and as I said requesting
every packager to request in a week is something I even consider an insult.

Alex

>  
>  Marcela
>  > 
>  >>
>  >> To get out of that automatic non responsive process the maintainer
>  >> would
>  >> have to comment on the bug and set it's status assigned ( or
>  >> something
>  >> similar ).
>  >>
>  >> JBG
>  >> --
>  >> devel mailing list
>  >> devel(a)lists.fedoraproject.org
>  >> https://admin.fedoraproject.org/mailman/listinfo/devel
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Matthias Runge]

On 02/03/12 12:52, Aleksandar Kurtakov wrote:
>  
>  If a maintainer doesn't respond to a bug repord with the status 
>  new in a week - give commit rights to the reporter in pkgdb
>  so he/she can fix it himself. 
I kind a' like this proposal. You're speaking
of current package
maintainers getting commit rights automatically after a timespan,
right?

What about bug reporter being unable to fix the mentioned bug?
And does the bug-reporter get his right revoked after a time
(automatically?)
-- 
Matthias Runge <mrunge(a)matthias-runge.de&gt;
               <mrunge(a)fedoraproject.org&gt;

[Marcela Mašláňová]

On 03/02/2012 01:00 PM, Matthias Runge wrote:
>  On 02/03/12 12:52, Aleksandar Kurtakov wrote:
> >
> > If a maintainer doesn't respond to a bug repord with the status 
> > new in a week - give commit rights to the reporter in pkgdb
> > so he/she can fix it himself.
>  I kind a' like this proposal. You're speaking of current package
>  maintainers getting commit rights automatically after a timespan,
>  right?
>  
>  What about bug reporter being unable to fix the mentioned bug?
>  And does the bug-reporter get his right revoked after a time
>  (automatically?) 
Yes, I would be afraid that reporters won't be able to fix it properly.
Even if I'm a provenpackager, I don't commit into packages not related
to mine.

Marcela

[Matthias Runge]

On 02/03/12 13:06, Marcela Mašláňová wrote:
>  Yes, I would be afraid that reporters won't be able to fix it
>  properly. Even if I'm a provenpackager, I don't commit into
>  packages not related to mine. 
Yes, I guess, that's a more general problem. But
since we have proven
packagers, they might jump in in this limited case.

-- 
Matthias Runge <mrunge(a)matthias-runge.de&gt;
               <mrunge(a)fedoraproject.org&gt;

[Reindl Harald]

Am 02.03.2012 13:00, schrieb Matthias Runge:
>  On 02/03/12 12:52, Aleksandar Kurtakov wrote:
> >
> > If a maintainer doesn't respond to a bug repord with the status 
> > new in a week - give commit rights to the reporter in pkgdb
> > so he/she can fix it himself.
>  I kind a' like this proposal. You're speaking of current package
>  maintainers getting commit rights automatically after a timespan,
>  right?
>  
>  What about bug reporter being unable to fix the mentioned bug?
>  And does the bug-reporter get his right revoked after a time
>  (automatically?) 
you are missing the differences between "ignored", "assigend" and
"fixed"
where did you see a line that a bug must be fixed in whatever time?
you did not because it is not there

the point is that if a reporter takes time to file a bugreport
he can expect any response - this response may be change status
from "new" to "assigend" even without any comment

if you now saying that a maintainer has not the time to do this
simple step realize that the reporter in the future has no time
to report any bugs for nothing and that if the "assigned" is
tto much work the maintainer has really other problems and
appearently no time to maintain the package any longer

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Reindl Harald" <h.reindl(a)thelounge.net&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Friday, March 2, 2012 2:09:00 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  
>  
>  Am 02.03.2012 13:00, schrieb Matthias Runge:
>  > On 02/03/12 12:52, Aleksandar Kurtakov wrote:
>  >>
>  >> If a maintainer doesn't respond to a bug repord with the status
>  >> new in a week - give commit rights to the reporter in pkgdb
>  >> so he/she can fix it himself.
>  > I kind a' like this proposal. You're speaking of current package
>  > maintainers getting commit rights automatically after a timespan,
>  > right?
>  > 
>  > What about bug reporter being unable to fix the mentioned bug?
>  > And does the bug-reporter get his right revoked after a time
>  > (automatically?)
>  
>  you are missing the differences between "ignored", "assigend" and
>  "fixed"
>  where did you see a line that a bug must be fixed in whatever time?
>  you did not because it is not there
>  
>  the point is that if a reporter takes time to file a bugreport
>  he can expect any response - this response may be change status
>  from "new" to "assigend" even without any comment
>  
>  if you now saying that a maintainer has not the time to do this
>  simple step realize that the reporter in the future has no time
>  to report any bugs for nothing and that if the "assigned" is
>  tto much work the maintainer has really other problems and
>  appearently no time to maintain the package any longer 
So are you saying that every one that finds a bug will obey and report that bug?
Once someone manages to enforce this he/she can try to give orders to others about their
workflow.
Let's agree on that - there are different people with different workflows and etc.
If the packager has no rights to say how/when/what will be tested and used I don't see
a reason why the reported should be able to give this orders to the packager.
It's evolutionary - this way the good packages with good maintainers will survive by
people either moving to such packages or becoming maintainers.

Alex


>  
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Karel Zak]

On Fri, Mar 02, 2012 at 01:09:00PM +0100, Reindl Harald wrote:
>  you are missing the differences between "ignored",
> "assigend" and "fixed"
>  where did you see a line that a bug must be fixed in whatever time?
>  you did not because it is not there
>  
>  the point is that if a reporter takes time to file a bugreport
>  he can expect any response - this response may be change status 
 It seems that you expect professional support service from
 volunteers. Please, use an enterprise Linux distro if you have such
 expectations. I have no clue why we should guarantee you any response
 time.

>  from "new" to "assigend" even without any comment
 For example I usually use "assigned" only if I'm sure that the report
 is real issue and I'm able to fix it.

>  if you now saying that a maintainer has not the time to do this
>  simple step realize that the reporter in the future has no time
>  to report any bugs for nothing and that if the "assigned" is
>  tto much work the maintainer has really other problems and
>  appearently no time to maintain the package any longer 
 Freedom is about responsibility. I believe that Fedora maintainers
 love freedom. The idea that responsibility is possible to replaced
 with bureaucracy, processes and meetings is old, unoriginal and
 wrong.

    Karel


-- 
 Karel Zak  <kzak(a)redhat.com&gt;
 http://karelzak.blogspot.com

[Reindl Harald]

Am 02.03.2012 17:20, schrieb Karel Zak:
>  On Fri, Mar 02, 2012 at 01:09:00PM +0100, Reindl Harald wrote:
> > you are missing the differences between "ignored", "assigend" and
> "fixed"
> > where did you see a line that a bug must be fixed in whatever time?
> > you did not because it is not there
> >
> > the point is that if a reporter takes time to file a bugreport
> > he can expect any response - this response may be change status
>  
>   It seems that you expect professional support service from
>   volunteers. Please, use an enterprise Linux distro if you have such
>   expectations. I have no clue why we should guarantee you any response
>   time. 
i expect only the same i do since years for all things

if i take resposibility i answer requests or do not take over resposibility
paid and not is irrelevant here

this has NOTHING to do with enterprise
do you pay the reporter for his time?
no? so do not spit in his face by ignore him!

there are people contributing with their time writing a
bugreport - this is in the interest of ALL

> > from "new" to "assigend" even without any
> comment
>  
>   For example I usually use "assigned" only if I'm sure that the report
>   is real issue and I'm able to fix it. 
for the example if you make a single comment "thank you for your report,
i am currently busy.... whatever phrase" you will not fall from your
throne and give the reporter a nice and acceptable feedback

>   Freedom is about responsibility. I believe that Fedora maintainers
>   love freedom. The idea that responsibility is possible to replaced
>   with bureaucracy, processes and meetings is old, unoriginal and
>   wrong 
responsibility is the right word but missing in fedora often
everybody is free to do everything or nothing
i agree this is good - but it does not work in the real world
because this needs people showing responsibility in the way
how tey are acting and not only using the word

it does simply not matter if someoney doing things for free
or for money - if someone does for money i would even understand
the no-response-attitude, if someone says he do things because he
likes them no understanding for this

one point of responsibility is taking some seconds of your
time to give ANY response after people spent time and
decided try to help making things better or they will
sooner or later deicde no longer waste their time!

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Matthias Runge" <mrunge(a)matthias-runge.de&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Friday, March 2, 2012 2:00:32 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  On 02/03/12 12:52, Aleksandar Kurtakov wrote:
>  > 
>  > If a maintainer doesn't respond to a bug repord with the status
>  > new in a week - give commit rights to the reporter in pkgdb
>  > so he/she can fix it himself.
>  I kind a' like this proposal. You're speaking of current package
>  maintainers getting commit rights automatically after a timespan,
>  right? 
TBH, I was really shocked by the proposal and this was the first thing that came to my
mind - let the reporters join instead of throwing out people.

Yes, current package maintainers should get commit rights after a timespan. Probably there
is no need to do it for sponsors and provenpackagers as they already can commit.

>  
>  What about bug reporter being unable to fix the mentioned bug? 
Well, this is what
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_gro...
is for, right? The reporter should find a sponsor to review his patch and sponsor him. If
he is unable to fix the issue for another reason this is out of scope for this talk
because throwing out the maintainer wouldn't help the reporter for sure.

>  And does the bug-reporter get his right revoked after a time
>  (automatically?) 
No need.

Alex

>  --
>  Matthias Runge <mrunge(a)matthias-runge.de&gt;
>                 <mrunge(a)fedoraproject.org&gt;
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Matthias Runge]

On 02/03/12 13:10, Aleksandar Kurtakov wrote:
>  What about bug reporter being unable to fix the mentioned bug?
Oh no. I'm mean unable to fix because of missing knowledge, not
unable because of missing commit rights.

I might file a bug against kernel, but I'm definitely not the right
person to patch there. (You might substitute kernel with everything
you want, just to make the picture).

I'm a bit puzzled by quick-and-dirty 'fixes' which may lead to errors
somewhere else.
-- 
Matthias Runge <mrunge(a)matthias-runge.de&gt;
               <mrunge(a)fedoraproject.org&gt;

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Matthias Runge" <mrunge(a)matthias-runge.de&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Friday, March 2, 2012 2:15:51 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  On 02/03/12 13:10, Aleksandar Kurtakov wrote:
>  > What about bug reporter being unable to fix the mentioned bug?
>  Oh no. I'm mean unable to fix because of missing knowledge, not
>  unable because of missing commit rights.
>  
>  I might file a bug against kernel, but I'm definitely not the right
>  person to patch there. (You might substitute kernel with everything
>  you want, just to make the picture).
>  
>  I'm a bit puzzled by quick-and-dirty 'fixes' which may lead to errors
>  somewhere else. 
Well, the whole idea came in a second so someone should refine it. FWIW the period should
be long enough - in my eyes not less than a months so if noone responded in like 3 months
the fix would no longer be at least quick. And as always we trust people to do the right
and have a good understanding of their capabilities and knowledge. No proposal/technology
can prevent bad intentions.

Alex

>  --
>  Matthias Runge <mrunge(a)matthias-runge.de&gt;
>                 <mrunge(a)fedoraproject.org&gt;
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Matthias Runge]

On 02/03/12 13:24, Aleksandar Kurtakov wrote:
>  Well, the whole idea came in a second so someone should refine it.
>  FWIW the period should be long enough - in my eyes not less than a
>  months so if noone responded in like 3 months the fix would no longer
>  be at least quick. And as always we trust people to do the right and
>  have a good understanding of their capabilities and knowledge. No
>  proposal/technology can prevent bad intentions. 
Yes, I guess, many people have very
different time frame in their heads.

If we'd like to try this out, what would be the right way to propose
this change?
-- 
Matthias Runge <mrunge(a)matthias-runge.de&gt;
               <mrunge(a)fedoraproject.org&gt;

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Matthias Runge" <mrunge(a)matthias-runge.de&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Friday, March 2, 2012 2:34:11 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  On 02/03/12 13:24, Aleksandar Kurtakov wrote:
>  > Well, the whole idea came in a second so someone should refine it.
>  > FWIW the period should be long enough - in my eyes not less than a
>  > months so if noone responded in like 3 months the fix would no
>  > longer
>  > be at least quick. And as always we trust people to do the right
>  > and
>  > have a good understanding of their capabilities and knowledge. No
>  > proposal/technology can prevent bad intentions.
>  Yes, I guess, many people have very different time frame in their
>  heads.
>  
>  If we'd like to try this out, what would be the right way to propose
>  this change? 
I really have no idea nor I would have the time to deal with such thing anytime soon as it
will also require development work if accepted. The current process works fine for me. I
just wanted to show that there are better way than throwing out people.

Alex

>  --
>  Matthias Runge <mrunge(a)matthias-runge.de&gt;
>                 <mrunge(a)fedoraproject.org&gt;
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Matthias Runge]

On 02/03/12 13:37, Aleksandar Kurtakov wrote:
>  I really have no idea nor I would have the time to deal with such
>  thing anytime soon as it will also require development work if
>  accepted. The current process works fine for me. I just wanted to
>  show that there are better way than throwing out people. 
Ok, agreed, My question
was merely academic. Who to contact, if...

I didn't ran into a limitation so far. Ok, once or twice. In total
the system works well. Changing a large number of packages is
surely a corner case.
-- 
Matthias Runge <mrunge(a)matthias-runge.de&gt;
               <mrunge(a)fedoraproject.org&gt;

[Panu Matilainen]

On 03/02/2012 02:00 PM, Matthias Runge wrote:
>  On 02/03/12 12:52, Aleksandar Kurtakov wrote:
> >
> > If a maintainer doesn't respond to a bug repord with the status
> > new in a week - give commit rights to the reporter in pkgdb
> > so he/she can fix it himself.
>  I kind a' like this proposal. You're speaking of current package
>  maintainers getting commit rights automatically after a timespan,
>  right?
>
>  What about bug reporter being unable to fix the mentioned bug?
>  And does the bug-reporter get his right revoked after a time
>  (automatically?) 
Not to mention bug reporter not necessarily understanding the full 
consequences of a change - change that might look trivial but has 
world-breaking effects.

And FWIW, four week vacations are common in this part of the world...

	- Panu -

[Matthias Runge]

On 02/03/12 13:16, Panu Matilainen wrote:
>  Not to mention bug reporter not necessarily understanding the full
>  consequences of a change - change that might look trivial but has
>  world-breaking effects.
>  
>  And FWIW, four week vacations are common in this part of the world...
>  
>      - Panu - 
Absolutely. I think, this can not (easily) be automated.

I would prefer to have a manual selection of packagers
getting access, something like proven packagers.
(I know, this leads to bureaucracy and should be avoided)

Accidental mistakes can happen, at least proven packagers
know, how to revert this.

What about: getting more proven packagers?
Make them more prominent, i.e. making it easier to contact
them?
-- 
Matthias Runge <mrunge(a)matthias-runge.de&gt;
               <mrunge(a)fedoraproject.org&gt;

[Vít Ondruch]

Dne 2.3.2012 12:52, Aleksandar Kurtakov napsal(a):
>  ----- Original Message -----
> > From: "Jóhann B. Guðmundsson"<johannbg(a)gmail.com>
> > To: "Development discussions related to
> Fedora"<devel(a)lists.fedoraproject.org>
> > Sent: Friday, March 2, 2012 12:20:10 PM
> > Subject: Automating the NonResponsiveMaintainers policy
> >
> > I am a feature owner for a feature that involves components in the
> > hundreds and is heavily depended on maintainers responsiveness.
> >
> > For me to start enacting the non responsive maintainers policy is a
> > tremendous work thus I'm wondering if there is something preventing
> > us
> > from automating the non responsive maintainer policy?
> >
> > An bugzilla script that acts something like if maintainer has not
> > responded to a bug report with the status new in a week ( or some
> > other
> > time ) the non responsive maintainers policy automatically starts
> > taking
> > effect.
>  Well, this is plain nonsense. Do you know how many bug reports do a number of the
> packagers have ?
>  And speaking for "A WEEK" is something that is even offensive. People tend to
> take 2 weeks of vacation still.
>
>  So I would make a contra-proposal.
>
>  If a maintainer doesn't respond to a bug repord with the status new in a week - give
> commit rights to the reporter in pkgdb so he/she can fix it himself.
>
>  I really think this is way more fare and people that tend to think that packagers are
> just a bunch of lazy guys should step in do some of this dirty work to get an idea what we
> speak about.
>
>  Alex 
But what if that is one bug who the maintainer don't want touch ATM 
although he fixes others? I have my own priorities and as long as there 
is no time for some bug, I'm not touching it at all. So one bug is not 
enough IMO. There should be some broader amount of activities taken in 
account.

Vit

[Jóhann B. Guðmundsson]

On 03/02/2012 11:52 AM, Aleksandar Kurtakov wrote:
>  So I would make a contra-proposal.
>
>  If a maintainer doesn't respond to a bug repord with the status new in a week - give
> commit rights to the reporter in pkgdb so he/she can fix it himself.
>
>  I really think this is way more fare and people that tend to think that packagers are
> just a bunch of lazy guys should step in do some of this dirty work to get an idea what we
> speak about. 
There currently is no place in the project for people that want to fix 
things without having to maintain packages themselves so I think your 
counter proposal as good as it is can not come to pass until that has 
been fixed.

JBG

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Friday, March 2, 2012 2:16:28 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  On 03/02/2012 11:52 AM, Aleksandar Kurtakov wrote:
>  > So I would make a contra-proposal.
>  >
>  > If a maintainer doesn't respond to a bug repord with the status new
>  > in a week - give commit rights to the reporter in pkgdb so he/she
>  > can fix it himself.
>  >
>  > I really think this is way more fare and people that tend to think
>  > that packagers are just a bunch of lazy guys should step in do
>  > some of this dirty work to get an idea what we speak about.
>  
>  There currently is no place in the project for people that want to
>  fix
>  things without having to maintain packages themselves so I think your
>  counter proposal as good as it is can not come to pass until that has
>  been fixed. 
Well, Fedora ships packages. I might be stupid but would someone please explain me how can
one deliver fixed/improved packages to users without do at least a bit of packaging work.
I don't see a way this to happen.

Alex

>  
>  JBG
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Aleksandar Kurtakov" <akurtako(a)redhat.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Friday, March 2, 2012 2:27:04 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  
>  
>  ----- Original Message -----
>  > From: "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;
>  > To: devel(a)lists.fedoraproject.org
>  > Sent: Friday, March 2, 2012 2:16:28 PM
>  > Subject: Re: Automating the NonResponsiveMaintainers policy
>  >
>  > On 03/02/2012 11:52 AM, Aleksandar Kurtakov wrote:
>  > > So I would make a contra-proposal.
>  > >
>  > > If a maintainer doesn't respond to a bug repord with the status
>  > > new
>  > > in a week - give commit rights to the reporter in pkgdb so he/she
>  > > can fix it himself.
>  > >
>  > > I really think this is way more fare and people that tend to
>  > > think
>  > > that packagers are just a bunch of lazy guys should step in do
>  > > some of this dirty work to get an idea what we speak about.
>  >
>  > There currently is no place in the project for people that want to
>  > fix
>  > things without having to maintain packages themselves so I think
>  > your
>  > counter proposal as good as it is can not come to pass until that
>  > has
>  > been fixed.
>  
>  Well, Fedora ships packages. I might be stupid but would someone
>  please explain me how can one deliver fixed/improved packages to
>  users without do at least a bit of packaging work. I don't see a way
>  this to happen. 
I have to do some clarification to my previous post.
If someone wants to get things improved but not touching packages he clearly wants to work
on upstream projects in order to get the fixes there. 
And the next time the package is updated to latest version the fixes will be in Fedora. I
think that this is the only way to improve Fedora by not touching packages.
P.S. Note that I speak about development work and what I wrote has nothing to do with the
work of Documentation/Translation teams which are doing great job.

Alex

>  
>  Alex
>  
>  >
>  > JBG
>  > --
>  > devel mailing list
>  > devel(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Jóhann B. Guðmundsson]

On 03/02/2012 12:27 PM, Aleksandar Kurtakov wrote:
>  Well, Fedora ships packages. I might be stupid but would someone
> please explain me how can one deliver fixed/improved packages to users without do at least
> a bit of packaging work. I don't see a way this to happen. 
Spec files are no rocket science and the process for them is heavily 
backed up by FPG.

One way to achieve that would be that one could do so by becoming proven 
packager through some kind of mentoring process ( which does not exist 
btw ) I would think.

Atleast I would think you would have to first complete that step then 
proceed into being allowed to actually patch the actual source of the 
component.

JBG

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Friday, March 2, 2012 2:34:10 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  On 03/02/2012 12:27 PM, Aleksandar Kurtakov wrote:
>  > Well, Fedora ships packages. I might be stupid but would someone
>  > please explain me how can one deliver fixed/improved packages to
>  > users without do at least a bit of packaging work. I don't see a
>  > way this to happen.
>  
>  Spec files are no rocket science and the process for them is heavily
>  backed up by FPG. 
Sure spec files are no rocket science, it's not the format and syntax but the content
that matters. 

>  
>  One way to achieve that would be that one could do so by becoming
>  proven
>  packager through some kind of mentoring process ( which does not
>  exist
>  btw ) I would think. 
Hmm, proven packagers are still packagers aren't they? I thought you were asking about
someone fixing things without being packager.

>  
>  Atleast I would think you would have to first complete that step then
>  proceed into being allowed to actually patch the actual source of the
>  component. 
Nope, if you are a packager already and you have a unit file you want to push in my
package just ask me about commit rights via pkgdb and a mail explaining it and I'll
definetely approve your request and I'm pretty sure that a number of packagers will do
that too.

Alex

>  
>  JBG
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Jóhann B. Guðmundsson]

On 03/02/2012 12:41 PM, Aleksandar Kurtakov wrote:
>  Nope, if you are a packager already and you have a unit file you want
> to push in my package just ask me about commit rights via pkgdb and a mail explaining it
> and I'll definetely approve your request and I'm pretty sure that a number of
> packagers will do that too. 
I'm not a packager already nor can I become one since I dont want to 
maintain a single package in the distribution since "it does not scratch 
my ich" but I would like to be able to fix things if I do come across 
them at least with regards to spec files changes.
( There is atleast one feature ( systemd preset ) on the horizon that 
might require spec file changes and that in turn means spec file changes 
for the equal amount packages that are daemon/services in the 
distribution and somebody will have to do that work )

But I do certainly understand what your getting at since a week back I 
was suggesting changes to one of the component ( nothing to do with 
systemd ) we ship by default and adding configuration files for few 
other components so we could deliver better out of the box experience to 
our end user base and the relevant maintainer agreed and told me that he 
had noticed that I was up for PP and I should just go ahead and fix it 
myself once I had been approved since this was not high enough on the 
priority list for him fix...

But as things are now I cant become a proven packager since I'm not 
already an packager and I never will become a packager since I dont want 
to be maintaining a package in the distribution so really there is no 
place for people like me that want to fix things without having to 
maintaining an package in the distribution first...

JBG

[Bruno Wolff III]

On Fri, Mar 02, 2012 at 13:55:11 +0000,
  "\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com&gt; wrote:
>  I'm not a packager already nor can I become one since I dont want
> to
>  maintain a single package in the distribution since "it does not
>  scratch my ich" but I would like to be able to fix things if I do
>  come across them at least with regards to spec files changes.
>  ( There is atleast one feature ( systemd preset ) on the horizon
>  that might require spec file changes and that in turn means spec
>  file changes for the equal amount packages that are daemon/services
>  in the distribution and somebody will have to do that work ) 
That's going to be difficult. Essentially you are asking to jump from
non-packager directly to proven packager.

What you you could do is post patches needed to do your suggested updates
in bugzilla for packagers to apply. In theory this process should
work well, as the packages just need to review what you did and then
apply it rather than doing a lot of background study on systemd before
being able to write their own patches to do the same thing.

>  But as things are now I cant become a proven packager since I'm
> not
>  already an packager and I never will become a packager since I dont
>  want to be maintaining a package in the distribution so really there
>  is no place for people like me that want to fix things without
>  having to maintaining an package in the distribution first... 
Well 'never' may be a bit extreme. I think there is a place for people like
this (specialist in some area that works with that specialty on a lot of
packages). But figuring out how to demonstrate that expertise and general
judgement will take some work. It may not be worth doing this if the
specialty is really only needed for a transition and wouldn't really
be used much after the transition was complete.

[Bruno Wolff III]

On Fri, Mar 02, 2012 at 12:34:10 +0000,
  "\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com&gt; wrote:
>  
>  One way to achieve that would be that one could do so by becoming
>  proven packager through some kind of mentoring process ( which does
>  not exist btw ) I would think. 
I would think the implied process for someone who wanted to get proven
packager status but wasn't sure about what they should be doing to
accomplish that is to work with their sponsor.

[Bruno Wolff III]

On Fri, Mar 02, 2012 at 12:16:28 +0000,
  "\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com&gt; wrote:
>  On 03/02/2012 11:52 AM, Aleksandar Kurtakov wrote:
>  >So I would make a contra-proposal.
>  >
>  >If a maintainer doesn't respond to a bug repord with the status new in a week -
> give commit rights to the reporter in pkgdb so he/she can fix it himself.
>  >
>  >I really think this is way more fare and people that tend to think that packagers are
> just a bunch of lazy guys should step in do some of this dirty work to get an idea what we
> speak about.
>  
>  There currently is no place in the project for people that want to
>  fix things without having to maintain packages themselves so I think
>  your counter proposal as good as it is can not come to pass until
>  that has been fixed. 
Wanting to be able to do that is one of the ways you get get proven packager
status. That is essentially why I have that status. I mostly use it to
fix games and I also usually ask for co-maintainer status, but I also
go around fixing FTBFS issues for packages I don't want to co-maintain.

[Karel Zak]

On Fri, Mar 02, 2012 at 10:20:10AM +0000, "Jóhann B. Guðmundsson" wrote:
>  I am a feature owner for a feature that involves components in the
> hundreds
>  and is heavily depended on maintainers responsiveness.
>  
>  For me to start enacting the non responsive maintainers policy is a
>  tremendous work thus I'm wondering if there is something preventing us from
>  automating the non responsive maintainer policy?
>  
>  An bugzilla script that acts something like if maintainer has not responded
>  to a bug report with the status new in a week ( or some other time ) the non
>  responsive maintainers policy automatically starts taking effect. 
 What's your project boy? .. create a huge collection of dirty words? ;-)

 IMHO it's bad idea.

    Karel

-- 
 Karel Zak  <kzak(a)redhat.com&gt;
 http://karelzak.blogspot.com

[Reindl Harald]

Am 02.03.2012 16:47, schrieb Karel Zak:
>  On Fri, Mar 02, 2012 at 10:20:10AM +0000, "Jóhann B.
> Guðmundsson" wrote:
> > I am a feature owner for a feature that involves components in the hundreds
> > and is heavily depended on maintainers responsiveness.
> >
> > For me to start enacting the non responsive maintainers policy is a
> > tremendous work thus I'm wondering if there is something preventing us from
> > automating the non responsive maintainer policy?
> >
> > An bugzilla script that acts something like if maintainer has not responded
> > to a bug report with the status new in a week ( or some other time ) the non
> > responsive maintainers policy automatically starts taking effect.
>  
>   What's your project boy? .. create a huge collection of dirty words? ;-) 
systemd

so you should not call the appearently only one in the whole
distribution careing about not have in 10 years still sysv
services "boy"

what are all these maintainers doing?

it takes exactly 5 minutes to write a systemd-unit for most
services like postfix/dbmail and nothing happens, even
not if the one you called "boy" submits patches, unit-files
and pinging maintainers since 3 releases with the result get
ignored

sad enough that he still needs to ping a single maintainer
after systemd introduced in F15 - look when it was released
__________________________

in F16 postfix is still a sysv-daemon

a maintainer who is not able to pack the few lines below
over releases can be called "NonResponsiveMaintainers"

[root@srv-rhsoft:~]$ cat /lib/systemd/system/postfix.service
[Unit]
Description=Postfix MTA
After=network.target dovecot.service mysqld.service

[Service]
Type=forking
ExecStart=/usr/sbin/postfix -c /etc/postfix start
ExecStop=/usr/sbin/postfix -c /etc/postfix stop
ExecReload=/usr/sbin/postfix -c /etc/postfix reload
Restart=always
RestartSec=1

[Install]
WantedBy=multi-user.target

[Thomas Moschny]

Am 2. März 2012 16:56 schrieb Reindl Harald <h.reindl(a)thelounge.net&gt;:
>  what are all these maintainers doing?
>
>  it takes exactly 5 minutes to write a systemd-unit for most
>  services 
Some packages need a bit more love, especially when the sysv init
scripts did more than just starting / stopping a service., e.g.
creating / migrating databases.

You need to convert that functionality to separate scripts, put those
somewhere (/usr/sbin? /usr/libexec/package?), decide whether to let
the user start them manually (which is a big step back in user
experience), or let systemd run them e.g. via ExecStartPre, and test
the whole thing. And then debug and test again. Not a 5 minute job.

Just my 2ct
- Thomas

[Jóhann B. Guðmundsson]

On 03/02/2012 04:23 PM, Thomas Moschny wrote:
>  Am 2. März 2012 16:56 schrieb Reindl
> Harald<h.reindl(a)thelounge.net>:
> > what are all these maintainers doing?
> >
> > it takes exactly 5 minutes to write a systemd-unit for most
> > services
>  Some packages need a bit more love, especially when the sysv init
>  scripts did more than just starting / stopping a service., e.g.
>  creating / migrating databases.
>
>  You need to convert that functionality to separate scripts, put those
>  somewhere (/usr/sbin? /usr/libexec/package?), decide whether to let
>  the user start them manually (which is a big step back in user
>  experience), or let systemd run them e.g. via ExecStartPre, and test
>  the whole thing. And then debug and test again. Not a 5 minute job. 
It takes at least an half an hour per systemd unit file with each 
migration and that's the time is for well written and well behaving 
daemon and well written legacy sysv init script to migrate, performed by 
a man experienced in migrating this...

JBG

[Reindl Harald]

Am 02.03.2012 17:23, schrieb Thomas Moschny:
>  Am 2. März 2012 16:56 schrieb Reindl Harald
> <h.reindl(a)thelounge.net&gt;:
> > what are all these maintainers doing?
> >
> > it takes exactly 5 minutes to write a systemd-unit for most
> > services
>  
>  Some packages need a bit more love, especially when the sysv init
>  scripts did more than just starting / stopping a service., e.g.
>  creating / migrating databases. 
agreed - but this no argument for the ones needing only 5 minutes
and are ignored since months, so i guess you did not read the
word "most"

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Reindl Harald" <h.reindl(a)thelounge.net&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Friday, March 2, 2012 5:56:10 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  
>  Am 02.03.2012 16:47, schrieb Karel Zak:
>  > On Fri, Mar 02, 2012 at 10:20:10AM +0000, "Jóhann B. Guðmundsson"
>  > wrote:
>  >> I am a feature owner for a feature that involves components in the
>  >> hundreds
>  >> and is heavily depended on maintainers responsiveness.
>  >>
>  >> For me to start enacting the non responsive maintainers policy is
>  >> a
>  >> tremendous work thus I'm wondering if there is something
>  >> preventing us from
>  >> automating the non responsive maintainer policy?
>  >>
>  >> An bugzilla script that acts something like if maintainer has not
>  >> responded
>  >> to a bug report with the status new in a week ( or some other time
>  >> ) the non
>  >> responsive maintainers policy automatically starts taking effect.
>  > 
>  >  What's your project boy? .. create a huge collection of dirty
>  >  words? ;-)
>  
>  systemd
>  
>  so you should not call the appearently only one in the whole
>  distribution careing about not have in 10 years still sysv
>  services "boy"
>  
>  what are all these maintainers doing?
>  
>  it takes exactly 5 minutes to write a systemd-unit for most
>  services like postfix/dbmail and nothing happens, even
>  not if the one you called "boy" submits patches, unit-files
>  and pinging maintainers since 3 releases with the result get
>  ignored 
Sure, everyone is free to come and show me how a random bug is fixable in 5 minutes.
fedpkg clone; fedpkg prep; git am (if you're lucky) ; fedpkg local; yum localinstall;
TEST_IT; git commit; git push; fedpkg build

Anyone wanting to do that in 5 minutes? be my guest

Alex

>  
>  sad enough that he still needs to ping a single maintainer
>  after systemd introduced in F15 - look when it was released
>  __________________________
>  
>  in F16 postfix is still a sysv-daemon
>  
>  a maintainer who is not able to pack the few lines below
>  over releases can be called "NonResponsiveMaintainers"
>  
>  [root@srv-rhsoft:~]$ cat /lib/systemd/system/postfix.service
>  [Unit]
>  Description=Postfix MTA
>  After=network.target dovecot.service mysqld.service
>  
>  [Service]
>  Type=forking
>  ExecStart=/usr/sbin/postfix -c /etc/postfix start
>  ExecStop=/usr/sbin/postfix -c /etc/postfix stop
>  ExecReload=/usr/sbin/postfix -c /etc/postfix reload
>  Restart=always
>  RestartSec=1
>  
>  [Install]
>  WantedBy=multi-user.target
>  
>  
>  
>  
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Reindl Harald]

Am 02.03.2012 17:35, schrieb Aleksandar Kurtakov:
> > it takes exactly 5 minutes to write a systemd-unit for most
> > services like postfix/dbmail and nothing happens, even
> > not if the one you called "boy" submits patches, unit-files
> > and pinging maintainers since 3 releases with the result get
> > ignored
>  
>  Sure, everyone is free to come and show me how a random bug is fixable in 5 minutes
where did i say "fix a random bug in 5 minutes"?

this postfix-update was before F16 release
there were more postfix updates in the timeframe
http://koji.fedoraproject.org/koji/buildinfo?buildID=263131

* writing the systemd-unit takes 2 minutes for postfix
* no need for package anything, install put it locally in /etc/systemd/system
* so testing takes another 3 minutes, no compile needed

and now explain me what a maintainer knowing that the change to systemd was
done with F15 is thinking by ship  the package with F16 again as sysv-service
while users partly converted 20 different services in /ect/systemd/system/

hallelujha, in F17 postfix has a systemd-unit
read the changelog who is responsible for this and compare
the name with the tread-starter, take a deep breath and
think about how fursutrated it must be for him running
behinfd maintainers from one release to the next

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Reindl Harald" <h.reindl(a)thelounge.net&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Cc: "Aleksandar Kurtakov" <akurtako(a)redhat.com&gt;
>  Sent: Friday, March 2, 2012 6:45:14 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  
>  
>  Am 02.03.2012 17:35, schrieb Aleksandar Kurtakov:
>  >> it takes exactly 5 minutes to write a systemd-unit for most
>  >> services like postfix/dbmail and nothing happens, even
>  >> not if the one you called "boy" submits patches, unit-files
>  >> and pinging maintainers since 3 releases with the result get
>  >> ignored
>  > 
>  > Sure, everyone is free to come and show me how a random bug is
>  > fixable in 5 minutes
>  
>  where did i say "fix a random bug in 5 minutes"?
>  
>  this postfix-update was before F16 release
>  there were more postfix updates in the timeframe
>  http://koji.fedoraproject.org/koji/buildinfo?buildID=263131
>  
>  * writing the systemd-unit takes 2 minutes for postfix
>  * no need for package anything, install put it locally in
>  /etc/systemd/system
>  * so testing takes another 3 minutes, no compile needed
>  
>  and now explain me what a maintainer knowing that the change to
>  systemd was
>  done with F15 is thinking by ship  the package with F16 again as
>  sysv-service
>  while users partly converted 20 different services in
>  /ect/systemd/system/
>  
>  hallelujha, in F17 postfix has a systemd-unit
>  read the changelog who is responsible for this and compare
>  the name with the tread-starter, take a deep breath and
>  think about how fursutrated it must be for him running
>  behinfd maintainers from one release to the next
>   
Have you ever thought that for number of people this systemd units might be something they
know nothing about and they need to spend time on it?
That's why I say random bug. If this issue is not random for you it doesn't mean
that's the same for everyone else. 
Have you ever thought that different people might have different priorities? 
If someone wants something to happen - step in and do it. 

Alex


>  
>  
>

[Reindl Harald]

Am 02.03.2012 17:55, schrieb Aleksandar Kurtakov:
>  Have you ever thought that for number of people this systemd units
> might be something 
>  they know nothing about and they need to spend time on it? 
have you ever thought that i wrote the systemd-units for nearly all
relevant services on my personal and business machines in a few days
also with know nothing about while i expexted this is what package
maintainers are for?

systemd was planned for F14, dealyed for F15

so please do not tell me there was not enough time for maintainers usualy
not the owner of hundret service-packages to take a look what is coming in
the next release and start preparing their packages within a full year

[Rahul Sundaram]

On 03/02/2012 10:15 PM, Reindl Harald wrote:

>  * writing the systemd-unit takes 2 minutes for postfix
>  * no need for package anything, install put it locally in /etc/systemd/system
>  * so testing takes another 3 minutes, no compile needed 
This timeline is not reasonable. It typically takes half an hour to an
hour to write and test it properly if you are not already familiar with
systemd.  For most packages, I would consider this a low priority item
because systemd has compatibility built-in.  Remember that many
maintainers deal with more than one package and several of them have
other projects including upstream development to take care of.  If you
think you are more efficient at it, you are welcome to sign up as
package maintainer and demonstrate that.  Talk is cheap.

Rahul

[Jóhann B. Guðmundsson]

On 03/02/2012 04:55 PM, Rahul Sundaram wrote:
>  This timeline is not reasonable. It typically takes half an hour to
> an
>  hour to write and test it properly 
Add another half an hour for an individual not familiar with the spec 
file making the necessary adjustments to the spec file and test rebuild 
it...

JBG

[Reindl Harald]

Am 02.03.2012 17:55, schrieb Rahul Sundaram:
>  On 03/02/2012 10:15 PM, Reindl Harald wrote:
>  
> > * writing the systemd-unit takes 2 minutes for postfix
> > * no need for package anything, install put it locally in /etc/systemd/system
> > * so testing takes another 3 minutes, no compile needed
>  
>  This timeline is not reasonable. It typically takes half an hour to an
>  hour to write and test it properly if you are not already familiar with
>  systemd. 
for a simple service like postfix or dbmail?
surely not!

>   For most packages, I would consider this a low priority item
>  because systemd has compatibility built-in.  
i was there and saw enough things breaking

>  Remember that many maintainers deal with more than one package
remember that i converted enough services after
F15 hit me the first time and that i am maintaining
nearly all server-packages as fork in a own repo
becuase the half is unuseable for me with missing
systemd-unit at least for mysqld and the other
half is unuseable because the feodra packages are
restarting services on each yum update instead
let the admin control this

>  and several of them have other projects including upstream
> development
>  to take care of.  If you think you are more efficient at it, you are
>  welcome to sign up as package maintainer and demonstrate that.  
>  Talk is cheap. 
i even sent a bunlde of systemd-units to the devel-list

* i sent a full migration-guide dbmail2->dbmail3 to the devel-list
* also including the systed-units
* i made a bugreport that 3.0 is final with the reference

i spent WEEKS with the upstream-developer to get dbmail3 stable
many threads on the mailing-list, most communication and debugging
off-list, provide a build/test-service upstream, even initiated
that my company spent money upstream to support the development
and the fedora-maintainer does NOT act in any single way

http://old.nabble.com/dbmail-users-f17485.html
look for my name there, and this are only 10% of the
communication over a full month, 7 days a week
___________________________________________________

the result is still a RC3 with sysv-init
this is the best example for really bad maintainance

first because a simple test proves that the RC3 never should been
included in a GA-release and finally because this mistake is not
fixed - so not "talking is cheap"

* http://old.nabble.com/dbmail-users-f17485.html
* http://koji.fedoraproject.org/koji/packageinfo?packageID=1572
* https://bugzilla.redhat.com/show_bug.cgi?id=797118
___________________________________________________

normally my job is web-developer. below a list of packages
forked/rebuilt and converted to systemd, so please do not
tell me about "talk is cheap" while i am doing all the work
missed in F15 besides my normal job

a52dec-0.7.4-15.fc15.20111201.rh.x86_64.rpm
a52dec-devel-0.7.4-15.fc15.20111201.rh.x86_64.rpm
aespipe-2.4c-2.fc15.20111201.rh.x86_64.rpm
apr-1.4.5-1.fc15.20111201.rh.x86_64.rpm
apr-devel-1.4.5-1.fc15.20111201.rh.x86_64.rpm
avidemux-2.5.5-6.fc15.20111206.rh.1.x86_64.rpm
avidemux-cli-2.5.5-6.fc15.20111206.rh.1.x86_64.rpm
avidemux-gtk-2.5.5-6.fc15.20111206.rh.1.x86_64.rpm
avidemux-libs-2.5.5-6.fc15.20111206.rh.1.x86_64.rpm
avidemux-qt-2.5.5-6.fc15.20111206.rh.1.x86_64.rpm
cmirror-2.02.84-4.fc15.20111201.rh.x86_64.rpm
crypto-utils-2.4.1-31.x86_64.rpm
cups-1.5.0-11.fc15.20120205.rh.x86_64.rpm
cups-devel-1.5.0-11.fc15.20120205.rh.x86_64.rpm
cups-ipptool-1.5.0-11.fc15.20120205.rh.x86_64.rpm
cups-libs-1.5.0-11.fc15.20120205.rh.x86_64.rpm
cups-lpd-1.5.0-11.fc15.20120205.rh.x86_64.rpm
cups-php-1.5.0-11.fc15.20120205.rh.x86_64.rpm
dbmail-3.0.1-22.fc15.20120301.rh.a6e9ce2795eab12e56592802772a17ab03111829.x86_64.rpm
dbmail-3.0.1-23.fc15.20120302.rh.62c20e2b2c15909941916bfe3c71386b31acc82a.x86_64.rpm
dbmail-3.0.1-23.fc15.20120302.rh.83199b3f9da0aa430bf9f99d38f8bbdc3f60e348.x86_64.rpm
dbmail-3.0.1-24.fc15.20120302.rh.62c20e2b2c15909941916bfe3c71386b31acc82a.x86_64.rpm
dbmail-auth-ldap-3.0.1-22.fc15.20120301.rh.a6e9ce2795eab12e56592802772a17ab03111829.x86_64.rpm
dbmail-auth-ldap-3.0.1-23.fc15.20120302.rh.62c20e2b2c15909941916bfe3c71386b31acc82a.x86_64.rpm
dbmail-auth-ldap-3.0.1-23.fc15.20120302.rh.83199b3f9da0aa430bf9f99d38f8bbdc3f60e348.x86_64.rpm
dbmail-auth-ldap-3.0.1-24.fc15.20120302.rh.62c20e2b2c15909941916bfe3c71386b31acc82a.x86_64.rpm
dbmail-postfix-policyd-2011.05.25-7.fc15.20111201.rh.noarch.rpm
device-mapper-1.02.63-4.fc15.20111201.rh.x86_64.rpm
device-mapper-devel-1.02.63-4.fc15.20111201.rh.x86_64.rpm
device-mapper-event-1.02.63-4.fc15.20111201.rh.x86_64.rpm
device-mapper-event-devel-1.02.63-4.fc15.20111201.rh.x86_64.rpm
device-mapper-event-libs-1.02.63-4.fc15.20111201.rh.x86_64.rpm
device-mapper-libs-1.02.63-4.fc15.20111201.rh.x86_64.rpm
dimp-1.1.8-2.fc15.20120210.rh.noarch.rpm
dirb-2.0.3-1.fc15.20111218.rh.x86_64.rpm
dovecot-2.1.1-2.fc15.20120224.rh.x86_64.rpm
dovecot-devel-2.1.1-2.fc15.20120224.rh.x86_64.rpm
dovecot-mysql-2.1.1-2.fc15.20120224.rh.x86_64.rpm
dovecot-pgsql-2.1.1-2.fc15.20120224.rh.x86_64.rpm
dovecot-pigeonhole-2.1.1-2.fc15.20120224.rh.x86_64.rpm
faac-1.28-6.fc15.20111201.rh.x86_64.rpm
faac-devel-1.28-6.fc15.20111201.rh.x86_64.rpm
faad2-2.7-3.fc15.20111201.rh.x86_64.rpm
faad2-devel-2.7-3.fc15.20111201.rh.x86_64.rpm
faad2-libs-2.7-3.fc15.20111201.rh.x86_64.rpm
ffmpeg-0.7.11-2.fc15.20120209.rh.x86_64.rpm
ffmpeg-devel-0.7.11-2.fc15.20120209.rh.x86_64.rpm
ffmpeg-libs-0.7.11-2.fc15.20120209.rh.x86_64.rpm
flac-1.2.1-6.fc14.rh.20110422.x86_64.rpm
flac-devel-1.2.1-6.fc14.rh.20110422.x86_64.rpm
flvtool2-1.0.6-4.fc15.20111202.rh.noarch.rpm
freenx-server-0.7.3-24.fc15.20111201.rh.x86_64.rpm
GeoIP-1.4.8-2.fc15.20111201.rh.x86_64.rpm
GeoIP-devel-1.4.8-2.fc15.20111201.rh.x86_64.rpm
gmime22-2.2.25-2.fc15.20111201.rh.x86_64.rpm
gmime22-devel-2.2.25-2.fc15.20111201.rh.x86_64.rpm
gmime-2.5.1-4.fc15.20120201.rh.x86_64.rpm
gmime-devel-2.5.1-4.fc15.20120201.rh.x86_64.rpm
gmime-sharp-2.5.1-4.fc15.20120201.rh.x86_64.rpm
greenbone-security-assistant-2.0.1-2.fc15.20111230.rh.x86_64.rpm
gsm-1.0.13-2.fc15.20111202.rh.x86_64.rpm
gsm-devel-1.0.13-2.fc15.20111202.rh.x86_64.rpm
gsm-tools-1.0.13-2.fc15.20111202.rh.x86_64.rpm
gstreamer-plugins-ugly-0.10.18-1.fc15.20111206.rh.1.x86_64.rpm
gstreamer-plugins-ugly-devel-docs-0.10.18-1.fc15.20111206.rh.1.noarch.rpm
horde-3.3.13-2.fc15.20120210.rh.noarch.rpm
horde-enhanced-3.3.13-2.fc15.20120210.rh.noarch.rpm
httpd-2.2.22-2.fc15.20120201.rh.x86_64.rpm
httpd-devel-2.2.22-2.fc15.20120201.rh.x86_64.rpm
httpd-manual-2.2.22-2.fc15.20120201.rh.noarch.rpm
httpd-tools-2.2.22-2.fc15.20120201.rh.x86_64.rpm
hylafax-5.5.0-1.fc15.20111214.rh.x86_64.rpm
iat-0.1.7-14.fc15.20111201.rh.x86_64.rpm
iaxmodem-1.2.0-7.fc15.20111201.rh.x86_64.rpm
imp-4.3.11-2.fc15.20120210.rh.noarch.rpm
ingo-1.2.6-3.fc15.20120210.rh.noarch.rpm
jigdo-0.7.3-11.fc15.20111201.rh.x86_64.rpm
jigdo-gui-0.7.3-11.fc15.20111201.rh.x86_64.rpm
kronolith-2.3.6-3.fc15.20120210.rh.noarch.rpm
lame-3.99.3-2.fc15.20120117.rh.x86_64.rpm
lame-devel-3.99.3-2.fc15.20120117.rh.x86_64.rpm
lame-libs-3.99.3-2.fc15.20120117.rh.x86_64.rpm
lame-mp3x-3.99.3-2.fc15.20120117.rh.x86_64.rpm
libavc1394-0.5.3-10.fc15.20111206.rh.x86_64.rpm
libavc1394-devel-0.5.3-10.fc15.20111206.rh.x86_64.rpm
libevent-2.0.17-2.fc15.20120220.rh.x86_64.rpm
libevent-devel-2.0.17-2.fc15.20120220.rh.x86_64.rpm
libmad-0.15.1b-13.fc15.20111201.rh.x86_64.rpm
libmad-devel-0.15.1b-13.fc15.20111201.rh.x86_64.rpm
libmng-1.0.10-5.fc15.20111201.rh.x86_64.rpm
libmng-devel-1.0.10-5.fc15.20111201.rh.x86_64.rpm
libmp4v2-1.5.0.1-11.fc15.20111201.rh.x86_64.rpm
libmp4v2-devel-1.5.0.1-11.fc15.20111201.rh.x86_64.rpm
libmpcdec-1.2.6-7.fc15.20111201.rh.x86_64.rpm
libmpcdec-devel-1.2.6-7.fc15.20111201.rh.x86_64.rpm
libmpdclient-2.6-2.fc15.20111201.rh.x86_64.rpm
libmpdclient-devel-2.6-2.fc15.20111201.rh.x86_64.rpm
libmpeg2-0.5.1-8.fc15.20111201.rh.x86_64.rpm
libmpeg2-devel-0.5.1-8.fc15.20111201.rh.x86_64.rpm
libmpeg3-1.8-3.fc15.20111202.rh.x86_64.rpm
libmpeg3-devel-1.8-3.fc15.20111202.rh.x86_64.rpm
libmpeg3-utils-1.8-3.fc15.20111202.rh.x86_64.rpm
libnss-mysql-1.5-15.fc15.20120111.rh.x86_64.rpm
libquicktime-1.2.3-3.fc15.20111206.rh.1.x86_64.rpm
libquicktime-devel-1.2.3-3.fc15.20111206.rh.1.x86_64.rpm
libquicktime-utils-1.2.3-3.fc15.20111206.rh.1.x86_64.rpm
libsamplerate-0.1.7-3.fc15.20111202.rh.x86_64.rpm
libsamplerate-devel-0.1.7-3.fc15.20111202.rh.x86_64.rpm
libsmbclient-3.6.3-78.fc15.20120208.rh.x86_64.rpm
libsmbclient-devel-3.6.3-78.fc15.20120208.rh.x86_64.rpm
libtheora-1.1.1-1.fc15.20111202.rh.x86_64.rpm
libtheora-devel-1.1.1-1.fc15.20111202.rh.x86_64.rpm
libtheora-devel-docs-1.1.1-1.fc15.20111202.rh.noarch.rpm
libtidy-0.99.0-21.20091203.fc15.20111201.rh.x86_64.rpm
libtidy-devel-0.99.0-21.20091203.fc15.20111201.rh.x86_64.rpm
libtool-2.4-6.fc15.20111201.rh.x86_64.rpm
libtool-ltdl-2.4-6.fc15.20111201.rh.x86_64.rpm
libtool-ltdl-devel-2.4-6.fc15.20111201.rh.x86_64.rpm
libvpx-1.0.0-2.fc15.20120202.rh.x86_64.rpm
libvpx-devel-1.0.0-2.fc15.20120202.rh.x86_64.rpm
libvpx-utils-1.0.0-2.fc15.20120202.rh.x86_64.rpm
lvm2-2.02.84-4.fc15.20111201.rh.x86_64.rpm
lvm2-cluster-2.02.84-4.fc15.20111201.rh.x86_64.rpm
lvm2-devel-2.02.84-4.fc15.20111201.rh.x86_64.rpm
lvm2-libs-2.02.84-4.fc15.20111201.rh.x86_64.rpm
lvm2-sysvinit-2.02.84-4.fc15.20111201.rh.x86_64.rpm
lynis-1.3.0-2.fc15.20111230.rh.noarch.rpm
lzo-2.06-1.fc15.20111201.rh.x86_64.rpm
lzo-devel-2.06-1.fc15.20111201.rh.x86_64.rpm
lzo-minilzo-2.06-1.fc15.20111201.rh.x86_64.rpm
mencoder-1.0-0.127.20110816svn.fc15.20120110.rh.x86_64.rpm
mencoder-1.0-0.129.20110917svn.fc15.20120302.rh.x86_64.rpm
mimp-1.1.4-7.fc15.20120210.rh.noarch.rpm
minizip-1.2.5-6.fc15.20120116.rh.x86_64.rpm
minizip-devel-1.2.5-6.fc15.20120116.rh.x86_64.rpm
mod_bw-0.8-6.fc15.20120201.rh.x86_64.rpm
mod_flvx-0.0-14.fc15.20120201.rh.x86_64.rpm
mod_h264_streaming-2.2.7-16.fc15.20120201.rh.x86_64.rpm
mod_security-2.6.3-3.fc15.20120201.rh.x86_64.rpm
mod_ssl-2.2.22-2.fc15.20120201.rh.x86_64.rpm
mp3info-0.8.5a-16.fc15.20111201.rh.x86_64.rpm
mpc-0.21-1.fc15.20111201.rh.x86_64.rpm
mpd-0.16.6-5.fc15.20111204.rh.x86_64.rpm
mpdscribble-0.22-4.fc15.20111201.rh.x86_64.rpm
mpeg2dec-0.5.1-8.fc15.20111201.rh.x86_64.rpm
mplayer-1.0-0.127.20110816svn.fc15.20120110.rh.x86_64.rpm
mplayer-1.0-0.129.20110917svn.fc15.20120302.rh.x86_64.rpm
mplayer-common-1.0-0.127.20110816svn.fc15.20120110.rh.x86_64.rpm
mplayer-common-1.0-0.129.20110917svn.fc15.20120302.rh.x86_64.rpm
mplayer-doc-1.0-0.127.20110816svn.fc15.20120110.rh.x86_64.rpm
mplayer-doc-1.0-0.129.20110917svn.fc15.20120302.rh.x86_64.rpm
mplayer-gui-1.0-0.127.20110816svn.fc15.20120110.rh.x86_64.rpm
mplayer-gui-1.0-0.129.20110917svn.fc15.20120302.rh.x86_64.rpm
mplayer-tools-1.0-0.127.20110816svn.fc15.20120110.rh.x86_64.rpm
mplayer-tools-1.0-0.129.20110917svn.fc15.20120302.rh.x86_64.rpm
mysql-5.5.21-2.fc15.20120221.rh.x86_64.rpm
mysql-bench-5.5.21-2.fc15.20120221.rh.x86_64.rpm
mysql-devel-5.5.21-2.fc15.20120221.rh.x86_64.rpm
mysql-embedded-5.5.21-2.fc15.20120221.rh.x86_64.rpm
mysql-embedded-devel-5.5.21-2.fc15.20120221.rh.x86_64.rpm
mysql-libs-5.5.21-2.fc15.20120221.rh.x86_64.rpm
mysql-server-5.5.21-2.fc15.20120221.rh.x86_64.rpm
mysql-test-5.5.21-2.fc15.20120221.rh.x86_64.rpm
mysqltuner-1.2.0-2.20110306git.fc15.20111201.rh.noarch.rpm
nag-2.3.7-3.fc15.20120210.rh.noarch.rpm
netatalk-2.2.2-1.fc15.20120116.rh.x86_64.rpm
netatalk-devel-2.2.2-1.fc15.20120116.rh.x86_64.rpm
nmap-5.51-1.fc15.20111219.rh.x86_64.rpm
nmap-frontend-5.51-1.fc15.20111219.rh.noarch.rpm
opencore-amr-0.1.2-1.fc15.20111202.rh.x86_64.rpm
opencore-amr-devel-0.1.2-1.fc15.20111202.rh.x86_64.rpm
openssh-5.8p2-24.fc15.20120209.rh.x86_64.rpm
openssh-askpass-5.8p2-24.fc15.20120209.rh.x86_64.rpm
openssh-clients-5.8p2-24.fc15.20120209.rh.x86_64.rpm
openssh-keycat-5.8p2-24.fc15.20120209.rh.x86_64.rpm
openssh-ldap-5.8p2-24.fc15.20120209.rh.x86_64.rpm
openssh-server-5.8p2-24.fc15.20120209.rh.x86_64.rpm
openssh-server-sysvinit-5.8p2-24.fc15.20120209.rh.x86_64.rpm
openssl-1.0.0g-1.fc15.20120120.rh.x86_64.rpm
openssl-devel-1.0.0g-1.fc15.20120120.rh.x86_64.rpm
openssl-perl-1.0.0g-1.fc15.20120120.rh.x86_64.rpm
openssl-static-1.0.0g-1.fc15.20120120.rh.x86_64.rpm
openvas-administrator-1.1.2-2.fc15.20111230.rh.x86_64.rpm
openvas-libraries-4.0.6-2.fc15.20111230.rh.x86_64.rpm
openvas-libraries-devel-4.0.6-2.fc15.20111230.rh.x86_64.rpm
openvas-manager-2.0.4-2.fc15.20111230.rh.x86_64.rpm
openvas-scanner-3.2.5-2.fc15.20111230.rh.x86_64.rpm
open-vm-tools-0.0.0.562307-27.fc15.20120225.rh.x86_64.rpm
open-vm-tools-devel-0.0.0.562307-27.fc15.20120225.rh.x86_64.rpm
openvpn-2.2.1-6.fc15.20111202.rh.x86_64.rpm
pam_ssh_agent_auth-0.9.2-31.24.fc15.20120209.rh.x86_64.rpm
perl-Class-Std-Fast-0.0.8-10.fc15.20111201.rh.noarch.rpm
perl-IO-Socket-INET6-2.67-2.fc15.20111201.rh.noarch.rpm
perl-Net-DRI-0.96-2.fc15.20111201.rh.noarch.rpm
perl-SOAP-WSDL-2.00.10-10.fc15.20111201.rh.noarch.rpm
perl-Tk-804.029-2.fc15.20111202.rh.x86_64.rpm
php-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-bcmath-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-cli-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-common-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-dba-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-devel-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-embedded-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-enchant-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-gd-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-imap-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-interbase-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-intl-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-ldap-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-manual-de-20110218-1.fc15.20111201.rh.noarch.rpm
php-mbstring-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-mcrypt-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-mssql-5.3.10-2.fc15.20120203.rh.x86_64.rpm
phpMyAdmin-3.4.10.1-2.fc15.20120218.rh.noarch.rpm
php-mysql-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-odbc-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-pdo-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-pecl-apc-3.1.9-9.fc15.20120203.rh.x86_64.rpm
php-pecl-apc-devel-3.1.9-9.fc15.20120203.rh.x86_64.rpm
php-pecl-archive-0.2-20.fc15.20120203.rh.x86_64.rpm
php-pecl-bbcode-1.0.2-20.fc15.20120203.rh.x86_64.rpm
php-pecl-crack-0.4-20.fc15.20120203.rh.x86_64.rpm
php-pecl-geoip-1.0.8-2.fc15.20120203.rh.x86_64.rpm
php-pecl-http-1.7.1-20.fc15.20120203.rh.x86_64.rpm
php-pecl-id3-0.2-20.fc15.20120203.rh.x86_64.rpm
php-pecl-imagick-3.0.1-20.fc15.20120203.rh.x86_64.rpm
php-pecl-mailparse-2.1.5-20.fc15.20120203.rh.x86_64.rpm
php-pecl-memtrack-0.2.1-20.fc15.20120203.rh.x86_64.rpm
php-pecl-mysqlnd_qc-1.0.1-20.fc15.20120203.rh.x86_64.rpm
php-pecl-rar-2.0.0-20.fc15.20120203.rh.x86_64.rpm
php-pecl-ssh2-0.11.3-20.fc15.20120203.rh.x86_64.rpm
php-pecl-uploadprogress-1.0.3.1-20.fc15.20120203.rh.x86_64.rpm
php-pecl-xattr-1.1.0-20.fc15.20120203.rh.x86_64.rpm
php-pecl-xdebug-2.1.3-2.fc15.20120203.rh.x86_64.rpm
php-pgsql-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-process-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-pspell-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-reader-1.8-1.fc15.20111201.rh.noarch.rpm
php-recode-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-snmp-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-soap-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-suhosin-0.9.33-2.fc15.20120203.rh.x86_64.rpm
php-tidy-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-xml-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-xmlrpc-5.3.10-2.fc15.20120203.rh.x86_64.rpm
php-zts-5.3.10-2.fc15.20120203.rh.x86_64.rpm
postfix-2.9.1-2.fc15.20120222.rh.x86_64.rpm
postfix-perl-scripts-2.9.1-2.fc15.20120222.rh.x86_64.rpm
postgrey-1.34-3.fc15.20111201.rh.noarch.rpm
procmail-3.22-27.fc15.20111202.rh.x86_64.rpm
pulsed-2.0-5.fc15.20111201.rh.noarch.rpm
pure-ftpd-1.0.35-3.fc15.20120109.rh.x86_64.rpm
pure-ftpd-selinux-1.0.35-3.fc15.20120109.rh.x86_64.rpm
rsyslog-5.8.7-2.fc15.20120127.rh.x86_64.rpm
rsyslog-gnutls-5.8.7-2.fc15.20120127.rh.x86_64.rpm
rsyslog-gssapi-5.8.7-2.fc15.20120127.rh.x86_64.rpm
rsyslog-libdbi-5.8.7-2.fc15.20120127.rh.x86_64.rpm
rsyslog-mysql-5.8.7-2.fc15.20120127.rh.x86_64.rpm
rsyslog-pgsql-5.8.7-2.fc15.20120127.rh.x86_64.rpm
rsyslog-relp-5.8.7-2.fc15.20120127.rh.x86_64.rpm
rsyslog-snmp-5.8.7-2.fc15.20120127.rh.x86_64.rpm
rsyslog-sysvinit-5.8.7-2.fc15.20120127.rh.x86_64.rpm
rsyslog-udpspoof-5.8.7-2.fc15.20120127.rh.x86_64.rpm
samba-3.6.3-78.fc15.20120208.rh.x86_64.rpm
samba-client-3.6.3-78.fc15.20120208.rh.x86_64.rpm
samba-common-3.6.3-78.fc15.20120208.rh.x86_64.rpm
samba-doc-3.6.3-78.fc15.20120208.rh.x86_64.rpm
samba-domainjoin-gui-3.6.3-78.fc15.20120208.rh.x86_64.rpm
samba-swat-3.6.3-78.fc15.20120208.rh.x86_64.rpm
samba-winbind-3.6.3-78.fc15.20120208.rh.x86_64.rpm
samba-winbind-clients-3.6.3-78.fc15.20120208.rh.x86_64.rpm
samba-winbind-devel-3.6.3-78.fc15.20120208.rh.x86_64.rpm
samba-winbind-krb5-locator-3.6.3-78.fc15.20120208.rh.x86_64.rpm
smokeping-2.4.2-16.fc15.20120122.rh.noarch.rpm
sonata-1.6.2.1-7.fc15.20120118.rh.x86_64.rpm
svn2cl-0.13-2.fc15.20111201.rh.noarch.rpm
sysstat-10.0.2-2.fc15.20111201.rh.x86_64.rpm
system-config-samba-1.2.93-1.fc15.20111029.rh.noarch.rpm
theora-tools-1.1.1-1.fc15.20111202.rh.x86_64.rpm
tidy-0.99.0-21.20091203.fc15.20111201.rh.x86_64.rpm
transcode-1.1.5-7.fc15.20111206.rh.x86_64.rpm
turba-2.3.6-3.fc15.20120210.rh.noarch.rpm
twolame-0.3.12-4.fc15.20111202.rh.x86_64.rpm
twolame-devel-0.3.12-4.fc15.20111202.rh.x86_64.rpm
twolame-libs-0.3.12-4.fc15.20111202.rh.x86_64.rpm
vnstat-1.11-6.fc15.20111201.rh.x86_64.rpm
w3af-1.0-5.fc15.art.x86_64.rpm
wapiti-2.2.1-3.fc15.20111222.rh.noarch.rpm
webalizer-xtended-2.23_05_RB29-1.fc15.20111201.rh.x86_64.rpm
whups-1.0.1-7.fc15.20120210.rh.noarch.rpm
x264-0.0.0-0.32.20120209git0.120.2164.da19765.fc15.20120209.rh.x86_64.rpm
x264-devel-0.0.0-0.32.20120209git0.120.2164.da19765.fc15.20120209.rh.x86_64.rpm
x264-libs-0.0.0-0.32.20120209git0.120.2164.da19765.fc15.20120209.rh.x86_64.rpm
xmms-faad2-2.7-3.fc15.20111201.rh.x86_64.rpm
zlib-1.2.5-6.fc15.20120116.rh.x86_64.rpm
zlib-devel-1.2.5-6.fc15.20120116.rh.x86_64.rpm
zlib-static-1.2.5-6.fc15.20120116.rh.x86_64.rpm

[Rahul Sundaram]

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

On 03/02/2012 10:45 PM, Reindl Harald wrote:

>  
>  for a simple service like postfix or dbmail? surely not! 
I disagree.

>  i even sent a bunlde of systemd-units to the devel-list 
As I informed you at that time, sending a bundle is not very useful.
You need to file individual bug reports and if you want to go further,
sign up as a package maintainer, get commit access and do the work
yourself.

Rahul

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJPUQJqAAoJELauRe7G9dGMzUAIALSCES0QxwWutRFn4wDzpiT4
> tREn9YJWHo90S0/NGrQDX6G/n3DmArEsSdJq7R9tn55KnmMTTSUGRfzLGHdBUKQ8
> +DlR5WL8rM4BvU6AXr//EtpJM+s7/WRaufMZCK6UZNfxhRe2YjiHRc5PVuXmOG2/
> 3QQWZdPoNejqdjTnqy0comrT6blqM3D7L2sggiUrvTVLY/fBXmsSrjKpRYOWjETB
> dlIho3YZjatlSnJxAypX1++8KxNHtPRUf/eHSjaRbqAIa6n4nWXtRM3JcRTQo/vK
> mJhCxiG0tEPG2jVS/Cjeo9M2TXTJm8Ub7wIMAIyeqkkf3dqMUPKVbM2h7hoYK/0=
> =vUtN
> -----END PGP SIGNATURE-----

[Jóhann B. Guðmundsson]

On 03/02/2012 03:47 PM, Karel Zak wrote:
>    What's your project boy? .. create a huge collection of dirty
> words?;-) 
Sorry not following where you are going with this?

>    IMHO it's bad idea. 
Why do you think it's a bad idea automating a process that is now done 
manually?

JBG

[Karel Zak]

On Fri, Mar 02, 2012 at 04:13:44PM +0000, "Jóhann B. Guðmundsson" wrote:
>  Why do you think it's a bad idea automating a process that is now
> done
>  manually? 
 because:

http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

 * After 2 attempts of no contact, the reporter asks if anyone knows how
   to contact the maintainer.

 * After another 7 days, the reporter posts a formal request to the
   fedora-devel list with the bug link.

 * If at least one FESCo member approves the takeover and no one objects
   within 3 days, the requester may take over the package. 


    Karel

-- 
 Karel Zak  <kzak(a)redhat.com&gt;
 http://karelzak.blogspot.com

[Jóhann B. Guðmundsson]

On 03/02/2012 04:29 PM, Karel Zak wrote:
>  On Fri, Mar 02, 2012 at 04:13:44PM +0000, "Jóhann B.
> Guðmundsson" wrote:
> > Why do you think it's a bad idea automating a process that is now done
> > manually?
>    because:
>
>  http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
>
>    * After 2 attempts of no contact, the reporter asks if anyone knows how
>      to contact the maintainer.
>
>    * After another 7 days, the reporter posts a formal request to the
>      fedora-devel list with the bug link.
>
>    * If at least one FESCo member approves the takeover and no one objects
>      within 3 days, the requester may take over the package. 
Yes the automation would just automate these steps ending with posting 
the formal request to devel for fesco to pick up.

JBG

[Rahul Sundaram]

On 03/02/2012 10:04 PM, "Jóhann B. Guðmundsson" wrote:
>  
>  Yes the automation would just automate these steps ending with posting
>  the formal request to devel for fesco to pick up.
>   
The best way to convince people is to actually just do it.  Post a
script and show that it can be done.

Rahul

[Jóhann B. Guðmundsson]

On 03/02/2012 04:42 PM, Rahul Sundaram wrote:
> > >  Yes the automation would just automate these steps ending
> with posting
> > >  the formal request to devel for fesco to pick up.
> > >  
>  The best way to convince people is to actually just do it.  Post a
>  script and show that it can be done. 
Do we have access bugzilla to test this against?

I'm pretty sure the answer here is no since last time I checked  you 
cant even get your username migrated or deleted.

So in this case consciousness needs to be reached first then you can 
start writing and convince whomever are behind the Red Hat bugzilla to 
be allowed to do this.

JBG

[Rahul Sundaram]

On 03/02/2012 10:15 PM, "Jóhann B. Guðmundsson" wrote:
>  On 03/02/2012 04:42 PM, Rahul Sundaram wrote:
> >> >  Yes the automation would just automate these steps ending with
> >> posting
> >> >  the formal request to devel for fesco to pick up.
> >> >  
> > The best way to convince people is to actually just do it.  Post a
> > script and show that it can be done.
>  
>  Do we have access bugzilla to test this against?
>   
What access do you need?  If you need something to test and you don't
have access, run your own instance.

Rahul

[Jóhann B. Guðmundsson]

On 03/02/2012 04:49 PM, Rahul Sundaram wrote:
>  What access do you need?  If you need something to test and you
> don't
>  have access, run your own instance. 
Here you assume that people have enough hw or vm capable hardware to do 
so which is not in my case.

And this only requires copying the current EOL script and make the 
necessary changes in use so the can be done on technical level if 
consciousness is reached for this.

Thus if people agree on this I shall put work on getting it done but 
before hand forget it.

JBG

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Friday, March 2, 2012 6:56:47 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  On 03/02/2012 04:49 PM, Rahul Sundaram wrote:
>  > What access do you need?  If you need something to test and you
>  > don't
>  > have access, run your own instance.
>  
>  Here you assume that people have enough hw or vm capable hardware to
>  do
>  so which is not in my case.
>  
>  And this only requires copying the current EOL script and make the
>  necessary changes in use so the can be done on technical level if
>  consciousness is reached for this.
>  
>  Thus if people agree on this I shall put work on getting it done but
>  before hand forget it. 
Running the NonResponsiveMaintainers automatically based on single bug report is something
that shouldn't be even discussed!

If something like this should be discussed it should have a lot different constraints:
* way longer period - (Eclipse.org marks people as not active after 9 months.) - at least
3 months
* not a single bugzilla - at least 3 bugzillas
* no commits in these 3 months
* no builds in these 3 months

And all of these should happen in the very same 3 months period to mark a person as
inactive.

Alex


>  
>  JBG
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Rahul Sundaram]

On 03/02/2012 10:26 PM, "Jóhann B. Guðmundsson" wrote:
>  On 03/02/2012 04:49 PM, Rahul Sundaram wrote:
> > What access do you need?  If you need something to test and you don't
> > have access, run your own instance.
>  
>  Here you assume that people have enough hw or vm capable hardware to do
>  so which is not in my case.
>  
>  And this only requires copying the current EOL script and make the
>  necessary changes in use so the can be done on technical level if
>  consciousness is reached for this.
>  
>  Thus if people agree on this I shall put work on getting it done but
>  before hand forget it. 
Again, what access do you need and who have you asked for it?

Rahul

[Jóhann B. Guðmundsson]

On 03/02/2012 05:10 PM, Rahul Sundaram wrote:
>  Again, what access do you need and who have you asked for it? 
It's pretty obvious that this is a proposal I made today thus I have 
asked no one for it nor can I since infrastructure has made it clear to 
me when I asked them to fix my user accounting mess that I found myself 
into that they do not handle bugzilla that is Red Hat only territory.

Secondly first we need to reach conscious about the proposal in general 
then if reached settle on a time frame for the automatic process to 
start taking place as Aleksandar and other have pointed out.

I'm not sure how you do things in your part of the world but usually 
here on top of the world we dont start building houses without knowing 
first how they should look like...

JBG

[Rahul Sundaram]

On 03/02/2012 10:53 PM, "Jóhann B. Guðmundsson" wrote:
>  On 03/02/2012 05:10 PM, Rahul Sundaram wrote:
> > Again, what access do you need and who have you asked for it?
>  
>  It's pretty obvious that this is a proposal I made today thus I have
>  asked no one for it nor can I since infrastructure has made it clear to
>  me when I asked them to fix my user accounting mess that I found myself
>  into that they do not handle bugzilla that is Red Hat only territory. 
I think you need to ask for access that you need rather than assume you
don't get it because of something unrelated in the past. It is not clear
to me what access do you need beyond what you already have to write a
test script.

>  I'm not sure how you do things in your part of the world but
> usually
>  here on top of the world we dont start building houses without knowing
>  first how they should look like... 
That was completely uncalled for.

Rahul

[Jóhann B. Guðmundsson]

On 03/02/2012 05:29 PM, Rahul Sundaram wrote:
>  That was completely uncalled for. 
I disagree

I know for a fact that you are well aware of the EOL and other script 
that is used with bugzilla so you were well aware this was technically 
achievable and you then your self go about asking me to start writing 
stuff without people having reached consciousness if we should do that 
in the first place.

So this was completely called for by your own doing with I might add and 
I quote you

"The best way to convince people is to actually just do it. Post a 
script and show that it can be done."

The question here is not if it can be done the question here is should 
it be done in the first place.

If the outcome is yes we should then we can start working on how we 
should go about doing that and yes then I will start looking into how to 
do it.

JBG

[Rahul Sundaram]

On 03/02/2012 11:20 PM, "Jóhann B. Guðmundsson" wrote:
>  On 03/02/2012 05:29 PM, Rahul Sundaram wrote:
> > That was completely uncalled for.
>  
>  I disagree 
Let me put in another way then.  Cut that out.  Talking about your world
vs my world makes it personal not to mention sarcastic there is zero
room for that in a technical discussion.

>  I know for a fact that you are well aware of the EOL and other
> script
>  that is used with bugzilla so you were well aware this was technically
>  achievable and you then your self go about asking me to start writing
>  stuff without people having reached consciousness if we should do that
>  in the first place. 
You will never reach consensus on these matters as you should know by
now having started many such discussions which has resulted in nothing.
 Some people will agree and others disagree and nothing will get done.
If that's how you want to roll, feel free.

Rahul

[Kevin Fenzi]

Lets drop this subthread please? 

I don't think it's doing anyone any good to see you two hitting back
and forth. 

If you must, take it to private email? 

kevin

[Al Dunsmuir]

On Friday, March 2, 2012, 12:23:51 PM, Jóhann wrote:
>  On 03/02/2012 05:10 PM, Rahul Sundaram wrote:
> > Again, what access do you need and who have you asked for it? 
>  It's pretty obvious that this is a proposal I made today thus I
> have 
>  asked no one for it nor can I since infrastructure has made it clear to
>  me when I asked them to fix my user accounting mess that I found myself
>  into that they do not handle bugzilla that is Red Hat only territory. 
>  Secondly first we need to reach conscious about the proposal in
> general
>  then if reached settle on a time frame for the automatic process to 
>  start taking place as Aleksandar and other have pointed out. 
>  I'm not sure how you do things in your part of the world but
> usually 
>  here on top of the world we dont start building houses without knowing
>  first how they should look like... 
Perhaps  one  factor  is  that what you are trying to build may not be
right  for  the  problem at hand, and a new solution is required for a
different  sort  of problem? Or perhaps the issue is that we only have
one sort of tool/process, and you are attempting to solve your problem
with that tool when a better solution would be to propose a new tool.

The NonResponsiveMaintainer process is designed to remove all packages
from  a maintainer who has gone missing, and is no longer able to take
care  of  their duties as a Fedora package owner.

It  seems  to  me  that  many who object to using this large hammer to
solve what some view (correctly or incorrectly) as one minor packaging
issue of many.

Perhaps  it would be better to view this as something more akin to the
FTBFS (fails to build from source) process, where regular attempts are
made  to  build packages from source, and those failures tracked. That
and  the  follow-up  process  are  more  of  an  "action  required  by
maintainer" type of process than a "fix it now or else" process.

I  would  suggest  that  you  might be better to propose a generalized
"FTFPG"  (fails  to follow packaging guidelines) process, of which one
of  the  first regular automated checks would be to discover and track
packages that are not enabled for systemd. This would expand over time
to  check  for other packages which violate other guidelines for which
automated  checks  can  be  created. Automation would include creating
bugs,  tracking  reports,  and  should have exception lists to support
known/approved exceptions.

By  the  way,  that  automation would need to be in a package... which
might well be suitable to be your one/only Fedora package. 8^)

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Friday, March 2, 2012 6:45:24 PM
>  Subject: Re: Automating the NonResponsiveMaintainers policy
>  
>  On 03/02/2012 04:42 PM, Rahul Sundaram wrote:
>  >> >  Yes the automation would just automate these steps ending with
>  >> >  posting
>  >> >  the formal request to devel for fesco to pick up.
>  >> >  
>  > The best way to convince people is to actually just do it.  Post a
>  > script and show that it can be done.
>  
>  Do we have access bugzilla to test this against?
>  
>  I'm pretty sure the answer here is no since last time I checked  you
>  cant even get your username migrated or deleted.
>  
>  So in this case consciousness needs to be reached first then you can
>  start writing and convince whomever are behind the Red Hat bugzilla
>  to
>  be allowed to do this. 
There is https://partner-bugzilla.redhat.com/ and I'm pretty sure that one can get
better permissions on it.

Alex

>  
>  JBG
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Bill Nottingham]

Karel Zak (kzak(a)redhat.com) said: 
> http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
>  
>   * After 2 attempts of no contact, the reporter asks if anyone knows how
>     to contact the maintainer.
>  
>   * After another 7 days, the reporter posts a formal request to the
>     fedora-devel list with the bug link.
>  
>   * If at least one FESCo member approves the takeover and no one objects
>     within 3 days, the requester may take over the package.  
So, trying to get some progress here, I see two issues:

1) It's all manual.

Ideally, there would be a way to pull this information, rather than relying
on manual pokes and collecting the results of said pokes, even if we didn't
change the policy at all.

2) It doesn't solve the problem of a non-responsive maintainer where the
requester *DOESN'T* want to take over the package.

For example, just because I might have a an issue getting a needed change
into glibc doesn't mean I would want take over glibc. Of course, without a
willing maintainer to take over in this case, you're still stuck.

Bill

[Bruno Wolff III]

On Fri, Mar 02, 2012 at 13:53:55 -0500,
  Bill Nottingham <notting(a)redhat.com&gt; wrote:
>  
>  2) It doesn't solve the problem of a non-responsive maintainer where the
>  requester *DOESN'T* want to take over the package.
>  
>  For example, just because I might have a an issue getting a needed change
>  into glibc doesn't mean I would want take over glibc. Of course, without a
>  willing maintainer to take over in this case, you're still stuck. 
Yeah, I have seen similar cases where it seemed like people thought that
somehow another maintainer would get assigned or that the current maintainer
should be punished. I tried to point out, that just removing a current
maintainer from a package doesn't actually help get things fixed.

[Kevin Fenzi]

On Fri, 2 Mar 2012 13:53:55 -0500
Bill Nottingham <notting(a)redhat.com&gt; wrote:

>  Karel Zak (kzak(a)redhat.com) said: 
>  > http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
>  > 
>  >  * After 2 attempts of no contact, the reporter asks if anyone
>  > knows how to contact the maintainer.
>  > 
>  >  * After another 7 days, the reporter posts a formal request to the
>  >    fedora-devel list with the bug link.
>  > 
>  >  * If at least one FESCo member approves the takeover and no one
>  > objects within 3 days, the requester may take over the package. 
>  
>  So, trying to get some progress here, I see two issues:
>  
>  1) It's all manual.
>  
>  Ideally, there would be a way to pull this information, rather than
>  relying on manual pokes and collecting the results of said pokes,
>  even if we didn't change the policy at all.
>  
>  2) It doesn't solve the problem of a non-responsive maintainer where
>  the requester *DOESN'T* want to take over the package.
>  
>  For example, just because I might have a an issue getting a needed
>  change into glibc doesn't mean I would want take over glibc. Of
>  course, without a willing maintainer to take over in this case,
>  you're still stuck. 
Related to this, Pierre-YvesChibon wrote a tool to check a bunch of
things for a fedora account, so you could at least see if someone was
still active in some areas while not in others: 

https://github.com/pypingou/fedora-active-user

If you are running into no reply from a bug, you could run this and see
if the maintainer has been active in other areas, or just appears to be
gone. Might help before determining if you should start the inactive
process. 

kevin

[Jóhann B. Guðmundsson]

On 03/02/2012 07:34 PM, Kevin Fenzi wrote:
>  Related to this, Pierre-YvesChibon wrote a tool to check a bunch of
>  things for a fedora account, so you could at least see if someone was
>  still active in some areas while not in others:
>
>  https://github.com/pypingou/fedora-active-user
>
>  If you are running into no reply from a bug, you could run this and see
>  if the maintainer has been active in other areas, or just appears to be
>  gone. Might help before determining if you should start the inactive
>  process. 
Thanks for that I'll have a look at this.

I should also mention if we implement an automated non responsive 
process we should do the same for "NEEDINFO" from reporters as in if an 
reporter has not responded in a month ( or some other time ) the bug 
should be closed as "INSUFFICIENT DATA".

I would think that's only fair...

JBG

[Richard W.M. Jones]

On Fri, Mar 02, 2012 at 10:20:10AM +0000, "Jóhann B. Guðmundsson" wrote:
>  An bugzilla script that acts something like if maintainer has not
>  responded to a bug report with the status new in a week ( or some
>  other time ) the non responsive maintainers policy automatically
>  starts taking effect. 
It's the same problem as email: anyone could push 'todo' items onto
anyone else's plate.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

[drago01]

2012/3/2 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;:
>  I am a feature owner for a feature that involves components in the
> hundreds
>  and is heavily depended on maintainers responsiveness.
>
>  For me to start enacting the non responsive maintainers policy is a
>  tremendous work thus I'm wondering if there is something preventing us from
>  automating the non responsive maintainer policy?
>
>  An bugzilla script that acts something like if maintainer has not responded
>  to a bug report with the status new in a week ( or some other time ) the non
>  responsive maintainers policy automatically starts taking effect.
>
>  To get out of that automatic non responsive process the maintainer would
>  have to comment on the bug and set it's status assigned ( or something
>  similar ). 
I understand that this is frustrating to you but your solution is just
wrong IMO.
We don't have infinite resources so throwing people out just because
they did not respond withing a week is a bad joke. The better fix here
is ... you want to do the change file a bug wait for $x amount of time
... no response -> go ahead an commit.

[Jóhann B. Guðmundsson]

On 03/02/2012 07:54 PM, drago01 wrote:
>  I understand that this is frustrating to you but your solution is
> just
>  wrong IMO.
>  We don't have infinite resources so throwing people out just because
>  they did not respond withing a week is a bad joke. The better fix here
>  is ... you want to do the change file a bug wait for $x amount of time
>  ... no response ->  go ahead an commit. 
The week was just a sample time and it would be week + the 
NonResponsiveMaintainers policy process time with an confirmation 
required from FESCO as the policy dictates.

Some people seem to be confusing this like this would instantly take 
effect which is not the case here.

We are just talking about automating the "NonResponsiveMaintainers 
policy" as is so instead of an reporter to manually perform these steps 
( which they can perform at any time now btw ) those steps would be 
automated...

JBG

[Al Dunsmuir]

On Friday, March 2, 2012, 4:21:13 PM, Jóhann wrote:
>  Some people seem to be confusing this like this would instantly take
>  effect which is not the case here. 
>  We are just talking about automating the
> "NonResponsiveMaintainers 
>  policy" as is so instead of an reporter to manually perform these steps
>  ( which they can perform at any time now btw ) those steps would be 
>  automated... 
It really _is_ quite different.

The  trigger for NonResponsiveMaintainers now is an actual person with
a  real  problem  that  they  need  solving.   People  understand this
trigger.

An automated trigger has to be something substantial, a tuned heuristic
based   on   actual   outstanding bugs in specific states.  Triggering
too often, or without clear justification will result in the automated
emails being ignored as spam.

Triggering  the process purely based on lack of activity is one of the
cases  that  isn't  reasonable. The maintainer's packages could all be
very  mature,  and  need no rebuilding and infrequent updates (because
upstream only releases every couple of years).