Bits from /me: Difficulties in Deep Learning Framework Packaging

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Bits from /me: Difficulties in Deep Learning Framework Packaging

Mo Zhou
Hi people,

This message is neither a good news, nor asking for help. I'm writing
to share some of my points about Deep Learning Framework packaging,
after a re-evaluation of the status of TensorFlow's latest build
systems. My thoughts are concluded from failures instead of success.
That said, they should be helpful to future maintainers who'd like to
maintain similar packages[1]. And you would probably find some of my
root initiatives for DUPR[2] or SIMDebian[6] in the points.

In Debian's context, maintainers have to face three obstacles:

1. License. Unfortunately the de facto dominating performance library is
cuDNN[3]. I'd say no serious user[4] would use a D-L framework without
cuDNN or TPU[5] acceleration. Maintaining a bunch of contrib or non-free
stuff is not good experience in Debian. Packaging for cuDNN is avaialble
under Salsa:nvidia-team, but the plan for uploading it had been aborted
because it's license looks too scary.

2. ISA Baseline. If you remember SIMDebian[6], or some of my motivations
of DUPR[2], it would be very easy to understand how the absense of SIMD
code affects the critical computational performance. People provided
helpful suggestions at this point, including ld.so[7] tricks and some
gcc features which allows run-time code selection according to cpu
capability[8]. The ld.so trick would bloat the resulting .deb packages
but it's the most applicable solution. In contrast, patching a million
lines of Tensorflow code to enable the "function attributes" feature
is probably impossible to a volunteer.

3. Build system. Look at the build systems of TensorFlow and PyTorch[10].
They are volatile due to the fast pace of development. Specifically,
TensorFlow's build system "bazel" is very hard to package for Debian,
and an anount of patching work is still required to prevent
bazel from downloading ~3.0GiB of ???[9] before building TensorFlow.
PyTorch's setup.py+cmake+shell build system ... requires some patching
work too.

So I recommend any future contributor who is about to deal with any deep
learning packages to carefully assess the 3 aspects above.  To some
extent I envy some other distros such as Arch and Gentoo, since they
already made a great progress in this field.

Sometimes ago (maybe several months?) in debian science team I said I'm
aborting D-L framework related development. Today Paul Liu poked me and
asked me about the status of src:tensorflow (in experimental).  I spent
several hours re-evaluating the situation, and finally decided to fully
give up and write the above points, because I'm not willing to undertake
the workload any more. At the same time, I filed Orphan[11] bugs against
tensorflow and several of its dependencies, except for src:nsync which
contains a neat set of cmake files. I plan to convert those Orphan bugs
into RM bugs after a year, if no one would touch them.

I do research with neural networks and I use these frameworks
frequently. Anadonda and Pip are already good enough for me. So DUPR[2]
is the best choice to me if I'd like some .deb packages.

This time I'm really giving up all related efforts [12], and shall never
touch them again. I don't feel pity, even if these points seem to be
tightly connected to some of my Debian activities. Apart from that, I'm
still willing to provide personal opinions about related packaging
works, or machine learning datasets, pretrained neural networks, etc.

Well, this result looks bad. Let's hope for a sun rise.

Best,
Mo

[1] Please take extra care in computational performance.
[2] https://github.com/dupr/duprkit
[3] (non-free) https://developer.nvidia.com/cudnn
[4] Bussiness groups, researchers.
[5] Google's computation acceleration hardware.
[6] https://github.com/SIMDebian/SIMDebian
[7] man ld.so -> search for "hardware capabilities"
[8] info gcc "Function Attributes";
    See Guillem's recent reply to "SIMDebian: ..." ([hidden email])
[9] I don't know what they are. They are more than build-deps.
[10] They are the top-2 frameworks.
[11] What a relief.
[12] My on-going works about intel-mkl / BLAS / LAPACK are unrelated.
     I still have strong interest in many other aspects of Debian development.

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Andreas Tille-5
Dear Mo,

On Tue, Apr 16, 2019 at 11:12:44AM +0000, Mo Zhou wrote:
> ...
> This time I'm really giving up all related efforts [12], and shall never
> touch them again. I don't feel pity, even if these points seem to be
> tightly connected to some of my Debian activities. Apart from that, I'm
> still willing to provide personal opinions about related packaging
> works, or machine learning datasets, pretrained neural networks, etc.

Thanks a lot for the summary and all your previous work you've spent
into this.  As far as I understand your summary it would be even
"burning" a student if we would throw theses packaging task on a
student in a GSoC / outreachy project (I'm aware that we are usually
not supporting packaging tasks in these projects but it could be an
exception in case my suspicion would be wrong).

