TSC Meeting 7/1/2010

TSC Meeting 7/1/2010

[Richard Purdie]

[Ed: Sorry for the delay, the email client didn't send the first round
to all recipients, then I was travelling for a couple of days and needed
to round up the Acks.]

Report from the first TSC Meeting

The five of us all met on Thursday 7th January 2010 at 8pm and our main
priority was to start to establish some kind of procedures for the TSC
to operate effectively.


Meeting of the TSC
==================

We decided that having a regular timeslot we could all get together for
a meeting would be desirable. We agreed to do this on the first Thursday
of each month at ~8pm with the meeting agenda being announced the Monday
beforehand. No meeting will be held unless agenda items have been
proposed. This also does not rule out adhoc meetings should there be a
need.

The log of the first meeting is not worth publishing, this summary which
we've all agreed on is what we want to publish. Future meetings will
also be summarized.

None of us object to the principle of holding TSC meetings in public but
we do have concerns about not getting anywhere if we have lots of people
talking rather than just us. We don't expect a lot of technical
discussion in most cases as this should have already happened in public
on the mailing lists. If that isn't the case we may sent it to the
community for discussion. We concluded that allowing lurkers for the
meetings was good, inviting key people involved in any dispute to
represent their position would also be good if appropriate but that in
general people wanting things presented at the meeting would do so by
proxy through any TSC member(s) of their choice. We will try this format
for the next meeting (4th February) and then take feedback.


Remit of the TSC
================

The TSC are the arbitrators for OE's technical decisions and direction
and we concluded there were two main types of decision the TSC is
responsible for:

a) Dispute resolution between two parties in disagreement
b) Final approval of architectural direction for OE


Decision Making Process
=======================

We decided to create a moderated mailing list for the TSC escalation
process. If someone wants to ask the TSC for a decision on a dispute or
sign off on an architecture improvement an email would be sent to this
list in a standard format (TBA). These will have a subject line of a
specific format and contain information about what the dispute is,
between who, with links to both sides of a discussion most likely on
oe-devel about the issue with an attempt at resolving it. The TSC will
either accept the request or reject it with a reason such as more
community discussion required. Once accepted it will be listed in the
list archives. If the opposing side in the dispute wishes to reply to
the request this is acceptable.

The TSC will then make a decision to resolve the issue which will be
published as a reply to the request. It can do this via email/irc/jabber
discussion between its members informally and then voting via email. Any
TSC member can request this be deferred and discussed in a full meeting.
Resolutions from the TSC will list each members vote since we want
transparency. Each person has one vote and the decision is by majority.
Abstention from voting is frowned up, TSC members are expected to
investigate issues and form opinions. Votes can be pre-arranged for
meetings if a member can't make it for any reason.


TSC Elections
=============

We're aware no election was held as the number of candidates matched the
number of places. We are aware of the overwhelming need for OE to have a
decision making process so we want to get processes setup to allow this
to happen ASAP but consider ourselves an interim solution. We propose
asking for candidates in April and holding elections for a new TSC then
if we have some. After this, elections will be annual or when the
membership calls for them through the normal e.V. processes.


Current Issues
==============

We did discuss the IMAGE_BOOT issue. We decided that weak defaults (?=)
in the class where the variables are used is a good thing and that the
current structure is pretty much inline with that for image.bbclass. The
IMAGE_BOOT change could have been better thought out but we're stuck
with it now with no real options for changing it.

Commit messages were mentioned. It should be clear from reading the
commit message what the change applies to and why its necessary. The TSC
will start naming and shaming people making lousy commit messages and
reserve the right to impose sanctions against repeat offenders.

The QA issues are not something the TSC can really "rule" on. Yes
testing is good but we have no hardware or human resources we can assign
to this. Where a regression is identified as being from a particular
commit, it is expected the regression should be fixed though.

Patches were mentioned. The TSC is encouraging patches to have headers
with information about who wrote them, when, why and if taken from
somewhere else, where this was.

Anything else we didn't cover we propose be submitted to the new mailing
list to test the new processes which will be available soon.


Regards,

Your TSC

Graeme Gregory (XorA)
Koen Kooi
Chris Larson (kergoth)
Michael 'Mickey' Lauer (mickeyl)
Richard Purdie (RP)

Re: TSC Meeting 7/1/2010

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13-01-10 23:22, Richard Purdie wrote:

> Commit messages were mentioned. It should be clear from reading the
> commit message what the change applies to and why its necessary. The TSC
> will start naming and shaming people making lousy commit messages and
> reserve the right to impose sanctions against repeat offenders.

Commit messages like these are considered bad:

http://cgit.openembedded.org/cgit.cgi/openembedded/log/?qt=grep&q=Kristoffer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLTlTrMkyGM64RGpERAq+7AJ9hIMs+B3o6Z1pTCUOiyo0Pg4kUxgCgjr2G
SGibebD9LbQ4t3mzlX8YsiQ=
=eTSE
-----END PGP SIGNATURE-----

Re: TSC Meeting 7/1/2010

[Frans Meulenbroeks]

Richard, Thanks for making the minutes available.

A short reaction on a few things:
>
> Current Issues
> ==============
>
> We did discuss the IMAGE_BOOT issue. We decided that weak defaults (?=)
> in the class where the variables are used is a good thing and that the
> current structure is pretty much inline with that for image.bbclass. The
> IMAGE_BOOT change could have been better thought out but we're stuck
> with it now with no real options for changing it.

I guess the IMAGE_BOOT issue is the defaulting to udev issue. Anyway
it seems good to briefly explain the issue.

