Re: Versioned Symbols

I think that we should implement versioned symbols. If you have not already done so please look at the log for bug#136707. I believe my writeup in that bug log of how versioned symbols interact with symbol resolution and under what circumstances it will cause ABI compatibility issues with other d

Re: Versioned Symbols

>>>>> "Anthony" == Anthony Towns writes: Anthony> On Sat, Mar 08, 2003 at 04:16:47PM -0500, Sam Hartman Anthony> wrote: >> I think that we should implement versioned symbols. Anthony> Uhh, versioned symbols means that programs built

Re: Versioned Symbols

dlopening RTLD_LOCAL does not actually solve the problem. Symbols from the namespace of the application can override symbols pulled in by the libraries. RTLD_GROUP, not supported by glibc, comes fairly close to being sufficient in most cases.

Referring bug #166718 and the initial groups issue to the TC

Hi. After discussing the issue together, the shadow maintainer and I (PAM maintainer) have decided to refer the issue of initial groups for users to the TC. This is not one developer asking the TC to overrule another; Karl and I are in agreement that the issue is bigger than either of our packa

Re: Referring bug #166718 and the initial groups issue to the TC

>>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes: Manoj> On Wed, 31 Mar 2004 14:15:00 -0500 (EST), Sam Hartman Manoj> <[EMAIL PROTECTED]> said: Manoj> It seems to me that this ought to be local policy. Can Manoj>

The TC and Spam

> "Ian" == Ian Jackson <[EMAIL PROTECTED]> writes: Ian> If the TC members are expected to read the messages and pay Ian> attention to them, rather than skimming them occasionally Ian> like the sewer that many of the other Debian lists have Ian> become, then we can expect not to

Formal request for review: [Sam Hartman ] Referring what kernel-images to build to the technical committee?

L PROTECTED] (kernel-image-i386 maintainer), [EMAIL PROTECTED] (concerned about package size) Subject: Referring what kernel-images to build to the technical committee? Reply-to: debian-devel@lists.debian.org From: Sam Hartman <[EMAIL PROTECTED]> Resent-Message-ID: <[EMAIL PROTECTED]&

Re: Bug#413926: wordpress: Should not ship with Etch

> "Anthony" == Anthony Towns writes: Anthony> Dividing by years gives: Anthony> CVEs Earliest Years CVEs/Year Anthony> 43 2004 3 14.3 wordpress 63 2002 5 12.6 phpbb2 37 2004 Anthony> 3 12.3 moodle 46 2002 5 9.2 bugzilla 45 2001 6 7.5 Anthony> phpmyadmin >> Viewed

qmail

*sigh* sent this from the wrong address. Bdale> The way I look at this is that it has not been a primary Bdale> *expectation* of the project that the ftpmasters review and Bdale> approve the quality of the software that is packaged. The Bdale> lack of a routine expectation does a

Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian

> "Steve" == Steve Langasek writes: Steve> Qmail does not value the contents of a bounce Steve> message. Dan documents this in a subordinate clause of his Steve> qmail reliability FAQ. That means: if your qmail is Steve> bouncing mail and at the same time, your system crashe

Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian

>>>>> "Sam" == Sam Hartman writes: >>>>> "Steve" == Steve Langasek writes: Steve> Qmail does not value the contents of a bounce message. Dan Steve> documents this in a subordinate clause of his qmail Steve> reliability FAQ

Re: Bug#552688: Please decide how Debian should enable hardening build flags

> "Kees" == Kees Cook writes: Kees> This is likely the core of the disagreement: how to apply the Kees> flags. I have a strong opinion about this because my Kees> perspective is security-oriented. I think all compiles should Kees> be hardened; default to being secure, and whi

Re: Bug#640874: leave: debian/rules is not a Makefile

> "Kurt" == Kurt Roeckx writes: Kurt> I've been wondering how to interprete that for some time. My Kurt> current idea is that it would require a GR to do that. I certainly think it would be really bad for the TC to override delegates on non-technical issues. For example, imagine th

Re: Draft GR for supermajority fix

> "Ian" == Ian Jackson writes: I'm trying to think of a situation where you'd want m != 1 and where there would be an intuitively reasonable understanding of what was intended. Absent that, I think it's more important that things be clear and easier to understand than that they work for m !=

