On the burden of proof and the correctness of software:
I'm afraid I see a pattern, where blanket statements are made which
are only "mostly" or "roughly" or "generally" true. But the
discrepancies and details matter. When we make computer systems, it's
not good enough to if they're only "mostly
Helmut Grohne writes ("Bug#1050001: Unwinding directory aliasing"):
> On Wed, Aug 23, 2023 at 05:04:36PM +0100, Ian Jackson wrote:
> > And, the approach being taken very seriously privileges Debian itself,
> > and those well-staffed derivatives able to do the necessar
Also, one other thing I noticed:
tl;dr: *no* version of usrmerge relieves us of the obligation of
naming files correctly, via the proper name in /usr rather than /.
Ian Jackson writes ("Bug#1050001: Unwinding directory aliasing"):
> The current plan, as I understand it, is that we w
d /usr by essentially the route you propose, successfully reached
> the symlink-farm state, but then got stuck without a way to get from the
> symlink farm to the single symbolic link. Do you have a plan for how that
> would be achieved without breaking upgrades or going behind dpkg'
en the way these discussions tend to go that means that others
will have to carry much of the more interactive load.
I'll write more about the more technical / practical aspects of your
mail at a later point.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he.
Package: tech-ctte
Background and current status
In 2019 the TC decided[1] that Debian would achieve the largely-agreed
goal of having only one place to put most files, /usr, by using
symlinks to alias from /bin etc. to e.g. /usr/bin.
At the time, concerns were raised that package management sy
Helmut Grohne writes ("Re: Bug#1007717: Updated draft resolution"):
> Simon looked at how other distributions approach patches and figured
> that basically everyone else uses the patches-unapplied model.
patches-unapplied is a good fit for distro experts in distros which
are still using tarballs-a
r. From what I know of the ftpmaster workflow I think
even Lucas's incremental tarball proposal would be a retrograde step
for them.
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
e maintaining because
our git transition is stalled.)
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source
package format with non-native version""):
> On 11/05/22 at 17:29 +0100, Ian Jackson wrote:
> > But I think that might not meet ftpmaster's review needs. AIUI
> > ftpmaster
I think there are many possibilities here which would suffice.
Right now, though, it's a bit hard to make progress without feedback
on what general direction would be most well received.
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
of the implied behaviour wrt scanning your ".." for stuff.
The *format* of 1.0-with-diff is quite reasonable, but it lacks
support more kinds of delta. That could be done as an extension to
1.0-with-diff, but I doubt that would be a popular direction.
Ian.
--
Ian JacksonThese opi
niche features here.
Mandating *more* use of patches-and-tarballs is a step backwards.
The .dsc source format (which I first invented in 1992 is now
obsolete). We must maintain it for compatibility for a very long
time, but almost everyone is already treating git as primary.
But our git setups are not official, not coherently discoverable or
useable.
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
dpkg maintainer under 6.1.4.
Let me requote myself with annotations:
> On Tue 15 Mar 2022 at 04:29pm GMT, Ian Jackson wrote:
> > Please:
> >
> > Part I - belss continued use of 1.0 native format, for now at least:
> >
> > 1. Declare explicitly that there is nothin
with
git-based workflows.
5. Consequently, declare that the recent MBF on this topic ought not
to have been filed against 1.0 with diff packages, at least
without some further filter.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.n
been filed against 1.0 with diff packages, at least
without some further filter.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
developing and integrating alternatives to both systemd and sysvinit.
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
uot; and "just download that shit from the internet" approach
is hideously bad engineering practice.)
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
power to overrule a maintainer
decision.
Furthermore, the TC can clearly make its opinion known. My view is
that the behaviour seen in #921012 and #964139 is an outrage which
ought to result in DAM action. It would be open to the TC to make a
statement strongly criticising the maintainer's behavi
r Suggests for the practical dependencies of less-critical
subcomponents.
devscripts is perhaps the best example.
> * When a user installs a library for one interpreter or environment,
> in general, we don't want the package dependencies to require that
> user to install an unrelated
Simon McVittie writes ("Bug#932795: Ethics of FTBFS bug reporting"):
> For the specific question of whether a single CPU core is a "reasonable"
> build environment, my answer at the moment is "I don't know".
There are two issues here:
1. "Is a 1-cpu system `reasonable' or `supported'" (or whateve
is reasonable but not supported.
etc.
On the point at issue, do these packages build in a cheap single-vcpu
vm from some kind of cloud vm service ? ISTM that this is a much
better argument than the one you made, if the premise is true.
Ian.
--
Ian JacksonThese opinions are my own.
r, an
post-promulgation objection is made which raises a substantial issue
that ought to be dealt with.
While vacillation is undesirable, making it easier and less socially
costly to handle mistakes, will make it easier to make changes.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
f the content of
those decisions.
Ian.
[1] I should say that I think the individual members of TC are and
have been people of generally very high caliber. IMO the failings are
emergent properties of the structure, context and framing.
[2] Much of this is, I think, ultimately my fault. I inve
change the process.
The process is a creation of the policy editors, not of the DPL nor of
the rest of the project.
Ian.
[1] https://lists.debian.org/debian-devel-announce/2017/06/msg5.html
[2] https://en.wikipedia.org/wiki/Ultra_vires
--
Ian JacksonThese opinions are my own.
If I ema
(sending this because I got the release team address wrong)
Ian Jackson writes ("That merged-usr is mandatory is RC"):
> Control: severity -1 serious
>
> In #923091, Guillem (with dpkg maintainer hat on) asks for a
> base-installer option to allow installing bus
ocial
cohesion.
CCing the TC FYI (they have already been involved in merged-usr
debates via #914897) and the release team, in case they have an
opinion. FAOD I am not a maintainer of base-files but AFAICT the
base-files maintainer has not expressed an opinion about severity.
Ian.
--
Ian Jackson
nvolves doing serious violence to the upstream
build system, or perhaps horrific rules file bodges.
Thanks,
Ian.
[1] Implicitly, without using a chroot.
[2] IIRC some people suggested this explicitly in the thread in
d-devel.
--
Ian JacksonThese opinions are my own.
If I emailed y
body with sufficient breadth.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Ping ?
Is the TC engaged in this issue or should I seek another approach ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
ce.
Certainly it is not right that the other project, whose name is being
appropriated, should suffer any inconvenience.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Declare that no-one is allowed the binary package name
/usr/bin/dune other than the C++ library dune-common
or its friends.
* Declare that the ocaml build system should choose a new source
package name and use it henceforth.
I am about to file an RC bug against the `dune' package, blocke
Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
> systems would no longer be supported. In this case someone would have
> to write a unusrmerge program to convert systems with merged-/usr to
> systems with
. That would be really nasty.
The problem comes when a niche optional feature, with wide-ranging
implications, is suddenly promoted to the default, without proper
consultation and without a proper transition plan.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an addre
Julien Cristau writes ("Re: Bug#914897: debootstrap, buster: Please disabled
merged /usr by default"):
> On 11/28/18 2:49 PM, Ian Jackson wrote:
> > This is a special case of a general problem: buster systems with
> > merged-/usr sometimes build packages which are broken
g new lossage we can have a proper
conversation about what the plan ought to be for buster and bullseye.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Tollef Fog Heen writes ("Bug#904302: Whether vendor-specific patch series
should be permitted in the archive"):
> Second draft:
...
> The Committee recognises that there is a need for packages to behave
> differently when built on different distributions, but this should be
> done by using differe
hly what they do right now.
The support for configuration in something like policy-rc.d has a few
design decisions to be made but doesn't seem really difficult. Also
nothing blocks on it. The TC would simply be saying "this would be a
good thing to have".
Ian.
--
Ian JacksonT
ent for you but it is wrong for your
downstreams and users. We should be discouraging such tradeoffs.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Adrian Bunk writes ("Bug#904302: Whether vendor-specific patch series should be
permitted in the archive"):
> On Thu, Oct 04, 2018 at 08:21:07PM +0200, Philip Hands wrote:
> > IMO policy should recomend the use of separate source packages as the
> > prefered solution to the problem that vendor-spe
Philip Hands writes ("Re: Bug#904302: Whether vendor-specific patch series
should be permitted in the archive"):
> IMO policy should recomend the use of separate source packages as the
> prefered solution to the problem that vendor-specific patch series were
> supposed to address.
That would be g
Adrian Bunk writes ("Bug#904302: Whether vendor-specific patch series should be
permitted in the archive"):
> On Wed, Sep 19, 2018 at 02:39:23PM +0200, Philip Hands wrote:
> > The Committee therefore resolves that:
> >
> > 1. Any use of dpkg's vendor-specific patch series feature is a bug for
the possibility that someone would disingenuously argue that a
series.ubuntu file, in a package in Debian, is not "use" of the
feature.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Anonymous writes ("Bug#904302: That's a free software issue!"):
> If Debian want patches it has to support this process with tools. The
> attitude Debian owns all source packages is wrong. Sharing source
> packages among different vendors is more efficient. Different patch
> series may be the best
Philip Hands writes ("Bug#904302: Whether vendor-specific patch series should
be permitted in the archive"):
> Possibly also with something like this?:
>
> Post-Buster this should be implemented in Debian Policy by
> declaring that a package MUST NOT contain a non-default series
>
Stuart Prescott writes ("Bug#904558: What should happen when maintscripts fail
to restart a service"):
> Ian Jackson wrote:
> > When I wrote that, it didn't occur to me that anyone would think that
> > a failure by a postinst script to perform an intended opera
Tollef Fog Heen writes ("Bug#904558: What should happen when maintscripts fail
to restart a service"):
> Ian Jackson:
> > There may be good reasons not to treat daemon startup failure as a
> > postinst failure, but the argument above is not one of them.
>
> I thin
le I'm open to be convinced otherwise, I don't see any benefit
> from postinst (particularly postinst + configure) ever failing.
Frankly I'm disturbed to be reading this, here. See above.
If the postinst fails, then the user has the opportunity to fix the
root cause and rerun dpkg-s
ee that (6) might be needed in some exceptional cases but
normally there is a better way.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
tuation at build-time where possible, but that should be done by
looking at which of the alternative build dependencies is installer,
or whatever, not by checking dpkg-vendor.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
; But it certainly falls under at least one of §6.1.1 and §6.1.3, and not
> §6.1.4.
Obviously I agree with this.
Thanks,
Ian.
[1] I don't read the delegation that way, but for this purpose the
wording of the delegation doesn't matter.
--
Ian JacksonThese opinions are my own.
I
pproaches will be
better still. It just means that vendor series are worse than
changing the source package.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Wouter Verhelst writes ("Re: Next Meeting: Wednesday, May 16th 19:00 UTC
(today) - Currently no topics"):
> On Wed, May 16, 2018 at 08:59:35PM +0200, Margarita Manterola wrote:
> > As David mentioned in IRC and I mentioned in person to the people in
> > Hamburg, it is a bit worrying to not have a
Philip Hands :
> You'll be pleased to note that the original bug in this case has now
> been closed as a result of a newly uploaded package version:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#101
>
> Thanks to all involved for bringing this to a successful resolution,
> at whi
Aleksander Morgado writes ("Re: Bug#877024: modemmanager should ask before
messing with serial ports"):
> Ian, any comment about this 1.8-rc1 version with the filter policies
> implemented?
Thanks for the ping. I haven't had a chance to test it, but if it
behaves as described earlier here then (
s in jessie to the Haskell binaries in
stretch is an undocumented chain of recompilations of packages from
snapshot.d.o. If we let Haskell do that, why are we being so hard on
JavaScript ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
he sense of knowledge or ownership that would
be appropriate for that.
> On Tue, Dec 05, 2017 at 05:36:10PM +, Ian Jackson wrote:
> > One question I have is about this: "several packages now require just
> > systemd-sysv". Can someone refer to some examples, please
bout this: "several packages now require just
systemd-sysv". Can someone refer to some examples, please ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Wouter Verhelst writes ("Re: TC nomination procedure v0"):
> It's a vote that will have effect on the appointment of a person to the
> TC. The constitution specifically wants appointment votes to be public.
> Without wanting to comment on the letter, I think this is contrary to
> the intent.
>
> T
ich contains the single sentence
| it is strange that the package Build-Depends: on itself!?
Lots of language compilers build-depend on themselves so surely there
is more to this.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.or
re all, ultimately, questions of politics: they concern the
balance of competing interests, and the location and scope of power
and control.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Sam Hartman writes ("Re: Let's Stop Getting Torn Apart by Disagreement:
Concerns about the Technical Committee"):
> I am discussing how we handle conflict because I hope we can do a better
> job of helping people feel valued even when we do not agree with their
> technical positions.
You've perh
ou don't like this,
> and I think we need some outside help deciding which of us is right.
> I'm going to give you a bit of time in less I've got it all wrong and
> you're OK with this approach and then I'm going to ask for help."
Ian.
--
Ian Jackson
Sam Hartman writes ("Re: Bug#877024: Modemmanager probing of unknown Devices"):
> I wanted to make you aware of a status update.
> The maintainer who has been doing most of the uploads on modemmanager
> stepped down after receiving my query.
Oh.
> As a matter of process, it's not clear that there
e, in prose, that I
intended to escalate this issue to the TC:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#77
I got no response, so I filed #877024. When I did so, the BTS sent
this mail CC the maintainers:
From: ow...@bugs.debian.org (Debian Bug Tracking System)
To:
ake guidance.
It is mostly if there is an objection about the principle of the
approach that modemmanager should take, or an objection to NMUs, that
a TC decision might be needed.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
That was my thinking.
For upstream: things in "experimental" are not automatically installed
on user systems (well, unless the user has been exceptionally
foolish), and do not automatically propagate to places where they
might be so installed (let alone, be released).
Ian.
--
Ian
ul for me to upload such a thing to experimental so
others can try it too ? Would the Debian modemmanager maintainers
object to that ?
I will do that upload: to DELAYED, picking some suitably cautious
version number, unless I hear to the contrary. (And I'll wait at
least a week for a reply t
t; sufficient. I suspect if someone brought it back to us later we'd
> support such a conclusion from the maintainer.
I hope that that such a supposition could be rebutted - for example,
by examples of misprobing (either predicted by looking at existing
devices, or actually experienced) desp
Aleksander Morgado writes ("Bug#877024: modemmanager should ask before messing
with serial ports"):
> This is part of the discussion we had in the MM mailing list for such
> a solution:
> https://lists.freedesktop.org/archives/modemmanager-devel/2017-September/005917.html
Thanks, this looks const
Aleksander Morgado writes ("Re: Bug#877024: modemmanager should ask before
messing with serial ports"):
> The solution you're suggesting involves changes not only in
> ModemManager, but in the whole stack... I personally don't like that,
> I don't want to ask users "is this a modem" especially whe
Aleksander Morgado writes ("Bug#877024: modemmanager should ask before messing
with serial ports"):
> [Ian Jackson:]
> > Many such modems present as USB serial devices, eg ttyACM or ttyUSB.
> > Consequently, modemmanager has the ability to open serial ports and
>
nance processes to escalate the bug, it is appropriate for me to
use a Debian channel for this.
But I really appreciate you taking an interest.
> An easier thing would be to allow just "dpkg -R
> modemmanager", there should be no other package depending on the
> daemon itself.
T
Keith Packard writes ("Re: Bug#877024: modemmanager should ask before messing
with serial ports"):
> Ian Jackson writes:
> > This has gone far enough. I would like to remind you of Constitution
> > 6.3(5)
>
> Here's what I prefaced my first remark with:
>
Keith Packard writes ("Bug#877024: modemmanager should ask before messing with
serial ports"):
> That requires fixing the package instead of just getting it out of the
> way, a significantly harder thing to manage.
This has gone far enough. I would like to remind you of Constitution
6.3(5)
| T
Keith Packard writes ("Re: Bug#877024: modemmanager should ask before messing
with serial ports"):
> Yeah, I was just thinking that it would be easier to stop installing
> support for modems by default than to actually fix modemmanager to
> behave itself. It's certainly how I work -- apt remove mo
Ansgar Burchardt writes ("Bug#877024: modemmanager should ask before messing
with serial ports"):
> It's not useless. At least not when using UMTS via USB dongles which I
> would guess more people use than ham radio. (Some of these USB dongles
> also emulate network cards and provide a DHCP serv
k that is desirable.
We should also consider whether to backport any of the resulting
changes, or include them in stable updates of some kind.
Thanks for your attention.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
ain fewer hurdles to adoption elsewhere.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Philip Hands writes ("Bug#862051: nodejs (6.11.2~dfsg-1) experimental;
urgency=medium"):
> I guess that one could do something like moving the symlink into another
> -legasy style package, and recomend that from the main package for one
> release to keep upgrades happy. Then drop the recomendation
Jérémy Lal writes ("Bug#862051: nodejs (6.11.2~dfsg-1) experimental;
urgency=medium"):
> Maybe i didn't express myself properly: the idea is to keep /usr/bin/nodejs
> until it's no longer needed - be it other debian packages or other user
> scripts.
Earlier you said only "other Debian packages":
estrictions on nodejs.
I think a natural reading of "Debian's usual backwards-compatibility
arrangements" applied to /usr/bin/nodejs would arguably involve
keeping it only for a realease or two. But in fact, there is no
reason to ever delete it (except for punishment purpose
Tollef Fog Heen writes ("Bug#862051: Allow nodejs to provide /usr/bin/node
(draft resolution)"):
> 1. The CTTE decision from 2012-07-12 in bug #614907 is repealed.
>
> This means Debian's normal policies and practices take over and the
> nodejs package is free to provide /usr/bin/node. The migra
How about this:
1. The CTTE decision in from 2012-07-12 in bug #614907 is repealed.
2. The nodejs package shall be free to provide /usr/bin/node.
Eventually, packages which use node.js will use /usr/bin/node,
and the nodejs-legacy package will become obsolete, and be
removed.
ly needed? They're
> just restating (somewhat imperfectly) Policy and/or normal practice in
> Debian, which presumably come back into effect anyway once the
> 2012-07-12 decision is repealed.
It would be better to simply say "following Debian's existing backward
compatibil
Adam D. Barratt writes ("Bug#857257: Re: Supporting configuration file changes
between versions in unstable/testing"):
> On 2017-03-09 9:41, Pirate Praveen wrote:
> > I request CTTE to declare this bug as not RC.
>
> That's not something that the Technical Committee has a remit to do.
>
> The de
Andreas Tille writes ("About the internal and external view of Blends (Was:
Bug#846002: blends-tasks must be priority:standard and not make a mess out of
tasksel menu)"):
> May be this is the right time to clarify the role of Blends inside
> Debian and I'd like to adjust my probably biased opinio
Sam Hartman writes ("Bug#846002: blends-tasks must be priority:standard and not
make a mess out of tasksel menu"):
> My reading of that is that the consensus of the TC is that the D-I team
> should make this decision.
I can see why Ole is frustrated. I don't think this is a proper
conclusion for
hould explicitly state whether you want this NMU to be DELAYED.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
is.
I suggest that the TC close #850967 NFA, and that the Debian gnupg
maintainers tag #850657 wontfix (and perhaps close it).
I won't promise to stop asking Debian maintainers of other packages to
make this change, when it trips me up.
Ian.
--
Ian JacksonThese opinions are my own.
I
even in upstream parts"):
> On Wed 2017-01-11 12:13:44 -0500, Ian Jackson
> wrote:
> > I think this argument is utterly wrong in principle. It is contrary
> > to the whole point of Debian.
>
> We clearly disagree here, though i think Ian might be overstatin
Sam Hartman writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be
hardcoded even in upstream parts"):
> [some stuff]
Please concentrate on the MIPS binutils bug.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.
are some things I might want to respond
in it but I don't want to distract the TC any further from #850887.
This issue isn't urgent, even though it is quite wide-ranging.
So, I won't press this now and instead I'll wait for a TC member to
pick it up.
Regards,
Ian.
--
Ian
ause it
makes those users' bug reports too hard to deal with.
I think this argument is utterly wrong in principle. It is contrary
to the whole point of Debian.
Thanks for your attention.
Ian.
PS: Please give the MIPS binutils bug priority.
--
Ian JacksonThese opinions are my own.
entation.
I would suggest that the TC should not delay. Delay makes the problem
worse.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
od but perhaps even too long. Anyone who wants anything ommore
complicated can cope with tasksel. Even someone who wants a server
can very likely cope with tasksel.
Bear in mind that every option on this list needs to be read even by
the most inexperienced user. There should be nothing on it t
partitioning is
unavoidable unless you want to make an express-disk-wiper image :-).
Perhaps the right answer is to prefix the tasksel question with a
pre-question, asking the user to choose between
Default desktop install
Choose selection(s) of packages ("tasks")
Then the t
the grasp of their oppressor.
This is all very dramatic language. Of course I know this is "only
Debian" and of course no-one is dying here. But the principles are
the same.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.u
maintainers ?
Ian.
From: Ian Jackson
To: Stefano Zacchiroli
Cc: debian-proj...@lists.debian.org
Subject: Re: Replace the TC power to depose maintainers
Message-ID: <22593.38530.975380.276...@chiark.greenend.org.uk>
Date: Fri, 2 Dec 2016 15:42:58 +
Stefano Zacchiroli writes ("Re: Replace t
y status is upstream.
[1] My point of view of trying to fix Debian's totally nonfunctional
processes for dealing with unwarranted blocking by maintainers, which
is a drum I have been banging for years and years now.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @f
1 - 100 of 1196 matches
Mail list logo