I personally do not see any capacity I could provide myself despite it
would be really helpful for Debian Med and Debian Science to cover these
projects.

> Well, this result looks bad. Let's hope for a sun rise.

+1
 
> [12] My on-going works about intel-mkl / BLAS / LAPACK are unrelated.
>      I still have strong interest in many other aspects of Debian development.

Very good to know.  Please keep on your great work

    Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Samuel Thibault-8
Hello,

Thanks for the feedback. In the accessibility team we had interest in
https://github.com/mozilla/DeepSpeech but I got quickly afraid but the
mention of "TensorFlow" in dependencies, it seems I was right in not
taking time to have a look, unfortunately.

Samuel

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Mo Zhou
In reply to this post by Andreas Tille-5
Hi Andreas,

On Tue, Apr 16, 2019 at 02:29:54PM +0200, Andreas Tille wrote:
> Thanks a lot for the summary and all your previous work you've spent
> into this.  As far as I understand your summary it would be even
> "burning" a student if we would throw theses packaging task on a
> student in a GSoC / outreachy project (I'm aware that we are usually
> not supporting packaging tasks in these projects but it could be an
> exception in case my suspicion would be wrong).

For your reference, at least the following skills are required if a
student wants to package a basic (CPU-only, ISA=generic) version of
tensorflow:

* Proficient in python, very familiar with C++.
* Good at cmake. Able to read the bazel build.
* Basic background in machine learning, and know how to use Tensorflow
  to train a neural network. So that he/she will be able to conduct
  smoke tests and simple benchmarks.

The student may also need access to a strong build machine. My Xeon
E5-2687v4 x1 [1] takes about 20 minutes to finish a build, while my
laptop (I5-7440HQ) takes ~90 minutes.

The student also needs to compare the existing build systems:
Tensorflow has three sets of build systems: (1) bazel, the officially
maintained build system. bazel packaging itself is already challenging
enough. Patching the bazel build to make it policy-compliant is not
a trivial work as well. This soulds like a dead end to the student;
(2) cmake build. It is not officially supported, and is badly synced
with the bazel build. The student could make the cmake build work
again as long as he/she has enough patience to dig into the bazel
build and update the cmake; (3) makefile. It is targeted on some
embedded services, and only builds a very core set of C++ interface.
This is not a sane choice for student. Apart from that, the
src:tensorflow in experimental uses a build system written by myself,
which is basically building the shared libraries manually with
auto-generated ninja build. This build system doesn't download
several gigabytes of dependencies, doesn't mixup outputs of 72 building
processes (thanks to ninja-build). It is able to produce the full
set of libraries including the shared object for python interface.
However, it's eventually experimental.

When all the prerequisites have been satisfied, it is still possible to
make some progress. Some people, for example, the accesibility team may
need the basic tensorflow package in the future.  A system such as
DeepSpeech, that recognizes audio with pre-trained neural networks is
doing "inference", or "forward pass". That process requires much less
hardware performance compared to the "training" process. A basic version
of tensorflow is fine for "inference". Unfortunately my demand is
"training", which makes me quite unwilling to move forward a bit because
I won't use the basic version[2]. Even if the basic version had been
prepared, problems about ISA baseline and non-free blobs are still
there.

License is not a problem for the basic version because there is no
non-free stuff involved, and I've already reviewed the source package
file-by-file checking the license.

> Very good to know.  Please keep on your great work

:-)

[1] It builds a defconfig linux kernel within a minute.
[2] My interest in a package will drastically decay to 0 if
    I don't use it......

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Adrian Bunk-3
In reply to this post by Andreas Tille-5
On Tue, Apr 16, 2019 at 02:29:54PM +0200, Andreas Tille wrote:
>...
> As far as I understand your summary it would be even
> "burning" a student if we would throw theses packaging task on a
> student in a GSoC / outreachy project (I'm aware that we are usually
> not supporting packaging tasks in these projects but it could be an
> exception in case my suspicion would be wrong).
>...

How many percent of the paid GSoC and Outreachy student workers
continue unpaid afterwards and become a DM or DD?

My impression is that GSoC does not have a high quota,
and Outreachy is a complete failure.[1]

Assuming the student would succeed in creating packages,
what we would get would be some complex packaging of
packages with a very volatile upstream - and the only
person who understands the packaging is likely gone.

The work Mo spent on the already-outdated tensorflow package in
experimental was wasted if there is noone who continues maintaining it.
And the same would be true for other new packages if the packager
disappears afterwards.

What is actually needed are one (or ideally several) people with
a long-term commitment to maintain these packages.

cu
Adrian

[1] If anyone has data to prove that I am wrong, please let me to know.

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Roger Shimizu
In reply to this post by Mo Zhou
Dear Mo,

Thanks for your work!

On Tue, Apr 16, 2019 at 11:53 PM Mo Zhou <[hidden email]> wrote:
>
> The student may also need access to a strong build machine. My Xeon
> E5-2687v4 x1 [1] takes about 20 minutes to finish a build, while my
> laptop (I5-7440HQ) takes ~90 minutes.

Have you tried ccache? Interested to know the result.

Cheers,
--
Roger Shimizu, GMT +3 Sofia
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Mo Zhou
In reply to this post by Adrian Bunk-3
Hi Adrian,

On Tue, Apr 16, 2019 at 11:07:34PM +0300, Adrian Bunk wrote:
>
> How many percent of the paid GSoC and Outreachy student workers
> continue unpaid afterwards and become a DM or DD?

It's not realistic to expect a student to continue any unpaid effort
after the GSoC / Outreachy participation. I guess most of them come for
money and experience. Continuous Debian development is partially based
on love, enthusiasm and belief. It's not realistic to expect these from
a random CS student, as most CS students in the world live with
micro$oft malware or the apple OS.  Many of my schoolmates, members of
the linux user group in my university, eventually end up embracing apple
OS after graduation and abandoned their ever-beloved Arch, Gentoo, etc,
due to various factors e.g. the 996.ICU working schedule.
 
> My impression is that GSoC does not have a high quota,
> and Outreachy is a complete failure.[1]
 
It's just Debian's proposals aren't attractive enough. Here
is a successful example of GSoC hosting organization:
https://github.com/opencv/opencv/wiki/ChangeLog#version410
Search for "GSoC" and 25 matches show up there.
And I somehow submitted a GSoC proposal to Gentoo this year.

> Assuming the student would succeed in creating packages,
> what we would get would be some complex packaging of
> packages with a very volatile upstream - and the only
> person who understands the packaging is likely gone.

Some ideas and proposals in the Debian community, including tensorflow
packaging or DUPR, aren't quite proper for GSoC students unless they
have strong motivation to do so. Maybe people could provide some more
attractive and interesting ideas for GSoC students. Or the students
won't understand "what on earth is this hosting organization doing".

> The work Mo spent on the already-outdated tensorflow package in
> experimental was wasted if there is noone who continues maintaining it.
> And the same would be true for other new packages if the packager
> disappears afterwards.

Debian should have already got used to the fact that volunteers are
scarce resource.
 
> What is actually needed are one (or ideally several) people with
> a long-term commitment to maintain these packages.

I think most of such long-term + high-workload maintaining works are
actually backed by salary.

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

intrigeri-4
In reply to this post by Adrian Bunk-3
Adrian Bunk:
> Outreachy is a complete failure.[1]
> […]
> [1] If anyone has data to prove that I am wrong, please let me to know.

I only have one single data point: the only person I've been an
Outreachy mentor for is now an active, uploading DD.

Cheers,
--
intrigeri

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Chris Lamb -2
In reply to this post by Adrian Bunk-3
Adrian Bunk wrote:

> How many percent of the paid GSoC and Outreachy student workers
> continue unpaid afterwards and become a DM or DD?
>
> My impression is that GSoC does not have a high quota,
> and Outreachy is a complete failure.

Curious that you have that perception. I don't have hard data but I
can immediately think of at least five folks.

And that's not counting myself.


Regards,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      [hidden email] 🍥 chris-lamb.co.uk
       `-

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Ondřej Surý-4
In reply to this post by intrigeri-4
The only single person I’ve been mentoring in GSoC did as little as possible to pass the half-time, cashed the money and stopped responding to emails.

So, experience might wildly vary...

Ondrej
--
Ondřej Surý
[hidden email]



> On 17 Apr 2019, at 07:17, intrigeri <[hidden email]> wrote:
>
> Adrian Bunk:
>> Outreachy is a complete failure.[1]
>> […]
>> [1] If anyone has data to prove that I am wrong, please let me to know.
>
> I only have one single data point: the only person I've been an
> Outreachy mentor for is now an active, uploading DD.
>
> Cheers,
> --
> intrigeri
>

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Adrian Bunk-3
In reply to this post by Chris Lamb -2
On Wed, Apr 17, 2019 at 07:08:53AM -0400, Chris Lamb wrote:

> Adrian Bunk wrote:
>
> > How many percent of the paid GSoC and Outreachy student workers
> > continue unpaid afterwards and become a DM or DD?
> >
> > My impression is that GSoC does not have a high quota,
> > and Outreachy is a complete failure.
>
> Curious that you have that perception. I don't have hard data but I
> can immediately think of at least five folks.
>
> And that's not counting myself.

GSoC or Outreachy?
And 6 out of how many?

Where can I find a list of all past Debian GSoC and Outreachy participants?
Based on that it would be easy to get hard data.

> Regards,

cu
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Mo Zhou
In reply to this post by Ondřej Surý-4
Hi Ondřej,

On Wed, Apr 17, 2019 at 01:12:12PM +0200, Ondřej Surý wrote:
> The only single person I’ve been mentoring in GSoC did as little as
> possible to pass the half-time, cashed the money and stopped
> responding to emails.
>
> So, experience might wildly vary...

Sorry to hear that. It must be a hurtful experience working with
someone who would rob the money and flee.

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Ondřej Surý-4

> On 17 Apr 2019, at 13:58, Mo Zhou <[hidden email]> wrote:
>
> Hi Ondřej,
>
> On Wed, Apr 17, 2019 at 01:12:12PM +0200, Ondřej Surý wrote:
>> The only single person I’ve been mentoring in GSoC did as little as
>> possible to pass the half-time, cashed the money and stopped
>> responding to emails.
>>
>> So, experience might wildly vary...
>
> Sorry to hear that. It must be a hurtful experience working with
> someone who would rob the money and flee.

Well, actually, it was a good lesson.  I should have failed him much
sooner, so at least I did gain some experience in that regard.

Also his work wasn’t complete failure - while he didn’t do much,
he had some some ideas and it finally pushed me to finish the work
on coinstallable PHP packages.

Ondrej
--
Ondřej Surý
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Jonathan Carter (highvoltage)-2
In reply to this post by Chris Lamb -2
Hi Chris

On 2019/04/17 13:08, Chris Lamb wrote:

>> How many percent of the paid GSoC and Outreachy student workers
>> continue unpaid afterwards and become a DM or DD?
>>
>> My impression is that GSoC does not have a high quota,
>> and Outreachy is a complete failure.
>
> Curious that you have that perception. I don't have hard data but I
> can immediately think of at least five folks.
>
> And that's not counting myself.

Well, the Outreachy site is running, and since they have plans ahead
they clearly seem to be continuing their work. So if Adrian wants to
call it a complete failure then the burden lies on him to justify that
statement, and not on everyone else to invalidate it.

-Jonathan

--
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Adrian Bunk-3
In reply to this post by Mo Zhou
On Wed, Apr 17, 2019 at 01:38:22AM +0000, Mo Zhou wrote:
> Hi Adrian,

Hi Mo,

> On Tue, Apr 16, 2019 at 11:07:34PM +0300, Adrian Bunk wrote:
>...
> > The work Mo spent on the already-outdated tensorflow package in
> > experimental was wasted if there is noone who continues maintaining it.
> > And the same would be true for other new packages if the packager
> > disappears afterwards.
>
> Debian should have already got used to the fact that volunteers are
> scarce resource.

Are they scarce or scared away?

I had some points in [1] regarding the problems of volunteers trying to
get contributions in Debian.

> > What is actually needed are one (or ideally several) people with
> > a long-term commitment to maintain these packages.
>
> I think most of such long-term + high-workload maintaining works are
> actually backed by salary.

>From what I am aware, I would say it is pretty much an exception when
maintaining packages in unstable is paid work.

Especially long-term, apart from Canonical there are not many companies
that have an interest in Debian that does not go away after their next
round of restructure+layoffs.

cu
Adrian

[1] https://lists.debian.org/debian-vote/2019/03/msg00199.html

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

GSoC / Outreachy (Was: Bits from /me: Difficulties in Deep Learning Framework Packaging)

Andreas Tille-5
In reply to this post by Adrian Bunk-3
On Tue, Apr 16, 2019 at 11:07:34PM +0300, Adrian Bunk wrote:
> How many percent of the paid GSoC and Outreachy student workers
> continue unpaid afterwards and become a DM or DD?
>
> My impression is that GSoC does not have a high quota,
> and Outreachy is a complete failure.[1]

Two out of three outreachy students I had remained active in the Debian
Med project with serious contributions.  They just joined our Debian Med
sprint in Vilnius.  I was very happy about the work of all three
outreachy students and their contribution helped a lot.

> [1] If anyone has data to prove that I am wrong, please let me to know.

You are welcome :-)

     Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Birger Schacht
In reply to this post by Adrian Bunk-3
Hi,

On 4/16/19 10:07 PM, Adrian Bunk wrote:

> On Tue, Apr 16, 2019 at 02:29:54PM +0200, Andreas Tille wrote:
>> ...
>> As far as I understand your summary it would be even
>> "burning" a student if we would throw theses packaging task on a
>> student in a GSoC / outreachy project (I'm aware that we are usually
>> not supporting packaging tasks in these projects but it could be an
>> exception in case my suspicion would be wrong).
>> ...
>
> How many percent of the paid GSoC and Outreachy student workers
> continue unpaid afterwards and become a DM or DD?
>
> My impression is that GSoC does not have a high quota,
> and Outreachy is a complete failure.[1]

Should the success of (Debians paricipation in) GSoC and Outreachy
really be measured on the participants becoming DM or DD afterwards?
I think its also a win if a student decides to join some upstream
project or contributes to another distribution or even just knows about
Debian and uses it for further work.

cheers,
Birger

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Adrian Bunk-3
In reply to this post by Jonathan Carter (highvoltage)-2
On Wed, Apr 17, 2019 at 03:04:12PM +0200, Jonathan Carter wrote:

> On 2019/04/17 13:08, Chris Lamb wrote:
> >> How many percent of the paid GSoC and Outreachy student workers
> >> continue unpaid afterwards and become a DM or DD?
> >>
> >> My impression is that GSoC does not have a high quota,
> >> and Outreachy is a complete failure.
> >
> > Curious that you have that perception. I don't have hard data but I
> > can immediately think of at least five folks.
> >
> > And that's not counting myself.
>
> Well, the Outreachy site is running, and since they have plans ahead
> they clearly seem to be continuing their work. So if Adrian wants to
> call it a complete failure then the burden lies on him to justify that
> statement, and not on everyone else to invalidate it.

I said it was my impression, and was asking if anyone has data to
prove me wrong.

IMHO anyone spending a 5 digit US Dollar amount of Debian money annually
should also have the burden of proof that the money is well-spent.

Personally I would also consider it questionable that Debian Outreachy
does "expressly invite"[1] every black man born with the privilege
of US citizenship to participate, while black heterosexual men in South
Africa are excluded and heterosexual men from South America are only
invited if living in the US - this conveys a not very subtle message
what kind of diversity and inclusivity in Debian is wanted and what
kind is not...

I am sure this all makes sense for people in the US,
but for a global project it is a WTF.

It might even happen one day that a female student born into a
middle-class German family gets paid 5k from Debian plus mentorship
from a DD in South America - who is too shy to ask Debian for 1k travel
sponsorship to a Debian event in Europe he cannot afford himself.[2]

> -Jonathan

cu
Adrian

[1] https://wiki.debian.org/Outreachy/Round17
[2] See the "we know it could be used for 4 or 5 other developers
    inside Europe to travel around there" in [3].
[3] https://lists.debian.org/debian-vote/2019/04/msg00011.html

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Holger Levsen-2
On Wed, Apr 17, 2019 at 08:05:17PM +0300, Adrian Bunk wrote:
> I am sure this all makes sense for people in the US,
> but for a global project it is a WTF.

not commenting on your main point (the above), but...

> [2] See the "we know it could be used for 4 or 5 other developers
>     inside Europe to travel around there" in [3].
> [3] https://lists.debian.org/debian-vote/2019/04/msg00011.html

I'm very glad this particular developer has asked the DPL for travel
funds and will be attending the mini debconf in hamburg!

and so should you! ;p

https://wiki.debian.org/DebianEvents/de/2019/MiniDebConfHamburg


--
tschau,
        Holger

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

Dance like no one's watching. Encrypt like everyone is.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

Chris Lamb -2
In reply to this post by Adrian Bunk-3
Adrian Bunk wrote:

> > Curious that you have that perception. I don't have hard data but I
> > can immediately think of at least five folks.
> >
> > And that's not counting myself.
>
> GSoC or Outreachy?

I don't really track in my head the origin outreach programme of these
new friends of mine, sorry.

> And 6 out of how many?

No idea. As others have pointed out, it feels like the ball is not
in my court to provide hard data to disprove your impressions.

To blindly continue in a purely anecdotal manner, since I posted I
could recall at least two more and was even told IRL about another two
in an entirely-spontaneous conversation last night.

Furthermore, the silent implication that this is the primary or even
the sole metric for these initiatives success does not sit right to
me, not least because a number you might find unacceptably low might
say more about Debian's attitude or welcoming atmosphere rather than a
judgement of the programmes themselves...

As an aside, you may need to reassure or correct me but I must say I
find myself somewhat uneasy at the tenor and manner in which you are
"just asking questions" in this thread.


Regards,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      [hidden email] 🍥 chris-lamb.co.uk
       `-