Re: draft alternative proposal: fix problem at the root
On Wed, Dec 3, 2014 at 9:31 AM, Sam Hartman wrote: >> "Russ" == Russ Allbery writes: > > Russ> There's another alternative to using the CTTE, and my > Russ> understanding is that this was generally the method used prior > Russ> to the existence of the CTTE, but I'm not sure it's really any > Russ> better. > > Russ> There are specific teams in Debian, generally delegates at > Russ> this point, that sit at choke points and can effectively make > Russ> decisions like this as part of the course of their duties. > Russ> For example, for the init system decision, I suspect a lot of > Russ> the pressure would have been on the d-i team to pick a > Russ> default. In the past, the usual victim for many of our > Russ> disputes has been ftp-master, since they can block archive > Russ> uploads or eject things from the archive. For others (and I > Russ> can recall some epic ones), it was the DAM. > > I remember back in my first years of Debian thinking that the TC wasn't > very effective. Stuff would get brought to them and not really > decided. > > Some folks (Ian's name springs to mind particularly but I don't recall > without going back to mail from the 2004-2006 time frame) really made an > effort to make sure that the TC responded to issues brought to it. The > TC became effective in that it gave answers if you brought issues to > them. > > Today, I think we have an opportunity to see if we can transform the TC > into a body that's good at helping people make these sorts of decisions > when there is conflict. I think it will be as much about mediation, > about asking people to work together, about pointing out to people they > are talking past each other, about asking people to reconsider their > decisions with certain criteria in mind than about overriding people. Doesn't that require constitutional change? The current powers as written make the TC a decision-making body, not a mediation body. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mm2pblhvxhpeyzq6k9y2wqv47fjaomuvbcehob_bda...@mail.gmail.com
Re: draft alternative proposal: fix problem at the root
On Wed, Dec 3, 2014 at 1:41 AM, Andrey Rahmatullin wrote: > On Tue, Dec 02, 2014 at 10:50:30PM -0500, Michael Gilbert wrote: >> Disbanding the TC would likely do more harm than good. There would be >> no way to conclude a disagreement. >> >> I suggested this before: >> >> TC actions should be limited solely to disagreement mediation, and only >> when >> that doesn't involve a conflict of interest pertaining to one of >> the TC members, >> and only when all other attempts at reconciliation have tried and failed. >> >> I would like to see all of section 6.1 removed and replaced by >> something simple, limited, and to the point like that. > > In that case we also need to make it easier to control the TC actions: > relax the requirements to override a decision and to remove a member, add > some provisions (at least think about it) for cases when the TC or its > members break the rules or procedures (by not recusing oneself, by acting > before trying to seek consensus, by making detailed design work etc.). Wouldn't public shaming of bad behavior as it occurs be a sufficiently effective control mechanism? Theoretically TC members should be the more mature members of the community and out of wisdom would err on the conservative side of whatever the constitution text finally reads. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MMsPwHQSQwZ4Lye7k2dwc=KunpXG=rscdacba9vphc...@mail.gmail.com
Re: draft alternative proposal: fix problem at the root
On Tue, Dec 2, 2014 at 6:42 PM, Daniel Kahn Gillmor wrote: > On 12/02/2014 06:13 PM, Jakub Wilk wrote: > >> This is an interesting proposal. But it's a big change, so I think it >> should be thoroughly discussed before I could second it. > > I agree some discussion would be useful, but seems like it's a lot > simpler than all the other noodling with term-limits that has gone on > thus far. What kind of thorough discussion would you like to have? > > It seems like the proposal is simple: > > * Do away with the Technical Committee entirely. > > The main questions this raises are: > > How would we deal with conflicts that would currently be addressed by > the TC? Hopefully, the answers would be something like: collaboration > and teamwork, negotiation, mediation, and GRs (in that order). > > Do we believe that those resolution mechanisms would be more or less > likely to cause strife within the project (or outside the project) than > would resolution by the current TC mechanism? Disbanding the TC would likely do more harm than good. There would be no way to conclude a disagreement. I suggested this before: TC actions should be limited solely to disagreement mediation, and only when that doesn't involve a conflict of interest pertaining to one of the TC members, and only when all other attempts at reconciliation have tried and failed. I would like to see all of section 6.1 removed and replaced by something simple, limited, and to the point like that. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mpmfvuexpu698ut+xn35thtk6ayg2m71z52gdk3dx7...@mail.gmail.com
Re: [all candidates] Return to the desert island (cont.)
On Wed, Mar 20, 2013 at 10:35 AM, Russ Allbery wrote: > Bart Martens writes: >> On Tue, Mar 19, 2013 at 05:09:00PM -0700, Russ Allbery wrote: > >>> note that free software interfaces to proprietary cloud platforms are >>> frequently used to manipulate the data in those platforms including >>> pull data *out* of those platforms. It would be quite ironic if we >>> refused to include in the distribution the tools required to pull one's >>> data out of non-free platforms. > >> An interface to facebook or to twitter or to the internet movie database >> or to websites with stock quotes may be freely redistributed but >> "requires software outside of the distribution to function". Why do we >> make exceptions depending on how "ironic" things are ? > > Because, similar to how all evil plans for taking over the world should be > run past a fifth grader first, all grand principles of ideology should be > checked for whether their actual outcomes are silly. I think the outcome of moving a package that falls in the "requires external stuff" from main to contrib would rarely qualify as silly. Take for example the twitter perl packages. The API is changing (of course that is something outside of Debian's control,). As a consequence, those packages are now up for removal from testing (since they're going to be broken for an entire stable release): http://bugs.debian.org/703257 If instead those packages were in contrib, which is of course considered not supported, if/when those external interfaces break, then at least the user knew upfront that they were taking a risk that their unsupported software may someday break. Part of the nuance is living up to user expectations. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mpg5d8_dbrmrttrc8p7awvqkm8kwa0nwrn5agqh_bk...@mail.gmail.com
Re: [all candidates] Return to the desert island (cont.)
On Tue, Mar 19, 2013 at 7:46 PM, Steve Langasek wrote: > On Tue, Mar 19, 2013 at 11:39:29PM +0100, Jérémy Bobbio wrote: >> 3. One test I've been taught to use to reason about free software is the >>Desert Island test [2] which starts by: > >> Imagine a castaway on a desert island with a solar-powered >> computer. > >> Obviously, software that are only frontends to unreproducible “cloud” >> services do not pass the desert island test. > > This is a mischaracterization of the "Desert Island test" as it was > formulated on debian-legal. The Desert Island test is about whether a user > can *comply with the license* of the software on a desert island when they > have no contact with the outside world. That the software may not be > *useful* to them on a desert island is a separate question, and applies to > many sorts of software, not just those used for connecting to particular > services over the Internet. Then again, this is a misinterpretation of the fundamental question Jeremy has attempted to pose. Although admittedly, bullet 3 does unfortunately lead to that kind of reasoning since it frames the question in a freeness context, which I agree is misleading. So, what then is the fundamental question Jeremy meant to pose? It is this: given the distinction between main and contrib as stated in policy 2.2.1 and 2.2.2 respectively: The main archive area comprises the Debian distribution. Only the packages in this area are considered part of the distribution. **None of the packages in the main archive area require software outside of that area to function.** [...] The contrib archive area contains supplemental packages intended to work with the Debian distribution, but **which require software outside of the distribution to either build or function**. are the packages currently in main that "require software outside of the distribution to either build or function" ultimately violating policy? And if so, should they be moved to contrib? I think Jeremy's suggestion of a Desert Island "Use" test seems quite appropriate to decide that question. And again, just to be clear, the Desert Island "Freeness" test has no relevance in answering the real question posed here. Note that I've looked into this problem in the past, and such cases where this question is relevant in main are fortunately quite rare. Nevertheless, it's an interesting subtle aspect that isn't much thought about (at least not in the right way). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mmx_sucjz2mzy-b78r4vb3+_w3jcxjwkjiisdqxu_2...@mail.gmail.com
Re: All candidates: Development and technical issues and challenges
On Tue, Mar 19, 2013 at 3:14 AM, Lucas Nussbaum wrote: >> Maybe we could discriminate on the package's priorities. For example, >> about a third of the 49 packages *really* blocking the release (not >> waiting for a transition) are from "extra"[2]. Only 5 bugs affect >> required, important or standard packages. We could focus on those and >> tell the "extra packages" to hurry up or be shipped with packages that >> will need to be fixed in a point release... or simply removed. > > That's something I already commented on in > https://lists.debian.org/debian-vote/2013/03/msg00020.html: > >Another possible area of improvement is the focusing on the more >important RC bugs. One way to achieve that would be to remove as many >leaf/not-so-popular packages as possible at the start of the freeze. >If they get fixed, they could get back in. Even the suggestion of a testing removal can evoke negative feelings for those affected (sometimes from those on the sidelines too). A recent example: http://bugs.debian.org/703258 Do you have any thoughts on addressing the social aspect of this approach? In actuality, a testing removal is really not a big deal since the package can come right back once the RC bug is fixed. Even so, some see removals as a kind of judgement on themselves as maintainer. What can be said or done to qualm the fear and anxiety? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mmpswcpjier+3aaeatqkecn9nl0tqca+ijqexpwpm_...@mail.gmail.com
Re: [all candidates] Debian as an FSF Free Software Distribution
On Thu, Mar 14, 2013 at 12:21 PM, Paul Tagliamonte wrote: > What work will you be doing to continue Zach's efforts to negotiate with > the FSF over Debian's status as a Free Software Distribution? > > Will you treat this issue as a priority? Can we expect continued open > dialogue with the FSF on this issue? Would you be willing to help find > the right concessions on both sides to collaborate? > > What is your opinion on this matter? I am more curious what the candidates think should or can be done in light of the FSF's absenteeism in that discussion (so far). What (if anything) can actually be accomplished without even a partially-defined path from their perspective? Best of luck! Mike -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MOcc1KxBYQ9HDri4sWTJdqQNVcc8H-FGz6p=o45mbu...@mail.gmail.com
Re: General Resolution: Diversity statement
On Tue, May 8, 2012 at 5:28 PM, Debian Project Secretary - Kurt Roeckx wrote: > Hi, > > A new General Resolution has been started about a diversity > statement. > > More details are at: > http://www.debian.org/vote/2012/vote_002 Question on procedure: The initiating GR mail included the following statement Q: What will be the procedure for maintaining/updating the statement, once voted? A: The gist of the statement will be fixed by the GR. But in order to avoid needing a vote for every minor tweak, language improvements can be applied by the -www team as for other parts of www.d.o and more substantial changes, that do not change the spirit, can be discussed on -project. Given that this statement is absent in the actual GR text to be voting on, are voters to assume it will or will not have any bearing on the outcome of the vote? Personally, I think it should not; although I'm sure opinions will vary. Given that, I don't think its possible to say one way or another. So, in order to have a definitive conclusion on this matter, shouldn't it be included in the actual GR text, or as an alternative, or as an amendment? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MM3=2pkustn27zrnfdnnikoxsaowwnuwc76spvfww4...@mail.gmail.com
