Hi,
On 7/1/24 04:55, Aigars Mahinovs wrote:
- if the NMU author has access to the main git repo of the package on
Salsa they can make a commit and tag there (normal team-like
maintenance)
If we create a method with a low technical barrier for NMUing, we also
need to have a discussion about p
Hi,
On 6/27/24 01:16, Ian Jackson wrote:
Secondsly, there is only currently one supported way to generate an
orig: git-deborig aka git-archive. So the protocol in this area is
fairly simple, and the possible extension to support other orig
generation modes is not described in the document.
S
Hi,
On 6/27/24 00:41, Russ Allbery wrote:
The second case seems fine with tag2upload? Particularly if upstream
signs the Git tag. Instead of pointing to a possibly signed release
tarball, the tag2upload tag points to a signed upstream Git tag. We get
basically the same properties and avoid d
Hi,
We basically have three cases:
1. upstream has an official .orig.tar.* file we can use
In my opinion, we'd want to use this because we don't need to explain
how it was generated, and any signature from upstream can be used to
verify that we are shipping exactly their release.
I'm aware
Hi,
On 6/26/24 03:42, Aigars Mahinovs wrote:
Do you actually check that the contents of the source *package* (after
all operations done by dpkg-source and possibly other tools) actually
match what you were looking at before in your source work tree folder?
Yes, although more from a quality c
Hi,
On 6/25/24 09:38, Brian May wrote:
But like it or not mistakes can happen. e.g. somebody applies a security
update to the project. And uploads it to Debian. But forgets to do a git
push to salsa.
You can only call it "forgetting" to do a git push if you introduce a
policy that contributi
Hi,
On 6/24/24 10:19, Marco d'Itri wrote:
I think we have seen and still see with usrmerge how difficult and cumbersome
the resolution of an initially as simple presented project turned out. I
understand the answer of Scott directed in that way, at least this is a
reservation of mine.
For th
Hi,
On 6/22/24 04:40, Russ Allbery wrote:
I am frequently told that Debian is a do-ocracy: the people who are
willing to do the work have wide latitude over how that work is done. One
of the implications of that is that delegates don't get to force other
people to do their work in arbitrarily
Hi Ian,
On 6/20/24 23:27, Ian Jackson wrote:
I think *usually* the git history is part of the source, but sometimes
it isn't (and sometimes it's even harmful and must be discarded).
Usually you wouldn't (and shouldn't) rewrite the history, but
sometimes you should (and sometimes you must).
Ov
Hi,
On 6/20/24 02:07, Matthias Urlichs wrote:
If dgit becomes the archive, not being able to mirror it is a major
regression.
It's not quite as trivial as I'd like to pack git archives (shallow or
not) so that they can be mirrored and mostly-seamlessly unpacked at the
destination, but it's
Hi,
On 6/19/24 17:33, Aigars Mahinovs wrote:
- we need to store the actual contents in the archive, not just a
reference to an online service, or the online service becomes part of
the archive.
Effectively the dgit.debian.org becomes the archive or the snapshot service
of the git view of
Hi,
On 6/19/24 00:57, Aigars Mahinovs wrote:
This is *exactly* the same situation as we already have with
source-only uploads. There is a
state of the software upload that the developer signs off on and then
there are further technical
build artifacts that the developer does *not* sign - they a
Hi,
On 6/17/24 21:13, Ian Jackson wrote:
Your WTF seems to be from a false assumption that git is central to
Debian package maintenance. It isn't. It is popular, but not central,
nor standardized.
git is central to most software maintenance in the world at large.
Not all, by any means. But
Hi,
On 6/17/24 18:49, Marco d'Itri wrote:
There is another aspect he mentioned: he thinks the uploader needs to test
the build of the package. (I'm theory I agree, but there are situations
Everybody can upload totally untested packages even without tag2upload:
maybe tag2upload would
Hi,
On 6/17/24 20:38, Jonathan Carter wrote:
When it comes to tag2upload, I believe it's something that most people
would want. At least it doesn't take away from any existing workflow or
force people to change their habits right away, so in terms of being
able to gain support for it, it has
Hi,
On 6/14/24 00:50, Russ Allbery wrote:
We have several 90% solutions of mapping Debian packaging onto git, but
all of these are incomplete and annoying to use because we disagree with
git on what constitutes data, and what constitutes metadata, so the data
model does not match reality or req
Hi,
On 6/13/24 22:27, Simon Josefsson wrote:
Generally I reach the same conclusion, although I think there are real
security problems with both the existing and the proposed tag2upload
mechanism that we should all be aware of. It is acceptable to realize
that we cannot protect against all atta
Hi,
On 6/13/24 20:29, Marco d'Itri wrote:
Do we actually want or need to hoard all the collaboration history?
Of course: this makes auditing much easier.
That is a *massive* amount of data though, especially if we're expected
to import the entire upstream git history as well and base the
Hi Ian,
On 6/13/24 18:57, Ian Jackson wrote:
(Because git inherently has history, the dgit-repos server can
perform both functions at once.)
Do we actually want or need to hoard all the collaboration history?
Simon
Hi,
On 6/13/24 06:00, Luca Boccassi wrote:
Yes, that's the argument - all Salsa features are bad and "bloat":
issues are bad, teams are bad, CIs are bad, merge requests are bad,
the only thing needed is to push&pull to some git backend, everything
else is bad and unneeded.
The requirements fo
Hi,
Since my signature got lost on the way, retrying:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
> START OF PROPOSAL TEXT
>
> Debian Public Statement about the EU Cyber Resilience Act (CRA) and the
> Product Liability Directive (PLD)
>
> The CRA includes requirements for manufacturers of
Hi,
On 23.11.23 03:16, Bart Martens wrote:
START OF PROPOSAL TEXT
Debian Public Statement about the EU Cyber Resilience Act (CRA) and the
Product Liability Directive (PLD)
The CRA includes requirements for manufacturers of software, followed
up by the PLD with compulsory liability for softwar
Hi,
On 11/20/23 08:21, Luca Boccassi wrote:
Therefore, the Debian project asks the legislators to enhance the
text of these regulations to clarify beyond any reasonable doubt that
Free and Open Source Software developers and contributors are not going
to be treated as commer
Hi,
On 11/15/23 20:27, Aigars Mahinovs wrote:
That is exactly why I think this is dangerous: I want GitLab and
Proxmox
to be responsible for what they release, but it is very difficult to
draw a line between their offering and what Microsoft is doing by
paying
for system
Hi,
On 11/15/23 15:22, Lucas Nussbaum wrote:
The Debian project however notes that not enough emphasis has been
employed in all parts of these regulations to clearly exonerate Free
and Open Source Software Projects from being subject to the same
liabilities as commercial pro
Hi,
On 13.11.23 19:54, Aigars Mahinovs wrote:
So a commercial company releasing open source
software that is *not* part of their commercial activity (for example a
router manufacturer releasing an in-house written Git UI) would be
"supplied outside the course of a commercial activity" and thu
Hi,
On 11/13/23 02:47, Lisandro Damián Nicanor Pérez Meyer wrote:
Similarly, where the
main contributors to free and open-source projects are developers
employed by commercial entities and when such developers or the employer
can exercise control as to which modifications are accepted in the co
Hi,
On 9/10/22 11:37, Andrew M.A. Cater wrote:
Multiplying installers might be a complexity too far at this or any other
stage.
We already multiply installers along several axes. Most of these work by
simply selecting different file sets and detecting at runtime whether a
specific file is p
Hi,
On 9/8/22 08:00, Didier 'OdyX' Raboud wrote:
As-is (that is: "changing only SC5 with a 3:1 majority") seems to be one very
simple way to express the change we (some of us) want.
It's the change we need to do in order to be consistent, so "want" is a
pretty strong word here.
It is a mar
Hi Russ,
On 9/7/22 21:58, Russ Allbery wrote:
Simon Richter writes:
Do users have the right to redistribute the installer?
In this proposal it's left unspecified (in other words, it's not an
inherent position of the Social Contract one way or the other), mostly
because I'm
Hi,
On 9/7/22 19:48, Russ Allbery wrote:
--
This ballot option supersedes the Debian Social Contract (a foundation
document) under point 4.1.5 of the constitution and thus requires a 3:1
majority.
The Debian Social Contra
Hi Jonas,
On 8/31/22 18:43, Jonas Smedegaard wrote:
The only way I could see to solve that conflict (other than interpreting
the official installer as not part of Debian) was to keep the free-only
installer around for purity reason even though generally we would
promote another unofficial insta
Hi Marco,
- users need to be aware of non-free licenses
I believe that "need" here is a strong word. Some users will /like/ to
know which non-free firmwares they need to use (I do!), but I cannot
think of any reasonable scenario in which somebody /needs/ to know that.
As I've mentioned earl
Hi Wouter,
On 8/27/22 12:18, Wouter Verhelst wrote:
The third point is something we can and should address in the medium term:
so far, license checks for non-free components have been mostly "can Debian
redistribute this" and "can users install this".
Thus, your concern can easily be handled
Hi,
On 8/23/22 22:22, Bart Martens wrote:
Debian would recommend the one with non-free-firmware, for the
purposes of enabling users to install on current hardware, but both
would be available.
Do we need to recommend one above the other? I'd rather use some short
explanation per installer to
Hi Ansgar,
On 8/19/22 17:09, Ansgar wrote:
I don't see a difference between having non-free files in the archive
and non-free files on the installation images. If having individual
non-free files was not acceptable then we would have to define the
archive not part of Debian as well.
Yes, and
Hi,
On 8/18/22 21:58, Steve McIntyre wrote:
We will include non-free firmware packages from the
"non-free-firmware" section of the Debian archive on our official
media (installer images and live images). The included firmware
binaries will *normally* be enabled by default where the system
deter
Hi,
On 11/8/21 5:30 PM, Sam Hartman wrote:
* A proposal to update our voting process (which looks like it will have
a couple of options on the ballot)
And that is a good thing. The core strength of our voting system is that
there are no spoiler options, and if I look back, the most contro
Hi Bdale,
On Tue, Apr 20, 2021 at 11:35:21AM -0600, Bdale Garbee wrote:
> I admit to having really mixed feelings about whether Debian should
> *ever* make broad public statements about anything. So, no problem in
> my mind with making it harder for the project to do so.
One of the purposes of
Hi Felix,
On 05.04.21 15:35, Felix Lechner wrote:
When a center option is likely to fail our majority requirement [1]
should I rank preferable extreme choices above FD even if I am
strictly moderately inclined?
You are making two bold assumptions here: that the options are on a
single one-di
Hi,
On 30.03.21 09:56, Dmitry Smirnov wrote:
Nobody is perfect. Everybody said a foolish thing at least once in a
lifetime. If we cancel those who love what they do, those who are good
with what they do, those who are passionate and caring for what they do
for something they have said somewhere
Hi,
On 26.03.21 08:32, Christian Kastner wrote:
> All I'm saying is that when people speak out about the wish to be
> apolitical, the term 'apolitical' should not be taken in the widest
> possible sense, which covers any action or inaction, and then dismissed
> for being impossible.
> Rather, in
Hi,
On 25.03.21 23:32, Christian Kastner wrote:
>> the "technical" decisions we make based on that also have political
>> consequences.
> That's taking meaning of the word 'political' in the widest possible
> sense, and in that sense, literally any action (or inaction) carried out
> by an indivi
Hi Roberto,
On 25.03.21 18:59, Roberto C. Sánchez wrote:
> I understand that it is not always possible to be completely apolitical,
> even for Debian as an organization.
Pretty much everything Debian does is political.
Free software enables users' technical autonomy, and this completely
shifts
Hi,
On Mon, Mar 22, 2021 at 09:08:14PM +0100, Christian Kastner wrote:
> The (1) adoption of debhelper by my most packages and (2) the move to
> Salsa have been an absolute blessing. They have made contributing to
> other packages so much easier.
We have multiple standards at different abstracti
Hi,
On Wed, Mar 18, 2020 at 12:01:28PM +0100, John Paul Adrian Glaubitz wrote:
> > Honestly, I don't think it's a problem we can solve right now, but at
> > the very least, we should do whatever it takes to not be part of the
> > problem, and we should take every small step we can take to be the
Hi,
On Thu, Dec 05, 2019 at 08:32:28AM -0500, The Wanderer wrote:
> At minimum, "X is the default" means "you will get X if you don't take
> any action to avoid doing so". All definitions I can think of seem to
> share that baseline.
> At something like maximum, "X is the default" could be read
Hi,
On Wed, Dec 04, 2019 at 10:24:40PM +0500, Andrey Rahmatullin wrote:
> > One of the options I had in my original proposal was that we could drop the
> > requirement for transitions through apt, and instead provide transition
> > scripts that use dpkg's --force options to go through an invalid
Hi,
On Wed, Dec 04, 2019 at 04:43:39PM +0100, Ansgar wrote:
> For one of the problems (apt making unexpected decisions) that is
> pretty close to what is the case. We do find such issues again and
> again, including too late, i.e. only after a stable release, also for
> other packages that aren't
Hi,
On 02.12.19 00:20, Simon McVittie wrote:
>> In that particular case, the user session must be available to allow
>> activation of gsettingsd via dbus
> There is no such thing as gsettingsd. Presumably you mean dconf-service
> (which is conceptually one of many backends, although in practice
Hi,
On 02.12.19 00:07, Uoti Urpala wrote:
> In short: there is little to no worthwhile work being done on any
> alternatives to systemd. What is happening is some people trying to
> keep sysvinit working to about the level it did in 2014, while doing
> very little fundamental development to the s
Hi,
On 01.12.19 23:24, Simon McVittie wrote:
> dbus-user-session is not, and probably will not be, usable on non-systemd
> systems. If per-user service managers other than `systemd --user` exist
> and can be configured to provide equivalent semantics, I'd be happy
> to review the necessary integr
Hi,
On 01.12.19 20:13, Russ Allbery wrote:
>> Right, but the dependency chain is there to make sure the package is
>> usable on systemd systems, i.e. we'd have to accept a regression for the
>> systemd case in order to facilitate the non-systemd case, which is what
>> we don't want, or live with
Hi Russ,
On 01.12.19 18:16, Russ Allbery wrote:
>> https://lists.debian.org/debian-devel/2019/08/msg00278.html
> This is a point that Ian's proposal specifically addresses by accepting
> the possibility that packages will be installable but not usable on
> non-systemd systems in order to avoid t
Hi,
On 01.12.19 10:06, Martin Michlmayr wrote:
> So there's a lot about proposal B that I like, but at the end of the
> day the proposal doesn't sound that different to the status quo.
> While it says systemd, there's no 100% commitment (there's no clear
> preference over Debian kludges for examp
On 01.12.19 02:54, Russ Allbery wrote:
>> Russ> Could you provide some more information about what your
>> Russ> concern is here? libsystemd-dev depends only on libsystemd0,
>> Russ> which has a pretty tiny list of dependencies and shouldn't
>> Russ> require that systemd be runnin
On 30.11.19 18:46, 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 pr
Hi,
On Fri, Nov 29, 2019 at 10:16:10PM +0200, Martin Michlmayr wrote:
> I'd like submit the following proposal:
I guess my second is not really needed anymore for this, but it's good to
have it on the ballot.
> Proposal: Focus on systemd to promote standardization and cross-distribution
> coop
Hi,
On Fri, Nov 29, 2019 at 09:07:58AM -0800, Russ Allbery wrote:
> Sam, I think you misunderstood Simon's concern. He's not looking for
> guidance for packages that don't work properly with sysvinit. He's
> looking for guidance for packages that don't work properly with *systemd*
> (the invers
Hi Sam,
On Fri, Nov 29, 2019 at 08:46:31AM -0500, Sam Hartman wrote:
> Martin [Pitt] has publically stated he's one of the people I reached out
> to in developing my proposals.
> As I understand, he's been active in maintaining systemd both in Ubuntu and
> Debain.
Indeed, most of my interaction
Hi,
On Fri, Nov 29, 2019 at 01:22:37PM +, Holger Levsen wrote:
> > I do not support delaying the CFV for an option that has not gained
> > sponsors.
> just sigh.
> Michael, I'm very very likely to sponsor anything you have written so
> far. Please publish something so it's on the table and
Hi,
On Fri, Nov 29, 2019 at 11:44:55AM +, Ian Jackson wrote:
> > For example, it raises a (probably valid) concern about
> > "non-init-related [declarative] systemd facilities", but:
> > 1/ it mixes it with an argument that declarative facilities are better.
> > Well, maybe I can agree with
Hi,
On Mon, Nov 25, 2019 at 01:09:10PM +, Ian Jackson wrote:
[change removing regret about having another GR]
> Unless anyone objects by 1400 UTC on Wednesday, I intend to accept
> this amendment, assuming that this is procedurally kosher.
I'm also in favour of that. My understanding of pro
Hi,
Dmitry Bogatov proposed the following amendment:
> Being able to run Debian systems with init systems other than systemd
> continues to be of value to the project. Every package MUST work with
> pid1 != systemd, unless it was designed by upstream to work exclusively
> with systemd and no supp
Hi Sam,
On Thu, Nov 21, 2019 at 07:44:02AM -0500, Sam Hartman wrote:
> I'd like to ask especially those people whether choice hartmans1 should
> be removed from the ballot. Within limits, I think more options is
> better, so my general preference would be to keep the option. However
> especiall
Ian Jackson writes:
> I hereby formally propose the following amendent (for my reference,
> 42471fd). Replace the entire text, with the text below.
>
> -8<-
>
> Title: Support non-systemd systems, without blocking progress
>
> PRINCIPLES
>
> 1. We wish to continue to support multiple init sys
Hi,
On Fri, Nov 15, 2019 at 10:03:35AM -0800, Russ Allbery wrote:
> My personal preference is for the project to either decide that we're
> going to use systemd facilities by default and sysvinit is going to break,
> or to decide that we're going to require standardized interfaces with the
> opti
Hi,
On Fri, Nov 15, 2019 at 10:29:10AM +0100, Thibaut Paumard wrote:
> I think this is very ambiguous and my immediate interpretation is
> probably not what the original proposer means. The two extreme
> interpretations I see for "designed to work exclusively with systemd" are:
> - my guess fo
Hi Sam,
On Fri, Nov 15, 2019 at 06:58:33AM -0500, Sam Hartman wrote:
> I saw someone on IRC just yesterday saying they had recently spent 16
> hours on init system GR stuff.
That was me.
> If other develpers, particularly developers who are not primary
> contributors to the discussion are alrea
Hi,
On Sun, Nov 10, 2019 at 12:19:24AM +0100, Bernd Zeimetz wrote:
> > Yes, that would be my desired outcome: an affirmation that Debian wants to
> > be "universal". This has been our greatest strength for years.
> Its a strength that wasted an enormous amount of ressources. See
> kfreebsd (whi
Hi Mike,
On Sat, Nov 09, 2019 at 09:48:03PM +, Mike Gabriel wrote:
> root@minobo:~# apt-rdepends -r systemd | wc -l
> 6598
It's not as bad as you think: the important package is systemd-sysv.
In buster:
$ apt-cache rdepends systemd-sysv
In bullseye:
systemd-sysv
Reverse Depends:
system
Hi Holger,
On Sat, Nov 09, 2019 at 06:09:35PM +, Holger Levsen wrote:
> > [Rationale: moving from systemd to sysvinit is currently an involved manual
> > process, so unavailable to anyone not already skilled in Unix
> > administration, creating an artificial barrier.]
> please clarify what y
Hi,
On Sat, Nov 09, 2019 at 10:01:27AM -0800, Russ Allbery wrote:
> > (Option 1)
> > The Debian Project aims at providing the greatest configuration flexibility
> > while maintaining a sensible default installation for end users. To that
> > end, we document functional dependencies in a machine-
Hi,
the main problem I see with this GR is that it is in essence a rehash of
the GR[1] we had in 2014, with pretty much the same options minus the one
that won, "A GR is not required."
> Choice 1: Affirm Init Diversity
The way this is worded is even stronger than in the 2014 GR, which made
allow
Hi,
On 02.04.19 05:59, Louis-Philippe Véronneau wrote:
> Some teams might dislike it, but I guess those people will also dislike
> the idea of giving all DDs commit access on all packages VCS.
Y'all are still solving social problems with technical solutions here,
and it's a bad technical solutio
Hi,
On 17.03.19 00:51, Simon Richter wrote:
> I'd also like nominate myself for the 2019 DPL election.
As you may have noticed, life happened to me shortly after sending that
mail. I'm definitely not in a position to make a serious bid anymore, so
I'd like to withdraw. I s
Hi,
I'd also like nominate myself for the 2019 DPL election.
Simon
signature.asc
Description: OpenPGP digital signature
Hi,
On 17.10.2014 22:13, Ansgar Burchardt wrote:
> I note that it was *not* possible to switch init systems in Wheezy in a
> supported way (in particular sysvinit is essential and various things
> get very unhappy if it gets uninstalled), but you seem to treat Jessie
> as more problematic even th
Hi,
On 17.10.2014 16:54, Daniel Kahn Gillmor wrote:
>> If the fix is not easy then we have three options: the release team
>> mark it `jessie-ignore', the GNOME maintainers fix it, or GNOME is
>> removed from jessie.
> The implication here appears to be troubling for any upstream who wants
> to
Hi,
On 17.10.2014 11:52, Marco d'Itri wrote:
>> for 30 years so why are some people pushing _so hard_ to replace it NOW and
>> by something
>> as controversal as the systemd stuff.
> A vocal minority and a lot of trolls do not make something
> controversial.
No, the majority disregarding the n
Hi,
> Upstream Developers considering a specific Free Software (including,
> but not limited to, a particular init system executed as PID 1)
> fundamental to deliver the best Software releases, are fully entitled
> to require, link, or depend on that Software, or portions of it.
Note that
Hi,
On 16.10.2014 17:05, Ian Jackson wrote:
> I wish to propose the following general resolution, and hereby call
> for seconds.
[...]
> ** Begin Proposal **
>
> 0. Rationale
>
> Debian has decided (via the technical committee) to change its
> default init system for the next release. The
Hi,
On Thu, Sep 16, 2010 at 06:52:02PM +0200, Kurt Roeckx wrote:
> > In case these changes are regarded as more than editorial (which is your
> > call, but I feel they are), the new proposal requires new seconds
> I'm not sure why you think the proposal requires seconds if it
> replaces an older
Hi,
On Wed, Sep 15, 2010 at 09:48:02PM +0200, Kurt Roeckx wrote:
> > I like that a lot more than the other wording, thus seconded.
> Please don't go and make this more confusing for me. As far as I
> can tell this wasn't meant to be amendment yet. He will probably
> accept this or something si
Hi,
On Wed, Sep 15, 2010 at 09:00:32PM +0900, Stefano Zacchiroli wrote:
> The Debian project aims at producing the best free operating system.
> To that end the project benefits from various types of contributions,
> including but not limited to: package maintenance, translations,
> infrastructur
Hi,
On Fri, Dec 19, 2008 at 12:36:54PM +0100, Marc Haber wrote:
> On Fri, Dec 19, 2008 at 01:50:40AM -0600, Manoj Srivastava wrote:
> > To paraphrase: Those who give up essential freedoms for
> > temporary convenience and popularity deserve neither.
> This is something we need to agree
Hi,
MJ Ray wrote:
Yes, that's my understanding. The "all the sensible combinations"
shortcut was deleted from Voting procedure on June 21st, 2003.
Would it make sense to reintroduce that?
Simon
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Cont
Hello,
MJ Ray wrote:
> AMENDMENT PROPOSAL
> Summary: reduce the campaign-only period to one week.
>
> The change to paragraph four is replaced by:
> 4. For [-three weeks-] {+one week+} after that no more candidates
>may be nominated; candidates should use this time for
>
Hi,
MJ Ray wrote:
> AMENDMENT PROPOSAL
> Point 2 remains as before; that is, it will still read:
> 2. The election begins nine weeks before the leadership post
>becomes vacant, or (if it is too late already) immediately.
> AMENDMENT PROPOSAL
Seconded.
Simon
Hello,
Nathanael Nerode wrote:
> (There is a special exception for the license texts and similar legal
> documents associated with works in Debian; modifications and derived
> works of these legal texts do not need to be allowed. This is a
> compromise: the Debian group encourages authors of
Hello,
Holger Levsen wrote:
> DebConf, the annual Debian Developers Conference, is currently not officially
> affiliated with Debian (or SPI) and its not listed on
> http://www.debian.org/intro/organization
> Do you think DebConf should have an official endorsement with Debian and how
> do yo
Hello,
Ana Guerrero wrote:
Why do you think you will be a good DPL?
I see the role of the DPL mostly as a mediator; for that to work it is
important to listen and to be able to put one's own opinion aside; both
of which I think I can do.
What you can for Debian as DPL that you can not do
Hello,
What do you think of the dunc-tank initiative ? What do you think are
the result of the "experiment" ?
I think we should have been able to see the outcome before trying it.
The idea itself is not a bad one, however during the entire course of
the experiment it was never questioned by
I wrote:
There is a lot of gray area between those extremes, and we have to
decide on a case-by-case basis. I can see Debian spending more money
than it used to (e.g. to get some of the developer machines back up),
but I want to avoid both setting precedent and starting an internal
competitio
Hello,
Kalle Kivimaa wrote:
What is the role of the DPL? Is he a strong leader, who uses his
position to Get Things Done His Way, a public figurehead, who just
Speaks For The Project, a mediator, who tries to solve internal
squabbles, or something else?
The current role seems to be that the D
Hello,
it appears as if my first mail was reflowed at some point, which made
the signature go bad.
Thus, I reconfirm nominating myself as a candidate for the Debian
Project Leader 2007.
Simon
signature.asc
Description: OpenPGP digital signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I hereby nominate myself as a candidate for the post of the Debian
Project Leader in 2007.
Simon
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFF3zYRGKDMjVcGpLQRAsG9AJ9k3JWQ73U3n8ZRQSNMecZVgQh8vQCeLNMF
kv85KdVwX8M+2
Hi,
Raul Miller schrieb:
>>This is silly. It seems like the constitution effectively says "if the
>>resolution passes it required a simple majority; if it failed, it needed 3:1".
> The only silliness is the verb tenses. Once some concept passes
> supermajority it doesn't need to pass again, be
Hi,
Xavier Roche wrote:
I fully agree. The "Holier than Stallman" stuff is really getting
ridiculous. After the firmware madeness, now the documentation madeness.
And after that, the font madeness maybe ? (after all, fonts ARE also
software, and they shall be distributed with their original sou
Hello,
Jérôme Marant wrote:
What is this supposed to mean? If no comments have been made by the
author for eight weeks, messages will be automatically declassified?
It looks like a kind of opt out to me.
True. It may be an idea to have another proposed amendment reversing the
logic, and see
1 - 100 of 101 matches
Mail list logo
