Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #91502 > unrolled thread

Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

Back to article view | Back to linux.debian.devel

Contents

  Consensus Call:  Do We Want to Require or Recommend DH; comments by 2019-06-16 Sam Hartman <leader@debian.org> - 2019-05-25 19:30 +0200
    Re: Consensus Call:  Do We Want to Require or Recommend DH; comments by 2019-06-16 Vincent Bernat <bernat@debian.org> - 2019-05-26 11:40 +0200
      Re: Consensus Call:  Do We Want to Require or Recommend DH; comments by 2019-06-16 Jonas Smedegaard <jonas@jones.dk> - 2019-05-26 12:10 +0200
        Re: Consensus Call:  Do We Want to Require or Recommend DH; comments by 2019-06-16 Vincent Bernat <bernat@debian.org> - 2019-05-26 19:30 +0200
          Re: Consensus Call:  Do We Want to Require or Recommend DH; comments  by 2019-06-16 Andreas Tille <andreas@an3as.eu> - 2019-05-27 06:30 +0200
            Re: Consensus Call:  Do We Want to Require or Recommend DH; comments by 2019-06-16 Jonas Smedegaard <jonas@jones.dk> - 2019-05-27 08:50 +0200
              Re: Consensus Call:  Do We Want to Require or Recommend DH; comments  by 2019-06-16 Andreas Tille <andreas@an3as.eu> - 2019-05-29 08:00 +0200
            Re: Consensus Call: Do We Want to Require or Recommend DH; comments  by 2019-06-16 Alex Mestiashvili <amestia@rsh2.donotuse.de> - 2019-05-27 14:00 +0200
      Re: Consensus Call:  Do We Want to Require or Recommend DH; comments  by 2019-06-16 Adrian Bunk <bunk@debian.org> - 2019-05-26 21:40 +0200
        Difficult Packaging Practices Sam Hartman <hartmans@debian.org> - 2019-05-26 23:10 +0200
          Re: Difficult Packaging Practices Jérémy Lal <kapouer@melix.org> - 2019-05-27 00:00 +0200
          Re: Difficult Packaging Practices Russ Allbery <rra@debian.org> - 2019-05-27 01:30 +0200
            Re: Difficult Packaging Practices Sam Hartman <hartmans@debian.org> - 2019-05-27 13:40 +0200
          Re: Difficult Packaging Practices Ben Finney <bignose@debian.org> - 2019-05-27 08:20 +0200
            Re: Difficult Packaging Practices Vincent Bernat <bernat@debian.org> - 2019-05-27 09:00 +0200
              Re: Difficult Packaging Practices Paul Wise <pabs@debian.org> - 2019-05-28 03:10 +0200
                Re: Difficult Packaging Practices Vincent Bernat <bernat@debian.org> - 2019-05-28 07:00 +0200
                  Re: Difficult Packaging Practices Vincent Bernat <bernat@debian.org> - 2019-05-28 08:50 +0200
                    RE:Difficult Packaging Practices PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2019-05-28 09:10 +0200
                      Re: Difficult Packaging Practices Vincent Bernat <bernat@debian.org> - 2019-05-28 09:40 +0200
                        Re: Difficult Packaging Practices (OT) Thomas Dettbarn <dettus@dettus.net> - 2019-05-28 09:50 +0200
                          Re: Difficult Packaging Practices (OT) Alex Mestiashvili <amestia@rsh2.donotuse.de> - 2019-05-28 10:20 +0200
                            RE:Difficult Packaging Practices (OT) PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2019-05-28 10:50 +0200
                          Simplified Debianization Process (was: Re: Difficult Packaging  Practices (OT) Mo Zhou <lumin@debian.org> - 2019-05-28 11:10 +0200
            Re: Difficult Packaging Practices Sam Hartman <hartmans@debian.org> - 2019-05-27 14:00 +0200
              Why do we take so long to realise good ideas (Was: Difficult  Packaging Practices) Andreas Tille <andreas@an3as.eu> - 2019-05-29 08:50 +0200
                Re: Why do we take so long to realise good ideas (Was: Difficult  Packaging Practices) Andrey Rahmatullin <wrar@debian.org> - 2019-05-29 09:00 +0200
                  Re: Why do we take so long to realise good ideas (Was: Difficult  Packaging Practices) Raphael Hertzog <hertzog@debian.org> - 2019-05-29 10:40 +0200
                    Re: Why do we take so long to realise good ideas (Was: Difficult  Packaging Practices) Ansgar <ansgar@debian.org> - 2019-05-29 10:50 +0200
                      Re: Why do we take so long to realise good ideas (Was: Difficult  Packaging Practices) Raphael Hertzog <hertzog@debian.org> - 2019-05-29 11:10 +0200
                        paying people for Debian work (Re: Why do we take so long to realise  good ideas (Was: Difficult Packaging Practices)) Holger Levsen <holger@layer-acht.org> - 2019-05-30 23:40 +0200
                          Re: paying people for Debian work (Re: Why do we take so long to  realise good ideas (Was: Difficult Packaging Practices)) Paul Wise <pabs@debian.org> - 2019-06-03 03:30 +0200
                            Re: paying people for Debian work (Re: Why do we take so long to  realise good ideas (Was: Difficult Packaging Practices)) Raphael Hertzog <hertzog@debian.org> - 2019-06-03 11:50 +0200
                              Re: paying people for Debian work (Re: Why do we take so long to  realise good ideas (Was: Difficult Packaging Practices)) Joël Krähemann <jkraehemann@gmail.com> - 2019-06-06 20:50 +0200
                            Re: paying people for Debian work (Re: Why do we take so long to realise good ideas Sam Hartman <hartmans@debian.org> - 2019-06-03 17:00 +0200
                      Re: Why do we take so long to realise good ideas (Was: Difficult  Packaging Practices) Helmut Grohne <helmut@subdivi.de> - 2019-05-31 07:20 +0200
                        Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices) Jonas Smedegaard <jonas@jones.dk> - 2019-05-31 08:30 +0200
                        Re: Why do we take so long to realise good ideas (Was: Difficult  Packaging Practices) Holger Levsen <holger@layer-acht.org> - 2019-05-31 17:40 +0200
                    Re: Why do we take so long to realise good ideas Mo Zhou <lumin@debian.org> - 2019-05-29 11:40 +0200
                      Realizing Good Ideas with Debian Money Sam Hartman <hartmans@debian.org> - 2019-05-29 13:50 +0200
                        Re: Realizing Good Ideas with Debian Money Adrian Bunk <bunk@debian.org> - 2019-05-31 22:40 +0200
                          Re: Realizing Good Ideas with Debian Money Luca Filipozzi <lfilipoz@debian.org> - 2019-05-31 23:10 +0200
                            Re: Realizing Good Ideas with Debian Money Luca Filipozzi <lfilipoz@debian.org> - 2019-06-01 01:00 +0200
                            Re: Realizing Good Ideas with Debian Money Adrian Bunk <bunk@debian.org> - 2019-06-01 01:00 +0200
                            Re: Realizing Good Ideas with Debian Money "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2019-06-01 23:00 +0200
                              Re: Realizing Good Ideas with Debian Money Russ Allbery <rra@debian.org> - 2019-06-02 00:20 +0200
                            Re: Realizing Good Ideas with Debian Money Ben Hutchings <ben@decadent.org.uk> - 2019-06-02 15:50 +0200
                      Re: Why do we take so long to realise good ideas Paul Wise <pabs@debian.org> - 2019-05-30 03:40 +0200
        Re: Consensus Call:  Do We Want to Require or Recommend DH; comments by 2019-06-16 Philip Hands <phil@hands.com> - 2019-05-26 23:20 +0200
          Re: Consensus Call:  Do We Want to Require or Recommend DH; comments  by 2019-06-16 Adrian Bunk <bunk@debian.org> - 2019-05-30 20:50 +0200
        Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16 Sam Hartman <hartmans@debian.org> - 2019-05-27 14:00 +0200
        Re: Consensus Call: Do We Want to Require or Recommend DH; comments  by 2019-06-16 Scott Leggett <scott@sl.id.au> - 2019-05-27 14:50 +0200
        Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16 Russ Allbery <rra@debian.org> - 2019-05-27 20:00 +0200
    Re: Consensus Call:  Do We Want to Require or Recommend DH; comments by 2019-06-16 Scott Kitterman <debian@kitterman.com> - 2019-05-27 07:10 +0200
      Re: Consensus Call:  Do We Want to Require or Recommend DH; comments by 2019-06-16 Sam Hartman <hartmans@debian.org> - 2019-05-27 14:00 +0200
        Re: Consensus Call:  Do We Want to Require or Recommend DH; comments by 2019-06-16 Scott Kitterman <debian@kitterman.com> - 2019-05-27 16:40 +0200
    Re: Consensus Call:  Do We Want to Require or Recommend DH; comments by 2019-06-16 Ian Jackson <ijackson@chiark.greenend.org.uk> - 2019-05-28 17:00 +0200
      Re: Consensus Call:  Do We Want to Require or Recommend DH; comments by 2019-06-16 Sam Hartman <hartmans@debian.org> - 2019-05-28 17:10 +0200
    Re: Consensus Call:  Do We Want to Require or Recommend DH; comments  by 2019-06-16 Bill Allombert <ballombe@debian.org> - 2019-06-17 00:10 +0200
      Re: Consensus Call:  Do We Want to Require or Recommend DH; comments by 2019-06-16 Russ Allbery <rra@debian.org> - 2019-06-17 00:50 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#91540 — Re: Difficult Packaging Practices (OT)

Hello.


This is slightly off-topic, and I have not been on this mailinglist
since this thread started. Nevertheless, I would like to express my
support for changing the packaging practices.

Over the last two weeks, I tried creating ports and packages for my
project "dMagnetic". It was rather easy for the OpenBSD and FreeBSD 
ports system. All that was needed there were some changes to some 
existing files, and my port was ready. FreeBSD was the easiest: 
Sourcecode URL, SHA256 sum and a short description was all that was 
needed. Now it is already part of the offical ports collection.

Debian was quite more complicated, and the documentation on that 
topic was scattered all over the interwebs. Here I had to download
the sources, rename the directories, rename the package, repackage,
change some files, count the number of spaces at the beginning of a
line... I did it, but it is rather frustrating for new developers. 

Please please help them! :)


