FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 07-12-2008, 12:04 AM
Patrice Dumas
 
Default No answer to easy bug policy

Hello,

With Rahul, we prepared a new pollicy which aim is to force maintainers
to answer to easy fix bugs or orphan packages if they fail to do so in a
one month delay. It may look a bit rude, but hopefully it will help
spreading co-maintainership and quicker bugfixes. It is at

https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance

In my opinion it should be added to the non responsive policy at
http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
I paste it here. Please comment. It should be proposed to FESCo after
discussion here.




= No answer to easy bug policy =

== The Problem ==

There are several occasions where the individual maintainers are still
active and working on some software packages while not fixing trivial
bugs on other software packages. If this occurs over a long period of
time, the maintainers should seek out co-maintainers or just be
orphaning the software packages they are not interested in. If it does
happen for a shorter periods, others can act as a buffer to avoid the
problem lingering for our users. Other experienced and trusted package
maintainers, developers or others in the community have offered a
specific simple solution to the problem in terms of patches or
recommendations that translate into straight forward solutions.
Maintainers are wary of stepping on each other's toes and clear
guidelines helps is setting expectations

== The solution ==

When the situation described above happens, somebody (called the
reporter) can proceed with what is explained below. However, this
should only be done in one bug at a time for each maintainer, even if
there are many such bugs for different or the same components.
To enforce that, a blocker bug should be associated with the bug such
that it is easy to see which maintainer is already concerned
by the procedure.

The reporter put the following comment in the bug:

---

As per the 'No answer to easy bug' policy, please answer within 2 weeks
whether

* you allow others to fix this bug

* you are not interested enough in that package to really keep on
* maintaining it by yourself, and are looking for a co-maintainer or
to orphan the package

If you don't answer after 2 weeks and one remainder lasting also at
least 2 week the package will be orphaned according to the policy stated
at <link>

---

- The reporter blocks a blocker bug, such that before following the
procedure another reporter can check that the packager hasn't have a
similar procedure already begun.

- The blocker bug is left for at least 1 month, even if the maintainer
answered, such that only one procedure per month can be engaged.


The idea is to avoid having people be able to bother maintainers more
than needed by having only one procedure opened at a time, while forcing
uninterested maintainers to orphan their packages.

== References ==

* http://fedoraproject.org/wiki/PackageMaintainers/Policy/EncourageComaintainership
* http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages
* http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers#Outline



--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-12-2008, 12:38 AM
Eric Sandeen
 
Default No answer to easy bug policy

Patrice Dumas wrote:
> Hello,
>
> With Rahul, we prepared a new pollicy which aim is to force maintainers
> to answer to easy fix bugs or orphan packages if they fail to do so in a
> one month delay. It may look a bit rude, but hopefully it will help
> spreading co-maintainership and quicker bugfixes. It is at
>
> https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance
>
> In my opinion it should be added to the non responsive policy at
> http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
> I paste it here. Please comment. It should be proposed to FESCo after
> discussion here.

Looks great except for the definition of "Easy Bug." Did I miss it?

-Eric

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-12-2008, 12:40 AM
Jesse Keating
 
Default No answer to easy bug policy

On Jul 11, 2008, at 20:38, Eric Sandeen <sandeen@redhat.com> wrote:


Patrice Dumas wrote:

Hello,

With Rahul, we prepared a new pollicy which aim is to force
maintainers
to answer to easy fix bugs or orphan packages if they fail to do so
in a

one month delay. It may look a bit rude, but hopefully it will help
spreading co-maintainership and quicker bugfixes. It is at

https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance

In my opinion it should be added to the non responsive policy at
http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
I paste it here. Please comment. It should be proposed to FESCo after
discussion here.


Looks great except for the definition of "Easy Bug." Did I miss


Those would be the bugs I file. All of them.

--
Jes

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-12-2008, 02:24 AM
Lyos Gemini Norezel
 
Default No answer to easy bug policy

Patrice Dumas wrote:

Hello,

With Rahul, we prepared a new pollicy which aim is to force maintainers
to answer to easy fix bugs or orphan packages if they fail to do so in a
one month delay. It may look a bit rude, but hopefully it will help
spreading co-maintainership and quicker bugfixes. It is at

https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance

In my opinion it should be added to the non responsive policy at
http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
I paste it here. Please comment. It should be proposed to FESCo after
discussion here.




= No answer to easy bug policy =

== The Problem ==

