Policy RFC: When to touch other peoples packages (or: Fix stuff that needs fixing)

[Thorsten Leemhuis]

Hi!

Patrice Dumas schrieb:
> On Mon, Oct 23, 2006 at 07:15:25PM +0200, Thorsten Leemhuis wrote:
> 
> Overall I find the proposal very satisfying, I have some minor remarks.

MAny thanks for your comments.

> One general remark, maybe it could be said somewhere that contacting by 
> mail/irc could also be done in place or in addition to bugzilla. No need
> to mention if it is too obvious.

Yeah, might be a good idea, but bugzilla should be preferred (see Nils mail)

>> === Inactive Packager ===
>> The packager normally should keep track of his packages; that means:
>>   * looking at the [:Extras/PackageStatus: Package Status] pages in the
>> wiki now and then
> 
> I am not sure about that one. I find the Package Status very usefull, but I
> can't see in which case it would justify a change in a package without 
> a report to the maintainer. Otherwise said, I don't think having an issue
> listed on the Package Status enough to permit experienced users to modify
> others packages without noticing them.

Of course not everything that's listed on that page requires that
someone else steps up to fix it. But contributors should look at the
page now and then and watch out for their names because that's a good
way to find potential problem.

>>   * fix EVR problems if they get mentioned in the problem reports on the
>> fedora-extras-list
> 
> I would propose a refinement here: 
>   * fix EVR problems if they get mentioned in the problem reports on the
>   fedora-extras-list, except for EVR issues with devel which occurs outside
>   of the pre-release mass-rebuilds.
> 
> The reasoning is that during testing periods those EVR issues with devel 
> are not to be considered serious as to justify somebody modifying others
> package without a notice.

Why not? People at any point of time may want to update from FC-current
to rawhide. It should just work. And rawhide users are probably the best
testers, so they always should have the latest version.

Further: I don't think we should go to much into details (like the one
you described) because the document otherwise might soon end might end i
a big page that might be unmaintainable and to long to read.

>>   * Important stuff should be fixed as quickly if possible -- waiting
>> one day for the maintainer to show up and step in to fix a issue that
>> got reported to him is considered enough
> Sometimes it is even acceptable not to wait at all. For example one of
> my packages screwed the build system and I think it was perfectly right
> not to wait a minute to fix it.

Agreed, maybe I can get that integrated.

>>   * not that important problems should be dealt with quickly, too --
>> waiting for 2-7 days (depending how bad the issue is) is considered enough
>>  * bugs need similar treatment like security problems:
> I have a cosmetic remark here, maybe would be better like
>    * bugs needing similar treatment like security problems:

k, I'll integrate that when the wiki is ready again.

>>   * annoying, but not that harmful bugs -- waiting for 21 days is
>> considered enough
> That's not always true. I think that those case should better be agreed
> upon in bugzilla discussion, and should only be acted upon if there is 
> no disagreement, only a lack of responsivness.

Well, the whole section is titled "Inactive Packager", so this of course
only applies to "lack of responsivness" ;-)

>>  * if you committed changes to another package wait some hours if
>> possible (normally 24 or 48) before you actually build the updated
>> package. That leaves some time for the maintainer to wake up ;-)
> It may be obvious, but this is a good rule but only for issues that are
> not serious.

Agreed, will adjust.

>> As experienced packagers count:
>>  * FESCo members
> 
> I don't want to be negative here, nor show disrepect to FESCo members,
> but I don't think being FESCo members should qualify here. A FESCo member
> could be there to represent something and not because he has great 
> technical ability to fix packages.

Well, I think all FESCo members normally should have a "technical
ability to fix packages". Maybe one time there will be someone in FESCo
that might not have it, but a FESCo member should be able to know about
that and leave such work to others. And otherwise yell on the
mailinglists ;) Errors get made by everyone and can be fixed.

> As a side note aren't the current
> FESCo members all sponsor? 

All FESCo members are sponsors these days.

>>  * Sponsors
>>
>>  * Especially the QA and Security SIGs
>>
>>  * the SIG that's handling the area in which the package or the fix is
>> needed. But
>>
>>   * the SIG has to exists for at least two months and needs to have
>> shown activity in the past two months
>>
>>   * the member is and experienced Extras packager and around for at
>> least four months and member of the SIG for at least one month
> 
> I think that it would also be right if experienced fedora core packagers
> could be considered as experienced Fedora packagers. Not all the core
> packagers, since some don't seems to care that much about the packaging 
> guidelines. What about a rule like 
> 
> * core packagers that have been through a number of reviews (for extra 
>   or core packages) and are core packagers for more than 4 months.
> 
> Or something like that.

k, agreed.

> I think that the reverse could also be true, core packagers should seek 
> more assistance in the extras community... But that's another debate.

+1 :-)

Cu
thl