Thomas Dettbarn

[toc] | [prev] | [next] | [standalone]

#91543 — Re: Difficult Packaging Practices (OT)

On 5/28/19 9:48 AM, Thomas Dettbarn wrote:
> Hello.
> 
> 
> This is slightly off-topic, and I have not been on this mailinglist
> since this thread started. Nevertheless, I would like to express my
> support for changing the packaging practices.
> 
> Over the last two weeks, I tried creating ports and packages for my
> project "dMagnetic". It was rather easy for the OpenBSD and FreeBSD 
> ports system. All that was needed there were some changes to some 
> existing files, and my port was ready. FreeBSD was the easiest: 
> Sourcecode URL, SHA256 sum and a short description was all that was 
> needed. Now it is already part of the offical ports collection.
> 
> Debian was quite more complicated, and the documentation on that 
> topic was scattered all over the interwebs. Here I had to download
> the sources, rename the directories, rename the package, repackage,
> change some files, count the number of spaces at the beginning of a
> line... I did it, but it is rather frustrating for new developers. 
> 
> Please please help them! :)
> 
> 
> Thomas Dettbarn
> 

This thread reminded me the Debian User Repository thread:
 https://lists.debian.org/debian-devel/2019/04/msg00064.html

Such a repository can be a "easy" packaging zone, possibly attracting
more contributing people. Eventually some people will try to improve the
packages and get them into official Debian.

