[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Call for a new DPL mediation ... This will be the only thread i will reply to in the next time about this issue.

On Monday 19 June 2006 08:27, MJ Ray wrote:
> Sven Luther <sven.luther@wanadoo.fr> wrote:
> > Also, you say i have been replaced, and this means you speak about
> > Colin Watson [...]
> Either that's a guess, or telepathy.  I'd guess it's a guess, but
> either way, it's not going to help anything change.  Either the
> guess is right, which makes it a pre-emptive attack, or the
> guess is wrong, which makes it irrelevant, or it's telepathy,
> which will scare the pants off 90%.

see the thread starting at [1], part of that thread is a discussion between 
Sven and Colin about what the open issues on powerpc are.

[1] http://lists.debian.org/debian-boot/2006/03/msg01198.html

> > Now, i am curious, did the DPL ever pass to you the compromise proposal
> > i made to them, and if so, what had you against it. The proposal was :
> > 1) i work on minor issues that needs fixing, partman-prep and apus
> > supoprt, and maybe one other i don't remember now.
> > 2) i don't post on debian-boot, and don't interact in issues where i
> > disagree with you.
> > 3) you reinstate my commit access, and don't make any more demands on
> > me, and don't get upset when i state my opinion on other forums where i
> > don't expect you to be.

regarding 2) I'm guessing the intention is _not_ to stop replying to 
powerpc-specific d-i bugs? 

Considering bugreports and replies get send to debian-boot how does this 
fit, do replies to bug simply not count or did you plan to reassign powerpc 
specific bugs to something that doesn't get send to -boot?

> Will nothing less than commit access solve this complaint?  I asked that
> in another message, but it's unanswered at the time of writing.

I really don't see how refusing Sven commit access alleviates any 
problems /providing he holds to point 1 above/:

- AFAIK nobody is arguing that Sven's patches aren't up to snuff
- AFAIK he hasn't ever abused his d-i commit rights (when he had them)

=> so IMO there's no _technical_ reason not to give him back his commit

AFAICT that leaves "to limit the contact between Sven and the d-i team 
members he doesn't get along with" as the only supposed reason to not give 
him back his commit rights. And I don't buy that one, I can't see any 
meaningfull difference in the amount of contact between:
a) having Sven commit through a middleman (current situation)
b) having him commit directly 
The same patches get committed in both cases, and in option a) credit is 
(presumably) given to Sven so his name appears just as often in commit 

> I don't see what compromise is being offered here.  As far
> as I recall, there was no problem about the first two points,
> while point three is all for Sven Luther. 

I'd expect any compromise solution to have some give on both sides. 

The above solution proposed by Sven has that:
- on Sven's side by: 
  - clearly delimiting what he can work on and 
  - not posting on debian-boot at all
- and on the d-i team's side by: 
  - letting Sven commit directly instead of through a middleman (i.e. not
    creating roadblocks on the technical side of his d-i work)

So we have:
1) Sven not posting on boot and limiting what he works on, but having commit
   -> this limits the social side of Sven's d-i work and thus adresses the
      problem directly
2) Sven posting on boot to his hearts content, but not having commit rights
   -> this changes the way Sven doess d-i work on a technical level by
      putting up a roadblock
   -> does absolutely nothing to adress the social problem, indeed it
      problably increases it as it adds a requirement for social interaction
      for every technical contribution Sven makes 
   -> creates extra work for both Sven and the middleman
   -> adds an otherwise unnecary delay for every fix done by Sven

The current 'solution' is IMO akin to telling Sven "yes you can participate 
in the d-i party, provided you stay outside and do it through the window". 
Which I think sucks big time as both a solution and a compromise. 
Cheers, cobaco (aka Bart Cornelis)

Attachment: pgpydJLZgKx5f.pgp
Description: PGP signature

Reply to: