Summary/Minutes from today's FESCo Meeting (2012-07-23)

Matthew Garrett mjg59 at srcf.ucam.org
Wed Jul 25 16:36:41 UTC 2012


On Wed, Jul 25, 2012 at 08:34:04AM -0700, Toshio Kuratomi wrote:
> On Tue, Jul 24, 2012 at 11:38:00PM +0100, Matthew Garrett wrote:
> > The feature was +1ed on the assumption that the feature owner, as a 
> > maintainer of relevant code, is in a better position to judge the impact 
> > on the packages they're working on than people who don't have that level 
> > of expertise in the area in question. If the change turns out to have a 
> > negative effect on the distribution as a whole then that's something 
> > that should be discussed. If there's no more reasonable solution then it 
> > should be reverted. But at present procedure is working pretty much 
> > exactly as expected.
> >
> While I think that there might be some hyperbole in reaction to this Feature
> approval, this view of the Feature Approval Process is certainly not how
> I envisioned it when we initially implemented the Approval Process.  FESCo
> reviews the Features in order to understand and point out how the changes
> will impact the distribution as a whole.  Maintainers *are* better at
> understanding how their changes affect the code they work on but they
> aren't always better at seeing how their changes impact other people and the
> code that they maintain.
> 

If it's clear to FESCo that the feature is going to have a significant 
impact on packages outside of those directly affected by the change then 
FESCo should take that into account when approving the feature. However, 
if a feature is well-confined to the packages under the maintainer's 
responsibility then second-guessing the maintainer's judgement is 
dangerous. Any negative fallout should be dealt with by the maintainer, 
and unless that fails I don't see any reason for FESCo to be involved.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org


More information about the devel mailing list