Bug#681419: Alternative main-non-free dependencies text
On Thu, Sep 26, 2013 at 04:50:07PM +0100, Colin Watson wrote: Yes, this is the main comment I have when reconciling Ian's version with my option B. I suspect - without having checked - that what happened is not so much that Ian intentionally dropped this, but that he took a part of my original text without the amendments I made in response to your previous comments [1]. I've taken the liberty of restoring similar text [2]. Great, thanks a lot! -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#681419: Alternative main-non-free dependencies text
On Sat, Jun 29, 2013 at 11:43:26AM +0200, Andreas Barth wrote: 9. When it is necessary to provide a reference in a Depends or Recommends from main to non-free, this should be done via a neutrally named virtual package. When depending on such a virtual package, other packages should specify a real package in main as the first alternative, e.g. Depends: package-in-main | virtual-interface. The second is already part of the policy, Uhm, not really. Policy certainly has provisions to ensure that non-virtual alternatives are provided in combination with virtual ones where needed. But my point with the observation above is to ensure that the non-virtual alternative *is in main*. As far as I can tell Policy is silent about that. Therefore it seems to me that if you don't say anything about this (IMHO very important) detail in the resolution, the risk of losing explicit preferences for packages in main along the way will become real. Cheers. PS I forgot to Cc: the bug log in my previous mail; I'll now bounce that mail to the bug log for the sake of easier retrieval with bts(1) -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
On Mon, Apr 15, 2013 at 07:49:10PM +0800, Thomas Goirand wrote: As a consequence, I am questioning the motivation behind all this, and asking myself if we aren't seeing here (yet) another instance of miss-behavior from Ganneff, who probably disliked the fact that I defended my friend when he expelled him, and when I questioned the possibilities of getting rid of the NEW queue in a debian-devel thread. I have of course no proof to back this up Then I strongly recommend that you refrain from suggesting something like the above in the future. I don't think that anyone in our community should go around spreading that kind of accusations, unless they're backed by *very* convincing evidence. I believe that the negative side-effects of doing so are far worse than anything that could possibly be be gained (technically or otherwise). FWIW I'm in charge as DPL for only 1.5 more days so I'll leave this up to Lucas to pick, in case something DPL-ish is actually needed. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Thanks.
On Tue, Feb 05, 2013 at 01:48:22PM +0100, Julien Cristau wrote: Package: tech-ctte [cc to syslinux maintainer, debian-release, debian-boot, leader] Hi, […] Just a short notice to thank everyone for the speedy handling of this matter. I've been impressed. tech-ctte should always remain the last resort to solve technical conflicts in Debian. But when it comes to tech-ctte, it is really important to be efficient, otherwise developers would lose faith in tech-ctte ability to solve issues in the time-frame that matters to them. This particular aspect has been perceived as an issue affecting the tech-ctte in the past, but we are now clearly past that, thanks to your work --- no matter how unpleasant I'm pretty sure it is sometimes. Kudos. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#699808: Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Thu, Feb 07, 2013 at 11:08:55AM +0100, Daniel Baumann wrote: i'm argueing for either an explicit unfrozen sid or an explicit frozen sid. since it's neither right now, and you intend to overwrite the maintainers decision via CTTE to upload newer syslinux to sid, you need to argue against it, not 'doesn't gain anything'. Daniel, I don't think this is the place for such a broad discussion. I believe we would all agree that a frozen distro development (no matter the suite where it happens) is a PITA that we could all live without. But at present, this is what our release processes and technologies offer. Like it or not. It would be very nice to improve them, and I've high hopes that dak based personal package archives would help a lot with that, but this is not the time for this kind of changes. More importantly, it is arguably false that sid is not explicitly frozen. The freeze policy [1], which has been repeatedly announced on d-d-a, reads: Please also note that since many updates (hopefully, the vast majority) will still be going in through unstable, major changes in unstable right now can disrupt efforts to get RC bugs fixed. We don't ask you not to make changes in unstable, but we do ask that you be aware of the effects your changes can have -- especially if you maintain a library. Please continue to keep disruptive changes out of unstable and continue making use of experimental where appropriate. Note that you can stage NEW uploads in experimental to avoid disruption in unstable. [1]: http://release.debian.org/wheezy/freeze_policy.html by evidence, your change to unstable has been disruptive. I understand (better, I trust your claim on that, but I haven't checked) that experimental is not a viable path for syslinux development. But that is no justification for getting in the way of a release, going explicitly against the freeze policy. Please put back in sid the syslinux version that the release team wants to see in there. Ideally, it wouldn't be for long, and an action of that kind will avoid burning cycles of all the people participating in this thread. I'm pretty sure we can all use those cycles to the betterment of Wheezy instead. As soon as Wheezy is out of the door, please re-raise this topic in a project-wide place, where we can work on solutions to avoid this kind of frustrating long freezes. That would be the appropriate time and place for this kind of discussions. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#699808: tech-ctte: syslinux vs the wheezy release
On Tue, Feb 05, 2013 at 01:48:22PM +0100, Julien Cristau wrote: The submitters sincerely hope that all parties can work together for a speedy resolution to this problem, avoiding further delay to this release. As a possibly useful data point for procedural reasons: I've verified on IRC with the submitters that this issue is blocking the release of d-i version RC1. As such, I'd appreciate if the tech-ctte could prioritize this issue over others submitted to their attention (this might imply increasing the severity of this bug as needed). Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#681419: Proposed ballot for free/non-free dependencies question
On Thu, Dec 06, 2012 at 09:35:11AM +, Colin Watson wrote: Right. I had this in the back of my mind as something I didn't need to spell out because policy already discusses real alternatives (7.5), but on reflection the wording there is much weaker than I remember and in any case you're correct that this is a disparity between the two ballot options. Thanks for taking my remark into account! I think we're in agreement already , but to stress my main point: - Policy §7.5 explains *how* to provide a real package preference when depending on a virtual package, but does not say *when* to do that. (IIRC there is some provision to do that with build-time dependencies, but I haven't found it with a quick search.) How about this, which I've committed to our git branch: B 6. Virtual packages are a suitable existing mechanism for packages to Bdeclare the set of abstract features they provide, and allow Bpackages in main to depend on such abstract features without Bneeding to name every (free or non-free) alternative. They should Bnevertheless name at least one free preferred alternative, so that Bthe package management system has appropriate defaults. How about: s/at least one free preferred alternative/a default free alternative/ that would be more consistent with the wording of Policy §7.5 (not a big deal, though). [...] B 8. We recommend that affected packages consider the use of virtual Bpackages instead. When doing so, they should specify a real Bpackage in main as the first alternative, e.g. Depends: Bpackage-in-main | virtual-interface. Looks good. Possible s/first/default/ if you apply the suggestion above, for consistency. I do find it more in line with our general principles for packages in main to be preferred for dependency resolution, though, so I went for should. I'm still convinced that a non-free default alternative would not be appropriate. But before trying to argue this point, in an attempt to save us all some discussion time, let me try to side-step it :-) In the initial bug report that brought this issue before the tech-ctte, Russ wrote: (I believe that the question of whether foo-nonfree | foo should be allowed is not at issue and that the consensus is that it's not permitted. However, the Technical Committee can certainly open that discussion if desired.) So it seems that, at least for non-virtual packages, the Policy Team already has consensus that a non-free default alternative is not acceptable. I would find surprising if consensus would be different for virtual packages. Granted, this is my interpretation only, Russ (with his policy editor hat on) would likely know better. As noted, the tech-ctte is certainly free to dig into this specific sub-matter further. But if you're simply looking for a sane default, I think sticking with Policy Team consensus would be entirely appropriate. HTH, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#681419: Proposed ballot for free/non-free dependencies question
Thanks Colin for this draft! On Thu, Oct 25, 2012 at 03:05:30PM +0100, Colin Watson wrote: The Technical Committee has been asked to determine whether a dependency of the form package-in-main | package-in-non-free complies with this policy requirement, or whether virtual packages must instead be used to avoid mentioning the non-free alternative. […] B 6. Virtual packages are a suitable existing mechanism for packages to Bdeclare the set of abstract features they provide, and allow Bpackages in main to depend on such abstract features without Bneeding to name every (free or non-free) alternative. […] B 8. We recommend that affected packages consider the use of virtual Bpackages instead. I've a concern about option (B), which I haven't seen addressed in this draft, and that I think it should be addressed before voting (yes, I realize this is a discussion draft, but the sooner the better :-)). It seems to me that the two alternative encodings being discussed have a fundamental difference: 1) package-in-main | package-in-non-free encodes alternative *and* preference for the DFSG-free version 2) virtual-package only encodes alternative between a number of alternatives, some of which are free some of which are not I think you should reword (2), so that the usage of virtual packages is accompanied by an explicit preferences on the free alternative, similarly to what we do for virtual packages when they're used as build dependencies, i.e.: Package: package-in-main Provide: virtual-package Package: package-in-non-free Provide: virtual-package Package: client1 Depends: package-in-main | virtual-package Package: client2 Depends: package-in-main | virtual-package I'm a bit on the extreme said perhaps, but I think we should *mandate* that client packages use the package-in-main | alternative and use it before virtual-package in the disjunction. Otherwise we risk having a significant regression. (I'm not sure if it is up to the tech-ctte to mandate this or, say, to the Policy.) I've skimmed briefly through policy, trying to find out whether package managers are supposed to favor package in main over packages in other suites, but haven't find it yet. If there is something like that already, then probably the above is redundant. But even in that case, I'd rather err on the safe side and at least recommend it in the ruling. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#688772: gnome Depends network-manager-gnome
On Fri, Oct 12, 2012 at 07:51:44PM +0100, Ian Jackson wrote: It seems to me that the gnome maintainers have a philosophical view that Network Manager is very strongly part of GNOME, and that they feel that this philosophical position can only be properly reflected by a hard dependency. That is, that demoting the dependency to Recommends would be failing to properly give effect to the truth that N-M is part of GNOME. To be fair, it seems to me that Joss has provided an additional answer to the why recommends? question in https://lists.debian.org/debian-ctte/2012/09/msg00089.html For lack of a better synopsis, the argument there is because recommends do not behave properly across upgrades. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Bug#573745: Initial draft of resolution of the Python Maintainer question
On Thu, Sep 27, 2012 at 04:12:08PM -0700, Don Armstrong wrote: I have prepared the draft as discussed; please find it below and in 57375_python_maintainer/dla_draft.txt in the git repository. If there are no changes, I would like to begin a call for votes in the next 48 hours or so, with options A, B and C as below, and F being further discussion. Thanks a lot for this draft. A including) Sandro Tosi mo...@debian.org […] B including) Jakub Wilk jw...@debian.org […] C The committee declines to change the maintainer of the python Just a comment on the above 3 options. Considering the fact that this conflict has been very long running now, I think it is important to be clear on how the tech-ctte has assembled the set of possible team options. I presume the above options descend directly from the discussions I've solicited on the -python list. If that is the case, I suggest to briefly mention that the options have been formed discussing with all relevant and interested parties, on the -python list or something similar. A relevant reference would be: https://lists.debian.org/debian-python/2012/04/threads.html#8 Thanks for considering, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Bug#685795: Possibly inviting a new TC member
On Fri, Sep 07, 2012 at 03:15:00PM -0700, Don Armstrong wrote: Below, please find the current draft of the call for nominations. I'd like to send this e-mail out on Monday the 10th, so please make any changes in the git repository [685795_new_member/call_for_nominations.txt] (or suggest them in a response, and I will incorporate them.): It looks great to me, thanks for working on this! (Yes, I'm probably late for this feedback..., sorry about that.) -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: tech-ctte webpage cleanup
On Wed, Aug 29, 2012 at 03:31:09PM +0100, Ian Jackson wrote: While I was there I noticed some infelicities, so I have: Thanks Ian. Prodded by this, I've documented the current team formation in /intro/organization, which was out of date after recent changes. The change will be live at the next website update pulse. It seems to me that the history section of appointments in the tech-ctte page is out of date: Manoj should be thanked there, AFAICT. Also, Colin is not mentioned in the Formal nontechnical and procedural decisions section. All in all, I'm not sure if it's worth the effort of keeping up to date that part... -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Bug#686235: Committee list of decisions on webpage is incomplete
On Thu, Aug 30, 2012 at 12:29:51PM +0100, Ian Jackson wrote: Thanks Ian. Prodded by this, I've documented the current team formation in /intro/organization, which was out of date after recent changes. The change will be live at the next website update pulse. Thanks. (Do you know how often that happens?) 6 times a day, IIRC. It seems to me that the history section of appointments in the tech-ctte page is out of date: Manoj should be thanked there, AFAICT. Also, Colin is not mentioned in the Formal nontechnical and procedural decisions section. All in all, I'm not sure if it's worth the effort of keeping up to date that part... I think we should do so. Someone (I volunteer) should go through the list archives and look for anything else we're missing. grepping for vote might do it. It's a relatively small amount of work to do this when we make a final decision, compared to the effort of discussing, voting, etc. If it gets too tedious we can probably automate it a bit more. The bug title makes me believe I didn't convey the scope of my comment well enough. I was referring specifically to the _nontechnical_ decisions section, which seems to boil down essentially to appointments. For the rest, I fully agree it's worth (and important) documenting technical decisions. Given you're working on standardizing BTS usage for tech-ctte purposes, automation can probably be built on top of that. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: seats shuffling
On Sun, Aug 12, 2012 at 12:49:33PM -0700, Manoj Srivastava wrote: On Mon, Jul 30 2012, Stefano Zacchiroli wrote: I agree with you that one member of the tech-ctte has been inactive at least over the period I've been DPL. No blame is intended with that: we all know that in a volunteer community that could happen for a whole lot of different reasons. I suspect that is likely to be me. Hi Manoj, yes, I confirm this. It was my intention to volunteer to contact you about this personally, but not before having received confirmation from the other tech-ctte members that they agreed with the course of action I suggested. I have been mostly inactive for over two years now, and I think it is time to accept that I might not have time to resume my duties. I agree that we do not want to have dead weight on the tech ctte, and I don't want to be an obstacle in inducting new people into the ctte. I, with some regret on my part, I hereby tender my resignation from the ctte. It has been an honor serving with all y'all. I hereby thank you for your honorable service as tech-ctte member up to now. And also for this message: I guess it was not an easy step to make, but it is useful for the Project to make the declared and actual forces on any team coincide. Thanks for helping with that. Cheers. PS from a merely procedural point of view, this means that we'll rather need to go ahead with a standard tech-ctte appointment, once the tech-ctte have decided how to nominate candidate(s) to me. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: seats shuffling
On Tue, Aug 07, 2012 at 05:20:58PM +0100, Ian Jackson wrote: Stefano Zacchiroli writes (seats shuffling): What do you think of joining the dots of: (1) a seemingly inactive seat and (2) the desire of having more views represented in the tech-ctte, and agree under Constitution §6.2.5 on a seat change? If you want me to, I'll be happy to help contacting the relevant persons, but the proposal for the new seat should better come from the tech-ctte itself (even after private discussion, if you prefer, under §6.3.4). I would be happy to see this happen. What process do you think would be good for selecting the new TC member ? (Assuming the you here was me, rather than other tech-ctte members.) On that front, according to the letter of the Constitution (§6.2.1), it should be the Technical Committee that proposes to me the new TC member. Now that I think of it, I've doubts on whether §6.2.5 (DPL and ctte chair can replace an existing member if they agree) is meant to work in conjunction with or in isolation from §6.2.1. Either way, my preferred process would be that tech-ctte members discuss together on who they want as new member. I'll then be happy to discuss the appointment with Bdale. And I'm positive we can easily reach an agreement under §6.2.1. But the first step remains the same: tech-ctte members should find a candidate to propose. (Assuming other members agree with you and me that a seat change is welcome, that is.) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
seats shuffling
Dear tech-ctte members,
I'm catching up with the DebConf12 events I've missed, and I've been
pleased to do so with the meet the Technical Committee session that
some of you have run. Very interesting discussion and QA, well done!
In particular, I'm delighted that you found so valuable the IRC meeting
proposal and that you're motivated to keep it going on a monthly basis.
But I'm writing here for another topic you mentioned in the session, two
in fact: tech-ctte seats availability and diversity (the latter not in
the strictly demographic sense, but in the more general sense of
having different views / mindsets represented, something that Steve
Langasek mentioned also at the time of the last tech-ctte appointment,
if I'm not mistaken.)
I agree with you that one member of the tech-ctte has been inactive at
least over the period I've been DPL. No blame is intended with that: we
all know that in a volunteer community that could happen for a whole lot
of different reasons.
What do you think of joining the dots of: (1) a seemingly inactive seat
and (2) the desire of having more views represented in the tech-ctte,
and agree under Constitution §6.2.5 on a seat change? If you want me
to, I'll be happy to help contacting the relevant persons, but the
proposal for the new seat should better come from the tech-ctte itself
(even after private discussion, if you prefer, under §6.3.4).
If you like to, we can also discuss this over the next IRC meeting. In
that case, please mention this in the agenda so that it'll catch my
attention and I'll make sure to attend the meeting.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: roaraudio dispute
On Mon, Jul 23, 2012 at 03:24:12PM +0100, Ian Jackson wrote:
Having said that I am concerned that there has been impropriety in the
process. In
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675610
Ron wrote
We'd like to have nothing depending on roar for wheezy
Without the background knowledge the most natural reading of that
message is that there is some technical problem with roar which cannot
easily be fixed, and that the roar maintainers agree. The maintainer
of cmus took it as a request from the roaraudio maintainers to remove
the dependency. That's how I would have read it too.
[…]
So while I wanted to put all the above on the record, there may be
little more to be done about it by the TC. (I have CC'd leader@ in
case they want to take this up.)
Hi Ian et al., thanks for bringing me in the loop (even though I'm
following this discussion anyhow). If there is a trust problem, that
would be in fact up to DAM, but it's true that the DPL is generally kept
in the loop of those kinds of discussions.
For my part, I'm inclined to see no malice by default, unless the
contrary is proven. I understand what you mean when pointing to the
above bug report, and I agree a bit more clarity would have been
welcome. But there might be plenty of other honest reasons for saying
we'd like to do $foo for Wheezy, other than impersonating a
maintainer. And given my no-malice-by-default principle, I do not see
malice there, just someone trying to make things work, according to his
own technical judgement (which might be wrong or not, but that's a
different matter).
I also expect the maintainer receiving such a bug report, to do some
technical verification before acting upon it. Failing that, and in case
the maintainers want to trust the bug reporter, I expect them to verify
the authoritativeness of the reporter.
All in all, I don't see any need to take further action on this part of
the dispute, ... but I'm looking forward to the conclusion of its other
parts!
Thanks for your work on this,
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Draft GR for permitting private discussion
On Tue, Jul 17, 2012 at 10:17:34AM -0700, Russ Allbery wrote:
I probably should save this for the main discussion in -vote or -project,
Let's do that, and sorry for dropping this here, but having mentioned it
to Ian before, I didn't want for any of you to wait indefinitely for my
comment. So feel free to go ahead with the broader discussion when you
please. I'll postpone comments to the broader discussion, but let me
point out a counterargument.
The current wording, read literally, means that if I happened to run into
Steve Langasek, say, at a social occasion, I am not permitted to mention
network-manager and GNOME to him, because that conversation isn't public
and that's an issue currently before the technical committee.
I would agree that if yours here is the common interpretation of the
current wording of the Constitution, then we have a problem. (It is not
*my* reading, but that's meaningless.) I don't think that anyone would
want to inhibit private discussions to happen at all. But I do think
people would expect them to be reported ex-post.
If you accept such a principle, you can have all the private discussions
you want at conferences with Steve and on a private usenet hierarchy
with Colin, as long as we agree on the fact that those discussions are
reported publicly where appropriate (e.g. in the relevant tech-ctte bug
log). FWIW, I know this is actually hard to do, after having noted down
on random notepads discussed $something with $someone over the past 3
years of FOSS conferences :-)
Note the above is nothing new and is just consistent with the well known
mantra that most Free Software projects try to apply that if it didn't
happen on a mailing list, it didn't happen.
I think the above principle would address your infeasibility concern.
(OTOH I don't have at the moment specific answers to your comparisons
with how other similar decision making bodies work in other contexts.)
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Draft GR for permitting private discussion
On Mon, Jul 16, 2012 at 12:01:50PM -0400, Michael Gilbert wrote:
As an example, the wine package was in a very similar state to the
python package a few months back. Instead of complaining about the
maintainer (and likely leading to a flamewar), I did my best to get
work done while concurrently allowing the maintainer to reject that
work if he were really interested. This involved many 10-day delayed
liberal nmus of the package, culminating in bringing it up to date. I
also ensured that all of my messages were positive, and acknowledged
the fact that the maintainer could review and reject the nmus while
they were in delayed. Apparently, my uploads were sufficient and none
were rejected. Ultimately, I brought the package up to date, and was
accepted in to the team.
This worked, I believe, because I maintained a positive stance
throughout the process.
Let's add a couple of data points to this example of yours. IIRC the
timeline, before your involved in it, I chimed in the relevant buglog
suggesting, if not encouraging, the NMU path. Later on you contacted me,
privately, asking for advice on the best way to proceed with the NMUs.
I've been happy to provide the advice, essentially encouraging your
NMU-based plan (my position towards NMUs is well known, so that should
come to no surprise to anyone). Then you proceeded, cautiously, doing
very proper NMUs that allowed, together with some help from the
maintainer later on (I'm thinking at alioth permissions here) to solve
the issue for Wheezy. Which is a great result.
But I still find interesting that in an example that you use to argue
for transparency, a private mail exchange has played a relevant role.
Transparency is hard. But it is a worthwhile goal. Out of hypocrisy, I
suspect that today every non trivial (social) conflict solving will end
up having some private exchanges. Especially when mediations are needed.
The question we should ask ourselves, then, is how to *minimize* those
exchanges. Ideally trying to reduce them to 0 even if we know we're not
there yet.
This is why I'm worried about this specific GR: it seems to go in the
opposite direction. I think that the present situation, i.e. thou shalt
not do that, is a moral check on the desire of discussing matters
privately with and within the tech-ctte. Those private discussions will
happen [1], but the fact that they are considered socially wrong will
limit them to cases that are considered extreme, even for tech-ctte
issues (which are already extreme per se). I fear that legitimating
private discussions will remove this useful moral check.
I realize that my stance above is a hack, based on the assumption that
people will occasionally break rules even if they shouldn't. And I
understand that the draft GR is trying to attack the problem from the
opposite angle, i.e. defining when private tech-ctte discussions are
acceptable. But the propose solution seems flawed in at least two ways.
The first one is that once easy mechanisms for discussing privately are
in place (e.g. a debian-ctte-private list), it will come very naturally
to discuss privately also matters that could've been discussed publicly.
The second one is that nobody outside the tech-ctte will be able to
control what is actually being discussed on those fora.
The tech-ctte is a trusted body in Debian anyhow and, presently, I have
no reason to distrust any single member of the tech-ctte. But removing
both the moral check of discussing matters publicly and the ability to
review what is going on doesn't seem wise. It is after all the kind of
paranoia that comes handy when designing constitution-like documents.
(One might argue that a similar problem exists with the leader@d.o
mailbox, and I agree with that. But at least the DPL is subject to
periodic reelections, which is not the case for tech-ctte members.)
As some sort of more positive conclusion, I encourage the tech-ctte to
go ahead with this GR. It is a very important matter on which a vote
should have a final say. But if you want for it some chances of success,
I think you should be more clear on the desire of limiting private
discussions to the very minimum. For one thing, I think [public]
discussion in the title of the constitution paragraph should stay.
Similarly, I don't find the usage of infeasible and
counterproductive reassuring enough. Especially the latter is very
subjective (who decides it?) and might be used to legitimate all sorts
of private discussions.
With many thanks for all the work the tech-ctte is putting in fixing
Constitution bugs here in there, it's much appreciated.
Cheers.
[1] for full disclosure, I remind here that I've pleaded guilty for
having done so myself ~24 hours before submitting #658341, asking
for comments on my draft bug report
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http
Re: TC-initiated GRs, redux
On Wed, Jul 11, 2012 at 01:26:14AM +0100, Ian Jackson wrote:
I think the recent flurry of discussion has more or less converged.
You can find the results here:
Thanks a lot for your very effective coordination work in drafting these
GRs, Ian. I really appreciate it.
I'd appreciate a final round of review (especially by TC members and
the Secretary) at this stage. If that is broadly positive I intend to
propose these as TC resolutions shortly after Debconf.
The files are:
informal-propose allow private discussion (const. change)
I've some pending comments on this one, but for family reasons I'll be
unable to post them before July 20th or so. If you'd like to hear them
before officially starting the GR in question, I'd appreciate if you
could wait 1 week more after DebConf end. But I also don't want to stop
this very welcome activism wave! So I though of simply mentioning this,
but in the end do as you please.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Draft GR for advice re overruling
On Mon, Jul 09, 2012 at 04:11:22AM +0100, Ian Jackson wrote:
In the past the Technical Committee have been slow and reluctant
[...]
- GENERAL RESOLUTION OPTION A -
The Technical Committee's approach so far has been correct.
What's the point of mentioning slow above? I don't think anyone wants
the tech-ctte (or any other Debian body, fwiw) to be slow on purpose.
That might come as a consequence of something else (e.g. reluctance),
but then you should ask for advice on that rather than on slowness.
Suggestion: drop slow and.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: periodic tech-ctte IRC meetings
On Sun, May 13, 2012 at 03:01:16PM -0700, Don Armstrong wrote:
On Sat, 12 May 2012, Andreas Barth wrote:
* Don Armstrong (d...@debian.org) [120509 22:58]:
As only Russ and myself have responded, I'm guessing that using Doodle
isn't going to work particularly well for scheduling:
How about I try scheduling by fiat:
Wed May 30 19:00:00 UTC 2012
Wed May 30 12:00:00 PDT 2012
date -d @1338404400
in #debian-ctte on irc.freenode.net.
I'd prefer irc.d.o (which is oftc for some time now). Otherwise ok
with me.
Yeah, this was a typo. It's irc.debian.org.
So, unless something has changed, and as a sort of reminder (to self),
this is for today at the above coordinates.
Thanks for the organization Don, by-fiat-ftw! :-)
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: periodic tech-ctte IRC meetings
On Wed, May 30, 2012 at 09:38:45AM -0700, Steve Langasek wrote:
Something did change; Ian said he can't make Wednesdays, so the final agreed
time is tomorrow (date -d @1338483600), per
20120511001418.gk3...@rzlab.ucr.edu.
Ah, thanks: calendar FAIL on my part, sorry.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: periodic tech-ctte IRC meetings
On Wed, May 09, 2012 at 01:47:51PM -0700, Don Armstrong wrote:
As only Russ and myself have responded, I'm guessing that using Doodle
isn't going to work particularly well for scheduling:
How about I try scheduling by fiat:
Looks like this works perfectly for the tech-ctte :-)
Thanks!
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Bug#573745: Please decide on Python interpreter packages maintainership
On Sat, Apr 28, 2012 at 01:00:16PM +0200, Andreas Barth wrote:
If neither Barry nor Jakub would support removing Matthias as a
maintainer, would there be the possiblity of both of them joining the
maintainer team? (Barry, Jakub, Matthias: comments on that are
appreciated - after all, if the goal is to have a maintainer team, it
can only work if it works for you.)
The answer to that is already in the thread I've pointed at.
Barry is fine in joining the current team, Jakub is not. (Of course
they can provide different indications here, but that's my understanding
of the situation at the time of last interactions with them.)
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Bug#573745: Please decide on Python interpreter packages maintainership
On Tue, Mar 20, 2012 at 02:46:58PM -0700, Russ Allbery wrote:
Stefano Zacchiroli lea...@debian.org writes:
If the Technical Committee welcome that, I'll be happy to take the
burden of verifying (publicly, and on -python) who would be willing, at
present, to be part of an alternative Python maintenance team.
Personally, I would be much more comfortable with that than any of the
delegate the decision to other people options. I think that would also
make the vote somewhat more concrete so that the TC can consider a
fully-formed alternative.
I don't speak for the TC, but I personally would appreciate that.
Not having heard other options, I've proceed with the verification
mentioned above. Everything has happened publicly and is hence available
for your review starting from [1]. My own conclusions on the potential
teams, based on that thread have been posted on list [2] and also
attached to this mail for your convenience.
According to the thread, the amount of volunteers willing to help has
changed but not diminished, although it seems to be more scattered now.
To conclude, let me remind that the purpose of this exercise was only to
verify the availability of the team that volunteered 2 years ago, in
order to give more data to the tech-ctte for deciding what team (if any)
should go in the vote ballots.
I hope this could help and that the tech-ctte have now all the input
needed to quickly come to a conclusion on this issue, one way or
another.
Good luck!
[1] https://lists.debian.org/debian-python/2012/04/msg8.html
[2] https://lists.debian.org/debian-python/2012/04/msg00101.html
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
---BeginMessage---
On Tue, Apr 03, 2012 at 10:36:58AM +0200, Stefano Zacchiroli wrote:
Allow me be blunt then: do we have volunteers to maintain the pythonX.Y
packages? Can those volunteers manifest themselves on this list?
snip
I understand there might be incompatibilities that make impossible for
potential volunteers to work with other such volunteers. Nonetheless, I
suggest first to have a public volunteering round, even if you have
conditions attached to your availability. One concern at a time :)
3 weeks into this, it seems we have reached a peek in the amount of
people who volunteer to maintain pythonX.Y. I've go not more candidacy
in private mail than what you saw on list, which is a good sign.
Considering the potential incompatibilities, it seems that the possible
maintenance teams boil down to:
- a maintenance team formed by Sandro
- a maintenance team formed by Matthias and Barry
- a maintenance team formed by Jakub
Then there is the availability to help by Luca to do grunt work, with
no strong requirement of doing so as a declared co-maintainer.
It should also be noted that Jakub, in spite of his availability, has
made clear that he does not support removing the current maintainer by
the means of a tech-ctte vote. Barry clarified in mail to me (asking me
to mention it here) that he does not support removing the current
maintainer either, which is why I've listed Barry in co-maintenance with
Matthias, but not with Sandro.
Having not heard from Matthias either, I had to pick some defaults for
his conflicts, which I'll be happy to refine as soon as he comments on
this (but quite frankly, I don't see that coming). I've assumed he would
be fine working with Barry, and that he would not be fine working with
Sandro. The rationale is a simple principle: I have witnessed in the
past conflicts between Matthias and Sandro, but no conflicts between
Matthias and Barry. It seems fair to assume that the status quo
(positive or negative) continues, until the contrary is proven.
If there are no further comments or candidacies, I'll proceed forwarding
the above possibilities to the tech-ctte, Cc:-ing this list, before the
end of the week.
I recall that the purpose of this exercise was simply to do a reality
check of the team who 2 years ago volunteered in the tech-ctte buglog.
No endorsement of any of the tech-ctte option is implied in the results
of the exercise.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
---End Message---
signature.asc
Description: Digital signature
Bug#573745: pythonX.Y maintenance team
Dear all,
I'm pretty sure tech-ctte bug #573745 does not need any introduction
on this mailing list. The recent news [1] on it is that the tech-ctte
seems to be inclined to have a vote on the matter, after having observed
that the issue is pretty stable now and further spontaneous evolutions
are unlikely.
Given the long time frame since bug submission, however, some things
might have changed. For one thing and according to Scott [2], the issue
seems now settled for the python*-defaults packages. As an external
observer I tend to agree with that.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573745#390
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573745#415
OTOH, the Maintainer field of the pythonX.Y packages is unchanged since
when the tech-ctte bug has been reported. While the tech-ctte has not
decided anything yet (that's what the vote will be for), they need to
decide what to put on the ballot. In particular, there are questions
about which alternative team should be put in it, for at least one of
the ballot options.
Back then, the following team has been proposed:
- Luca Falavigna dktrkr...@debian.org
- Josselin Mouette j...@debian.org
- Sandro Tosi mo...@debian.org
- Bernd Zeimetz b...@debian.org
- anyone else willing to help, including of course the current
maintainer, provided the above points are met.
I'd like to help the tech-ctte in finding a team to put on the ballot
(!= finding the team who will maintain the packages, as that would be
tech-ctte decision, via vote). And I'd like to do so on this list,
because I believe that a maintenance team that does not have consensus
on this list would hardly be able to solve past issues.
Allow me be blunt then: do we have volunteers to maintain the pythonX.Y
packages? Can those volunteers manifest themselves on this list?
If you volunteered in #573745 already, and you're still available,
please reiterate your availability here. 2 years is quite a long time
and the tech-ctte should better be sure of the availability of its
members before picking a team.
I understand there might be incompatibilities that make impossible for
potential volunteers to work with other such volunteers. Nonetheless, I
suggest first to have a public volunteering round, even if you have
conditions attached to your availability. One concern at a time :)
Note that, in the absence of a team of people volunteering to maintain
the pythonX.Y packages, the tech-ctte would probably have to exclude a
we hereby appoint $team option from their decision ballot.
Thanks in advance for your help,
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Bug#573745: Please decide on Python interpreter packages maintainership
On Sun, Mar 18, 2012 at 09:57:02PM -0700, Russ Allbery wrote:
Okay, this isn't going to make anyone happy, but here goes.
Thanks.
D. The Technical Committee exercises our power under 6.1.2 of the
Constitution to designate:
- Luca Falavigna dktrkr...@debian.org
- Josselin Mouette j...@debian.org
- Sandro Tosi mo...@debian.org
- Bernd Zeimetz b...@debian.org
as the new maintenace team for the Python interpretor packages. (This
of course assumes that all of those people still want to be part of the
maintenance team; we should ensure we have an accurate list before we
vote.)
If the Technical Committee welcome that, I'll be happy to take the
burden of verifying (publicly, and on -python) who would be willing, at
present, to be part of an alternative Python maintenance team.
Even though I'm merely a lurker of the -python list, I'm positive the
mailing list participants will be able to reach consensus (modulo the
potential objection of the current maintainer) on a suitable maintenance
team for the purpose of being included in the tech-ctte ballot. I think
that can be done in the time frame mentioned by Russ for the vote.
Let me know if you want me to try that,
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Bug#573745: Please decide on Python interpreter packages maintainership
On Mon, Mar 19, 2012 at 03:26:50PM -0700, Russ Allbery wrote:
Andreas Barth a...@ayous.org writes:
You think it's worse than just orphan the package now and/or ask the DPL
to choose a new maintainer? (I would say it's the least agressive one of
the variants that do require a change of the maintainer, as Matthias has
some say of the new maintainer team as long as it's a team but YMMV. Of
course, it's not nice. But no of the options is nice.)
I suppose it depends on how you look at it, but if I were being forcibly
overridden in opinions about Python maintenance, I'd want the people
overriding me to take responsibility for the whole thing, rather than
continuing to make it my responsibility. But either way that's an option,
so I don't feel very strongly about it.
FWIW, I'm not particularly keen of the option delegate the choice to
the DPL either. Although, if that would be the winning option and if it
would be me the DPL having to implement it (both are significant IF-s),
I'll be ready to abide to it.
The reason is that the tech-ctte is the highest decision body in Debian.
I've always considered unfortunate that this issue has been escalated to
the tech-ctte before attempting some more middle-ground options, such as
asking the DPL or others to mediate. But given that the issue *has* been
escalated up to the tech-ctte, pushing it down to the DPL at the end
of a long process would probably give the impression of unwillingness to
decide.
Just my 0.02€,
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
On Tue, Mar 20, 2012 at 11:39:54AM +, Ian Jackson wrote:
* Possibly increasing the maximum size of the committee. I would be
happy with 12, given the busy nature of the existing members.
If there are people interested in helping drive things to resolution, that
would be helpful, as we're not currently doing a stellar job on that
front.
I still think we should formally allocate issues to TC members as they
come in.
Do you agree that the maximum size should be increased ? It would
look something like this perhaps:
As the DPL is part of tech-ctte appointments, I'd like to comment on
that. I don't think the issue of tech-ctte efficacy should (or could)
be approached from the not enough manpower angle.
People on the tech-ctte tend to be quite busy, that's true and normal.
The typical profile of a tech-ctte member is a talented hacker with a
lot of experience. Such a person has often responsibilities and
demanding duties, both within and outside the Debian Project. Augmenting
the number of tech-ctte members would not change this aspect, unless we
want at the same time to change the profile of tech-ctte members, which
I don't think would be wise.
I've been observing the tech-ctte activities for a long while, as an
external observer. In fact, I don't think the long time that some
decisions take is related to how busy are the members of the technical
committee. It looks like a recurrent pattern of decisions is:
1. fruitful discussion
2. long limbo
3. someone takes the lead
4. fruitful discussion
5. vote
it is true that (2) is useful in some cases, to let things linger and
dissipate, but looking from the outside it doesn't seem to be a
deliberate choice. It seems to be often there just because the passage
from (2) to (3) is prone to starvation.
Look at this precise moment: Russ has decided to go through outstanding
tech-ctte bugs and suddenly a lot of them look closer to completion than
a week ago!
Let me then re-propose something that I have proposed at DebConf11 (or
was it DebConf10?) during the tech-ctte session. I suggest to the
tech-ctte to hold periodic public IRC meetings, *just* to go through the
list of open issues. It can be as quick as 30 minutes every 1 or 2
months, and it doesn't matter if only a few members could attend each
meeting. I have the impression that it would be enough to reduce the
duration of (2) by guaranteeing that, periodically, outstanding issues
are re-considered.
Back then at DebConf, IIRC, present tech-ctte members were in favor of
the idea, but in the end it hasn't been implemented. Is that something
the tech-ctte cold consider trying, before proposing Constitution
changes due to the specific issue of the time that some decisions take
to be made?
Thanks for your work,
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Bug#658341: Multiarch support in dpkg — really in time for wheezy?
On Sat, Mar 03, 2012 at 03:58:42AM +0100, Guillem Jover wrote:
[ Replying to this now, because it appears some people seem to think
mails that go unanswered are considered as accepted facts... ]
So be it.
work is also considered ready enough by other dpkg co-maintainers, by
the Release Team, and by various porters, which have all asked multiple
times to have that work in the Debian archive.
Claims by people who during all this time, when this has supposedly been
considered such a priority and so important to the point of bringing
it to a confrontational body like the tech-ctte, have been either
unable or unwilling to review that code and find the problems it had.
I still have to see a single code review on the list...
The accusation part of this is not for me to be picked up.
But that's not the point. The point is whether you did get to decide
that thorough code review had to be completed before uploading, even
only to experimental. Code review is *a* way to achieve code quality, it
is not the *only* way. User testing is another one.
You keep mentioning this ralatively new “Debian is a do-ocracy” (which
I think it's been promoted mostly by you?) when it seems to me the
commonly held motto has always been “Debian is a meritocracy”. In any
case, more often than not whenever I've seen that being used, it seems
like an excuse to justify unsound technical decisions, or poor work.
I've used the term a lot, yes. But I don't think I've invented it in the
first place. Anyhow the difference among the two is crucial here. The
way I see it --- and you're free to disregard of course, we're entirely
in the realm of opinions here --- is that in a meritocracy you get to
command on the basis of past, acquired rights. In a do-ocracy you
need to keep on maintaining those rights by showing you're doing
something. Blocking others is not enough to maintain the right to
command.
[...] (And TBH the thought of you hurrying up now in doing such a
work is worrisome in its own right.)
So, you mean that doing code review and cleanup is worse than not doing
any at all... ok.
Uh? Non sequitur. My quoted text above meant that the idea one is doing
code review in a hurry is not as reassuring as the idea of one doing
code review more calmly.
If rushing things out and being sloppy or merging technically unsound
code is being a team player, then count me out.
I think Debian has now decided, using the most appropriate means, that
uploading to experimental at this stage wasn't really rushing things
out. So let's agree to disagree.
On Sat, Mar 03, 2012 at 04:05:44AM +0100, Guillem Jover wrote:
I'm convinced that such an attitude actively harms Debian and as such
should not be tolerated. That's why I've asked for tech-ctte technical
judgement on your decision to postpone the upload in wait of full code
review.
If by stalling you mean, having to work on an unpleasant, distressful
and annoying environment, when supposedly doing it for fun, while still
managing to motivate myself enough to make progress by doing design,
implementation, review and cleanup work; not merging code I deem
technically not acceptable, regardless of the provenance (for which I
don't think I've ever discriminated on, as can be seen from the amount
of unmerged branches on my own repo, because they are not ready yet...)
on a project like dpkg, which has far reaching repercusion compatibility
wise, where we might have to live with issues forever or where package
maintainers might need to do useless fixup work due to the consequences
of those issues, on the whole distribution, then I guess, sure, guilty
as charged...
I'm sorry Guillem, but you will not convince me with this side argument.
I'm terribly sorry for the stress you went through, I really am and I
wish nobody in Debian goes through something like that due to Debian
every again. But the above is not the point. The point is that you
picked the rules of the game (code review must be) and actively
blocked others to participate in the game.
You may even pretend, here and now, that you would have welcomed others
to participate in the code review, but that is not the impression that
you gave for the past year. You've frequently worked on a private branch
and referring on -dpkg to changes made in it that have not been pushed
to any public place for a long time. This seems to have happened also
for the last code review after the experimental upload. How could you
possibly expect that attitude to encourage other to participate in code
review?
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Bug#658341: Conclusion: upload multi-arch enabled dpkg (in time for wheezy)
On Sun, Feb 05, 2012 at 12:18:46PM -0800, Russ Allbery wrote:
I think at least some of this should go to debian-devel-announce. I'm not
sure if we should send the entire ruling there, or select bits and pieces
of it, but at least the testing part probably needs to reach a broader
audience.
Do we have a past precedent for how we handle publicizing tech-ctte
decisions?
FWIW, I'll surely mention this in my next bits from the DPL mail, but
it won't happen before early March. Also, I expect that when the upload
happens [1] the uploader to send a wide call for testing to d-d-a. This
is just to say that I don't think we should fear people will overlook
the practical impact of the decisions.
However, the idea of systematically announcing tech-ctte decisions to
d-d-a (hinted by your last paragraph) seems a very good one to me.
Please do :-)
Cheers.
[1] http://lists.debian.org/debian-dpkg/2012/02/msg00010.html
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Bug#658341: upload of multi-arch enabled dpkg (in time for wheezy)
Package: tech-ctte
Severity: serious
Dear members of the Technical Committee,
I hereby submit to your attention the dpkg multi-arch conflict.
I believe the issue is well-known, so I describe it only briefly below;
feel free to ask if you need more information.
A multi-arch [1] enabled version of dpkg has been available for quite a
while. Its inclusion in the archive has been one of the early Wheezy
release goals. Since many months now, the upload of such a version of
dpkg has been held back due to repeated NACK-s by one of the dpkg
co-maintainers (Guillem Jover, Cc-ed), based on his desire to do a full
code review of the multi-arch implementation, which has written by the
other dpkg co-maintainer (Raphael Hertzog, Cc-ed as well).
[1] http://wiki.debian.org/ReleaseGoals/MultiArch
The desire to do a full code review is good, but Guillem doesn't seem to
be able to complete the review in a reasonable time frame. Since many
months now, the delay of the upload is a cause of worry for the release
team [2] and other project members. The situation has escalated to the
point that another developer (Cyril Brulebois) has done a dpkg NMU a
couple of days ago [3]; the NMU has been promptly reverted by Guillem
[4].
[2] http://lists.debian.org/debian-dpkg/2011/10/msg00050.html
[3] http://lists.debian.org/debian-dpkg/2012/01/msg00049.html
[4] http://lists.debian.org/debian-dpkg/2012/02/msg0.html
As DPL, I'm worried about two aspects of this issue:
a) The risk of legitimating the fact that by not acting a developer can
block indefinitely the work of other developers (and possibly of the
entire project when working on a rather far reaching release goal);
I've elaborated more on this subject 3 months ago in [5].
[5] http://lists.debian.org/debian-dpkg/2011/10/msg00060.html
b) The risk of a negative impact on project morale if---due to the
reason above rather than a legitimate technical reason---we will miss
the Wheezy multi-arch release goal.
I therefore bring before you the issue of whether:
- one of the dpkg co-maintainers has the right to block indefinitely a
dpkg upload, in wait of full code review of the multi-arch code;
- or rather if the other co-maintainer has the right to override his
NACKs and go ahead with uploads that would allow project-wide testing
of the dpkg multi-arch implementation.
Many thanks in advance for your help,
Cheers.
PS I've to point out that timing on this issue is, unfortunately,
critical. The Wheezy freeze is close and according to the release
team we're already late wrt the ideal upload date for dpkg. The delay
is not tech-ctte's fault, of course, but please understand that a
long decision time on your part would be a de facto decision. I'd
appreciate if you could reach a decision on this in a timely manner.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Bug#658341: upload of multi-arch enabled dpkg (in time for wheezy)
On Thu, Feb 02, 2012 at 04:59:53PM +0100, Guillem Jover wrote:
a) The risk of legitimating the fact that by not acting a developer can
block indefinitely the work of other developers (and possibly of the
entire project when working on a rather far reaching release goal);
I've elaborated more on this subject 3 months ago in [5].
[5] http://lists.debian.org/debian-dpkg/2011/10/msg00060.html
Not acting!? I can accept not acting fast enough as people might like,
but not the former.
Fair enough, you're right, not acting is not quite correct in this
case. I apologize for my inappropriate use of that expression.
Your wording is indeed more appropriate, but it's also incomplete. In
Debian nobody could be held responsible for not completing some work in
a given time frame; nor could anybody be forced to work for the Project.
At the same time, the inability to complete some work should not be used
to block the work of others. Let's call this stalling.
I believe you've been stalling --- with NACKs first and now with an NMU
revert --- the work of a co-maintainer of yours and also of the entire
Project, who is trying to reach a legitimate release goal.
I'm convinced that such an attitude actively harms Debian and as such
should not be tolerated. That's why I've asked for tech-ctte technical
judgement on your decision to postpone the upload in wait of full code
review.
I hate to have to do this, and to be honest I find it petty, but my
acting can be seen here, obviously not all related to multi-arch, but
quite many have been, just not in an obvious way:
FWIW, I do not particularly enjoy all this either; in fact, I hate it.
But given all other attempts have failed, I felt it was needed. And it
was now or never.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Bug#573745: ping
On Wed, Mar 09, 2011 at 12:56:34PM -0800, Steve Langasek wrote:
Do you mean that you would get a *private* ack from the current
maintainer, but no public one? But as long as we have the current
maintainer's agreement (in whatever form), this concern is null.
I didn't mean to imply that I can get one but not the other. I just
wanted to share my impression that I see as unlikely that the maintainer
will publicly comment about that (while other people in this bug log
have already mentioned private discussions). I'll be happy to be proven
wrong on that point. I'm not convinced that a non-public agreement is
useful at this point, but it'd be better than nothing.
And if the problem is that the current maintainer can DoS the process
by not responding, I'm ok with giving an ultimatum that we would go
forward with a change unless Matthias responds in a certain
(reasonable) timeframe, provided that he still has the option to say
no.
This is a position I can understand, thanks for making it explicit.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bug#573745: ping
On Fri, Mar 04, 2011 at 03:48:37PM -0800, Steve Langasek wrote:
Additionally, as DPL, I'm worried by seeing packages as important as the
Python interpreters maintained by a single person. Even if all other
surrounding issues were not there, that would be a bus-factor problem
worth fixing by itself. (I concede there are other similar situations
in the archive, but this is no excuse; they are just other problems to
be solved.)
snip
Team maintenance is a reasonable practice to encourage, because in many
cases this will reduce the average turnaround on bugs; but that's not true
in all cases, and treating this as a problem to solve maligns the enormous
contributions of single maintainers to Debian over the years. The TC should
concern itself here with ensuring that the python packages are well
maintained and the python ecosystem within Debian is healthy, using
/whatever maintenance structure works best for the developers involved/, and
take no position on the essentially political question of team maintenance
as a rule.
I do agree that whether the Python interpreter packages are team
maintained or not should not be a concern of CTTE. I disagree with your
evaluation of the risks, for Debian, of one-man-show maintenance for
important packages and I'll be glad to discuss this, but doing that here
would most likely be off-topic. My mention above was more of an extra
motivation of mine for delving into this, than an argument that the CTTE
should have taken into account.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: cross-distro work on App Store/Software Center - looking for volunteers
[ M-F-T to lea...@d.o for volunteering ]
I've received more details about this. There are now on board people
from Fedora, openSUSE, Ubuntu, Mageia. The plan is to have a 2-3 days
face to face meeting in Nürnberg (Germany) during the 3rd week of
January 2011. Later on discussions will be moved to some mailing list,
but the organizers would like to start with a meeting. Once confirmed by
representative of all main distros, an open invitation will be sent to
the distributi...@freedesktop list; a discussion slot at FOSDEM will
probably be allocated as well.
I'm still lacking a volunteer to represent Debian there. I've considered
attending myself, but that week I'll be traveling to LCA (for a Debian
talk) and I've already made trip arrangement which will be difficult to
reconcile with another week.
I think it would be important to have a Debian representative at the
meeting. So, if you are interested, please contact me to volunteer. The
sooner, the better.
Cheers
PS full quote below of the initial mail, to the benefit of -project
readers
On Sun, Dec 12, 2010 at 04:43:01PM +0100, Stefano Zacchiroli wrote:
Dear all,
Vicent Untz has contacted me about a cross-distro meeting he is
organizing, to brainstorm about the app store / software center idea
and how/if it can interact with more traditional distribution packages.
He is looking for 1-2 person(s) from Debian who are interested in the
topic, who could attend a meeting, and who are possibly interested in
joining a working group on the topic later on. I'd like to know who
those people are and propose them as potential attendees.
Ideally, the topic is within the realm of Debian Policy, so it would be
wonderful if someone from -policy could attend, but in case they can't,
it would be nice to have a fallback. Of course, I'll expect any attendee
to provide feedback to the Debian community a posteriori.
I understand it's a hot topic in various ways (I'm myself pretty
scared at the idea at first), but it's IMHO important to be part of the
discussion, in order to have a Debian say.
Please contact me to volunteer.
You can find below Vincent's mail, forwarded with permission.
Cheers
PS Please avoid turning this thread into a technical discussion about
the idea, we can have it separately and, more importantly, once we
have a clearer technical presentation of the idea. What we need here
are people interested in the topic who volunteer some time to
represent Debian.
- Forwarded message from Vincent Untz vu...@gnome.org -
From: Vincent Untz vu...@gnome.org
To: Stefano Zacchiroli lea...@debian.org
Subject: Cross-distro work on App Store/Software Center
Hi Stefano,
I'm currently working on organizing a cross-distro meeting about the App
Store/Market Place/Software Center topic, since this is a hot topic in
various distributions, with many people willing to work on something. If
we can get some collaboration there, things would probably move much
faster.
I currently have people from Fedora, openSUSE and Ubuntu willing to
participate, and I've already contacted some Mageia people. I'd love to
have some Debian representation too, but I'm unsure who would be a good
contact for this? Is there anybody in Debian working on this topic?
Thanks,
Vincent
- End forwarded message -
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Bug#607368: Please decide how kernel ABI should be managed
On Sun, Dec 19, 2010 at 07:30:58PM +0100, Julien BLACHE wrote:
I am hereby asking the tech-ctte to decide how the kernel ABI should
be managed.
Hi Julien, from the bug log it's pretty clear that there was no
possibilities of agreement between you and the kernel team, so thanks
for bringing this issue to tech-ctte.
I've a question for the kernel team, which might help some investigation
of the tech-ctte. There seem to be two intertwined issue here:
1) the general policy of kernel ABI maintenance
2) the specific smp_ops issue
You asked ruling about (1), on which there is a clear divergence of
opinions between you (as bug reporter / user) and the kernel team (as
package maintainers). Of course ruling about (1) will also address (2),
one way or the other.
Still, (2) is more urgent, as (I agree on that) it will impact upgrade
experience of Debian users like Julien, who are forced to use VMWare. No
matter who is at fault, the choice about (2) will have an impact on a
specific class of users.
My question to the kernel team is if, no matter (2), there are
*technical* reasons for not reverting the removal of the smp_send_stop
symbol. I understand there are political reasons for *not* reverting
the change, like reinforcing the position that people should not rely on
symbols not exported for out-of-tree modules. I believe it would help
the discussion to know whether there are technical blockers to the
revert.
I think it would be best if this matter would be decided upon before
the release of Squeeze, or not too long after it, so as to avoid
further breakages in early kernel updates for Squeeze.
+1
Just my 0.02€,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
cross-distro work on App Store/Software Center - looking for volunteers
[ M-F-T: lea...@d.o, for volunteering ]
Dear all,
Vicent Untz has contacted me about a cross-distro meeting he is
organizing, to brainstorm about the app store / software center idea
and how/if it can interact with more traditional distribution packages.
He is looking for 1-2 person(s) from Debian who are interested in the
topic, who could attend a meeting, and who are possibly interested in
joining a working group on the topic later on. I'd like to know who
those people are and propose them as potential attendees.
Ideally, the topic is within the realm of Debian Policy, so it would be
wonderful if someone from -policy could attend, but in case they can't,
it would be nice to have a fallback. Of course, I'll expect any attendee
to provide feedback to the Debian community a posteriori.
I understand it's a hot topic in various ways (I'm myself pretty
scared at the idea at first), but it's IMHO important to be part of the
discussion, in order to have a Debian say.
Please contact me to volunteer.
You can find below Vincent's mail, forwarded with permission.
Cheers
PS Please avoid turning this thread into a technical discussion about
the idea, we can have it separately and, more importantly, once we
have a clearer technical presentation of the idea. What we need here
are people interested in the topic who volunteer some time to
represent Debian.
- Forwarded message from Vincent Untz vu...@gnome.org -
From: Vincent Untz vu...@gnome.org
To: Stefano Zacchiroli lea...@debian.org
Subject: Cross-distro work on App Store/Software Center
Hi Stefano,
I'm currently working on organizing a cross-distro meeting about the App
Store/Market Place/Software Center topic, since this is a hot topic in
various distributions, with many people willing to work on something. If
we can get some collaboration there, things would probably move much
faster.
I currently have people from Fedora, openSUSE and Ubuntu willing to
participate, and I've already contacted some Mageia people. I'd love to
have some Debian representation too, but I'm unsure who would be a good
contact for this? Is there anybody in Debian working on this topic?
Thanks,
Vincent
- End forwarded message -
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: TWAIN
On Tue, Nov 16, 2010 at 08:37:46AM -0800, Pam Doyle wrote:
Can you provide some guidance as to how we can provide this code for the
Debian respositories so developers can write code against it.
Thank you, in advance, for your guidance.
For what is worth, this request has been handed over to the Sane
maintainer. They are now in touch with Pam Doyle to understand how to
proceed further on this matter.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bug#560238: tech-ctte: Default value for net.ipv6.bindv6only sysctl
On Tue, Jun 22, 2010 at 01:39:53AM +0200, Andreas Barth wrote:
Hm. As it currently looks to me, the decision was delegated to us. If Marco
removes that delegation, that'd be fine with me. If not, we need to
make a decision (at least I believe it's sensible to not wait until
someone just does it for us).
Sorry to jump in, but how so? The last message I can find from the
maintainer to this bug log is 1272368497-1114-bts...@linux.it (dated
27/04/2010), which I agree can be interpreted as a delegation to
tech-ctte to address the issue.
However in 20100614063558.gb28...@bongo.bofh.it, dated 14/06/2010
(which I believe is the message Russ was referring to), the maintainer
claims that the change will be reverted Unless the maintainer [of some
broken packages] believes that we can get a fixed version before the
release. From that, several people included myself deduced that the
default is that the change *will* be reverted.
Maybe Marco, Cc:-ed, can clarify whether he still wants the tech-ctte to
take a decision in place of him or not?
Thanks tech-ctte for your activity on this!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