[toc] | [prev] | [next] | [standalone]

#91546 — RE:Difficult Packaging Practices (OT)

> This thread reminded me the Debian User Repository thread:
>  https://lists.debian.org/debian-devel/2019/04/msg00064.html

> Such a repository can be a "easy" packaging zone, possibly attracting
> more contributing people. Eventually some people will try to improve the
> packages and get them into official Debian.

Some upstreams maintain there conda recipes, with these nice badges whcih remind them that it doe not work, or that it work.
It would be great if we could have this in Debian, in order to let the upstream get use to the Debian packaging and let them target our distributions.
so maybe the packaging should be as simple as droping a debian-ci file into the upstream source and our salsa pipeline could start running its pipeline.

Cheers

Frederic

[toc] | [prev] | [next] | [standalone]

#91547 — Simplified Debianization Process (was: Re: Difficult Packaging Practices (OT)

Hi Thomas,

On 2019-05-28 07:48, Thomas Dettbarn wrote:
> Debian was quite more complicated, and the documentation on that 
> topic was scattered all over the interwebs. Here I had to download
> the sources, rename the directories, rename the package, repackage,
> change some files, count the number of spaces at the beginning of a
> line... I did it, but it is rather frustrating for new developers. 
> 
> Please please help them! :)

That complexity comes from various reasons.

There is an on-going project named duprkit[1], which aims to provide
a simplified Debian packaging experience. Specifically, it defines
a "Recipe" format (YAML+HFT), which can be automatically converted
into a Debianized source tree (including downloading the source).
This tool set allows:

  * automatic Recipe guessing (nothing -> Recipe)
  * translating Recipe into debian/ directory (Recipe -> debian/ dir)
  * automatic debian/ directory generation (nothing -> Recipe -> debian/
dir)
  * Recipe -> .deb/.dsc convertion (download, extract, debianize, build)

I plan to beat both dh-make and debmake in the future.
(although you might be interested in them)

However, the problem is, even if this "duprkit" aims at
"Simplification" and "Automization", documentation is still
a problem due to lack of time and energy. The only thing
you can read is the code and some examples[2]. Plus, due
to the same reason y I'm still dragging the next major release
after a significant redesign.

[1] https://github.com/dupr/duprkit
[2] https://github.com/dupr/duprkit/tree/master/examples

[toc] | [prev] | [next] | [standalone]

#91525 — Re: Difficult Packaging Practices

>>>>> "Ben" == Ben Finney <bignose@debian.org> writes:

    Ben> Sam Hartman <hartmans@debian.org> writes:
    >> If you just want to get upstream's idea of their package onto a
    >> system with their release schedule and their recommended
    >> dependency versions, there are better ways than getting a package
    >> into Debian.

    Ben> In the Debian mentors forum (that is, the chat channel, the
    Ben> mailing list, etc.) we make a point of saying: that's fine!

    Ben> Not every package needs to be in Debian, for its users to
    Ben> install that package.

I think I was trying to agree with you.


I'd actually recommend understanding people's pain points for other
approaches and making sure there aren't things we can do to make it
easier.

As an example, Ubuntu makes it easy to add side-loaded channels (ppas).
we don't.

The fast-paced repository discussion from earlier this year is another
example of where we could address a pain point.

Another pain point is people who would like to do the work of making
something stable but who need a fixed set of dependencies; the space
where containers might be a solution.
We as a distribution haven't done a lot there beyond including flatpak
and snap.

--Sam

[toc] | [prev] | [next] | [standalone]

#91574 — Why do we take so long to realise good ideas (Was: Difficult Packaging Practices)

On Mon, May 27, 2019 at 07:54:20AM -0400, Sam Hartman wrote:
> As an example, Ubuntu makes it easy to add side-loaded channels (ppas).
> we don't.

IMHO this touches another burning topic:  Its not that we do not want to
provide some PPA equivalent - its just that we do not realise it.  I do
not remember how many years ago we talked about bikesheds (and
obviously we even found an extremely speaking name). 

I do not want to trigger another PPA-bikeshed thread but may be some
analysis why we need to take so much time to realise good ideas (i.e.
I consider a Debian release another very good idea where we take too
long) and what we can possibly do to shorten that time span.

Kind regards

      Andreas.

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#91576 — Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices)

[Multipart message — attachments visible in raw view] — view raw

On Wed, May 29, 2019 at 08:43:55AM +0200, Andreas Tille wrote:
> IMHO this touches another burning topic:  Its not that we do not want to
> provide some PPA equivalent - its just that we do not realise it.  I do
> not remember how many years ago we talked about bikesheds (and
> obviously we even found an extremely speaking name). 
> 
> I do not want to trigger another PPA-bikeshed thread but may be some
> analysis why we need to take so much time to realise good ideas (i.e.
> I consider a Debian release another very good idea where we take too
> long) and what we can possibly do to shorten that time span.
One of the popular answers to this and some other problems is "nobody sat
down and wrote the code". Not sure what can we do about this class of
reasons.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#91577 — Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices)

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Wed, 29 May 2019, Andrey Rahmatullin wrote:
> One of the popular answers to this and some other problems is "nobody sat
> down and wrote the code". Not sure what can we do about this class of
> reasons.

Use the $300,000 on our bank accounts?

https://lists.debian.org/debian-news/2019/msg00002.html

