|IRC Transcript from today's session 22feb06 [message #575322]
||Wed, 22 February 2006 13:17
| Oisin Hurley
Registered: July 2009
AMiguel joined the chat room.|
[17:08] sdaume: when are we going to start ?
[17:09] oisin: I'm expecting Carl to run this meeting
[17:09] DavidBosschaert: I think he will join.
[17:09] DavidBosschaert: He was testing his IRC client earlier today.
[17:10] oisin: he was on earlier...could be just a local glitch
[17:10] sdaume: ok
[17:10] oisin: let's give him a few more minutes and if no sign assume
client meltdown and continue on with items from the list/newsgroup...
[17:13] boisvert joined the chat room.
[17:14] oisin: ok that's three minutes, let's begin with some items from
the newsgroup, agreed?
[17:14] AMiguel: ok
[17:14] davidbrpr: yes
[17:14] sdaume: ok
[17:14] oisin: Thx. I'll list 'em and then we can take them in turn...
[17:14] boisvert: ok
[17:15] oisin: 1: code review issue: Mike@scapa has cast this as a
possible anti-trust situation
[17:15] oisin: 2: build system: update on status and any specific
[17:17] oisin: 3: confirm possible proposal for commit decision:
Mike@scapa has mentioned 'retroactive commit model' as mentioned in
Eclipse Charter 1.0 :
[17:17] oisin: any other items, now is the time to shout
[17:18] oisin: [note - our Dublin office experienced internet outage for
most of yesterday, apologies if anything else from mail etc missed]
[17:18] oisin: I see no items above and beyond those mentioned.
[17:19] oisin: Item 1...
[17:20] sdaume: apart from the anti-trust issue there are a few more
concerns I would like to raise with this
[17:20] oisin: ?
[17:20] oisin: sorry
[17:20] sdaume: having reviewed this a bit more, I think that there is a
contradiction between the status a committer has in the Eclipse
community and the proposed STP commit review procedures
[17:20] oisin: can you give us the details?
[17:21] sdaume: in my view by the very nature of the process that allows
someone to become an Eclipse
[17:21] sdaume: committer this person must be viewed as a trustworthy
source ensuring quality and
[17:21] sdaume: reliability of his or her contribution
[17:21] sdaume: and yet we propose to put another level of review on the
commit process that in my view is likely to stifle progress
[17:22] DavidBosschaert: I was wondering if other people have concerns
[17:23] DavidBosschaert: Remember, the suggestion was really to only
have one other committer say that he agrees with the submission. All the
other processes (vetos and the like) are still in place.
[17:23] oisin: the nature of the meritocracy gives implicit trust to
those responsible for commits...
[17:25] oisin: stefan, do you think that the PMC should make a decision
on a commit process as described in the eclipse charter?
[17:25] sdaume: can I take this as agreement that we do not need
committers ok-ing each others contributions (vetos, etc are of course
still in place)
[17:25] boisvert: I tend to agree with Stefan
boisvert: i agree
[17:25] DavidBosschaert: Maybe we need to get this through PM or a vote
on the mailing list
[17:26] DavidBosschaert: there are many people absent today on the IRC...
[17:26] DavidBosschaert: (PMC that is, not PM)
[17:26] boisvert: i think a process like this makes sense for large
[17:26] AMiguel: Does anyone currently still strongly feel that we
should have code reviews?
[17:26] DavidBosschaert: I do
[17:27] jrohn: I agree with Stefan.
[17:27] boisvert: I must say I have seen this review process work well
in other open-source projects
[17:27] boisvert: and I'm thinking about FreeBSD in particular
[17:27] boisvert: so it's mostly a question of culture, as always
[17:28] davidbrpr: i would agree with stefan as well
[17:29] sdaume: i would be very worried as to whether we could ensure a
consistent review process
[17:29] oisin: how about a middle ground in which PMC does not mandate
code review, but it is strongly encouraged to be a part of the project
[17:31] AMiguel: might that still be in breach of anti-trust laws?
[17:31] alainow joined the chat room.
[17:31] oisin: I am concerned about the phrase 'anti-trust' being used here.
[17:31] oisin: Let me say why...
[17:32] oisin: The PMC can mandate a commit process as per the eclipse
charter. Mike has pointed this out.
[17:32] oisin: The example commit processes in the charter include
voting, and vetoes
[17:33] oisin: Any process that can include a veto/simple majority vote
is potentially open to exploit in a manner that would be inconsistent
with anti-trust laws
[17:33] oisin: So the point is not explicitly connected with code
review, but any commit decision process that involves the group as a whole
[17:35] oisin: Now -- I am inferring that bringing up 'anti-trust' this
early in the day means that you are not in favour of *any* commit
decision process. Is this the case?
[17:37] sdaume: I think these are two different issues
[17:37] AMiguel: I'm not bringing up anti-trust to block code reviews
[17:37] sdaume: we should not mandate code reviews
[17:37] oisin: So - the issues are already divided up as issue (1) and
issue (3) for this chat
[17:38] sdaume: if people are happy with encouraging it and that leads
to agreement it seems sensible to me
[17:39] sdaume: although one has to wonder how useful it is to put it
down at all in this case
[17:39] AMiguel: I'm not at all sure but I think that what we might be
encouraging here might be deemed collusion unless it was an open process
and everyone was invited
[17:39] AMiguel: If the meeting was declared in advance on the mailing
lists and anyone could attend then I think that would be ok
[17:40] ericn joined the chat room.
[17:40] AMiguel: As I say, I'm not sure, but I think we have to run this
by Mike or the Board before we can OK recommending code reviews
[17:40] AMiguel: Personally I don't have a problem with us recommending
[17:41] ericn: sorry to join late but as a board member perhaps I can help
[17:41] oisin: Ok, so now I have another proposal
[17:41] sdaume: by encouraging I understand that it is entirely optional
and thus its usefulness is questionable
DavidBosschaert: I agree that just encouraging doesn't really mean anything.
[17:42] sdaume: so we should just drop it
[17:42] oisin: I disagree with David and Stefan
[17:43] oisin: A statement that encourages an activity that builds
knowledge and cohesiveness of the project team is important.
[17:43] jrohn: I agree with David and Stefan, if it isn't mandated,
putting in the statement "strongly encouraged" doesn't really mean much.
[17:44] sdaume: we should not mandate code reviews but the PMC may adopt
a commit decision process which should be adapted to the project phase
(the charter states that it may change over time)
[17:45] sdaume: initially, I am very keen to see progress and anything
that stifles progress with regard to the initial contributions is not good
[17:45] oisin: actually, has anyone assumed that initial contributions
must fall under code review?
[17:46] DavidBosschaert: I thought that a separate contribution process
was for that?
[17:46] sdaume: initial could extend quite some time
[17:46] AMiguel: I have been assuming that the idea is all code
contributions would require code review
[17:46] sdaume: its soemthing we need to define
[17:46] oisin: when does initial stop being initial?
[17:47] sdaume: i guess this is down to the definition of certain
[17:47] sdaume: we should park this since we really need to have Carl
and others in the conversation for this
[17:47] oisin: ok. implication here is that we will need to decouple
sub-project release cycles, yes
[17:48] oisin: agreed stefan.
[17:48] AMiguel: I think we should park it and ask the board if either
A) mandating code reviews or recommending code reviews is OK
[17:48] DavidBosschaert: Agree
[17:49] ericn: ok I can take that action if someone would like to
summarize it for me
[17:49] oisin: Should we approach the EMO first as they are the legal
entity and then they may escalate to the board?
[17:49] ericn: yes actually that is probably the correct path forward
[17:50] oisin: Wording for the questions to the EMO....
[17:50] sdaume: I think we should NOT mandate code reviews (or state an
ecouragement in the guidelines) and I also think that the discussion
today allows us to put this to a vote on the list
[17:51] sdaume: furthermore we should raise the issue of commit decision
process in another meeting with everyone present
[17:52] oisin: I think that our discussion today was good, but I would
submit that the issue is important enough that everyone must read it
[17:52] sdaume: so we pass the vote until next weeks IRC ?
[17:53] sdaume: and address point 3 then as well ?
[17:53] oisin: I think we should try to do it before then over email if
[17:53] sdaume: agreed
[17:53] AMiguel: agreed
[17:54] oisin: Is everyone here on the dev list?
[17:54] DavidBosschaert: Yep
[17:54] AMiguel: yep
[17:54] sdaume: yes
[17:54] jrohn: yes
[17:54] ericn: not sure
[17:55] ericn: can someone add me?
[17:55] oisin: no prob eric
[17:55] ericn: thx
[17:55] oisin: does anyone object to bringing this issue before the EMO?
[17:56] oisin: for guidance on anti-trust issues.
[17:57] oisin: I see no objections, this can be a parallel activity.
[17:57] oisin: Before time up: item (2) briefly
[17:58] oisin: I'm working with help of Naci from the WTP on getting the
build system set up
[17:59] oisin: I'm guessing that we will need to decouple the milestone
release plans for the sub projects
[17:59] oisin: So we will need that ability
[18:00] oisin: AOB?
[18:02] AMiguel: all done?
[18:03] oisin: I think so, if no-one has any more - I'll post IRC
transcript to list, we can extract and discuss issues and make some
progress there before next week
[18:03] sdaume: ok
[18:03] oisin: see y'all then
Principal Engineer, IONA