Re: Proposition: Simlify the Installation

[Andy Simpkins]

There has been a lot of descension over the past couple of weeks about 
DI and what it could do to be better.


I think it is important that I join that debate with a couple of 
requirements for any replacement / enhancement:



(1)  Must work on all architectures supported by Debian
(2)  Must work on all platforms supported by Debian

This (1&2) means that DI must provide a UI on any machine that can run 
Debian.
It must attempt to discover what interface the user has chosen to use 
during the installation.  This could be a keyboard, mouse, and screen, 
equally it could be a serial device (UART, USB, Ethernet etc)

There may be any number of these possible interfaces and any combination

DI must also attempt to detect all of these devices, and configure it 
correctly - Some of these devices (laptop screens for example) may or 
may not correctly report their "console modes". DI may also have to 
probe around in order to configure the display back light and turn it 
on...  there may be several of these as well.  DI must determine which 
controller is associated with the display.


Of cause it also means that we must be able to install from various 
different boot media, support different network and storage methods 
(some of which may need non-free firmware/drivers to work correctly)
DI must work with different boot processes such as BIOS / EFI and the 
different and poor implementations that exist on different machines.



(3) Must be accessible

What do you mean you can't read English?  What do you mean your language 
doesn't use a 'Roman based alphabet', read top left to bottom right 
etc.  DI must still work...
Blind? DI must support audio and TTS or brail 'screens' - this means we 
need to be very careful of layout, windowing, pop-ups etc.
Sight problems? Large font sizes, high contrast colour schemes 
(different colours for different users)
Other conditions? Typically these have a specialist interface for the 
user, but these *normally* present (or consume) the same low level 
interface to the compute system - meaning that DI doesn't need to do 
anything special


Accessibility issues may limit the number of interfaces that we *can* 
present a UI in a suitable format to the user



(4) Configurable

We must also remember that Debian is open to all, DI may well be the 
first interaction that the user has with Debian, that user may equally 
well be an 'old hand'.
This installation may be for a desktop, a server, a deeply embedded 
device, a mobile device, a VM, the list goes on...

This may be a local or a remote install.
What about automated installations?
What about distribute then configure on first run?  (AKA OEM 
installations - with or without a recovery 'partition')?



DI may not be able to do all of these things, it may not do all of them 
well at the movement.  If, however, an overhaul of DI is to happen then 
we should start by deciding what it must be able to do BEFORE deciding 
on how to go about this.  And for me that also means that the above 
points MUST be demonstrable in any prototype / first offering because 
experience has shown me that unless it is all baked in from the 
beginning such features are often impossible to add later.



/Andy




On 24/06/2019 06:15, Marc Haber wrote:

On Sun, 23 Jun 2019 23:10:29 +0200, patrick.dre...@gmx.net wrote:

Proposition: Simlify the Installation. Dosn't have 2 Installation options.
..., Graphical Installation.

Rebuttal: I work with Debian every day, and I have not seen the
graphical installer in a decade.

Not everything that works for your should be default or even the only
option.


With kind Greetings!

Ebenso.

Grüße
Marc

Re: Survey: git packaging practices / repository format

[Ian Jackson]

Theodore Ts'o writes ("Re: Survey: git packaging practices / repository 
format"):
> On Fri, Jun 21, 2019 at 05:59:52PM +0100, Ian Jackson wrote:
> > How do you update to a new upstream version while preserving your
> > delta queue ?  Just git merge with an upstream seems like it might
> > work sometimes but at some point the patches will need to be
> > refreshed...
> 
> Well, I'm cheating a bit, since I *am* upstream for the package in
> question.  In that case, or in the case of people who can follow an
> "upstream first" policy, when you sync up with upstream, by definition
> you can just completely empty debian/patches.

Right.  OK, thanks.