Re: Draft GR for permitting private discussion

> "Ian" == Ian Jackson writes: Ian> - it suggests that the TC doing difficult work that needs private Ian> discussion (eg, dealing with interpersonal problems, mediation, Ian> etc.) should be `kept to a minimum'. Speaking as a member of the project who is not part of t

Bug#688772: gnome Depends network-manager-gnome

Ian, I consider myself an uninvolved party in this matter; I don't really want network-manager installed on my systems, but I'm not particularly keyed up about it. I'm not on the TC. I have been following the issue enough to have an opinion. I'm reasonably good at process issues, and think I unders

Bug#688772: gnome Depends network-manager-gnome

> "Ian" == Ian Jackson writes: Hi. I'm very pleased that you took the time to write a thoughtful response to my message. I appreciate that you're trying to work with me even though the situation is frustrating and you feel under pressure to work towards the solution you want in time for wheezy

Bug#688772: gnome Depends network-manager-gnome

> "Ian" == Ian Jackson writes: Ian> Ian Jackson writes ("Bug#688772: gnome Depends Ian> network-manager-gnome"): >> 6. We specifically forbid anyone from introducing in wheezy, or >> in sid until wheezy is released: a. Any new or enhanced >> dependencies, or any other mech

Bug#688772: gnome Depends network-manager-gnome

I'm still confused why recommends doesn't work for everyone. I understand that the Gnome maintainers want N-M installed by default. Except I think recommends gets you that. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas

Bug#688772: gnome Depends network-manager-gnome

Don, in your option 4B, I wonder if it would be a good idea to have the depend be something like g-n-m|wicd|no-network-manager ANd have an empty extra package that users can install if they really want neither n-m or wicd? While I don't get a vote, I think that would be a reasonable option if yo

Bug#700759: Shared library policy on private libs

Hi. I'd like to speak a bit to what tthe right answer here is rather than what the policy currently says. It's sometimes fairly annoying to move a library out of the default path and to adjust the build system accordingly. Russ did that for one of krb5's private libraries, and in retrospect, I fee

Bug#700759: Shared library policy on private libs

>>>>> "Phillip" == Phillip Susi writes: Phillip> On 2/18/2013 1:21 PM, Sam Hartman wrote: >> 2) don't install a .so in a -dev package. Phillip> That might be a signal a human can understand, but the Phillip> build system won't c

Bug#700759: Shared library policy on private libs

>>>>> "Guillem" == Guillem Jover writes: Guillem> On Tue, 2013-02-19 at 20:30:48 -0500, Sam Hartman wrote: >> with the current packaging tools, you tend to end up producing >> the .shlibs files in order to manage cross-package dependencies

Bug#700759: Shared library policy on private libs

> "Phillip" == Phillip Susi writes: Phillip> Not having the .pc file and headers etc in the -dev package Phillip> would prevent the build of anything with a decent Phillip> pkg-config enabled build system, so that could work with a Phillip> tweak to the policy to allow it. Th

Bug#1077764: Ruling request on os-release specification implementation

> "Luca" == Luca Boccassi writes: Luca> On Fri, 2 Aug 2024 at 13:00, Simon McVittie wrote: >> >> On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote: >> > To further clarify why the status quo with >> VERSION_CODENAME=trixie in > sid is really bad: it used to be

Bug#727708: systemd jessie -> jessie+1 upgrade problems

> "Adrian" == Adrian Bunk writes: Adrian> Yes, it is speculation that other new features (or even Adrian> bugfixes) might appear in the kernel and might become Adrian> mandatory in systemd between jessie and jessie+1. Adrian> But that is a risk, and it is a risk that is uniq

Bug#727708: systemd jessie -> jessie+1 upgrade problems

Adrian, I'm frustrated when I read your message because you put words in my mouth that I did not speak. I never said that Debian should allow systemd to dictate policy for multiple distributions nor did I say that Debian should allow one upstream systemd maintainer to dictate decisions for Debian.

Bug#727708: Please clarify L options with regard to interfaces

Hi. There seems to be a significant conflict within the TC about what the L options mean. Speaking as a maintainer who could be affected by this and as someone who would sponsor a GR to override one interpretation butnot another, I'd request that the TC clarify what it means with the next ballo

Bug#727708: Call for votes on init system resolution

> "Ian" == Ian Jackson writes: Ian> Anthony Towns writes ("Re: Bug#727708: Call for votes on init Ian> system resolution"): >> It's really pretty terrible to actively use FD to try to block >> options that aren't your favourite. Honestly, I would have >> expected the tech

Bug#727708: Please clarify L options with regard to interfaces

> "Colin" == Colin Watson writes: Colin> I think Ian and I are agreed that L excludes 1), and permits Colin> 3). On reflection I think I agree that L has to exclude 2) Colin> as well. Hmm, I am reading Ian as against 3. I request that TC members work with Ian on the wording of

Bug#727708: Please clarify L options with regard to interfaces

>>>>> "Sam" == Sam Hartman writes: >>>>> "Colin" == Colin Watson writes: Colin> I think Ian and I are agreed that L excludes 1), and permits Colin> 3). On reflection I think I agree that L has to exclude 2) Colin> as well.

Bug#727708: Please clarify L options with regard to interfaces [and 1 more messages]

Yeah, I now understand what you mean by L. I'll be writing more in the form of a blog post and probably GR text. I will send a pointer to the TC as I think I may be hitting close to something that Russ may find useful. I'll refrain from trying to convince the TC because you have enough voices t

Re: Call to fork

> "debianfan" == debianfan writes: debianfan>I would like to propose forking Debian if the ctte debianfan> committee selects systemd It's with great hesitation that I jump in here, and I know what I'm doing is wrong. I hope I've earned enough credibility over the years in the

Understanding the current state

Hi. There's been a lot of mail in the last couple of days and I'll admit to a bit of uncertainty to where things stand. I'd appreciate it if people would correct me if I've gotten anything wrong: 1) Bdale's resolution is waiting for a casting vote to be declared. It may be possible for a TC me

Bug#727708: call for votes on default Linux init system for jessie

> "Bdale" == Bdale Garbee writes: Bdale> Steve Langasek writes: >> FWIW I have always assumed that the casting vote is implicit in >> the chair's ballot. To require the chair to explicitly exercise >> their casting vote, as opposed to the chair's preferences as >> expres

Bug#727708: init system coupling etc.

When I've found myself trying to avoid normative language in situations like this I end up with statements like: It is important that all packages support smoothe upgrades from Wheezy to Jessie , even when the system is booted with sysvinit. -- To UNSUBSCRIBE, email to debian-ctte-requ...@list

Bug#741573: Two menu systems

t that consensus. If no consensus was reached or the TC finds it has a compelling interest not to respect that consensus, then focusing on the technical details of the policy seems reasonable. In my opinion, not respecting the project as a whole enough to make a determination about consensus does

Bug#741573: Two menu systems

>>>>> "Steve" == Steve Langasek writes: Steve> On Wed, Apr 09, 2014 at 01:27:46PM -0400, Sam Hartman wrote: >> Thanks for bringing this issue back to the question that was >> brought to the TC. >> The discussion so far on this bug h

Bug#741573: Two menu systems

> "Ian" == Ian Jackson writes: >> So, if you've reviewed this enough to support Bill's claim that >> there isn't a consensus because there are substantial objections >> raised in the discussions and not addressed, then please say >> that. If you have not reviewed things suff

Bug#681419: Alternative dependencies on non-free packages in main: counterargument

> "Ian" == Ian Jackson writes: Ian> And from a practical point of view, I would prefer to make a Ian> choice that significantly eases collaboration with the GNU Ian> Project to one that slightly eases collaboration with Ian> proprietary software vendors. The more interesting

Bug#765803: Status of prompting / notification on upgrade for init system switch?

> "Josh" == Josh Triplett writes: Josh> - It can't check for generated lines for serial consoles or Josh> similar; finish-install can generate various additional Josh> inittab lines, which the check should include. Since when did systemd actually handle these correctly? I've gene

Bug#746578: libpam-systemd to flip dependencies - proposal

> "josh" == josh writes: josh> I wouldn't necessarily suggest using this as an argument josh> against the proposed resolution. Instead, I'd recommend josh> making sure that cgmanager is just as harmless under systemd josh> as systemd-shim 8-4 currently is, by making it not r

Bug#746578: libpam-systemd to flip dependencies - proposal

I don't think this matters for the vote, and apologies because there's probably a better place to send this advice. I was thinking last night about the apt and debootstrap resolver issues and was wondering whether the following solution might help. I realize the issue is minor and is more about

Re: [CTTE #746578] libpam-systemd to switch alternate dependency ordering

> "Charles" == Charles Plessy writes: Charles> Le Mon, Nov 17, 2014 at 11:58:41AM +0100, Lucas Nussbaum a Charles> écrit : >> >> Specifically, I would like to ask Debian Developers to contribute >> (positively) to TC discussions when relevant, in order to help >> the

Thanks for all your hard work

Hi. Thanks for your hard work. Over the past years you've put in a lot of work in the TC. I think you were one of the forces that really pushed the TC to be a viable decision making body. You seemed to really care that when issues were brought to the TC, they were considered and a decision made.

Re: Bug#762194: On automatic init system switching on upgrade

Has the TC asked whether any of the stakeholders want help? I understand why absent options you may not want to do something. But is the release-team and the d-i team and other stakeholders happy with the status quo? I think the answer is yes. However, you've had a number of situations recently w

Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building

> "Ron" == Ron writes: Ron> I'd be kind of sad if that stopped being possible again for the Ron> final released version of Jessie, and we had to skip yet Ron> another release before being able to do this on Debian again. Ron> It may not be the best and final answer, but it h

Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building

> "Dimitri" == Dimitri John Ledkov writes: Dimitri> Comparing squeeze and jessies - have things regressed? if Dimitri> yes, how? As far as I expect, the way one uses debian Dimitri> source packaging to produce cross toolchains has not Dimitri> changed, nor has been affected b

Bug#762194: Automatic switch to systemd on wheezy->jessie upgrades (thoughts)

Thanks. I found this post of your to be really thought-provoking and useful and an example of the sort of discourse we should strive to when discussing these issues. I think the discussion of switching default inits in the future is something to particularly consider. --Sam -- To UNSUBSCRIBE, e

Bug#769972: Read before Voting: Note from hartmans about new member ballots

>>>>> "Don" == Don Armstrong writes: Don> ===BEGIN Don> The Technical Committee recommends that Sam Hartman (hartmans) Don> be appointed by the Debian Project Leader to the Technical Don> Committee. Don> A: Recommend to Appoint S

IS hartmans a good fit for the TC

Hi. When I submitted my application to be considered as a TC member, it was with excitement, hoping to work together with great folks to learn from the strengths and weaknesses of past TC work. From the discussions I saw there seemed to be agreement both that there was really great technical work

Re: IS hartmans a good fit for the TC

>>>>> "Don" == Don Armstrong writes: Don> On Wed, 04 Mar 2015, Sam Hartman wrote: >> I'd like to see people come to the TC earlier in the process. I >> hope that asking for help, especially from the TC will be viewed >> as a way

On Consensus

> "Tollef" == Tollef Fog Heen writes: Tollef> Consensus are at least two things: «Are everybody Tollef> ok/happy/ecstatic about this?», and «Are somebody unable to Tollef> live with this resolution». Those are different things, and Tollef> I don't think we're entirely clear o

Re: bastardizing packages or stepping down

> "Adam" == Adam D Barratt writes: Adam> Hi, Making no comment on the remainder of the mail: Adam> On 2015-03-05 10:38, Michael Tokarev wrote: >> And since I can't do my work, I'm stepping down from being >> busybox maintainer, and am kindly asking the release team to >>

Re: bastardizing packages or stepping down

>However, I still really want to understand that unknown reason >why all this happened, why it is so difficult to accept a >working package than to do more bastardizing work, why it is >smart to reject good stuff and to do absolutely unnecessary work >(double work with maintaining 2 version and a

Do we want to submit a sprint request for debconf

A couple of weeks ago I noticed mail to d-d-a talking about sprints at debconf. I'm wondering whether we want to try and spend a day at debconf or debcamp exploring how we want to work together, how we want to resolve issues, working on internal procedure, getting to know each other, that sort of t

Re: Call for Votes for new CTTE Chairman

I will not be able to vote on this. First, as I've mentioned I have great respect for Don and look forward to working with him as chair. I find though that if further discussion were on the ballot, it would be my top ranked choice, exactly because I don't know what kind of chair we need, because

Re: Call for Votes for new CTTE Chairman

>>>>> "Andreas" == Andreas Barth writes: Andreas> * Sam Hartman (hartm...@debian.org) [150311 13:18]: >> So, I don't feel that I have the information I need to make an >> informed decision on this issue, so I won't be able to ca

Re: Scheduling CTTE Meetings

Unfortunately, the two times I've tried to reach https://dudle.inf.tu-dresden.de/ctte_march_meeting/ today, I've never been able to establish an https connection. I never complete a TCP handshake. The only conflicts I have are Wednesdays from 1300-1600 UTC and Thursday starting at 2100 UTC. --

Re: Scheduling CTTE Meetings

> "Andreas" == Andreas Barth writes: Andreas> * Don Armstrong (d...@debian.org) [150317 19:50]: >> On Tue, 10 Mar 2015, Don Armstrong wrote: >> > Given that we have new members, if anyone has a conflict with >> that time > slot, and would prefer that it was moved, I've >>

Re: Scheduling CTTE Meetings

>>>>> "Don" == Don Armstrong writes: Don> On Wed, 18 Mar 2015, Sam Hartman wrote: >> Two hours later would be a problem for me on Thursdays although >> not other days. One hour later is starting to be an issue but I'd >> generall

Bug#741573: Requesting input on TC deliberations about menu system and policy

Dear Charles, Last Thursday, the TC met. As part of that meeting we discussed #741573. See the logs at http://meetbot.debian.net/debian-ctte/2015/debian-ctte.2015-03-26-18.59.log.html . Currently the plan is that Keith is going to propose some text within the policy process that he believes

Policy Process and Rough Consensus

Steve, in one of the TC meetings last year, you made the claim that the policy process was not a rough consensus process. I recently read process.txt.gz from the debian-policy package. That document (admittedly dated after #741573 was submitted) claims the opposite. I don't know what the docu

Re: bastardizing packages or stepping down

Hi. I'm sorry it has taken a while to write back to you. I asked how the TC could help and was confused when I read your message. I provided a couple of options how we might be able to help and you neither selected one of my options nor provided your own. So, I wasn't sure what you were looki

Re: Policy Process and Rough Consensus

hi, thanks for an excellent mail. I've read it and agree with your analysis. To the best of my understanding you were elaborating on what I wrote, not disagreeing with it. --Sam -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact

Bug#741573: Menu Systems: Thoughts about Next Steps

Having reviewed the policy team's process.txt document and having reviewed Charles's comments, I'm much less sanguine when I think about the approach for resolving the menu system discussion that we discussed last Thursday. Keith may well have an approach that improves over both the status quo

Re: Poll for next CTTE Meeting (and default in future)

Don, I'll be voting based on my general availability. I am unavailable Wednesday-Friday of that week because I'm going to a spiritual retreat, so it's fairly likely I'll miss this meeting. However, most of those times would generally be good for me and I think it's more important to pick times that

Re: Polling open for next CTTE Meeting (and default in future)

l = M = N > g = h = i = j = d = e > O > z > c > b = a pgpoomumf7ONb.pgp Description: PGP signature

Re: Bug#750135: Status of #750135 (Maintainer of aptitude package)

> "Tollef" == Tollef Fog Heen writes: Tollef> My suggestion is basically to say yes to Manuel: Make him Tollef> the maintainer of aptitude and ask the Alioth admins to Tollef> reinstate him as an admin, removing Daniel. Manuel is Tollef> clearly interested in working on aptit

Re: Bug#750135: Status of #750135 (Maintainer of aptitude package)

>>>>> "Tollef" == Tollef Fog Heen writes: Tollef> ]] Sam Hartman >> A major advantage of this approach is that it can happen from >> within the aptitude project. Christian has the technical >> authority to implement this. He

Bug#750135: Status of #750135 (Maintainer of aptitude package)

> "Didier" == Didier 'OdyX' Raboud writes: Didier> Given the situation (an unresponsive Daniel, a proposal from Didier> people with powers to push the situation forward), I'd be Didier> more inclined to say yes to Christian, without a formal Didier> resolution. Given that Ch

Moved up menu system in the agenda

Folks, I will only be able to make the first part of the meeting because I need to head to the airport. I'd like to request that we discuss the menu system bug during a part of the meeting I can attend so I can get feedback on my comments sent to the bug. To that end I've pushed a change to the a

Re: Bug#750135: Status of #750135 (Maintainer of aptitude package)

I just arrived in the UK this morning for a series of meetings, and I expect it will take one sleep cycle before I'll be awake enough to draft ballot text, but I'll attempt to do that in the next couple of days. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of

Sorry about the Delay

Hi. My meetings in the UK ended up requiring 100% of my mental focus for the last few days. Lots of fun technical design work and project planning, but very little time available to actually write up a ballot option. I expect to catch up on TC business Saturday the 16th. -- To UNSUBSCRIBE, ema

Bug#750135: Initial draft of resolution

Proposed for your consideration and checked into git for your editing: Background/Rationale (Constitution 6.1(5)): 1. In #750135, the technical committee was asked by Manuel Fernandez Montecelo who should be the maintainer of the aptitude projectp. He had been actively committing until his com

Bug#750135: Initial draft of resolution

> "Didier" == Didier 'OdyX' Raboud writes: >> Background/Rationale (Constitution 6.1.5): >> >> 1. In #750135, the Technical Committee was asked by Manuel >> Fernandez Montecelo who should be the maintainer of the Aptitude >> project. He had been actively committing until

Bug #741573:Process Approach vs Others

Hi. During the conversation of #741573 last meeting, and while reading the log, I felt really frustrated and disappointed. I would like to be heard and understood, and when I read what Bdale and Don are saying, I don't think that they are connecting with some issues that are really important to

Bug#741573: Bug #741573:Process Approach vs Others

issue, rather than just asserting a decision from on high. That is, we communicate to them that we believe that they didn't have consensus rather than just jumping to a conclusion. I don't think we need to vote for that if we have internal rough consensus, although I'd be fine

Bug#741573: Bug #741573:Process Approach vs Others

>>>>> "Kurt" == Kurt Roeckx writes: Kurt> On Wed, May 27, 2015 at 09:19:07PM -0400, Sam Hartman wrote: >> [moving back to the bug, because we're starting to discuss the >> issue rather than a TC communications matter.] >>

Re: Bug#750135: Initial draft of resolution

> "Tollef" == Tollef Fog Heen writes: Tollef> I think this is fine and we should vote on this before even Tollef> more time passes. Opinions? I'll call for a vote on June 15 unless people either seem to believe earlier is better or I hear objections. However, between now and then, I

Re: Bug#750135: Initial draft of resolution

I'm fine with this proposal. I slightly prefer it to my original draft and hope others prefer it significantly. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/

Bug#750135: Call for Vote: Resolution on Aptitude Maintainer

I here-by call for a vote on the following text (option A); the other option is FD. I will be out much of the next two weeks so if the vote becomes resolved I'd appreciate it if someone could step in and announce the decision. Background/Rationale: 1. In #750135, the Technical Committee was ask

Bug#750135: Call for Vote: Resolution on Aptitude Maintainer

>>>>> "Sam" == Sam Hartman writes: Sam> I here-by call for a vote on the following text (option A); the Sam> other option is FD. I will be out much of the next two weeks Sam> so if the vote becomes resolved I'd appreciate it if someone

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

> "Aron" == Aron Xu writes: Aron> I don't hold a view on whether we want lz support in dpkg/dak, Aron> but it could be a pity if we really involve CTTE for such an Aron> issue. To me, it's sorta abusing the escalation process if Aron> every individual developer raise an issue

Bug#741573: Bug #741573:Process Approach vs Others

>>>>> "Don" == Don Armstrong writes: Don> On Wed, 27 May 2015, Sam Hartman wrote: >> >>>>> "Bdale" == Bdale Garbee writes: Bdale> I hear you, I just don't have any idea what to do differently Bdale> on this

Bug#741573: Investigation of the bug log

You are copied on this message because you raised objections noted by the policy editors during the discussion of menu policy or seconded the proposal in #707851. The TC is currently evaluating a request to review that proposal and the process surrounding it. If you seconded the proposal, I'd lik

Regrets for Tomorrow's Meeting

Hi, folks. I will be at an event in maryland that starts just around the time of the meeting so I'll be unable to attend. I hope I've been more clear in my communication about the menu policy bug. I'd really like to see us call for any objections to the proposal on debian-policy and amongst ourse

Bug#741573: Investigation of the bug log

> "Lisandro" == Lisandro Damián Nicanor Pérez Meyer > writes: Lisandro> Hi Sam! A long time has passed since then and I should re Lisandro> read the full and extensive bug log to assert whatever you Lisandro> want to ask. But I can be sure on one thing: at the time Lisand

Re: Regrets for Tomorrow's Meeting

> "Don" == Don Armstrong writes: Don> OK. So assuming this is the case, does option B in the draft Don> now represent your view? Or is option A sufficient? Assuming that the discussion plays out as I suspect, I'd probably vote a=b>z>c If it's clear from the log that we thought about

Regrets for Debconf

I'm an owner of a small company. We had a managers meeting yesterday and realized that there's a lot of design ideas in my head related to a number of new projects. If I go to debconf, it's going to significantly gum up the works in a period where we have significant upcoming deliverables. So,

Bug#741573: #741573: Menu Policy and Consensus

posal and outcome of the discussion, and thought that the people who had raised objections were in the rough. I may not have done a very good job of that, though. (Also, I felt like the proposal was a good path forward, which doesn't make me a particularly unbiased judge of consensus.) Sam hartman Speaking only for myself pgpXXbUrHHGVF.pgp Description: PGP signature

Bug#741573: #741573: Menu Policy and Consensus

>>>>> "Bill" == Bill Allombert writes: Bill> On Fri, Jul 17, 2015 at 10:08:04PM +, Sam Hartman wrote: >> In March of 2014, Charles Plessy asked the Debian Technical >> Committee to review one of the policy editors decisions to revert

Bug#741573: #741573: Menu Policy and Consensus

>>>>> "Charles" == Charles Plessy writes: Charles> Le Sat, Jul 18, 2015 at 01:56:49PM +, Sam Hartman a Charles> écrit : >> >>>>> "Bill" == Bill Allombert writes: Charles> Also, the question is not whether th

Bug#741573: #741573: Menu Policy and Consensus

>>>>> "Charles" == Charles Plessy writes: Charles> Le Sun, Jul 19, 2015 at 08:05:56AM +, Sam Hartman a Charles> écrit : >> >> Bill, in his role of policy editor said that he believed there >> was not a consensus. Cha

Bug#741573: Russ's role

You said: > > I think that what you wrote does not reflect what happened: > Charles> - Russ gave me the green light for committing the changes, see Charles>. Only Policy Charles>Editors can decide that a change will be commi

Bug#741573: #741573: Menu Policy and Consensus

>>>>> "Josselin" == Josselin Mouette writes: Josselin> Sam Hartman wrote: Bill, in his role Josselin> of policy editor said that he believed there was not a Josselin> consensus. He cited a specific set of messages that he Josselin>

Bug#741573: Russ's role

>>>>> "Bill" == Bill Allombert writes: Bill> On Mon, Jul 20, 2015 at 10:34:47AM -0400, Sam Hartman wrote: >> You said: >> Hi. As a matter of fact finding. Russ's message, which Charles >> sites implies to me that Russ was s

Bug#741573: #741573: Menu Policy and Consensus

> "Ian" == Ian Jackson writes: Ian> 1. The TC - not the policy process, not the policy editors, and Ian> not the consensus on debian-policy - has the ultimate Ian> responsibility to set technical policy. (Constitution 6.1(1)) Ian> So in the TC the question of whether the pol

Bug#741573: #741573: Menu Policy and Consensus

>>>>> "Ian" == Ian Jackson writes: Ian> Sam Hartman writes ("Re: Bug#741573: #741573: Menu Policy and >> I think the key area where we differ is that I would give >> preference other things being mostly equal to upholding the work

Bug#741573: #741573: Menu Policy and Consensus

> "Charles" == Charles Plessy writes: Charles> I made efforts to keep the wording mild, but I think that Charles> it was an error. >> From your attiude as the lead person behind the Debian Menu, it >> is clear that Charles> it has no future. For one decade, you have taken

  1   2   3   >