[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Orphaned packages not! (splat, gpsman, nec2c)



On Fri, 2008-06-06 at 16:41 +0200, Patrice Dumas wrote:
> 
> The policy here is the non responsive maintainer policy. Otherwise the
> primary maintainer should not be changed. However the redhat folks don't 
> seem to follow this procedure and instead it seems that change in package
> maintainers owned by people @redhat is done by other procedures,
> including with more sharing of responsibility over package among groups.
> 
> I am not sure that there is something that can be done in fedora about 
> that issue. Maybe the exception should be written down explicitly such 
> that people like you who is at redhat and in the community knows who 
> to contact @redhat to follow the fedora rules.
> 
> Also maybe I am mistaken and there are no specific rules for redhat
> people, only remnants from the past (like the many agg co-maintainer I
> have who are certainly not interested).
> 

Part of the problem is the CLA entry.  Many Red Hat employees have a CLA
attached to their account through the redhat_cla, that is part of their
employment contract.  When they leave Red Hat, that contract is no
longer valid, nor is their CLA status.  In actuality, this is true of
any Fedora contributor that changes employers, we just have less
visibility into that and assume the maintainer is doing the right thing
wrt to their CLA status.

I've asked Casey to put some thought into a process we can use when we
become aware of somebody changing their CLA status, like leaving Red
Hat, especially if we know ahead of time that they are leaving Fedora at
the same time.  Waiting for bugzilla entries to be replied to when
they're assigned to a non-valid email address seems like a bit of a
waste.

All in all, there is definitely some room for better process here.

-- 
Jesse Keating
Fedora -- FreedomĀ² is a feature!

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]