There are several occasions where the individual maintainers are still
active and working on some software packages while not fixing trivial
bugs on other software packages. If this occurs over a long period of
time, the maintainers should seek out co-maintainers or just be
orphaning the software packages they are not interested in. If it does
happen for a shorter periods, others can act as a buffer to avoid the
problem lingering for our users. Other experienced and trusted package
maintainers, developers or others in the community have offered a
specific simple solution to the problem in terms of patches or
recommendations that translate into straight forward solutions.
Maintainers are wary of stepping on each other's toes and clear
guidelines helps is setting expectations


== The solution ==

When the situation described above happens, somebody (called the
reporter) can proceed with what is explained below. However, this
should only be done in one bug at a time for each maintainer, even if

there are many such bugs for different or the same components.
To enforce that, a blocker bug should be associated with the bug such
that it is easy to see which maintainer is already concerned
by the procedure.

The reporter put the following comment in the bug:

---

As per the 'No answer to easy bug' policy, please answer within 2 weeks
whether

* you allow others to fix this bug

* you are not interested enough in that package to really keep on
* maintaining it by yourself, and are looking for a co-maintainer or
to orphan the package


If you don't answer after 2 weeks and one remainder lasting also at
least 2 week the package will be orphaned according to the policy stated
at <link>

---

- The reporter blocks a blocker bug, such that before following the
procedure another reporter can check that the packager hasn't have a
similar procedure already begun.

- The blocker bug is left for at least 1 month, even if the maintainer
answered, such that only one procedure per month can be engaged.


The idea is to avoid having people be able to bother maintainers more
than needed by having only one procedure opened at a time, while forcing
uninterested maintainers to orphan their packages.

== References ==

* http://fedoraproject.org/wiki/PackageMaintainers/Policy/EncourageComaintainership

* http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages
* http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers#Outline



--
Pat




I'm no developer (not since the 6502 ASM days at any rate), but it seems
to me that this may cause some contention. I hate bureaucracy in all
it's forms, but I can see I slightly modified version of this being put
into use, PROVIDED the majority of developers concerned (ie., at least
70%) agree to be bound by such rules. Otherwise, you risk losing alot of
people.


At any rate, the modification I propose is actually fairly simple. It
simply makes an exception to a particular type of case. There are
instances where the bug itself may be easy to fix, and there may even be
a patch available, but solving that particular bug may cause bugs in
other (possibly more vital) programs or libraries.


I'm merely suggesting an exception for this particular case, on the off
chance you'd have developers being forcefully removed because of such
bugs. And yes, I do know that such cases would be rare.


Lyos Gemini Norezel

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-12-2008, 05:30 AM
Hans de Goede
 
Default No answer to easy bug policy

Patrice Dumas wrote:

Hello,

With Rahul, we prepared a new pollicy which aim is to force maintainers
to answer to easy fix bugs or orphan packages if they fail to do so in a
one month delay. It may look a bit rude, but hopefully it will help
spreading co-maintainership and quicker bugfixes. It is at

https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance

In my opinion it should be added to the non responsive policy at
http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
I paste it here. Please comment. It should be proposed to FESCo after
discussion here.




Hmm,

First of all, I agree that non-repsonsive ness to easy bugs and / or
bugs with patches attached is an issue.


But I'm not sure this is a good solution. There are really 2 problems here:
1) The person responsible for the package is letting these bugs linger
2) Others do not fix it, even though they could, because they are afraid
of stepping on each other's toes, as you correctly point out.

I feel that your policy completely fails to address 2), whereas that
might be one of the more important points. For example I don't mind
other people touching my packages _at all_, which can be seen from there
ACL's. So we could have a policy that says that "easy fixes" (whatever
the definition) may be done by anyone with CVS extras without a prior
headsup, when the ACL's allow it. IOW, codify in policy that the ACL
signals how much a developer minds other people touching his packages.


Another possible solution would be a I don't mind my toes getting
stepped on list in the wiki.


Regards,

Hans

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-12-2008, 06:01 AM
Lyos Gemini Norezel
 
Default No answer to easy bug policy

Hans de Goede wrote:

Hmm,

First of all, I agree that non-repsonsive ness to easy bugs and / or
bugs with patches attached is an issue.


But I'm not sure this is a good solution. There are really 2 problems
here:

1) The person responsible for the package is letting these bugs linger
2) Others do not fix it, even though they could, because they are afraid
of stepping on each other's toes, as you correctly point out.