(FYI, you may wish to consider using `dgit quilt-fixup' to generate
the d/patches.  It will commit them to git.  IDK if that is what you
want, and it may not work every time depending what you do to your
history and your tree, but it may save you a bit of typing.)

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.

Re: Realizing Good Ideas with Debian Money

[Thomas Goirand]

On 6/2/19 3:39 PM, Ben Hutchings wrote:
> On Fri, 2019-05-31 at 21:04 +, Luca Filipozzi wrote:
> [...]
>> However, without an HPE donation or discount, we are much more likely to
>> follow a less expensive approach: pairs of 2U servers with local
>> storage, etc. Still not cheap but not multiples of 100k.
>>
>> If a hardware vendor happens to offer a discounts, then we can stretch
>> the dollars further.
> [...]
> 
> As I understand it, list prices for "enterprise" hardware are set with
> the assumption that customers will negotiate a 50% or higher discount.
> If that's right, we should expect and ask for discounts, regardless of
> whether the vendor is interested in being a sponsor.
> 
> Ben.
> 

Oh, Ben... You don't know how much that's truth.

We got had a vendor (that I will not name) to lower his quote some N
amount of network cards from 13k to 5k, just because we told him we
would buy more and that we felt it was too expensive (sorry, I don't
think my employer would be happy if I was disclosing more details of who
and what...).

So very much, when purchasing hardware, negotiating is mandatory. Asking
2 vendors at once, comparing, let them know one has quoted for less, is
also super important. This is secret to no-one doing hardware purchase.

Cheers,

Thomas Goirand (zigo)

Content Rating System in Debian

[Bagas Sanjaya]

Hello Debian Developers,

Debian provides more than 51000 packages. From those packages, some are 
appropriate for every ages, and some others are
only for specific age groups for some reasons.

In order to inform to users, especially parents, about potentially 
objectionable content in Debian packages, Content
Rating System (CRS) can be deployed to Debian. With CRS, users can choose to 
install packages that is rated for their
age. In some cases, CRS also filter or block certain contents in certain 
jurisdictions when legally required.

As in Google Play, Debian CRS is based on official ratings from International 
Age Rating Coalition (IARC).

Pros:
- Users, especially parents, can install packages suitable for their age. In 
case of parents, this apply to their
sons/daughters.
- For users in some jurisdiction, they can only install packages that is legal 
in their jurisdiction. For example, Debian
users in USA can only install US version of GnuPG, but in outside USA, users 
can install international version of GnuPG
instead.

Cons:
- Since there are more than 51000 packages currently in Debian, rating review 
for those existing packages and new
packages can take long time, depending on complexity of packages that are 
reviewed.
- Current Debian system need to be overhauled (for example, when creating users 
with adduser, sysadmins need to input
date of birth of their users) in order to make CRS work in Debian.
- Not all programs/packages is suitable for rating review, especially 
command-line programs.

If CRS will be implemented in Debian, I proposed following packaging workflow, 
based on Google Play:
- Maintainers that is about to package a program, will notify to the upstream 
whether he/she would take a rating
questionnaire or not. If he/she didn't take the questionnaire, the resulting 
package will be categorized as Unrated.
- The upstream fill rating questionnaire and send it to IARC.
- IARC calculates rating for upstream's program and send rating certificate 
back to upstream. If upstream don't agree
with rating assigned to the program, he/she can file appeal using link in the 
certificate email.
- Upstream contact maintainer about rating of the program that he/she get.
- Maintainer then do packaging as usual and add rating for the package, 
possibly to control file.

Based on above, what are your opinions/thoughts/positions about Content Rating 
System in Debian?

Regards, Bagas

Re: Content Rating System in Debian

[Russ Allbery]

Bagas Sanjaya  writes:

> Based on above, what are your opinions/thoughts/positions about Content
> Rating System in Debian?

It sounds like a whole ton of work to get a useful amount of coverage (not
to mention bothering upstreams with questionnaires that I suspect many of
them would find irritating -- I certainly would with my upstream hat on),
and I'm not clear on the benefit.  Do you have some reason to believe that
this is a common request by users of Debian?  If so, could you share with
us why you believe that?

Debian already has a couple of voluntary labeling mechanisms that, while
not precisely relevant to this, are at least adjacent: debtags for general
package tagging (see the junior tag root, for instance, and name-based
labeling of packages with potentially offensive content per

https://www.debian.org/doc/debian-policy/ch-binary.html#packages-with-potentially-offensive-content

Both of those are nowhere near as comprehensive as CRS, of course, but
it's not clear to me that something as comprehensive as CRS has enough
demand to be worth the effort, and there's obviously a maintenance burden
incurred by using it.

It's probably worth noting, though, that if any group felt strongly enough
about CRS to do the work, I don't see any obvious reason why debtags
couldn't handle a set of CRS tags, which has the huge advantage of not
requiring any work by the package maintainer and instead shifting the
burden to the people who care about CRS.

-- 
Russ Allbery (r...@debian.org)   

getting rid of "testing"

[Ansgar]

Hi,

what do people think about getting rid of current suite names ("stable",
"testing", "unstable") for most purposes?  We already recommend using
codenames instead as those don't change their meaning when a new release
happens.

Related to that I would like to be able to write something like

  deb http://deb.debian.org/debian debian11 main
  deb http://security.debian.org/debian-security debian11-security main

in sources.list as codenames confuse people.

Ubuntu already has no suite names, only codenames, but having to map
"Ubuntu 18.04" to "bionic" instead of just writing the version in
sources.list is annoying (I always have to look up the codename to be
sure as I don't use Ubuntu that much).

Ansgar

Re: Re: Content Rating System in Debian

[Bagas Sanjaya]

Russ Allbery:

It sounds like a whole ton of work to get a useful amount of coverage (not
to mention bothering upstreams with questionnaires that I suspect many of
them would find irritating -- I certainly would with my upstream hat on),
and I'm not clear on the benefit.  Do you have some reason to believe that
this is a common request by users of Debian?  If so, could you share with
us why you believe that?

I'm discussing about CRS inspired from Google Play.

A case study of implementing CRS is when parents which have Debian system 
installed on their computer wants to make sure
that any programs installed there are appropriate for all family users there. Also we 
have "Self-Censoring" campaign
which encouraging users to filter contents suitable for their age. 
"Self-Censoring" originates from TV programs, but it
can also be applied to computer programs and applications (especially games) as 
well. Regardless, CRS is good not only
to Debian, but also to end-user in longterm, although it is hard to implement 
and have some maintenance burden.

Re: getting rid of "testing"

[Andrey Rahmatullin]

On Tue, Jun 25, 2019 at 08:08:22AM +0200, Ansgar wrote:
> Hi,
> 
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes?  We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
Are you supposed to change the code name manually if you want to stay on
testing after a release happens?

> Related to that I would like to be able to write something like
> 
>   deb http://deb.debian.org/debian debian11 main
>   deb http://security.debian.org/debian-security debian11-security main
> 
> in sources.list as codenames confuse people.
Yes please.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: getting rid of "testing"

[Bagas Sanjaya]

what do people think about getting rid of current suite names ("stable",
"testing", "unstable") for most purposes?  We already recommend using
codenames instead as those don't change their meaning when a new release
happens.


Hi Ansgar,

Regarding suite names (stable, testing, and unstable), there are for 
convenience if you rather just want to stick to
particular distribution. If suite names are removed, you have to update 
sources.list whenever a new release is made
in order to keep up to date to your chosen suite. If you e.g. track buster 
(which at the time of writing is in testing)
instead of testing, you are tracking buster until EOL.

PS: I'm not Debian User or Developer, so my opinion can be misleading.

Regards, Bagas