Is there a rationale why (in this case) weak defaults were considered
a good thing?
Personally I would prefer no defaults as an image recipe can easily
define them themselves (perhaps using an include of udev.inc or so).
In any case I feel if there are defaults the existence of the default
and perhaps some rationale should be documented (in the cookbook?).
I think we may expect that someone doing a recipe reads the cookbook,
but it should not be required to go through the class code to find out
about defaults etc.

(btw and if IMAGE_BOOT is not the "default use udev" issue I suggest
to table the latter topic).

>
> Commit messages were mentioned. It should be clear from reading the
> commit message what the change applies to and why its necessary. The TSC
> will start naming and shaming people making lousy commit messages and
> reserve the right to impose sanctions against repeat offenders.

I agree that we want good commit messages.

Some remarks though:

Before publicly naming and shaming people, I would suggest discussing
it with the offender in private email or on irc.
Naming and shaming might drive people away from oe.

I suggest that when someone gets commit rights (s)he is explicity
reminded of http://wiki.openembedded.net/index.php/Commit_Policy and
http://wiki.openembedded.net/index.php/Commit_log_example

I suggest to review the rules;. E.g. this one:
# This should all be on one line and you should leave an empty line
before any detailed commit information.
Nice, but if you use git commit and enter your message empty lines are removed.

Also i suggest an additional rule that commit messages should be polite.
E.g. no snide remarks on someone who made an earlier patch or on the
source package or on the code itself.

Frans

Re: TSC Meeting 7/1/2010

[Mark Brown]

On Wed, Jan 13, 2010 at 10:22:17PM +0000, Richard Purdie wrote:

> Patches were mentioned. The TSC is encouraging patches to have headers
> with information about who wrote them, when, why and if taken from
> somewhere else, where this was.

Debian has a draft standard for this:

	http://dep.debian.net/deps/dep3/

which might be useful.

Re: TSC Meeting 7/1/2010

[Guo Hongruan]

在 Thu, 14 Jan 2010 06:22:17 +0800，Richard Purdie <rpurdie@rpsys.net>  
写道:

> The QA issues are not something the TSC can really "rule" on. Yes
> testing is good but we have no hardware or human resources we can assign
> to this. Where a regression is identified as being from a particular
> commit, it is expected the regression should be fixed though.

The first goal of QA could be making sure that every (machine, distro,  
libc) combinations with default configuration will be built smoothly. In  
fact, I am trying to test them.

To achieve this goal, we don't need lots of human resources but several  
computers. We can develop a automation test Mechanism just like auttest  
using by linux kernel developing.

Thanks a lot!

-- 
Guo Hongruan, Embedded Linux Consultant
Skype: camelguo
Twitter: camelguo
http://www.gulessoft.com

Re: TSC Meeting 7/1/2010

[Philip Balister]

On 01/14/2010 04:02 AM, Frans Meulenbroeks wrote:

>> Commit messages were mentioned. It should be clear from reading the
>> commit message what the change applies to and why its necessary. The TSC
>> will start naming and shaming people making lousy commit messages and
>> reserve the right to impose sanctions against repeat offenders.
>
> I agree that we want good commit messages.
>
> Some remarks though:
>
> Before publicly naming and shaming people, I would suggest discussing
> it with the offender in private email or on irc.
> Naming and shaming might drive people away from oe.
>
> I suggest that when someone gets commit rights (s)he is explicity
> reminded of http://wiki.openembedded.net/index.php/Commit_Policy and
> http://wiki.openembedded.net/index.php/Commit_log_example
>
> I suggest to review the rules;. E.g. this one:
> # This should all be on one line and you should leave an empty line
> before any detailed commit information.
> Nice, but if you use git commit and enter your message empty lines are removed.
>
> Also i suggest an additional rule that commit messages should be polite.
> E.g. no snide remarks on someone who made an earlier patch or on the
> source package or on the code itself.

The commit messages problem has been an on going issue. For some reason, 
there seems to be a never ending series of commits with not very good 
messages.

People, when you are working with new contributors, encourage them to 
start out using good commit messages so the the problems Frans is 
describing do not crop up.

Project specific branches should also strive to follow the commit 
message form so that changes can easily be merged into the main OE repo.

Philip

Re: TSC Meeting 7/1/2010

[Denys Dmytriyenko]

On Thu, Jan 14, 2010 at 10:02:57AM +0100, Frans Meulenbroeks wrote:
> I suggest to review the rules;. E.g. this one:
> # This should all be on one line and you should leave an empty line
> before any detailed commit information.
> Nice, but if you use git commit and enter your message empty lines are removed.

Not really. "git format-patch" and "git am" use the empty line separation to 
determine, what becomes patch subject and what is patch description in the 
body. So, the above rule/requirement is very correct. More on the topic:

http://progit.org/book/ch5-2.html#commit_guidelines

-- 
Denys

Re: TSC Meeting 7/1/2010

[Frans Meulenbroeks]

2010/1/15 Denys Dmytriyenko <denis@denix.org>:
> On Thu, Jan 14, 2010 at 10:02:57AM +0100, Frans Meulenbroeks wrote:
>> I suggest to review the rules;. E.g. this one:
>> # This should all be on one line and you should leave an empty line
>> before any detailed commit information.
>> Nice, but if you use git commit and enter your message empty lines are removed.
>
> Not really. "git format-patch" and "git am" use the empty line separation to
> determine, what becomes patch subject and what is patch description in the
> body. So, the above rule/requirement is very correct. More on the topic:
>
> http://progit.org/book/ch5-2.html#commit_guidelines
>
> --
> Denys

I stand corrected.
When I wrote that I seemed to recall that the file you get when you
commit says that whitespace and comment is removed, but my memory
played games with me as only the leading and trailing empty lines and
comments are removed. (and no one ever complained to me about not
having empty lines in the commit message)

And thanks for the progit.org link. Didn't know that one. Interesting reading.

Frans