Re: What do you expect from the DPL?
On 16/02/15 at 20:39 +0100, Ondřej Surý wrote: > Just few random notes... > > On Fri, Feb 13, 2015, at 04:08, Paul Wise wrote: > > > - Mediation regarding social and technical problems > > > > The former seems like the responsibility of Debian as a whole and the > > latter is the responsibility of the CTTE. > > I have several occasions in my mind when I would be happy if someone has > stepped in and helped with mediation. For my own sake, and for the > problem sake. Note that it can also have very negative effects if someone jumps in and starts mediating when none of the parties involved have actually asked for mediation. So, in general, if you think mediation from someone would be helpful, it's better to be explicit and request it. > I view CTTE as a heavy hitter and DPL could use more soft approach > before the parties approach CTTE. Having the DPL and the CTTE involved at the same time is a bit problematic, as they are defined as two very separate and independent bodies in the constitution. In the case of issues with CTTE member(s), I think that a better first step is to approach another CTTE member, or the CTTE chairman, and then if this fails, to approach the DPL about it. > Also sometimes there is a feud between developer and delegate. This is > also area where DPL could step in and help with the outcome. Sure. Lucas signature.asc Description: Digital signature
Re: What do you expect from the DPL?
Just few random notes... On Fri, Feb 13, 2015, at 04:08, Paul Wise wrote: > > - Mediation regarding social and technical problems > > The former seems like the responsibility of Debian as a whole and the > latter is the responsibility of the CTTE. I have several occasions in my mind when I would be happy if someone has stepped in and helped with mediation. For my own sake, and for the problem sake. I view CTTE as a heavy hitter and DPL could use more soft approach before the parties approach CTTE. Also sometimes there is a feud between developer and delegate. This is also area where DPL could step in and help with the outcome. I can provide specific examples off-list. > > - Be aware of everything that goes on with Debian. E.g. I have the feeling > > some > > people expect the DPL to read all the Debian mailing lists. > > That is simply not feasible, even though the amount of discussion that > goes on in Debian feels like it is going down over time. Just the sole idea of reading all the mailing lists gives me shivers. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1424115598.3334844.228244697.336a5...@webmail.messagingengine.com
Re: What do you expect from the DPL?
On Feb 16 2015, Ian Jackson wrote: >> I haven't seen any followup from the tech ctte on some of the disucssion from >> Dec about improving the way the ctte approaches requests, cf >> >> https://lists.debian.org/debian-vote/2014/12/msg00050.html >> https://lists.debian.org/debian-vote/2014/12/msg00069.html >> https://lists.debian.org/debian-vote/2014/12/msg00075.html >> >> Improvements there might help with the DPL's workload, in so far as that >> involves dealing with arguments over technical things. > > I have a very different view of the TC to Anthony (and to those otehrs > who have suggested that the TC should be less quick to decide, or less > definite). > > My view is probably best summarised here: > > https://lists.debian.org/debian-vote/2014/12/msg00098.html > > And exemplified by my very trenchant comments (un-rebutted!) here: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766708#305 I'm a little confused by this: | IMO the committee has utterly failed to discharge its responsibility | here. If I had still been on the committee I would have pushed for a | swift vote to overrule. This bug was filed on Oct 25. The init system GR voting ended on Nov 18th, and I think you resigned a few days later. It seems to me there was at least some time available to push for a vote... On the other hand, I can't help but see an eery similary to #741573, where one maintainers actions are also blocking other people's hard work. In that bug, however, you seemto the main force preventing a swift vote. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87h9ulpvfv@thinkpad.rath.org
Re: Why are in-person meetings required for the debian keyring?
Christian Kastner dijo [Thu, Feb 12, 2015 at 10:30:16PM +0100]: > > In my opinion, exactly the same applies for someone you've met. I think > > it's a lot easier to get a forged id than to establish a history of > > valuable contributions. > > Well, it depends. A forged passport[1], if one even knows where to get > it, will cost you thousands of dollars or euros, and would furthermore > constitute a serious criminal offense. I wouldn't call that easy. Hundreds of dollars here (depending on the degree of "forgedness"). Passports good enough for international travel. Why? Lets say that... I just happen to know ;-) That's one of the reasons I don't care too much for government-issued IDs. That's why I didn't ask you to provide me with one. But at the same time, that's the reason why I (that happen to be a terrible physionomist and often don't recognize people) cared enough to pay attention to who is who, remember where we had lunch and what we talked about, and can reasonably describe your face. Of course, that's the reason I signed your key. That's also, however, why I didn't sign some people's keys: If I don't recall enough details about a person to satisfy my personal validation, I won't sign. Of course, given the example Paul said about Santa Claus: I *do* sign based on pseudonyms. Of course, on well-established and well-recognized pseudonyms. I don't know nor care about the real names of several of the people I have cross-signed with. > [1] A passport is the only form of identification some people were > willing to accept from me. I myself have only accepted these save for a > few exceptions, where I accepted a US driver's license but was otherwise > certain of the person's identity. When somebody asks for my govt-issued IDs, I take care to explain the inconsistencies they usually have. Like my driving license having "permanent" validity, or my voter ID card stating I'm 35 years old (the previous one said I was 29 until I lost it in France; the previous one, 20). -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150216180015.gh77...@gwolf.org
Re: What do you expect from the DPL?
Anthony Towns writes ("Re: What do you expect from the DPL?"):
> To my mind, that's because there's a lack of obvious alternatives on how
> to do ambitious Debian reform plans -- or in particular establishing the
> moral and practical support for them. So in the same sense that "the DPL"
> is the final answer for trying to resolve disputes when everything else
> you can think of fails, it's also the answer for trying to make big
> changes when you run out of other idas.
It seems to me that the problem is that
- the workload is too big for one person (although Zack did
an astonishing job)
- too many of the tasks involve exercise of implicit personal
authority, so that delegation is not an effective tool
I don't have an easy answer to this. It has often been suggested to
replace the DPL with a board, but with Debian's current approaches to
collective decsionmaking the board would want to argue internally
about each decision. The result would probably be more work per board
member per decision than the current DPL has work to do per decision!
> > They are all fine and well of course, but DPL time will in
> > the end have to be split among implementing those plans and tending to
> > often unpredictable day by day duties, with the latter often dominating
> > the DPL agenda (IME).
>
> I haven't seen any followup from the tech ctte on some of the disucssion from
> Dec about improving the way the ctte approaches requests, cf
>
> https://lists.debian.org/debian-vote/2014/12/msg00050.html
> https://lists.debian.org/debian-vote/2014/12/msg00069.html
> https://lists.debian.org/debian-vote/2014/12/msg00075.html
>
> Improvements there might help with the DPL's workload, in so far as that
> involves dealing with arguments over technical things.
I have a very different view of the TC to Anthony (and to those otehrs
who have suggested that the TC should be less quick to decide, or less
definite).
My view is probably best summarised here:
https://lists.debian.org/debian-vote/2014/12/msg00098.html
And exemplified by my very trenchant comments (un-rebutted!) here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766708#305
Ian.
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21730.11212.829216.241...@chiark.greenend.org.uk
