On Sat, 26 Apr 2008 22:35:37 +0200
alain.portal@free.fr (Alain PORTAL) wrote:

> Le samedi 26 avril 2008, Michael Schwendt a écrit :
> > On Sat, 26 Apr 2008 00:11:33 +0200, Alain PORTAL wrote:
> > > Hi,
> > >
> > > As I get too many conflicts, first with the french translation
> > > team six month ago, second with some Redhat people, today, with a
> > > big head (as several people in the french translation team), I
> > > make the decision to definitevely leave the Fedora Extras Team.
> >
> > Alain, can't these issues with people be fixed instead?
>
> Unfortunately, I don't think.

Well, we can try... and if not, at least we could perhaps learn from it
and how to make things like this not happen again.
>
> No. Unfortunately, my english is to poor to have an intensive
> discussion to explain my anger and all blames I can do to several
> people. But you can get a little idea with these bugs:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=139695

Yeah, I don't know what to say there. The maintainer clearly didn't
answer or do anything with the bug. ;(

> https://bugzilla.redhat.com/show_bug.cgi?id=197353

Sadly, I do see what happened here...

The bug never seemed to block any of the review blockers bugs back when
extras reviews were doing that. So, it would never have appeared on
lists of packages to review, etc. Also, it shows as assigned, so
anyone who did see it would have assumed it was under review and left
it alone. Was it created assigned to notting? Did you use the template
on the new package review page on the wiki? or just manually created it?

> have a look in the man-pages-fr.spec file to see how often this
> package is update. In addition, I can tell you this package really
> need a review...
>
> A one year old bug, easy to fix
> https://bugzilla.redhat.com/show_bug.cgi?id=238070

Yeah. ;( No response from maintainer...

> And the one that convinced me to get out
> https://bugzilla.redhat.com/show_bug.cgi?id=443634

It's been reopened. I think it was closed in error, and the people
involved realize that now.

So, I my thoughts on this:

- We need to make sure and improve review process so reviews don't get
lost like that. I think a lot of improvement has been made since the
extras days however, since we have the fedora-review flag now, your
review flag would probably have had someone at least comment that it
was assigned, but didn't seem to be under review.

- We need to work harder to spot where maintainers need assistance and
are not answering their bugs. Triage folks may be able to help there.

- We need to work harder to identify easyfix bugs and get a group of
people able to go in and just fix them.

- Finally (and just speaking for myself), I would like to stress that I
am happy to listen to concerns or problems and try and get solutions to
happen. At every FESCo irc meeting there is a 'free discussion' period
at the end. On every FESCo scheduling post there is a chance to reply
to the list and bring up issues. Please, let us know where and when
there are problems so we can try and find some solution.

kevin
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sun, 2008-04-27 at 00:23 +0200, Patrice Dumas wrote:
> The first one is, in my opinion, a contributor killer issue and I have
> been reporting it more than once. It is not acceptable to have packagers
> not handling rapidly bugs where submitter proposes patches, or volunteer
> to take care of the issue. FESCo should really come up with a guideline
> or a solution for such issues, which is not a case-by-case decision.
> It is especially frustrating when a contributor has done some work and
> still the package maintainer doesn't seems to care at all about it.

Perhaps the AWOL maintainer policy could be adapted/extended into a
"non-responsive" maintainer policy. Not caring about a package is not a
mark against the maintainer, but allowing it to bitrot is.

--
Ignacio Vazquez-Abrams <ivazqueznet@gmail.com>

PLEASE don't CC me; I'm already subscribed
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sat, Apr 26, 2008 at 07:11:33PM -0400, Ignacio Vazquez-Abrams wrote:
>
> Perhaps the AWOL maintainer policy could be adapted/extended into a
> "non-responsive" maintainer policy. Not caring about a package is not a
> mark against the maintainer, but allowing it to bitrot is.

I don't think that the AWOL maintainer policy should be extended to cope
with these cases, since it seems to me to be a distinct case. But it
could certainly be adapted to have a procedure for forced
co-maintainership or forced orphaning when a packager doesn't handle the
easy to fix/proposed solution bugs in a given time.

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sun, 2008-04-27 at 00:23 +0200, Patrice Dumas wrote:
> On Sat, Apr 26, 2008 at 07:49:51AM -0500, Josh Boyer wrote:
> >
> > Can you email the issues you're having to
> > fedora-extras-steering@redhat.com please? Perhaps we can look them over
> > and find an amicable way to solve them for everyone involved.
>
> Looking at te bug reports Alain posted in another mail, there seems to
> be 2 issues. One is that he has proposed patches for packaging issues
> for years without being heard. The second is, in my opinion, a less
> problematic issue of a bug being closed to rapidly.
>
> The first one is, in my opinion, a contributor killer issue and I have
> been reporting it more than once. It is not acceptable to have packagers
> not handling rapidly bugs where submitter proposes patches, or volunteer
> to take care of the issue. FESCo should really come up with a guideline
> or a solution for such issues, which is not a case-by-case decision.

Why? Grr! It does not take someone from FESCo to draft such a thing.
Anyone, yes ANYONE, can draft something and ask FESCo to ratify it.

Now, frankly I'm not sure something outside of the existing AWOL
procedure is needed at all.

> It is especially frustrating when a contributor has done some work and
> still the package maintainer doesn't seems to care at all about it.

I agree. Open CVS ACLs and co-maintainers _should_ help lessen the
occurrence of this. However, that is still up to the primary maintainer
to decide, and we have to take exceptions as they come.

josh

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sat, Apr 26, 2008 at 07:52:19PM -0500, Josh Boyer wrote:
>
> Why? Grr! It does not take someone from FESCo to draft such a thing.
> Anyone, yes ANYONE, can draft something and ask FESCo to ratify it.

Indeed, but nobody has come with something now, so I think it would be
nice to have FESCo propose something.

> Now, frankly I'm not sure something outside of the existing AWOL
> procedure is needed at all.

I am sure of the contrary. AWOL is for people who are AWOL. Here we are
talking about maintainers who are not AWOL but still don't act. It is
a very different situation. If somebody AWOL has his packages forcefully
orphaned there is no problem (it is even right...), while for a maintainer
not AWOL, it may be considered to be rude.

> I agree. Open CVS ACLs and co-maintainers _should_ help lessen the
> occurrence of this. However, that is still up to the primary maintainer
> to decide, and we have to take exceptions as they come.

No, open CVS ACLs and co-maintainers don't help in that case. Well, it
helps implementing the fix, but it isn't the issue here. Here we just
want that the maintainer says 'ok, you seem to be interested, be
co-maintainer, implement what you propose I'll check and rebuild'. Or
'Ok, propose a patch'. Or 'This seems to be an easy fix, but there are
some issues you are missing, still I don't have currently the time to
explain, I'll come back as time permit'.

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sun, 27 Apr 2008 10:13:11 +0200, Patrice Dumas wrote:

> On Sat, Apr 26, 2008 at 07:52:19PM -0500, Josh Boyer wrote:
> >
> > Why? Grr! It does not take someone from FESCo to draft such a thing.
> > Anyone, yes ANYONE, can draft something and ask FESCo to ratify it.
>
> Indeed, but nobody has come with something now, so I think it would be
> nice to have FESCo propose something.
>
> > Now, frankly I'm not sure something outside of the existing AWOL
> > procedure is needed at all.
>
> I am sure of the contrary. AWOL is for people who are AWOL. Here we are
> talking about maintainers who are not AWOL but still don't act. It is
> a very different situation. If somebody AWOL has his packages forcefully
> orphaned there is no problem (it is even right...), while for a maintainer
> not AWOL, it may be considered to be rude.

Here the maintainer would end the AWOL procedure with a comment in
bugzilla, but afterwards might still not take proper action to fix the bug
(and apply a patch or version upgrade).

A different procedure is needed, in particular for the hard problems where
months pass by without progress. Somebody to rule how to proceed. Somebody
with the decision-power to open up the cvs acls for a package or to
over-rule the package owner if necessary. Else the package collection
cannot be called not community-driven in such areas.

> > I agree. Open CVS ACLs and co-maintainers _should_ help lessen the
> > occurrence of this. However, that is still up to the primary maintainer
> > to decide, and we have to take exceptions as they come.
>
> No, open CVS ACLs and co-maintainers don't help in that case. Well, it
> helps implementing the fix, but it isn't the issue here. Here we just
> want that the maintainer says 'ok, you seem to be interested, be
> co-maintainer, implement what you propose I'll check and rebuild'. Or
> 'Ok, propose a patch'. Or 'This seems to be an easy fix, but there are
> some issues you are missing, still I don't have currently the time to
> explain, I'll come back as time permit'.

The last excuse I find questionable. Lack of time is a primary reason to
search for co-maintainers. Else it becomes a hindrance. If specific issues
are known, they can be summed up (briefly!) to give the contributors and
potential co-maintainers some input to think about. Consider it
home-work. Such brief feedback need not be ultimately convincing and may
result in a series of comments over a longer period of time.

--
Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8
loadavg: 1.10 1.18 1.04

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Patrice Dumas wrote:

On Sat, Apr 26, 2008 at 07:49:51AM -0500, Josh Boyer wrote:

Can you email the issues you're having to
fedora-extras-steering@redhat.com please? Perhaps we can look them over
and find an amicable way to solve them for everyone involved.


Looking at te bug reports Alain posted in another mail, there seems to
be 2 issues. One is that he has proposed patches for packaging issues
for years without being heard. The second is, in my opinion, a less
problematic issue of a bug being closed to rapidly.

The first one is, in my opinion, a contributor killer issue and I have
been reporting it more than once. It is not acceptable to have packagers
not handling rapidly bugs where submitter proposes patches, or volunteer
to take care of the issue. FESCo should really come up with a guideline
or a solution for such issues, which is not a case-by-case decision.
It is especially frustrating when a contributor has done some work and
still the package maintainer doesn't seems to care at all about it.




+1

I'm so fed up with this (people not responding to trivial to fix bugs / bugs
with patches attached) that I _regulary_ put a comment like this in bugzilla:


Can you please fix this, this blocks X other bugs. I'm sorry todo this, but
consider this your first ping in the light of the NonResponsiveMaintainers policy:
http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers

Which sometimes gets people attention and sometimes not. I guess the
NonResponsiveMaintainers policy is already an answer to this, which is why I
use it, but I wonder if it is _the_ answer.


Regards,

Hans

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Kevin Fenzi wrote:


- We need to work harder to identify easyfix bugs and get a group of
people able to go in and just fix them.



If such a group was formed, I would certainly volunteer to join!

Regards,

Hans

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sun, 27 Apr 2008 11:28:08 +0200, Hans de Goede wrote:

> I'm so fed up with this (people not responding to trivial to fix bugs / bugs
> with patches attached) that I _regulary_ put a comment like this in bugzilla:
>
> Can you please fix this, this blocks X other bugs. I'm sorry todo this, but
> consider this your first ping in the light of the NonResponsiveMaintainers policy:
> http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
>
> Which sometimes gets people attention and sometimes not. I guess the
> NonResponsiveMaintainers policy is already an answer to this, which is why I
> use it, but I wonder if it is _the_ answer.

It's the AWOL procedure, and it assumes that the maintainer doesn't
respond.

It doesn't cover the case, where a maintainer shows up from time to time,
but still doesn't take the requested/recommended action (such as applying
a patch or upgrading to a new upstream release).

And it boils down to FESCo deciding on how to proceed, which is exactly
what is needed in the non-AWOL cases, too.

--
Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8
loadavg: 1.05 1.20 1.37

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Michael Schwendt wrote:

On Sun, 27 Apr 2008 11:28:08 +0200, Hans de Goede wrote:

I'm so fed up with this (people not responding to trivial to fix bugs / bugs
with patches attached) that I _regulary_ put a comment like this in bugzilla:


Can you please fix this, this blocks X other bugs. I'm sorry todo this, but
consider this your first ping in the light of the NonResponsiveMaintainers policy:
http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers

Which sometimes gets people attention and sometimes not. I guess the
NonResponsiveMaintainers policy is already an answer to this, which is why I
use it, but I wonder if it is _the_ answer.


It's the AWOL procedure, and it assumes that the maintainer doesn't
respond.



True, but ...


It doesn't cover the case, where a maintainer shows up from time to time,
but still doesn't take the requested/recommended action (such as applying
a patch or upgrading to a new upstream release).



Well sofar no-one has been so naughty / abusive as to just put a pong comment
in BZ and say, see I responded happy now? That would also be rather ill advised
as I can guarantee I would cry wolf very loudly in public, resulting in a
public grilling.



And it boils down to FESCo deciding on how to proceed, which is exactly
what is needed in the non-AWOL cases, too.



Not necessarily in some cases it helps to wake people up, atleast long enough
to open the ACL's for me, which although still is not good maintainership, but
often is all that I need.


Which makes me think that as a possible solution to this, I would like to see:

1) Other rules about ACL's, currently lots of former core packages have
inherited there ACL settings from core, but why are so many packages closed to
cvs-extras? I would really like to see an ACL guideline which enforces open
ACL's unless the maintainer asks permission to close them to FESco.


Suggestion, the security people make a list of security sensitive packages,
those get to keep their current ACL's the rest is opened up to cvsextras,
unless a request is made to FESco before date <date>, then a list can be given
to rel-eng / CVS-admin's, with do not open up these packages and please open up
all others, which then could be run as a one time batch job to remove all those
ancient no cvsextras access flags from a long time ago.


2) Some kind of guidelines document, where I really mean guidelines, and not
rules as most of our current guidelines are, for when its ok to touch other
people's packages without prior communication, and when and how much prior
communication is needed.



Regards,

Hans

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list