ate what this
needs a bit further (and probably discuss the idea further on
#debian-matrix:matrix.org for now).
Ansgar
[1] https://matrix.org/docs/projects/clients-matrix
haven't used them so far.
Ansgar
[1] https://matrix.org
[2] https://riot.im
ment and ${work} looking at
Matrix and so ended up looking at it. The first impression was quite
good :-)
I'm not so confident about bridges though; they are far from
user-friendly. Native rooms give a better experience.
Ansgar
Sean Whitton writes:
> On Fri 08 Nov 2019 at 04:51PM +01, Ansgar wrote:
>> We already have people complaining that source packages are "too Debian
>> specific" and should be replaced. The tooling above is even more of a
>> problem as third parties currently
Debian has made the choice to only support one
specific implementation of something.
Ansgar
ckaging which is inherently
more package-manager- and thus distribution(-familiy)-specific.
On the other side, we have Debian-specific, least common denominator
tooling that is hard to change.
Ansgar
s, the relevant maintainers will work with the downstreams to
> figure out which changes it makes sense to fold into Debian and which
> changes remain purely in the derivative.
I don't think Debian should do such a specific commitment (also not in
Choice 2). It's also a separate problem.
Ansgar
. I'm mentally translating it as "discouraged," but I
> wonder if something like "are not acceptable within the Debian Project"
> might be closer to the meaning you're intending.
Would calling sysvinit or subfeatures like elogind to be "of
questionable value" still be acceptable? :)
Ansgar
Russ Allbery writes:
> Ansgar writes:
>> On Thu, 2019-11-14 at 18:29 -0800, Russ Allbery wrote:
>>> As with Dmitry's proposal, I'm not seconding this because it's not my
>>> own first choice, but I would vote this above further discussion and
>>> I'm satisf
to Policy have slowly
been gaining usage for some time before. I don't think we should
change that approach.
Ansgar
ess-system ideas that some people are
interested which is easier the less config files in /etc are.
(Sadly sysvinit refused to support alternatives such as also
looking into /usr/lib/init.d/* in addition to /etc/init.d/* or
such; it would be nice if they were open to make it easier to
support sysvinit without running into such problems.)
Ansgar
Russ Allbery writes:
> Ansgar writes:
>> Note that this would also block updating upstream packages to new
>> releases, possibly delaying development for a long time. I don't think
>> we need much slower development cycles.
>
> I'm not sure why you think this is the ca
use their normal procedures for deciding which
> patches to include.
Seconded.
I think we should eventually move on from sysvinit-compatible init
scripts as mandatory lowest common denominator for all init systems and
so far this is the only proposal which seems to allow so.
Ansgar
signature.asc
Description: PGP signature
Russ Allbery writes:
> Ansgar writes:
>> On Thu, 2019-11-14 at 15:08 -0500, Sam Hartman wrote:
>
>>> Unless the project or relevant parties have agreed otherwise, systemd
>>> facilities, where they exist and are stable and supported by the
>>> systemd maint
ch changes it makes sense to fold into Debian and which
> changes remain purely in the derivative.
>
> Packages may include support for alternate init systems besides
> systemd. Maintainers use their normal procedures for deciding which
> patches to include.
```
Packages may include support for alternate init systems and/or
other facilities as mentioned above besides systemd. Maintainers
use their normal procedures for deciding which patches to include.
```
Ansgar
Hi Sam,
On Mon, 2019-12-02 at 15:25 -0500, Sam Hartman wrote:
> > > > > > "Ansgar" == Ansgar writes:
>
> Ansgar> Adam Borowski writes:
> >> * dependencies on "systemd | other" rather than "other |
> >> systemd&qu
On Wed, 2019-12-04 at 18:04 +0100, Simon Richter wrote:
> 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, includin
Team has been contacted several times for
similar reasons already; it doesn't always result in individuals
changing their behavior (again, see the "call for vote" message).
Maybe just try to see it as following clause 11 of proposal D. ;-)
Ansgar
use of, functionality provided by
> systemd. Solutions based on systemd technologies will allow for more
> cross-distribution cooperation. The project will work on proposals and
> coordinate transitions from Debian-specific solutions where appropriate.
Seconded.
Ansgar
signature.asc
Description: PGP signature
do this as it complicates
packaging and, more importantly, package relationships (it's very hard
to get the right packages installed in some cases in Debian's dependency
system; see [1] for a related example).
Ansgar
[1]
https://qa.debian.org/popcon-graph.php?packages=sysvinit-core+systemd-shim_installed=on_legend=on=1
an cause
and would prefer if you didn't try to block people from improving
things.
Really, going back to a "should we really ship systemd units" discussion
makes me wish we would just drop sysvinit completely so we don't have to
restart any discussion from zero (or the point where any alternative
init system was added to Debian).
Ansgar
Hi,
I would like to ask people to wait a bit longer before calling for a
vote. Michael Biebl said he is looking into drafting an alternative,
but has been too busy with work in the last few days. He would
therefore like to have a bit more time to prepare.
Ansgar
n of the FSF. This is not a
> condemnation of free software.
>From the bylaws[1] I think the directors are elected by the Voting
Members. So if people are unhappy that the Voting Members elected
Stallman, shouldn't they complain about the Voting Members instead of
the other directors?
Ansgar
[1] http
away VMs instead of throw-away containers
(e.g. for buildds). Another example is anacron (migrate to systemd
timer units?).
Of course this isn't always possible; for example I don't think we can
easily remove/replace autoconf (as another QA Group-maintained package
installed on my laptop).
Ansgar
finished.
+---[ https://www.debian.org/devel/constitution, 5.2 Appointment ]
Ansgar
ger
needs changes (only minor changes do not reset the discussion period
under A.1.6). I don't think anyone already has a finished proposal in
their drawer.
And rushing changes to the constitution doesn't seem like a good idea.
Ansgar
ck at votes to decide
> whether to delegate to someone?
And the same here.
Mailing list posts seem way more problematic than voting behavior if
you are concerned about opinions being made public. It also covers way
more topics.
Regards,
Ansgar
Constitution
| embodied in git commit ed88a1e3c1fc367ee89620a73047d84a797c9a1d.
Would removing the trailing space introduced by these changes require a
separate GR? There are also other similar inconsistencies, e.g., one
space vs. two spaces after a period.
Ansgar, noting that "noone" an
go:
https://www.debian.org/vote/2014/vote_004
> and would you
> consider applying a similar policy to other positions of power in
> Debian?
But I won't answer this.
Ansgar
es as
an example. In case of disagreement, the bar to change maintainers is
higher than for changing delegates, but the Technical Committee can do
so.
Do you think that an Appointments Committee should also handle package
maintainership and should we have term limits for how long people can
maintain packages, in particular core packages like gcc, libc, dpkg,
apt, ...?
Ansgar
On Wed, 2022-02-16 at 13:27 +0100, Gard Spreemann wrote:
> Ansgar writes:
>
> > On Mon, 2022-02-14 at 18:47 -0700, Sam Hartman wrote:
> > > I think there are problematic uses of votes well beyond
> > > harassment
> > > though.
> > >
> > >
as access to the data?
For what purposes might the data be used?
What retention period is defined for the data?
Why was I not informed that data about me is being stored?
Ansgar
ted on
https://www.debian.org/trademark#licenses, but uses Debian trademarks.
So it pretty much looks like DebConf is part of Debian.
Ansgar
able then we would have to define the
archive not part of Debian as well.
In addition the Social Contract explicitly asks people building
installation images[1] to include the "contrib" and "non-free" parts of
the archive. With this change we just follow that ourselves
Ansgar
[1]: Okay, it talks about CDs.
ot to.
I don't think everyone can affort the energy (in)efficiency of a decade
old hardware. Most users will also have more recent hardware; I don't
know much 10+ years hardware still in productive use...
Either way, such ancient hardware is probably not a good example for
the firmware problem: it was a significantly smaller problem back then.
Ansgar
On Tue, 2022-08-23 at 20:38 +0200, Jonas Smedegaard wrote:
> Quoting Ansgar (2022-08-23 19:44:17)
> > > On 2022-08-23 18:50, Jonas Smedegaard wrote:
> > > > (I only see that being possible by treating the install image as not
> > > > part of Debian, which I con
There is [1] and also the debian-installer-11-netboot-amd64 packages.
I'm not sure if these would also include firmware or only the "large"
installation media built by the CD team? Do network install images need
to include it or can they reliably download it? The audio and video
examples su
ath when trying
> to support lots of common current hardware. Increasingly, modern
> computers don't function fully without these firmware blobs.
>
> Since I started talking about this, Ansgar has already added dak
> support for a new, separate non-free-firmware component - see
> [4].
as well
include "non-free-firmware" explicitly as well, i.e., replace
We have created "contrib" and "non-free" areas in our archive for
these works.
by
We have created "contrib", "non-free-firmware" and "non-free"
areas in our archive for these works.
Ansgar
signature.asc
Description: PGP signature
of voters in tech-
ctte it is practically often even higher than 3:1. So one should
probably also drop or at least lower it for tech-ctte decisions and
maybe lower it to 2:1 for changes to the constitution or foundation
documents, matching real-life constitutional changes.
Ansgar
easonable)
firmware by default, just like we install all kernel drivers even for
devices that are not present on the target system.
Ansgar
Debian"
>
> That looks the same? Do you mean to says "is not part of Debian"?
It's "non-free firmware" vs "non-free software". I had to read three
times too.
Ansgar
get to the decent free
> environment.
Try removing all non-free firmware then. Your system won't boot, not
display anything and you won't be able to input anything either.
Ansgar
fficult position to ask for a
> change.
So we should include firmware after all? Because Debian not including
firmware seems to be trying to solve the problem on its own unlike the
solution most others have adopted.
Ansgar
quot;inclusive" there). So people who
think not allowing antivaxx and other conspiracy theories or racism or
whatever on project channels is thought policing have alternatives.
Ansgar
>
be good looking back at issues that were
reopened several times without much new arguments and took a long time
to get closed again...)
Ansgar
don't think there is a reason for it to be higher than a
simple majority.
Should we look at changing these?
Ansgar
privileges (for both new packages and updates
to existing packages)?
Regards,
Ansgar
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f5e0c5c.1030...@43-1.org
for jessie.
2. Init support in jessie+1.
Also option C Defer the decision to the Technical Committee will be
reduntant with another option once the TC makes a decision. I therefore
suggest to wait until they made at least a decision on the default init
on Linux[1].
Ansgar
[1] Provided they don't
than later!
Ansgar
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ob1nfkj2@eisei.43-1.org
a diff makes things more
confusing, especially when one references the GR text at a later time.
Ansgar
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5316000
or the kernel if it's just anti-evil-Red-Hat...)
Ansgar
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738anyipe@deep-thought.43-1.org
.
No, it does not mean packages have to work with *any* init system. It's
specifically aimed against a specific init replacement, see [1].
Ansgar
[1] https://lists.debian.org/debian-vote/2014/03/msg00103.html
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject
changing the details later without a GR by
just setting inital policy.
Maybe something similar could be done here?
Ansgar
[1] https://www.debian.org/vote/2007/vote_003
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
a regression that takes away
choice?
Ansgar
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbni3152@deep-thought.43-1.org
choices of
packages they depend on.
Again, this does seem to be a different issue than what the GR proposes.
Ansgar
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org
systems; however as far as I understood from earlier discussions you
only want to forbid depending on *one* specific init system, that is
dependencies like init-A | init-B would still be allowed.
Ansgar
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe
.
If you just come back from doing nothing to start insulting people who
actually *do* a lot of work, please consider using your time for
something more useful. Maybe you should also just consider to just leave
offically...
Please also at least read [1].
Ansgar
[1] https://www.debian.org
to make it support B. In the
good old days[tm] it would be the responsibility of the people wanting
to use B to submit patches to make P work with B (but here I suspect
many people demanding support for B do not even use P[1]...).
Ansgar
[1] In particular I heard somebody asked if anybody wanted
Hi,
On 10/24/2014 02:02 PM, Josselin Mouette wrote:
Aigars Mahinovs aigar...@gmail.com wrote:
On 24 October 2014 12:35, Ansgar Burchardt ans...@debian.org wrote:
In fact, they want to require that if P supports only A (and not
A|B)
that the maintainers of P have
understand.
The earliest Call for Votes would thus be possible on
Wed, 22 Oct 2014 07:45:39 +0900 + 2 weeks,
that is in about two more days.
Ansgar
[1] https://lists.debian.org/debian-vote/2014/10/msg00296.html
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject
expect people who are told they act out of malice to trust that
this is still a fair decision process? I do not, and I think it's a
good reason to ask somebody to consider to step back.
Ansgar
[1] https://lists.debian.org/debian-ctte/2014/01/msg00054.html
--
To UNSUBSCRIBE, email to debian-vote
with TC powers (4.1.4).
Option 3: GR with an 1:1 majority to act with DAM powers (4.1.3) to expel
the person from the project altogether.
I think you forget the option that (I think) is the least personal
damaging one:
Option 0: Ask the member to consider stepping back himself.
Ansgar
with the subject "gr_srp".
[...]
> The dedicated email address this ballot should be sent to is:
>
> gr_cttet...@vote.debian.org
Shouldn't this be "gr_srp@vote.d.o"?
Ansgar
neutral position which doesn't quite fit with tie-breaking.
[1] <https://en.wikipedia.org/wiki/Chairman>
[2] <https://en.wikipedia.org/wiki/Facilitator>
All non-Chair choices also avoid confusion with a possible future Chair
of the Technical Committee that might be used as part of an inauguration
ceremony ;)
Ansgar
65 matches
Mail list logo