I feel that your policy completely fails to address 2), whereas that
might be one of the more important points. For example I don't mind
other people touching my packages _at all_, which can be seen from
there ACL's. So we could have a policy that says that "easy fixes"
(whatever the definition) may be done by anyone with CVS extras
without a prior headsup, when the ACL's allow it. IOW, codify in
policy that the ACL signals how much a developer minds other people
touching his packages.


Another possible solution would be a I don't mind my toes getting
stepped on list in the wiki.


Regards,

Hans


How about both? A list in the wiki... AND ACLs.
I like this solution alot more than Rahul's proposal.
Lyos Gemini Norezel

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-12-2008, 08:12 AM
Richard Hughes
 
Default No answer to easy bug policy

On Sat, 2008-07-12 at 02:04 +0200, Patrice Dumas wrote:
> There are several occasions where the individual maintainers are still
> active and working on some software packages while not fixing trivial
> bugs on other software packages.

Surely the maintainer in question knows the package well enough to
decide whether to merge patches? For instance, I might push a patch
upstream and hold off applying it to fedora as it's trivial and will get
updated at the next version bump of my package in a few weeks.

This all seems so very beurocratic to me.

Richard.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-12-2008, 08:48 AM
Patrice Dumas
 
Default No answer to easy bug policy

On Sat, Jul 12, 2008 at 09:12:50AM +0100, Richard Hughes wrote:
> On Sat, 2008-07-12 at 02:04 +0200, Patrice Dumas wrote:
> > There are several occasions where the individual maintainers are still
> > active and working on some software packages while not fixing trivial
> > bugs on other software packages.
>
> Surely the maintainer in question knows the package well enough to
> decide whether to merge patches? For instance, I might push a patch
> upstream and hold off applying it to fedora as it's trivial and will get
> updated at the next version bump of my package in a few weeks.

But you can mention it on the patch, so that the reporter knows what is
happening. Or close UPSTREAM. Also I have added a 3 weeks delay before
this is started. This leads to 3 weeks + 1 month time.

> This all seems so very beurocratic to me.

It is. But burocracy is required when it comes to forcing other
contributors.

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-12-2008, 08:59 AM
Patrice Dumas
 
Default No answer to easy bug policy

On Sat, Jul 12, 2008 at 02:04:47AM +0200, Patrice Dumas wrote:
> Hello,
>
> With Rahul, we prepared a new pollicy which aim is to force maintainers
> to answer to easy fix bugs or orphan packages if they fail to do so in a
> one month delay. It may look a bit rude, but hopefully it will help
> spreading co-maintainership and quicker bugfixes. It is at
>
> https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance
>
> In my opinion it should be added to the non responsive policy at
> http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers

I have hopefully adressed th ecomments, by stating that this is a policy
for bug fixes, not easy bug as such. Also added a 3 weeks delay before
the procedure is started, precise a bit what is a bug easy to fix and
put explicitely the cleaning of blocker bugs on the reporter.

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-12-2008, 09:07 AM
Patrice Dumas
 
Default No answer to easy bug policy

On Sat, Jul 12, 2008 at 07:30:13AM +0200, Hans de Goede wrote:
>
> First of all, I agree that non-repsonsive ness to easy bugs and / or
> bugs with patches attached is an issue.
>
> But I'm not sure this is a good solution. There are really 2 problems here:
> 1) The person responsible for the package is letting these bugs linger
> 2) Others do not fix it, even though they could, because they are afraid
> of stepping on each other's toes, as you correctly point out.
>
> I feel that your policy completely fails to address 2), whereas that
> might be one of the more important points. For example I don't mind

I agree. But this is not the intent of this policy, I mean even if 2) is
easier (and it has became a lot easier already) it may happen that
something is needed to have the maintainer react.

> other people touching my packages _at all_, which can be seen from there
> ACL's. So we could have a policy that says that "easy fixes" (whatever
> the definition) may be done by anyone with CVS extras without a prior
> headsup, when the ACL's allow it. IOW, codify in policy that the ACL
> signals how much a developer minds other people touching his packages.

I don't think we should mix the ACL with the intent to allow anybody to
fix packages. Having open ACL also allows to have a package fixed for
cases already covered by the WhoIsAllowedToModifyWhichPackages policy,
for example.

> Another possible solution would be a I don't mind my toes getting
> stepped on list in the wiki.

I think that it should better be in the packagedb.

But I am not sure that it will fix the case I did the policy for, since
if somebody is really opened like you are, a simple comment in the bug
like 'you can do it' is very low cost, but I personally have never seen
such a comment on the typical bugs that triggered me to do this policy.

--
Pat

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

Thread Tools




All times are GMT. The time now is 08:29 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org