TSC minutes for 20101007

TSC minutes for 20101007

[Phil Blundell]

TSC Meeting of 20101007T1500

Present: Richard, Chris, Holger, Phil

1. OEDEM

Richard reports Intel have everything under control.  No action needed
except to announce the venue (same as ELC-E) and solicit items for the
agenda (see wiki page Oedem/2010).

2. Revert policy

Frans Meulenbroeks requested the TSC to consider whether a particular
reversion commit (which was pushed without review despite changing
"core" files) was in breach of the agreed policies. 

Although the commit policy calls for changes to core files to be
reviewed, the existing revert policy does state specifically that
reverting one's own changes is permitted without further review.  There
is some ambiguity over whether the general requirement in the commit
policy for changes to "core components" to have review still applies to
the specific case of reversions, or whether this general requirement is
overridden by the specific guidance in the revert policy.

The TSC is of the opinion that, although the interaction between the
policies could be more clearly spelled out, the intended effect is that
one should always be able to revert one's own changes without further
review.  Consequently, the TSC considers that the commit in question was
legitimate and did not breach the policies.  Holger will write to Frans
and inform him of this decision. 

3. MAINTAINER(S)

Frans Meulenbroeks requested the TSC to consider whether the MAINTAINER
field in recipes should be revived, on the grounds that the existing
MAINTAINERS text file is not performing well and many recipes/distros
appear to be orphaned.

The TSC considers that the MAINTAINER field has not been a success in
the past and there is no evidence that it will work better this time.
The TSC also feels that, since MAINTAINER is included in output
packages, it would be best left to individual DISTROs to decide how (if
at all) they wish to set that variable.

However, the TSC acknowledges that the existing MAINTAINERS file is
indeed stale and of questionable value.  Accordingly, the TSC proposes
to start with a fresh copy of the file and invite active maintainers to
migrate their entries from the old one.

4. Speed of removal

Richard noted that he feels the pace of removal has been too slow.

Chris noted that the pace of development has been too slow in general,
and that removals are just one part of this.

5. Future meetings

Phil suggested that it might be useful to hold TSC meetings more often
than the current once per month.  It was agreed that we will now hold
meetings every 2 weeks (next to be on Oct 21) and see if that works out
better.

Holger noted that, since he is now living in Europe, he would no longer
object to the meetings being held later in the day.  Absent any desire
for change from other members, however, it was agreed to leave the
meeting time unchanged at 15:00 UTC.

Meeting closed 16:16.

Re: TSC minutes for 20101007

[Graeme Gregory]

 On 15/10/2010 17:23, Phil Blundell wrote:
> The TSC is of the opinion that, although the interaction between the
> policies could be more clearly spelled out, the intended effect is that
> one should always be able to revert one's own changes without further
> review.  Consequently, the TSC considers that the commit in question was
> legitimate and did not breach the policies.  Holger will write to Frans
> and inform him of this decision. 
>
This was certainly my intention when I drafted the policy as part of the
TSC. My reasoning was that even after review a major flaw may be found
in your own patch. Reverting back to unpatched state may do less damage
than waiting 2 weeks for a futher patch to be implemented and reveiwed.

Graeme

Re: TSC minutes for 20101007

[Frans Meulenbroeks]

2010/10/15 Phil Blundell <philb@gnu.org>:

Phil, thanks for your minutes. TSC thanks for the wise decisions.

>
> 3. MAINTAINER(S)
>
> Frans Meulenbroeks requested the TSC to consider whether the MAINTAINER
> field in recipes should be revived, on the grounds that the existing
> MAINTAINERS text file is not performing well and many recipes/distros
> appear to be orphaned.
>
> The TSC considers that the MAINTAINER field has not been a success in
> the past and there is no evidence that it will work better this time.
> The TSC also feels that, since MAINTAINER is included in output
> packages, it would be best left to individual DISTROs to decide how (if
> at all) they wish to set that variable.
>
> However, the TSC acknowledges that the existing MAINTAINERS file is
> indeed stale and of questionable value.  Accordingly, the TSC proposes
> to start with a fresh copy of the file and invite active maintainers to
> migrate their entries from the old one.

Actually the request was to add MAINTAINER in distro and machine conf
files and in recipes, and I also indicated that in my opinion at least
for distro and machine it is good to know who is the owner.
We seem to have some stale distro's (see
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-August/022698.html)
and I also feel that we have some stale machines.

Note also that there are ways to define the value in different ways.
E.g. I can image a # comment in the .conf file.
Restarting MAINTAINERS is also possible.

BTW the root cause of my request is not the because I want to have the
MAINTAINER field in the recipe.
Idea is to know whom to contact in case there is an issue, and make it
clear when a distro or machine (and to a lesser extend a recipe)
becomes orphaned.
Since distro's (and to a lesser case conf files) can pin recipes it
seems more important that it has an identified maintainer.
>
> 4. Speed of removal
>
> Richard noted that he feels the pace of removal has been too slow.
>
> Chris noted that the pace of development has been too slow in general,
> and that removals are just one part of this.

Should we discuss this at OEDEM ?

Best regards, Frans