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

[Toshio Kuratomi]

On Wed, Jul 25, 2012 at 05:36:41PM +0100, Matthew Garrett wrote:
> 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.
> 
Absolutely.  But it is FESCo's responsibility to determine how well confined
a feature is.  So rather than phrasing this as FESCo should stay out of it
unless "it's clear that the feature is going to have a significant impact on
packages outside of those directly affected by the change" I would emphasize
that FESCo is supposed to play an active role in discovering and evaluating
what hte impact of a feature will be.  This is because, as I stated, the
feature owners are better are understanding how their changes affect what
they are working on.  But they aren't always better at seeing the big
picture.

And if you disagree with that, then I will reiterate that we should add that
to the Fixing Features page a an anti-goal for an updated Feature Policy.
If it is an anti-goal, it would allow for options where FESCo is not
involved in the Feature Process for many features.  If FESCo isn't a player
in fact finding about how big the impact of a feature is, Features can be
processed for whether they should be documentation-only features vs ones
that require either "approval on whether this is a direction the distro
should take" and "needs coordination among maintainers" before they reach
FESCo.  FESCo would only step in on "documentation-only" features if someone
complains that the feature is more than a documentation-only change.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120725/bcfe502c/attachment.sig>