And I heard of another $300,000 donation from Google (through Thomas Koch)
although I can't find any reference to it.

FWIW, I gave a talk on LTS and the topic of funding Debian work
at the minidebconf in Marseille (30 minutes):
http://meetings-archive.debian.net/pub/debian-meetings/2019/miniconf-marseille/2019-05-25/5_years_lts_funding.webm

My slides are here:
https://wiki.debian.org/DebianEvents/fr/2019/Marseille?action=AttachFile&do=view&target=debian-lts-5-years-of-funding.pdf

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

[toc] | [prev] | [next] | [standalone]

#91578 — Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices)

On Wed, 2019-05-29 at 10:38 +0200, Raphael Hertzog wrote:
> On Wed, 29 May 2019, Andrey Rahmatullin wrote:
> > One of the popular answers to this and some other problems is "nobody sat
> > down and wrote the code". Not sure what can we do about this class of
> > reasons.
> 
> Use the $300,000 on our bank accounts?

I heard that this didn't work out well the last time ("dunc tank"),
though that was before the time I followed Debian development.

Ansgar

[toc] | [prev] | [next] | [standalone]

#91579 — Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices)

On Wed, 29 May 2019, Ansgar wrote:
> On Wed, 2019-05-29 at 10:38 +0200, Raphael Hertzog wrote:
> > On Wed, 29 May 2019, Andrey Rahmatullin wrote:
> > > One of the popular answers to this and some other problems is "nobody sat
> > > down and wrote the code". Not sure what can we do about this class of
> > > reasons.
> > 
> > Use the $300,000 on our bank accounts?
> 
> I heard that this didn't work out well the last time ("dunc tank"),
> though that was before the time I followed Debian development.

