Re: General Resolution to deploy tag2upload
On Thu, 27 Jun 2024 16:21:47 +0200, Joerg Jaspert wrote: > On 17273 March 1977, Aigars Mahinovs wrote: > > Refusing to make a decision is a decision. > We haven't refused to make one. > We haven't been asked for one, even. > > There is no point in service building a > > Debian source package where there is a hard requirement that the Debian > > source package must be a part of the inputs provided to the system. > We already said that we will do it in a way, that it can be done with > *minimal* things necessary on client side. Two comments, one more emotional and one more analytical: * Part of my gut feeling is that the call for a GR might be a bit premature, as I have the feeling that especially Gannef is not opposed to t2u in general but is trying to work out how it might work; and I really appreciate this positive attitude! * On the other hand, I have the impression, based on my own experiences with the FTP team, that this can go on for another 5 years or longer, as the FTP team usually avoids taking any formal decisions; and this (meta level now) comes from the fact the no delegated or ad-hoc team in Debian (except the TC) has any bylaws/procedures for taking a decision, so it's easier to just not decide. Not sure what my conclusion might be; maybe something like "Wait for 4 more weeks for an official statement of the FTP team, and failing that, call for a GR." Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Re: Question to candidates: what are your quantitative diversity goals and metrics?
On Fri, 29 Mar 2024 11:28:33 -0400, Roberto C. Sánchez wrote: > The reason for asking the question in the first place is because the > statements made by the candidates demand some level of quantification. > What, precisely, is the problem with asking for a quantitative > description of a quantifiable problem? Sorry to interrupt and jump on a meta level, but it's not "the statements" which demand quantitative descriptions, it is you who does this. I'm not saying this is inappropiate or wrong or whatever per se, but it's not nature-given, god-given or something, it's _your_ opinion that a quantifiable approach to these questions would be useful and _your_ decison to ask those questions. Apparently, even if not explicitly spellt out, others disagree. Also fine, also legitimate. And … > The reason for asking so persistently is because the question still is > not being answered. … probably the reason why you don't get any answers on those questions. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Re: New option for the RMS/FSF GR: reaffirm the values of the majority
On Sat, 03 Apr 2021 21:46:08 +0200, Enrico Zini wrote: > Hello, Hm? | -- | GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini | | [-- End of signed data --] | | [-- PGP output follows (current time: Sun Apr 4 00:09:30 2021) --] | gpg: Signature made Sat Apr 3 21:46:04 2021 CEST | gpg:using RSA key 2490211AD036087E6D1D9A92D0FF49CBE3F4FB68 | gpg: requesting key 0xD0FF49CBE3F4FB68 from hkps server hkps.pool.sks-keyservers.net | gpg: Can't check signature: No public key | [-- End of PGP output --] Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Orquesta Aragon: El Charlatan signature.asc Description: Digital Signature
Re: Should the project hire one or two persons to help the DPL?
On Fri, 19 Mar 2021 23:20:58 +0100, Joerg Jaspert wrote: > Leaving out the detail of Debian paying someone for work, this has one more > thing that can backfire hard, as I just could witness in an (entirely > unrelated) org: That those hired ones got more powerful than the actual > leader. Simply by being there continuously, doing ground work, that the > actual leader(s) over time didn't want to do. With time a big bunch of the > work just got done, mostly leaving the radar of the leader then, and so they > ended up controlling much, the leader being a figurehead in the end. I'd like to echo what Ganneff is saying. I also know from personal experience in (non-software) volunteer organizations, and a friend of mine has written her diploma thesis on this topic researching yet another NGO, that a setup with a volunteer board/committee/chairperson/president and employed executives/secretaries is difficult, as the latters are the one spending more time, collecting more information, becoming the information centre, … over time, and hereby either become the de facto power centre or at least causing struggles or fights over who actually controls the whole thing. This is not to say that I would dismiss the idea of having paid employees in a volunteer organization completely; like Sam wrote, I think paying for work that doesn't get done otherwise and (my addition) that is not a core activity of the organization -- e.g. accounting -- can make sense. But I'd like to stress that the whole construction needs careful thought in order to prevent unintended side effects as far as possible. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Bettina Wegner: Jesus signature.asc Description: Digital Signature
Re: Last minute cominbations G+D and/or G+E
On Thu, 05 Dec 2019 11:59:36 +, Ian Jackson wrote: > Here is the formal version of this proposal. (My previous mail wasn't > signed.) Thank you. > Title: Support portability, without blocking progress > > PRINCIPLES > > 1. The Debian project reaffirms its commitment to be the glue that > binds and integrates different software that provides similar or > equivalent functionality, with their various users, be them humans or > other software, which is one of the core defining traits of a > distribution. > > 2. We consider portability to different hardware platforms and > software stacks an important aspect of the work we do as a > distribution, which makes software architecturally better, more robust > and more future-proof. > > 3. We acknowledge that different upstream projects have different > views on software development, use cases, portability and technology > in general. And that users of these projects weight tradeoffs > differently, and have at the same time different and valid > requirements and/or needs fulfilled by these diverse views. > > 4. Following our historic tradition, we will welcome the integration > of these diverse technologies which might sometimes have conflicting > world-views, to allow them to coexist in harmony within our > distribution, by reconciling these conflicts via technical means, as > long as there are people willing to put in the effort. > > 5. This enables us to keep serving a wide range of usages of our > distribution (some of which might be even unforeseen by us). From > servers, to desktops or deeply embedded; from general purpose to very > specifically tailored usages. Be those projects hardware related or > software based, libraries, daemons, entire desktop environments, or > other parts of the software stack. > > SYSTEMD DEPENDENCIES > > 6. Ideally, packages should be fully functional with all init systems. This > means (for example) that daemons should ship traditional init scripts, or use > other mechanisms to ensure that they are started without systemd. It also > means > that desktop software should be installable, and ideally fully functional, > without systemd. > > 7. So failing to support non-systemd systems, where no such support is > available, is a bug. But it is *not* a release-critical bug. Whether the > requirement for systemd is recorded as a formal bug in the Debian bug system, > when no patches are available, is up to the maintainer. > > 8. When a package has reduced functionality without systemd, this should not > generally be documented as a (direct or indirect) Depends or Recommends on > systemd-sysv. This is because with such dependencies, installing such a > package > can attempt to switch the init system, which is not what the user wanted. For > example, a daemon with only a systemd unit file script should still be > installable on a non-systemd system, since it could be started manually. > > One consequence of this is that on non-systemd systems it may be possible to > install software which will not work, or not work properly, because of an > undeclared dependency on systemd. This is unfortunate but trying to switch the > user's init system is worse. We hope that better technical approaches can be > developed to address this. > > 9. We recognise that some maintainers find init scripts a burden and we hope > that the community is able to find ways to make it easier to add support for > non-default init systems. Discussions about the design of such systems should > be friendly and cooperative, and if suitable arrangements are developed they > should be supported in the usual ways within Debian. > > CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED > > 10. Failing to support non-systemd systems when such support is available, or > offered in the form of patches (or packages), *should* be treated as a release > critical bug. For example: init scripts *must not* be deleted merely because a > systemd unit is provided instead; patches which contribute support for other > init systems (with no substantial effect on systemd installations) should be > filed as bugs with severity `serious'. > > This is intended to provide a lightweight but effective path to ensuring that > reasonable support can be provided to Debian users, even where the > maintainer's > priorities lie elsewhere. (Invoking the Technical Committee about individual > patches is not sensible.) > > If the patches are themselves RC-buggy (in the opinion of, initially, the > maintainer, and ultimately the Release Team) then of course the bug report > should be downgraded or closed. > > 11. Maintainers of systemd components, or other gatekeepers (including other > maintainers and the release team) sometimes have to evaluate technical > contributions intended to support non-systemd users. The acceptability to > users > of non-default init systems, of quality risks of such contributions, is a > matter for the maintainers of non-default init systems and the surr
Re: Last minute cominbations G+D and/or G+E
On Wed, 04 Dec 2019 17:11:49 +, Ian Jackson wrote:
> gregor herrmann writes ("Re: Reframing"):
> > So yes, for me a combination of options G and D would be (or maybe
> > more accurately: would have been ) helpful in finalizing my ranking
> > of the options given my ambivalence.
>
> To make it concrete I am going to post texts of those two options. If
> people come forward to say they support or or both of them I will
> formally propose them tomorrow morning (in the hope that the Secretary
> and/or the DPL will allow them on the ballot). If you support either
> of these options enough, then please formally propose it yourself and
> I will second it tomorrow.
Thank you for your work on this!
I think I would support the G+D combination but given Kurt's mails
from this evening [0] it looks like this ship has sailed, and I will
now follow your example and spend the time before going to bed with
something more enjoyable than reading -vote and thinking the options
through.
Cheers,
gregor
[0]
https://lists.debian.org/debian-vote/2019/12/msg00109.html
https://lists.debian.org/debian-vote/2019/12/msg00114.html
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Mark Knopfler: Sands Of Nevada
signature.asc
Description: Digital Signature
Re: Reframing
On Tue, 03 Dec 2019 12:54:40 +, Ian Jackson wrote: > I have written this mail To people who seconded Guillem's proposal and > to some people from the thread. I would particularly like to hear > your views. > > I am considering making a formal variant of Guillem's proposal, which, > if Guillem doesn't agree that specific guidance is needed, would stand > on the ballot alongside Guillem's and my proposal D. I would like > that proposal to reflect the views of people who seconded Guillem's > proposal. I found and find Guillem's text very appealing; and I also can see that people who are involved in the issue on the technical or the policy side would like to have concrete answers to the pending questions and guidance for moving forward. For the latter I think that your proposal is a good approach as it tries to spell out the compromise in concrete actions. So yes, for me a combination of options G and D would be (or maybe more accurately: would have been …) helpful in finalizing my ranking of the options given my ambivalence. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Dave Brubeck: In Your Own Sweet Way signature.asc Description: Digital Signature
Re: Proposal: Reaffirm our commitment to support portability and multiple implementations
On Sat, 30 Nov 2019 18:46:27 +0100, Guillem Jover wrote: > I'm thus proposing the following: > > X< > Title: Reaffirm our commitment to support portability and multiple > implementations > > The Debian project reaffirms its commitment to be the glue that binds > and integrates different software that provides similar or equivalent > functionality, with their various users, be them humans or other software, > which is one of the core defining traits of a distribution. > > We consider portability to different hardware platforms and software > stacks an important aspect of the work we do as a distribution, which > makes software architecturally better, more robust and more future-proof. > > We acknowledge that different upstream projects have different views on > software development, use cases, portability and technology in general. > And that users of these projects weight tradeoffs differently, and have > at the same time different and valid requirements and/or needs fulfilled > by these diverse views. > > Following our historic tradition, we will welcome the integration of > these diverse technologies which might sometimes have conflicting > world-views, to allow them to coexist in harmony within our distribution, > by reconciling these conflicts via technical means, as long as there > are people willing to put in the effort. > > This enables us to keep serving a wide range of usages of our distribution > (some of which might be even unforeseen by us). From servers, to desktops > or deeply embedded; from general purpose to very specifically tailored > usages. Be those projects hardware related or software based, libraries, > daemons, entire desktop environments, or other parts of the software > stack. > X< Seconded. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Bob Dylan: I Want You signature.asc Description: Digital Signature
Re: Proposal: Focus on systemd
On Fri, 29 Nov 2019 18:12:48 -0500, Sam Hartman wrote: > I'm trying to figure out if the new proposal is redundant with proposal > C. The text is obviously very different, but I'm trying to figure out > if there are any practical differences. Understand this is not a > criticism of this proposal, but if there are no significant practical > differences I am enclined to withdraw Proposal C. Without having thought this through, I have a gut feeling that you could withdraw all of your original proposals, because we now have 3 clear proposals, worded by the respective proponents, for the 3 general directions: Dmitry's pro multiple init systems variant, Ian's compromise proposal, and now tbm's clear pro systemd text. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Beatles signature.asc Description: Digital Signature
Re: Choice Hartmans1a
On Fri, 22 Nov 2019 08:01:37 -0500, Sam Hartman wrote: > >>>>> "gregor" == gregor herrmann writes: > gregor> This contradicts the spirit, culture, and conventions around > gregor> NMUs which are prevalent in Debian for at least ten years > gregor> and are written down in DevRef 5.11.1. > > I actually think that being able to NMU a package to add init system > support is entirely consistent with what debref says about NMUs. > It sounds like you're worried that I'm trying to lessen the categories > of things that can be NMUed. > Or that I'm tieing NMU to bug sevirity. > I'm not trying to do that either. > I'm trying to recommend a bug severity and emphasize that NMUs are > appropriate. Thanks for the clarification. > I'd appreciate help in achieving these goals without undermining the > text in debref. I think the main problem is actually that you try to write down NMU rules in a GR; where they do not belong, as the NMU guidelines develop in practice and are reflected in the process of updating DevRef. From a different point of view: If you are just referring to the existing NMU guidelines, why do you mention them in proposal 1a but not in proposal 2 and 3? > I think it is important to emphasize that these bugs can be NMUed in > this choice. Why? I mean, why are you treating these bugs differently than any other of the gazillions of bugs, or more to the core of this GR, differently from missing systemd service units in proposal 2 etc.? > Since that is already consistent with the tradition you > cite, I'm not seeing the problem. The problem in my opinion is mostly that this aspect doesn't belong into this (or any) GR. > But if you can suggest language that > continues to emphasize that NMUs are appropriate in this situation > without doing damage to that tradition, I would greatly appreciate it. I think Holger's proposal goes in the right direction, although I would go a step further and say, leave it out and maybe mention "BTW, we have NMUs for bugs" in an appendix -- for all options. > I do not support removing the statement about NMUs under the grounds > that it is obvious. Fine with me; personally I will rank all options talking about NMUs below FD. And taffit has captured my thoughts very good when he writes: On Fri, 22 Nov 2019 06:06:59 -1000, David Prévot wrote: > By doing that, this choice de facto overrides the currently documented > (and working) NMU workflow and practices. > I believe it opens a can of worms. It sets on stone an NMU workflow, > making it impossible to let the rule evolve as it usually did. Worse, if > such things is accepted via GR, one will be able to argue later that > other NMU fixes are not acceptable (“the only NMU fix one can do is the > one the project agreed on with GR2019#1“). That's exactly what I oppose: Writing down NMU rules in a GR, even if they at the time of writing just represent the current culture and guidelines, will get into the way of adjusting them in the future. Maybe this also answers a bit your followup question to taffit: On Fri, 22 Nov 2019 12:40:47 -0500, Sam Hartman wrote: > David> By doing that, this choice de facto overrides the currently > David> documented (and working) NMU workflow and practices. > In what way? > How does it override them? > To override them it needs to say something inconsistent with these > practices. > What is inconsistent between what the resolution says and the existing > practices. Currently probably nothing. But NMU guidelines might (want to) change and then the GR is still there. And then they might contradict each other. - I just don't see any advantage and potential disadvantages. On a more general point (answering your other question on potentially withdrawing your proposal 1(a)): Yes, I think as we have Ian's and Dmitry's options I don't see any huge value in keeping hartmans1a on the ballot. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: trio infernal: desafinado signature.asc Description: Digital Signature
Re: Choice Hartmans1a
On Thu, 21 Nov 2019 13:58:09 -0500, Sam Hartman wrote: > Choice hartmans1A: Init deversity is Important and NMUable […] > Developers may > perform non-maintainer uploads to fix these bugs. This contradicts the spirit, culture, and conventions around NMUs which are prevalent in Debian for at least ten years and are written down in DevRef 5.11.1. NMUs can happen for any package, for any bug, at any time, and are not tied to any bugs types, bug severities, or permissions from GR outcomes. Obviously it makes sense to follow the conventions from DevRef; the text there explicitly also mentions wishlist bugs, and differentiates between bug severities only in the choice of the recommended DELAYED queue. Inventing NMUability rules tied to bug severities in a GR seems counterproductive to me. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Kurt Ostbahn & Die Kombo: Ollas wa so afoch signature.asc Description: Digital Signature
Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
On Fri, 08 Jul 2016 15:27:56 +0200, Margarita Manterola wrote: > I'm therefore proposing the following General Resolution: > > === BEGIN GR TEXT === > > Title: Replace "Chairman" with "Chair" throughout the Debian Constitution > > All appearances of the word Chairman shall be replaced with the word Chair. > > === END GR TEXT === Seconded. Cheers, gregor -- .''`. Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- signature.asc Description: Digital Signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, 16 Oct 2014 19:24:52 +0200, Stefano Zacchiroli wrote: > > As Matthew said, I don't think further lengthy discussion of the > > issues is likely to be productive, and therefore hope we can bring > > this swiftly to a vote. This is particularly true given the impact on > > the jessie release. > Speaking of which, > before deciding anything (including seconding it or not) about this > proposal, I'd like to know what impact a positive outcome of this GR > would have on the work load of teams whose efforts we badly need to put > the Jessie release in shape. Secon^WAgreed. And let me add a question: What does this GR actually mean in practice? Is it about specific problems? If yes, which ones (bug numbers)? If not, what else? Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Beatles: Rocky Raccoon signature.asc Description: Digital Signature
Re: GR proposal: code of conduct
On Fri, 07 Mar 2014 11:23:48 +0100, Stefano Zacchiroli wrote: > So, even if this second amendment is accepted by Wouter, I'd rather vote > on two options: one where the DPL might change the CoC, and a separate > one which requires a GR. Assuming I'm not alone on this --- public > feedback welcome --- it might be simpler if Wouter simply does not > accept Neil's second amendment. Feedback, as requested: I agree. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Tom Waits: What's He Building? signature.asc Description: Digital signature
Re: GR proposal: code of conduct
On Thu, 27 Feb 2014 23:42:47 +1100, Stuart Prescott wrote: > To me the strength of the CoC draft we are looking at here is that it > doesn't concern itself with trivialities or with specific media. It talks > about conduct -- that is behaviour, deportment, how we want people interact > as human beings -- be respectful, be collaborative, assume good faith, be > concise, be open. These are all about social interactions and not technical > details on character limits, attachment sizes or whether people get CCs on > messages. None of these technical things are conduct, they are, if you like, > protocol. The CoC could happily refer to medium-specific guidelines for such > minutiae if they are necessary. Wow, thank you. You put my thoughts into way better words than I ever could have done. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Mark Knopfler: Junkie Doll signature.asc Description: Digital signature
Re: [all candidates] Removing or limiting DD rights?
On Mon, 25 Mar 2013 18:02:08 +0100, Lucas Nussbaum wrote: > On 25/03/13 at 16:22 +, Steve McIntyre wrote: > > Are we strict enough with our existing contributors? When we're trying > > to work together as best we can to make the Universal Operating System > > happen, what could/should we do with contributors who hinder our work? > > Sometimes that hindrance is inadvertent, sometimes it seems > > deliberate. At other times it looks like we have developers who are > > just not paying attention to what they're doing or who just don't care > > about the goals of the project. Thanks for this question, which I would like to extend a bit. Im my understanding you are pointing to unconstructive behaviour related to technical work. What we also see (and discuss) every now and then is behaviour that is socially questionable or clearly unacceptable (from disrespect for peers to blatant abusive language). I guess we all remember such examples, which have led to demotivation, frustration, hurt feelings, and have driven contributors away. Lucas' reponse already shows an idea that might also be used for these cases: > One small thing that we could improve on is earlier official > communication. For example, in case of seriously problematic behaviour > that could eventually lead to censure or expulsion, official warnings > could be issued to the DD, and Cced to -private@. In some cases, that > could help the DD realize that s/he needs a behaviour change, and also > limit the surprise effect if/when a final decision is taken. What other ideas do you (plural, for all candidates, in case you see the necessity to improve the handling of "social problems") see as viable? Examples that have come up in the past and might or might not be helpful: - Encourage everyone to chime in when they see potentially unacceptable behaviour? In public/private? - Should we try to establish a Code of Conduct for project members? Cf. https://openhatch.org/wiki/Project_codes_of_conduct for examples. If yes, how would we do this, and how could we make sure it gets respected? - Could the CoC for mailing lists (http://www.debian.org/MailingLists/#codeofconduct) be used as a starting point / be extended? - Or Enrico's Debian Community Guidelines? http://people.debian.org/~enrico/dcg/index.html - Another recurring topic is the Social Committee, cf. e.g. https://lwn.net/Articles/221077/ (or the ombudsman team mentioned in the article: https://lists.debian.org/debian-project/2007/01/msg00101.html ) Would such a body make sense? With which powers? Short summary: Does Debian need procedures for intervening in cases of dysfunctional social behaviour and which? Thanks to all of you for standing/running in this vote, and for taking the time to answer all these questions! Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Rod Stewart: Smile signature.asc Description: Digital signature
Re: All candidates: Development and technical issues and challenges
On Wed, 20 Mar 2013 01:15:58 -0400, Michael Gilbert wrote: > Even the suggestion of a testing removal can evoke negative feelings > for those affected (sometimes from those on the sidelines too). A > recent example: > http://bugs.debian.org/703258 There seems to be a misunderstanding; at least my surprise was not caused by the proposal to remove the package from testing (actually, I mentioned this as the most probably option in my first mail in the original bug report), but by the fact that I wouldn't have known about the removal bug without the later CC by Jonathan. > Do you have any thoughts on addressing the social aspect of this > approach? In this case, "X-Debbugs-Cc: $original_bug|$maintainer_address" would have been enough :) Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Jimi Hendrix: Message To Love signature.asc Description: Digital signature
Re: mentoring programs in Debian
On Tue, 12 Mar 2013 19:55:42 +0100, Lucas Nussbaum wrote: > "schools/seminars" > -- > Ubuntu does https://wiki.ubuntu.com/UbuntuDeveloperWeek - a set of > seminars on IRC to teach Ubuntu development. I'm not sure of how useful > that is (I've never attended it) and if we should do it too. AFAIK we > don't do that inside Debian. But I thought it was worth mentioning. There have been some IRC Training Sessions organized by the Debian Women team: http://wiki.debian.org/DebianWomen/Projects/Events/TrainingSessions Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Bob Dylan: It's All Good signature.asc Description: Digital signature
Re: [Call for seconds] GR: diversity statement for the Debian Project
On Mon, 07 May 2012 20:32:41 +0200, Francesca Ciceri wrote: > TEXT TO BE VOTED STARTS HERE > > The Debian Project welcomes and encourages participation by everyone. > > No matter how you identify yourself or how others perceive you: we > welcome you. We welcome contributions from everyone as long as they > interact constructively with our community. > > While much of the work for our project is technical in nature, we value > and encourage contributions from those with expertise in other areas, > and welcome them into our community. > > TEXT TO BE VOTED ENDS HERE Seconded. Thanks, Francesca! Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Didier Squiban: Bannec signature.asc Description: Digital signature
Re: Draft amendment: Welcome non-packaging contributors as Debian Developers with upload access
On Wed, 15 Sep 2010 16:17:40 +0200, Lucas Nussbaum wrote: > Before pushing it forward as an amendment, I'd like to hear opinions about > this: we have had problems with GRs proposing orthogonal options in the past. > This amendment proposal discusses two things that are orthogonal (giving full > upload access to non-packaging contributors, and limiting every DDs' access on > a volunteer basis). Should the second part of the amendment (after > "Additionally, ..") be dropped for now? Or should we move forward as is? I'd prefer two have the two issues separated and not in one GR. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Beatles signature.asc Description: Digital signature
Re: To all candidates: personal mentoring
On Thu, 25 Mar 2010 20:08:00 +0100, Stefano Zacchiroli wrote: > Still, in your question you're hinting at some earlier mentoring, and I > believe that should happen in teams. [..] > That is why I like the http://www.debian.org/Teams/ page. Ideally, that > can become the welcome place for new contributors which will first look > around what they like to do and then approach the corresponding team on > the suggested media. /me agrees twice. > In principle, we can additionally establish within team some form of > personal mentoring with the goal of bringing accompanying the newbie to > the advocacy mail. In practice I doubt it would change much the status > quo, but I agree it might be nice from the newbie POV (e.g. he/she will > have someone to mail when feeling unsure about some course of action). JFTR: There was a BOF around these questions during the last DebConf; the summary and some resources are linked from http://wiki.debian.org/Teams/Resources Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG Key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Tom Waits: Day After Tomorrow signature.asc Description: Digital signature
Re: Q for all candidates: license and copyright requirements
On Wed, 24 Mar 2010 08:27:43 +0900, Charles Plessy wrote: Salut Charles, > Our users, if they want to modify, study, redistribute or use after rebuild > our ^^ > system, need the source. At no moment these operations involve modifying a RFC ^^ ^ The marked spots above seem to be a contradiction to me. > or a binary program that is aimed at run on a Windows system. I conclude that > that kind of file, although present in our source packages, are not part of > the > source of our operating system. JFTR: Like some others I disagree on this point of view. IMO "Debian, the distribution" consists equally of binary and source packages, so if a package wants to be considered free as defined by the DFSG there must not be any non-free parts neither in the binary nor in the source package. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG Key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Peter Ratzenbeck: Recycling Rag signature.asc Description: Digital signature
Re: Proposal: Enhance requirements for General resolutions
On Mon, 23 Mar 2009 16:23:06 +, Stephen Gran wrote:
> While the number of seconds required to start a vote should be nQ, the
> number of seconds for an amendment should mQ, where m = n/x (x > 1). I
> think that it should be difficult to start a GR, as it's a large time
> sink for the project as a whole. Once it's clear we're going to have a
> ballot, though, I see no reason it should be difficult to represent
> a range of opinions on the ballot. Possibly it should be more difficult
> than it currently is, but I am not yet convinced either way.
I'm not sure either; I see your point about having a range of
opinions , but OTOH more options can also lead to more confusion, so
making them too "cheap" might be unfavourable.
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Die Schmetterlinge: Feiertag
signature.asc
Description: Digital signature
Re: I hereby resign as secretary
On Thu, 18 Dec 2008 08:44:11 -0600, Manoj Srivastava wrote:
> I am hereby resigning as secretary, effective immediately.
I'm sorry to hear about this decision.
Although I don't agree with some of your arguments around the current
GR, I have respect for you and your work, and I trust you and think
that you have always acted in good faith, according to your
principles and with Debian's well-being in mind.
I hope that you will find the energy to stay as a DD and continue with
your valuable contributions to the project.
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Led Zeppelin: Travelling Riverside Blues
signature.asc
Description: Digital signature
Re: First call for votes for the Lenny release GR
On Wed, 17 Dec 2008 21:45:54 -0200, Margarita Manterola wrote:
> On Wed, Dec 17, 2008 at 9:02 PM, Manoj Srivastava wrote:
> >If there is sufficient support, we could also scrap the current
> > vote, change our ballot, add options to it, or something, and restart
> > the vote, but that would need a strong grass roots support (I do not
> > think the secretary has the power to do so).
I support stopping this GR and starting all over, if this is
possible.
I won't repeat all the reasons why this GR is seen as problematic;
they have been named at great length already. I just want to add that
even if we finish this GR we won't have the questions solved since we
will continue to discuss what the winning Choice #n actually means,
and this won't do the project any good.
> As far as I understand from reading the immense threads, most people
> (me included) don't want more options in the ballot. We want separate
> ballots for separate subjects.
I agree on this point, and I think your proposal is a good starting
point for a new start in general - thanks!
[..]
> I hope that you can take that into consideration.
+1
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Leonard Cohen: You Have Loved Enough
signature.asc
Description: Digital signature
Re: call for seconds: on firmware
On Sat, 15 Nov 2008 09:45:56 -0600, Debian Project Secretary wrote:
> Since some people have had trouble reading the proposals, I am
> including a short impact of the proposal list below the proposal.
Thanks for listing the consequences of the different choices.
In order to make it easier for me and maybe others I'm trying to
compact them into a single table below (the FD column is from Russ'
followup mail to -vote).
v Consequence / Proposal > | 1 | 2 | 3 | 4 | 5 | 6 | FD
---|---|---|---|---|---|---|---
i require source for firmware in main| Y | N | N | N | Y | N | Y
ii allow Rel.Team to ignore SC violation bugs | N | N | N | Y | N | N | N
iii What do we do for Lenny| W | R | R | R | R | R | W
iv modify foundation documents| N | N | N | Y | N | Y | N
v override foundation documents | N | Y | Y | N | N | N | N
---|---|---|---|---|---|---|---
Y(es) N(o) R(elease) W(ait)
As a side note:
I guess what makes this vote confusing (at least for me) is that we
try to answer several questions (roughly equivalent to the
consuequences) in one vote ...
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Andrew Lloyd Webber & Tim Rice
signature.asc
Description: Digital signature
Re: On the "Debian Maintainers" GR
On Fri, 27 Jul 2007 11:54:24 +0200, Andreas Barth wrote:
> > I don't see a contradiction here; on the contrary I can imagine that
> > DMs take some work off the shoulders of DDs in teams.
> In teams, commit rights to the repository are enough for that. So, what
> is the point?
(Again, from my experience in the pkg-perl group:)
Keeping the packages in svn and in the archive in sync is not that
easy; sometimes the overview about pending uploads gets lost in a
bunch of mails with upload requests by non-DDs and notices by DDs
("uploaded foo", "working on bar", ...).
It's no grave problem, and we're working on improving keeping the
overview in the Debian Perl Group. But still, the possibility of
making uploads for non-DDs might slightly ease the situation.
Cheers,
gregor
--
.''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
: :' : debian: the universal operating system - http://www.debian.org/
`. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/
`-NP: Tina Turner: I Don't Wanna Lose You
signature.asc
Description: Digital signature
Re: On the "Debian Maintainers" GR
On Thu, 26 Jul 2007 23:27:12 +0200, Josselin Mouette wrote: > > I don't see a contradiction here; on the contrary I can imagine that > > DMs take some work off the shoulders of DDs in teams. > I fail to see how. More pet packages mean more work I was not thinking about those "pet packages" but about existing packages that are maintained by existing teams where now non-DDs already do part of the work but then always have to bother a DD when it comes to uploading. Maybe I'm wrong but I guess some DDs in those teams might appreciate the lesser work. Cheers, gregor, member of the pkg-perl team, non-DD -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: The Eagles: Lyin' eyes signature.asc Description: Digital signature
Re: On the "Debian Maintainers" GR
On Thu, 26 Jul 2007 19:40:29 +0200, Pierre Habouzit wrote: > This is exactly what I don't like in the proposal. I think I already > said that, but DM is about pet packages, while Debian as a whole is > advocating Team work, Alioth, and co-maintenance. Something here feels > wrong and fishy. I don't see a contradiction here; on the contrary I can imagine that DMs take some work off the shoulders of DDs in teams. Cheers, gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Guns N' Roses: Sympathy For The Devil signature.asc Description: Digital signature
Re: Debian Maintainers GR Proposal
On Wed, 27 Jun 2007 12:03:22 +0200, Raphael Hertzog wrote: > and once Anthony has > fixed the proposal so that a DM doesn't automatically get upload rights > on all packages where he's currently listed as Maintainer/Uploader (via > the mandatory "DM-Upload: yes" field that only a DD can add), I think that field might pose a problem for team-maintained packages -- which of the persons in Uploaders: would it apply to? Or is it an additional requirement, i.e. "if $person is a DM _and_ $package listing her as an uploader has 'DM-Upload: yes' set, then $person may upload $package"? Cheers, gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Treibhaus: Maceo Parker signature.asc Description: Digital signature
Deficiencies in Debian (was: A question to the Debian community ...)
[cc and reply-to/m-f-t [EMAIL PROTECTED] On Thu, 10 May 2007 12:32:26 -0700, Russ Allbery wrote: > There are other things > that *are* signs of fundamental deficiencies in the project, Would you mind to elaborate on this point, I'm really interested in your opinion. Cheers, gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Miles Davis: Don't Stop Me Now signature.asc Description: Digital signature