Yes, I was there (and mention it briefly in the questions of the talk I
gave) but it's been a long time ago. There are things to learn
from this failed experiment (such as "don't let the DPL decide alone who
gets paid") but there are also many reasons to believe that we are no
longer in the same situation. At that time, the number of persons working
on open source as part of their paid work was rather low and the jealousy
aspect was likely more problematic than it would be today. We have been
getting used to have Debian contributors being paid (such as on LTS) and
we know that with appropriate rules, the social impact of the use of money
is acceptable.

The topic still needs to be approached carefully but I believe that we
should aim to have this discussion and build some framework where we can
leverage money to complete projects and tasks that we find important
but that have not gone forward through volunteer work.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

[toc] | [prev] | [next] | [standalone]

#91626 — paying people for Debian work (Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices))

[Multipart message — attachments visible in raw view] — view raw

On Wed, May 29, 2019 at 11:01:44AM +0200, Raphael Hertzog wrote:
> > > Use the $300,000 on our bank accounts?
> > I heard that this didn't work out well the last time ("dunc tank"),
> > though that was before the time I followed Debian development.
> Yes, I was there (and mention it briefly in the questions of the talk I
> gave) but it's been a long time ago. 

that dunc tank has been 10y ago doesnt really mean things have changed.

> There are things to learn
> from this failed experiment (such as "don't let the DPL decide alone who
> gets paid") but there are also many reasons to believe that we are no
> longer in the same situation.

well, "believe"...

> At that time, the number of persons working
> on open source as part of their paid work was rather low and the jealousy
> aspect was likely more problematic than it would be today. We have been
> getting used to have Debian contributors being paid (such as on LTS) and
> we know that with appropriate rules, the social impact of the use of money
> is acceptable.

I'm not sure this conclusion is true. True, nowadays there are probably
more people being paid to work on free software (but then, also 10y many
people were paid doing that) and true, there's now Debian LTS, which
pays very few Debian people to do work which many Debian people consider
boring.

But there's one significant difference between LTS and dunc tank: dunc
tank was ment as an initiative inside Debian, while LTS is carefully set
up on both sides, in- and outside Debian, and the money part of it is
*completly* handled outside Debian, and I very much like this and I
consider this a main reason why LTS is accepted by the Debian community.

I *believe* things can become ugly very easily if a volunteer projects
decides about salaries and whom to hire and fire, to give two basic
examples.

Also, once motivation has been destroyed, it can be very hard to
impossible to rebuild it. Money can be a huge motivator, and a huge
demotivator as well.

So I don't think LTS has shown that "this can work", as in LTS we have a
very nice benevolent dictator and as such the setup is very different
from what I imagine would be a Debian setup.

I'd much rather have an/more external entity/project/s paying people
doing Debian work. And if that entity is a charity as/under SPI, Debian
could even transfer money to that entity.


-- 
tschau,
	Holger, who is getting paid for free software work, incl. LTS

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[toc] | [prev] | [next] | [standalone]

#91661 — Re: paying people for Debian work (Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices))

On Fri, May 31, 2019 at 5:32 AM Holger Levsen wrote:

> LTS is accepted by the Debian community.

I'm not entirely sure this fully represents the range of feelings
about the LTS efforts.

There are a few things that are possibly concerning:

Freexian is essentially the only available-to-hire provider of
services for Debian LTS, as the Freeside link doesn't lead anywhere
useful. This means that Freexian essentially does not have any
competition in the provision of these services. Individuals or
companies who don't like Freexian's offering do not have any other
choices, short of going to the general Debian consultants list, who
may or may not have the needed skills and would take time to search
through.

https://wiki.debian.org/LTS/Funding

The funding breakdown for the LTS team appears to be 48% Freexian, 31%
volunteer/unknown, 21% other companies. I don't have any data on the
proportion of LTS work done by each of these groups, but I get the
feeling that the majority of LTS uploads are done by Freexian folks.
This means that if Freexian decides to end its provision of services
for Debian LTS, then the level of work done for LTS would go down
significantly. Were this to happen, it would either significantly
damage the image of Debian due to having to end the LTS effort or
require us to do work which we have had a hard time finding volunteers
for in the past.

https://wiki.debian.org/LTS/Team

There is strong coupling between Debian and Freexian in the language
on the Debian LTS pages and the Freexian pages. This is free
advertising for Freexian's LTS services and representing Freexian's
LTS services as "blessed" by Debian or somehow "official", which could
be objected to by other companies who might decide to provide security
support services. It may be prudent to remove or alter the language on
the Debian LTS pages.

https://wiki.debian.org/LTS/Funding

As far as I can tell, the sole communication between the LTS team and
the list of individuals/organisations doing consulting around Debian
is a mail attempting to recruit folks to work for Freexian. As far as
I can tell, there has been no suggestion that
individuals/organisations doing consulting around Debian add
themselves to the list of organisations available to hire to work on
LTS. This means that the individuals/organisations doing consulting
around Debian miss out on the opportunities to work on LTS.

https://www.debian.org/consultants/
https://lists.debian.org/msgid-search/20160502094142.GA19672@home.ouaza.com

Freexian doesn't fund LTS contributors who are not DDs/DMs: this
eliminates skilled developers from outside Debian who could contribute
to LTS via Freexian and eventually work on Debian more generally. This
seems to have prevented at least one former Debian member who was
interested in Freexian's offer from contributing. It might also make
LTS funding seem like a reward for Debian insiders.

https://www.freexian.com/services/debian-lts-details.html#join
https://lists.debian.org/msgid-search/CALQVJpbWcpvr82JRmxmCWUGA_Mn7woT425-QfTVPqPB7aa7A7Q@mail.gmail.com

The structure of using existing Debian contributors and funnelling
most of the funding to them through one company reduces incentives for
companies wanting security support to direct their employees to work
on Debian security support. This means that our contributor base stays
more static and reduces the chance that new folks will join us. An
alternate model where each of the companies currently sponsoring
Freexian LTS services instead directed their employees to spend some
hours on Debian security support seems more likely to lead to new
people getting involved.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#91665 — Re: paying people for Debian work (Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices))

Hi,

On Mon, 03 Jun 2019, Paul Wise wrote:
> There are a few things that are possibly concerning:

Thanks for sharing those. Let me answer them.

> Freexian is essentially the only available-to-hire provider of
> services for Debian LTS, as the Freeside link doesn't lead anywhere
> useful. This means that Freexian essentially does not have any
> competition in the provision of these services. Individuals or
> companies who don't like Freexian's offering do not have any other
> choices, short of going to the general Debian consultants list, who
> may or may not have the needed skills and would take time to search
> through.

That's correct. But the agreement was always that the relationship
was non-exclusive from the Debian point of view. I.e. someone else
could setup "Debian LTS by XXXX" and Debian would not endorse one more
than the other.

> The funding breakdown for the LTS team appears to be 48% Freexian, 31%
> volunteer/unknown, 21% other companies. I don't have any data on the
> proportion of LTS work done by each of these groups, but I get the
> feeling that the majority of LTS uploads are done by Freexian folks.

That breakdown does not reflect reality at all. Indeed the vast majority
of the work is done by contributors paid by Freexian.

> This means that if Freexian decides to end its provision of services
> for Debian LTS, then the level of work done for LTS would go down
> significantly. Were this to happen, it would either significantly
> damage the image of Debian due to having to end the LTS effort or
> require us to do work which we have had a hard time finding volunteers
> for in the past.

That's correct. However, there's no reason for this to happen. I do care
about Debian and the uninteresting paper work that I have to do to keep
the Freexian service running is paid for.

That said there are multiple ways to avoid this:
- Debian organizes this by itself (it's possible, the criteria I use
  to allocate work hours to contributors are relatively transparent)
- Debian defines clear rules for external services leveraging the Debian
  name to fund Debian-related work and encourages to have more of those

> There is strong coupling between Debian and Freexian in the language
> on the Debian LTS pages and the Freexian pages. This is free
> advertising for Freexian's LTS services and representing Freexian's
> LTS services as "blessed" by Debian or somehow "official", which could
> be objected to by other companies who might decide to provide security
> support services. It may be prudent to remove or alter the language on
> the Debian LTS pages.

I don't see the need to act pro-actively here. The current description
is a fair representation of the reality. It might not be the ideal
situation that we want for Debian but then again I suggest we work on
defining criteria for all services/companies that would aim to have the
same kind of "Debian blessing".

> LTS. This means that the individuals/organisations doing consulting
> around Debian miss out on the opportunities to work on LTS.

This is not true. Many have joined the set of contributors paid by
Freexian. Some of the contributors are working as individuals
(freelancers) and others as members of an organization that invoices
Freexian (Codethink for Ben Hutchings for example).

You are saying that they don't have an opportunity to work on LTS
outside of Freexian. That's also not true but the easy path is
definitely to go through Freexian who has an established situation
and whose join rules are open-enough to avoid the need to create
a competitor.

> Freexian doesn't fund LTS contributors who are not DDs/DMs: this
> eliminates skilled developers from outside Debian who could contribute
> to LTS via Freexian and eventually work on Debian more generally. This
> seems to have prevented at least one former Debian member who was
> interested in Freexian's offer from contributing. It might also make
> LTS funding seem like a reward for Debian insiders.

Or it creates an incentive to contribute to Debian to be able to join
the set of paid developers.

I'm sorry that you see this as a problem. This job is about contributing
to Debian and we need persons who already know how to do this. Contrary to
GSOC and others, our purpose is not to train outsiders to contribute to
Debian.

> The structure of using existing Debian contributors and funnelling
> most of the funding to them through one company reduces incentives for
> companies wanting security support to direct their employees to work
> on Debian security support. This means that our contributor base stays
> more static and reduces the chance that new folks will join us. An
> alternate model where each of the companies currently sponsoring
> Freexian LTS services instead directed their employees to spend some
> hours on Debian security support seems more likely to lead to new
> people getting involved.

I certainly agree that the efficiency of the contributors paid by Freexian
means that companies that used to allocate time to their employees to
contribute to long term security support has disappeared. There are
exceptions though, for instance credativ with their PostgreSQL support.

That said, the net result is a better service to our users. The model
where each company allocates a few hours per week to a few employees
was not reliable and not reactive enough. They would typically only care
about the packages that they use and would leave huge gap in the support
both in terms of packages covered and in terms of when the updates is made
available to users.

I also don't think that this matter of fact changes anything on chances
to have new folks in Debian. Either you are interested by Debian or not,
the fact that your boss told you to work on something related to Debian
doesn't change much. YMMV.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

[toc] | [prev] | [next] | [standalone]

#91749 — Re: paying people for Debian work (Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices))

Hi,

Why to support additional fragmentation?

My opinion is debian was left behind regarding infrastructure. I do
packaging for
various distributions.

Honestly, I am running debian. But you could provide continues integration for
different architectures, not only i386 and amd64.

Extend access to porter machines for debian maintainers. Make the request
easier and faster. Especially for more exotic flavors like kfreebsd and hurd.

I caught me different times setting up some VM, only to check why a test
was failing on arch X and not on Y.

Best regards,
Joël

On Mon, Jun 3, 2019 at 11:43 AM Raphael Hertzog <hertzog@debian.org> wrote:
>
> Hi,
>
> On Mon, 03 Jun 2019, Paul Wise wrote:
> > There are a few things that are possibly concerning:
>
> Thanks for sharing those. Let me answer them.
>
> > Freexian is essentially the only available-to-hire provider of
> > services for Debian LTS, as the Freeside link doesn't lead anywhere
> > useful. This means that Freexian essentially does not have any
> > competition in the provision of these services. Individuals or
> > companies who don't like Freexian's offering do not have any other
> > choices, short of going to the general Debian consultants list, who
> > may or may not have the needed skills and would take time to search
> > through.
>
> That's correct. But the agreement was always that the relationship
> was non-exclusive from the Debian point of view. I.e. someone else
> could setup "Debian LTS by XXXX" and Debian would not endorse one more
> than the other.
>
> > The funding breakdown for the LTS team appears to be 48% Freexian, 31%
> > volunteer/unknown, 21% other companies. I don't have any data on the
> > proportion of LTS work done by each of these groups, but I get the
> > feeling that the majority of LTS uploads are done by Freexian folks.
>
> That breakdown does not reflect reality at all. Indeed the vast majority
> of the work is done by contributors paid by Freexian.
>
> > This means that if Freexian decides to end its provision of services
> > for Debian LTS, then the level of work done for LTS would go down
> > significantly. Were this to happen, it would either significantly
> > damage the image of Debian due to having to end the LTS effort or
> > require us to do work which we have had a hard time finding volunteers
> > for in the past.
>
> That's correct. However, there's no reason for this to happen. I do care
> about Debian and the uninteresting paper work that I have to do to keep
> the Freexian service running is paid for.
>
> That said there are multiple ways to avoid this:
> - Debian organizes this by itself (it's possible, the criteria I use
>   to allocate work hours to contributors are relatively transparent)
> - Debian defines clear rules for external services leveraging the Debian
>   name to fund Debian-related work and encourages to have more of those
>
> > There is strong coupling between Debian and Freexian in the language
> > on the Debian LTS pages and the Freexian pages. This is free
> > advertising for Freexian's LTS services and representing Freexian's
> > LTS services as "blessed" by Debian or somehow "official", which could
> > be objected to by other companies who might decide to provide security
> > support services. It may be prudent to remove or alter the language on
> > the Debian LTS pages.
>
> I don't see the need to act pro-actively here. The current description
> is a fair representation of the reality. It might not be the ideal
> situation that we want for Debian but then again I suggest we work on
> defining criteria for all services/companies that would aim to have the
> same kind of "Debian blessing".
>
> > LTS. This means that the individuals/organisations doing consulting
> > around Debian miss out on the opportunities to work on LTS.
>
> This is not true. Many have joined the set of contributors paid by
> Freexian. Some of the contributors are working as individuals
> (freelancers) and others as members of an organization that invoices
> Freexian (Codethink for Ben Hutchings for example).
>
> You are saying that they don't have an opportunity to work on LTS
> outside of Freexian. That's also not true but the easy path is
> definitely to go through Freexian who has an established situation
> and whose join rules are open-enough to avoid the need to create
> a competitor.
>
> > Freexian doesn't fund LTS contributors who are not DDs/DMs: this
> > eliminates skilled developers from outside Debian who could contribute
> > to LTS via Freexian and eventually work on Debian more generally. This
> > seems to have prevented at least one former Debian member who was
> > interested in Freexian's offer from contributing. It might also make
> > LTS funding seem like a reward for Debian insiders.
>
> Or it creates an incentive to contribute to Debian to be able to join
> the set of paid developers.
>
> I'm sorry that you see this as a problem. This job is about contributing
> to Debian and we need persons who already know how to do this. Contrary to
> GSOC and others, our purpose is not to train outsiders to contribute to
> Debian.
>
> > The structure of using existing Debian contributors and funnelling
> > most of the funding to them through one company reduces incentives for
> > companies wanting security support to direct their employees to work
> > on Debian security support. This means that our contributor base stays
> > more static and reduces the chance that new folks will join us. An
> > alternate model where each of the companies currently sponsoring
> > Freexian LTS services instead directed their employees to spend some
> > hours on Debian security support seems more likely to lead to new
> > people getting involved.
>
> I certainly agree that the efficiency of the contributors paid by Freexian
> means that companies that used to allocate time to their employees to
> contribute to long term security support has disappeared. There are
> exceptions though, for instance credativ with their PostgreSQL support.
>
> That said, the net result is a better service to our users. The model
> where each company allocates a few hours per week to a few employees
> was not reliable and not reactive enough. They would typically only care
> about the packages that they use and would leave huge gap in the support
> both in terms of packages covered and in terms of when the updates is made
> available to users.
>
> I also don't think that this matter of fact changes anything on chances
> to have new folks in Debian. Either you are interested by Debian or not,
> the fact that your boss told you to work on something related to Debian
> doesn't change much. YMMV.
>
> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: https://www.freexian.com/services/debian-lts.html
> Learn to master Debian: https://debian-handbook.info/get/
>

[toc] | [prev] | [next] | [standalone]

#91677 — Re: paying people for Debian work (Re: Why do we take so long to realise good ideas

>>>>> "Paul" == Paul Wise <pabs@debian.org> writes:

    Paul> On Fri, May 31, 2019 at 5:32 AM Holger Levsen wrote:
    >> LTS is accepted by the Debian community.

    Paul> I'm not entirely sure this fully represents the range of feelings
    Paul> about the LTS efforts.

    Paul> There are a few things that are possibly concerning:

    Paul> This means that if Freexian decides to end its provision of services
    Paul> for Debian LTS, then the level of work done for LTS would go down
    Paul> significantly. Were this to happen, it would either significantly
    Paul> damage the image of Debian due to having to end the LTS effort or
    Paul> require us to do work which we have had a hard time finding volunteers
    Paul> for in the past.

If Freexian were to end its LTS effort because the funding disappeared,
then I do not think Debian's image would be significantly damaged by
ending LTS.
We've made it clear that we're doing this because people are funding it.
If they stop and are not replaced with people doing the work, then
market demand has disappeared.

If Freexian stopped their LTS effort but people were still interested in
funding LTS, I suspect we could find someone else willing to handle the
administrative aspects of it.

    Paul> https://wiki.debian.org/LTS/Team

    Paul> There is strong coupling between Debian and Freexian in the language
    Paul> on the Debian LTS pages and the Freexian pages. This is free
    Paul> advertising for Freexian's LTS services and representing Freexian's
    Paul> LTS services as "blessed" by Debian or somehow "official", which could
    Paul> be objected to by other companies who might decide to provide security
    Paul> support services. It may be prudent to remove or alter the language on
    Paul> the Debian LTS pages.

I actually think it's important for us as a project to endorce or
support people doing great work in our communities.
That's something we can do that significantly increases user confidence
and makes it easier for people to partner with us.

If we get the objections you're talking about, let's find a way to
figure out whether we should be blessing or making those other companies
official too.

I've seen a number of discussions over the years about partnering with
people stall because we wanted to establish a bunch of rules ahead of
time.
I do think it's important that we respond to objections from people who
want to be included and are not.  I think the best response will be to
work with those organizations and figure out how they can be included
too.

Yes, if we get a bunch of different organizations jumping up and down to
work on LTS, we'll have to figure out rules for inclusion.  It seems
that whatever those rules are, Freexian (today) would be one of the
official partners.

So, I think both our users and the free software community are best
served by being honest that we are working closely with Freexian.

    Paul> https://wiki.debian.org/LTS/Funding

    Paul> As far as I can tell, the sole communication between the LTS team and
    Paul> the list of individuals/organisations doing consulting around Debian
    Paul> is a mail attempting to recruit folks to work for Freexian. As far as
    Paul> I can tell, there has been no suggestion that
    Paul> individuals/organisations doing consulting around Debian add
    Paul> themselves to the list of organisations available to hire to work on
    Paul> LTS. This means that the individuals/organisations doing consulting
    Paul> around Debian miss out on the opportunities to work on LTS.

If we get feedback from people who would like to work on LTS but who
don't think the current structure works for them, we should definitely
look into that.

    Paul> https://www.debian.org/consultants/
    Paul> https://lists.debian.org/msgid-search/20160502094142.GA19672@home.ouaza.com

    Paul> Freexian doesn't fund LTS contributors who are not DDs/DMs: this
    Paul> eliminates skilled developers from outside Debian who could contribute
    Paul> to LTS via Freexian and eventually work on Debian more generally. This
    Paul> seems to have prevented at least one former Debian member who was
    Paul> interested in Freexian's offer from contributing. It might also make
    Paul> LTS funding seem like a reward for Debian insiders.

The difference between reward and job qualification small here.
Or put another way, if doing a bunch of hard work to learn about Debian
packaging and contributing to our community opens up opportunities for
our members and maintainers, that sounds great to me.

[toc] | [prev] | [next] | [standalone]

#91629 — Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices)

On Wed, May 29, 2019 at 10:46:48AM +0200, Ansgar wrote:
> On Wed, 2019-05-29 at 10:38 +0200, Raphael Hertzog wrote:
> > Use the $300,000 on our bank accounts?
> 
> I heard that this didn't work out well the last time ("dunc tank"),
> though that was before the time I followed Debian development.

I tend to concur with Raphael and Holger here. We've learned a few
lessons, but that doesn't mean it cannot work. Indeed, I argue that "we"
are paying developers now and you just didn't notice.

Freexian was already mentioned. But the Linux Foundation is also paying
people to make Debian reproducible. They're putting a similar amount of
money into Debian.

While Canonical maintains Ubuntu, they also pay a number of people who
work on Debian directly and often times push their work into Debian
first. I think we can honestly say that Debian wouldn't be where it is
today without Canonical's support in a positive sense.

A number of people report their activities on planet.d.o and some
disclose which parts of their work are being paid. It turns out that
some fraction of maintenance cost is performed on company time.

What all of these have in common is that it's some external (to Debian)
entity that decides which work ends up being done and that it is the
business of that external entity to source the relevant money. The
decision who is being paid is externalized from the Debian project and
that is a quite strong difference to dunc tank.

So if someone were to run a "Fix problems in Debian" company and were
able to source money for doing so, I think that'd actually work. I'm
less convinced that we can use Debian money for this in any way. But we
can still tell people: If you want to improve X in Debian, consider
donating to Y.

In a sense, I'm arguing that this money business should be
decentralized. And it already is.

Helmut

[toc] | [prev] | [next] | [standalone]

#91630 — Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices)

[Multipart message — attachments visible in raw view] — view raw

Quoting Helmut Grohne (2019-05-31 07:17:07)
> On Wed, May 29, 2019 at 10:46:48AM +0200, Ansgar wrote:
> > On Wed, 2019-05-29 at 10:38 +0200, Raphael Hertzog wrote:
> > > Use the $300,000 on our bank accounts?
> > 
> > I heard that this didn't work out well the last time ("dunc tank"), 
> > though that was before the time I followed Debian development.
> 
> I tend to concur with Raphael and Holger here. We've learned a few 
> lessons, but that doesn't mean it cannot work. Indeed, I argue that 
> "we" are paying developers now and you just didn't notice.
> 
> Freexian was already mentioned. But the Linux Foundation is also 
> paying people to make Debian reproducible. They're putting a similar 
> amount of money into Debian.
> 
> While Canonical maintains Ubuntu, they also pay a number of people who 
> work on Debian directly and often times push their work into Debian 
> first. I think we can honestly say that Debian wouldn't be where it is 
> today without Canonical's support in a positive sense.
> 
> A number of people report their activities on planet.d.o and some 
> disclose which parts of their work are being paid. It turns out that 
> some fraction of maintenance cost is performed on company time.
> 
> What all of these have in common is that it's some external (to 
> Debian) entity that decides which work ends up being done and that it 
> is the business of that external entity to source the relevant money. 
> The decision who is being paid is externalized from the Debian project 
> and that is a quite strong difference to dunc tank.
> 
> So if someone were to run a "Fix problems in Debian" company and were 
> able to source money for doing so, I think that'd actually work. I'm 
> less convinced that we can use Debian money for this in any way. But 
> we can still tell people: If you want to improve X in Debian, consider 
> donating to Y.
> 
> In a sense, I'm arguing that this money business should be 
> decentralized. And it already is.

There is a big difference between "Debian people get paid" and "Debian 
pays Debian people".  The former was always the case, the latter is 
problematic.

Debian is a community (involving participants some doing business).

Debian is not a business, and should not become a business!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#91632 — Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices)

[Multipart message — attachments visible in raw view] — view raw

hi,

just commenting on two bits now:

On Fri, May 31, 2019 at 07:17:07AM +0200, Helmut Grohne wrote:
> On Wed, May 29, 2019 at 10:46:48AM +0200, Ansgar wrote:
> > On Wed, 2019-05-29 at 10:38 +0200, Raphael Hertzog wrote:
> > > Use the $300,000 on our bank accounts?
> > I heard that this didn't work out well the last time ("dunc tank"),
> > though that was before the time I followed Debian development.
> I tend to concur with Raphael and Holger here. 

I think you misunderstood me, in some aspects of this discussion I very much
disagree with Raphael, while at some others I agree with him very much.
Or maybe you haven't ;)

in short: I think Debian should stay a project of volunteer work(ers) and
should not have paid staff. I also think that more people should be paid
by outside entities to work on Debian. And that more people should work
completly voluntarily on Debian!

> [...] But the Linux Foundation is also paying
> people to make Debian reproducible.

"has paid" is correct, nowadays we work under SFC's umbrella, see
https://reproducible-builds.org/news/2018/11/08/reproducible-builds-joins-software-freedom-concervancy/


-- 
tschau,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[toc] | [prev] | [next] | [standalone]

#91582 — Re: Why do we take so long to realise good ideas

Hi,

On 2019-05-29 08:38, Raphael Hertzog wrote:
> Use the $300,000 on our bank accounts?

I totally support the idea that we should find more valuable usage
of our fund. For example, if developers don't have enough time or
don't want to do something difficult, we could hire somebody else
to fix them.

For example, many years ago I proposed that we could hire some
web developers to rewrite our homepage, to make it more good-looking
(Generally I don't care about superficial stuff but our homepage
is really old enough. Look at Gentoo's homepage and compare it with
the ancient version.)

[toc] | [prev] | [next] | [standalone]

#91589 — Realizing Good Ideas with Debian Money

[moving a discussion from -devel to -project where it belongs]

>>>>> "Mo" == Mo Zhou <lumin@debian.org> writes:

    Mo> Hi,
    Mo> On 2019-05-29 08:38, Raphael Hertzog wrote:
    >> Use the $300,000 on our bank accounts?

So, there were two $300k donations in the last year.
One of these was earmarked for a DSA equipment upgrade.
DSA has a couple of options to pursue, but it's possible they may
actually spend $400k on an equipment refresh.

$200k doesn't really go that far in terms of big infrastructure projects
like bikeshed or similar.

I'm looking for someone who would be willing to guide a discussion of
the Money issues Martin brought up in his campaign.  I don't have time
to guide that effor myself.  Real thought needs to be put into it; it
will be at least as much work as the discussions I'm leading on
packaging practices and git if done correctly.

However it could be very valuable for the project.

--Sam

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.devel

csiph-web