On Saturday, 11 April 2020 4:45:08 AM AEST Peter Silva wrote:
> Debian policy is there to shape packages so they fit into stable. If we
> "know" that a package will never make it into stable, is Policy relevant?
Of course policy is relevant. Debian is not only "stable" but also "testing",
On 4/10/20 9:50 AM, Marc Haber wrote:
> A package without upstream support is bound to be a zombie.
There's many examples of this in Debian. It all depends, and you cannot
make a generality like this.
On 4/10/20 9:43 AM, Marc Haber wrote:
> On Thu, 9 Apr 2020 08:47:16 +0200, Thomas Goirand
>
On Fri, Apr 10, 2020 at 1:12 PM Russ Allbery wrote:
> Dmitry Smirnov writes:
>
> > Let's remember that Kubernetes was never in "stable" to begin with.
>
> > This is not to say that it couldn't be useful in "testing", "unstable"
> > or even "experimental". Many packages that may be considered
Dmitry Smirnov writes:
> Let's remember that Kubernetes was never in "stable" to begin with.
> This is not to say that it couldn't be useful in "testing", "unstable"
> or even "experimental". Many packages that may be considered not
> suitable for "production" are nevertheless useful.
Speaking
On Friday, 10 April 2020 5:43:57 PM AEST Marc Haber wrote:
> That a big package in Debian stable that has been abandoned by
> upstream months or even years ago is actually supported is fairy tale.
Let's remember that Kubernetes was never in "stable" to begin with.
This is not to say that it
On Thu, 9 Apr 2020 09:36:22 +0200, Thomas Goirand
wrote:
>On 4/8/20 10:58 PM, Michael Stone wrote:
>> Or, if they're not clear about what
>> adopting this tool means, I agree that isn't in their interest for them
>> to see that there's a debian package and be fooled into thinking it
>> doesn't
On Wed, 8 Apr 2020 16:58:54 -0400, Michael Stone
wrote:
>On Wed, Apr 08, 2020 at 10:36:17PM +0200, Thomas Goirand wrote:
>>I don't agree with this *at all*. It is not in the interest of our users
>>to be forced to update the software they use for their infrastructure
>>every few months.
>
>Isn't
On Thu, 9 Apr 2020 09:21:35 +0200, Tomas Pospisek
wrote:
>On 09.04.20 08:47, Thomas Goirand wrote:
>
>> As a user, I'd prefer Kubernets to be in Stable if possible. I'd be one
>> of these users who don't care about the latest shiny feature, and prefer
>> something stable, supported for YEARS to
On Thu, 9 Apr 2020 08:47:16 +0200, Thomas Goirand
wrote:
>On 4/8/20 10:44 PM, Peter Silva wrote:
>> doesn´t this whole discussion just mean that k8 should just not be in
>> Debian?
>
>IMO no. It means that if we have enough packaging resources (which
>probably we don't, I can't tell),
We don't.
On 2020-04-09 09:42:28 +0200 (+0200), Thomas Goirand wrote:
[...]
> I agree with all what you wrote above. However, there's still no
> LTS release in OpenStack, unfortunately. I can support Debian
> stable, though I have (understandably) given up on oldstable, yet
> even on Debian LTS.
Yep, at
On 4/8/20 11:25 PM, Jeremy Stanley wrote:
> On 2020-04-08 22:36:17 +0200 (+0200), Thomas Goirand wrote:
> [...]
>> Also, the docker world is not the only one to be this way. It used to be
>> like this in OpenStack too. In the OpenStack world, they haven't changed
>> the way they release (ie: every
On 4/8/20 10:58 PM, Michael Stone wrote:
> On Wed, Apr 08, 2020 at 10:36:17PM +0200, Thomas Goirand wrote:
>> I don't agree with this *at all*. It is not in the interest of our users
>> to be forced to update the software they use for their infrastructure
>> every few months.
>
> Isn't that the
On 09.04.20 08:47, Thomas Goirand wrote:
> As a user, I'd prefer Kubernets to be in Stable if possible. I'd be one
> of these users who don't care about the latest shiny feature, and prefer
> something stable, supported for YEARS to come, not just 3 months.
To give a datapoint:
Kubernetes as a
On 4/8/20 10:44 PM, Peter Silva wrote:
> doesn´t this whole discussion just mean that k8 should just not be in
> Debian?
IMO no. It means that if we have enough packaging resources (which
probably we don't, I can't tell), then we may just as well ignore an
upstream who's basically saying we
On Mi, 08 apr 20, 16:44:22, Peter Silva wrote:
> doesn´t this whole discussion just mean that k8 should just not be in
> Debian?
>
> It should be a third party package, perhaps with a third party repo, and
> just not be in Debian at all.
> If any means of packaging for a Debian release results in
On 3/25/20 11:45 PM, Marc Haber wrote:
On Tue, 24 Mar 2020 20:37:16 +, Jeremy Stanley
wrote:
If this represents the actual state of building Kubernetes, it's
unclear to me why Debian would package it at all. I don't see the
value to users in consuming Kubernetes from a Debian package if
On 2020-04-08 22:36:17 +0200 (+0200), Thomas Goirand wrote:
[...]
> Also, the docker world is not the only one to be this way. It used to be
> like this in OpenStack too. In the OpenStack world, they haven't changed
> the way they release (ie: every 6 months), but the user survey has shown
> that
On Wed, Apr 08, 2020 at 10:36:17PM +0200, Thomas Goirand wrote:
I don't agree with this *at all*. It is not in the interest of our users
to be forced to update the software they use for their infrastructure
every few months.
Isn't that the user's decision, when they decided to adopt a tool
doesn´t this whole discussion just mean that k8 should just not be in
Debian?
It should be a third party package, perhaps with a third party repo, and
just not be in Debian at all.
If any means of packaging for a Debian release results in a package that is
essentially unsupported by upstream...
On 4/8/20 6:14 PM, Marc Haber wrote:
> On Sun, 5 Apr 2020 23:16:51 +0100, Wookey wrote:
>> On 2020-04-05 21:15 +0200, Marc Haber wrote:
>>> having an obsolete version of the software distributed
>>> with/through Debian is (rightfully) seen a liabilty by some upstreams,
>>> not as an asset.
>>
>>
On Sun, 5 Apr 2020 23:16:51 +0100, Wookey wrote:
>On 2020-04-05 21:15 +0200, Marc Haber wrote:
>> having an obsolete version of the software distributed
>> with/through Debian is (rightfully) seen a liabilty by some upstreams,
>> not as an asset.
>
>I think a more interesting/important question
On 2020-04-05 21:15 +0200, Marc Haber wrote:
> having an obsolete version of the software distributed
> with/through Debian is (rightfully) seen a liabilty by some upstreams,
> not as an asset.
I think a more interesting/important question is whether users like
it, rather than whether upstreams
On Sat, 28 Mar 2020 12:41:46 +1100, Dmitry Smirnov
wrote:
>On Friday, 27 March 2020 7:08:35 PM AEDT Marc Haber wrote:
>> Many upstreams deliver .deb packages of their current releases in
>> noticeably high quality from a Debian point of view. One should look
>> at them before putting them in
On 3/28/20 2:41 AM, Dmitry Smirnov wrote:
> On Friday, 27 March 2020 7:08:35 PM AEDT Marc Haber wrote:
>> Many upstreams deliver .deb packages of their current releases in
>> noticeably high quality from a Debian point of view. One should look
>> at them before putting them in production.
>
> I
On Friday, 27 March 2020 7:08:35 PM AEDT Marc Haber wrote:
> Many upstreams deliver .deb packages of their current releases in
> noticeably high quality from a Debian point of view. One should look
> at them before putting them in production.
I have a very different observations regarding
On 3/26/20 11:52 PM, Dmitry Smirnov wrote:
>> Applying the Debian "library" policy on go code is imho impossible -
>> there are no sonames, often no proper releases. The way how Debian
>> packages source code does not fit for go.
>
> The way how Golang community handled dependencies was insane
On 27.03.20 01:57, Paul Wise wrote:
> On Thu, Mar 26, 2020 at 8:30 PM Christian Kastner wrote:
>
>> [Well, technically, you could use your own lawyer to perform the due
>> diligence and have them submit any necessary changes to the BTS, but I
>> think it's safe to assume that that is a
On Thu, 26 Mar 2020 20:22:18 +1100, Dmitry Smirnov
wrote:
>On Thursday, 26 March 2020 7:27:33 PM AEDT Marc Haber wrote:
>> I still wouldn't dare pulling testing or unstable packages to
>> production systems. It's like a worst-of-all-worlds approach.
>
>Not at all. Packaging is an extra layer of
On Thu, Mar 26, 2020 at 8:30 PM Christian Kastner wrote:
> [Well, technically, you could use your own lawyer to perform the due
> diligence and have them submit any necessary changes to the BTS, but I
> think it's safe to assume that that is a theoretical example.]
The OSI started
On Friday, 27 March 2020 5:42:47 AM AEDT Bernd Zeimetz wrote:
> B) there are reasons why people recommend not to use the packaged
> versions of docker.io. No opinion on the others, never touched them.
The are some valid reasons, for example version in "stable" is too old and
the package (and
Quoting Andrej Shadura (2020-03-26 22:24:41)
> On Thu, 26 Mar 2020 at 21:01, Russ Allbery wrote:
> > > An example: commercial users. They need to know *exactly* what they
> > > are running and under which licenses. They often want to be holier not
> > > only than the Pope, but holier than the
Hi,
On Thu, 26 Mar 2020 at 21:01, Russ Allbery wrote:
> > An example: commercial users. They need to know *exactly* what they
> > are running and under which licenses. They often want to be holier not
> > only than the Pope, but holier than the whole population of Poland,
> > Italy and
Hi,
Quoting Russ Allbery (2020-03-25 03:25:49)
> Michael Lustfield writes:
> > One last thing to consider... NEW reviews are already an intense process.
> > If this package hit NEW /and/ we allowed vendored libs, you could safely
> > expect me to never complete that particular review. I doubt
On 26.03.20 19:57, Andrej Shadura wrote:
> An example: commercial users. They need to know *exactly* what they
> are running and under which licenses.
The only way to know that is by performing your own due diligence.
> They are often bound by regulations with heavy fines for violating
> them,
Andrej Shadura writes:
> An example: commercial users. They need to know *exactly* what they
> are running and under which licenses. They often want to be holier not
> only than the Pope, but holier than the whole population of Poland,
> Italy and Spanish-speaking countries altogether (I hope I
On Thursday, March 26, 2020 3:27:18 PM EDT Kyle Edwards wrote:
> On Thu, 2020-03-26 at 19:57 +0100, Andrej Shadura wrote:
> > An example: commercial users. They need to know *exactly* what they
> > are running and under which licenses. They often want to be holier
> > not
> > only than the Pope,
On Thu, 2020-03-26 at 19:57 +0100, Andrej Shadura wrote:
> An example: commercial users. They need to know *exactly* what they
> are running and under which licenses. They often want to be holier
> not
> only than the Pope, but holier than the whole population of Poland,
> Italy and
Hi,
On Thu, 26 Mar 2020 at 12:40, Christian Kastner wrote:
> There's this expression in German for when one takes a policy too far:
> "Don't try to be holier than the Pope".
>
> But that's how maintaining debian/copyright has come to feel to me. We
> still apply a level of detail that seems out
On 3/25/20 11:30 PM, Dmitry Smirnov wrote:
> Given that logic even re-compiling using different compiler would not be
> trustworthy. And indeed some people make exactly that argument -- "use our
> tested binary" as one can't be sure if re-compiling introduces any bugs.
Indeed I'd expect it
Hi,
On 25.03.20 23:39, Dmitry Smirnov wrote:
>> Software packages like kubernetes, docker, and many of the other "hip
>> tools of the day" are moving way too fast for our release scheme.
> It is worth remembering that Debian is not only a stable release.
> Statically built Golang apps are easy
On Thursday, March 26, 2020 7:40:42 AM EDT Christian Kastner wrote:
> On 25.03.20 15:50, Scott Kitterman wrote:
> > The FTP Team review of debian/copyright is about DFSG and upstream license
> > compliance. Most licenses require things like copyright statement
> > preservation in binary
On 25.03.20 15:50, Scott Kitterman wrote:
> The FTP Team review of debian/copyright is about DFSG and upstream license
> compliance. Most licenses require things like copyright statement
> preservation in binary distribution and debian/copyright is how we do that.
> Occasionally, in the
On Thursday, 26 March 2020 7:27:33 PM AEDT Marc Haber wrote:
> I still wouldn't dare pulling testing or unstable packages to
> production systems. It's like a worst-of-all-worlds approach.
Not at all. Packaging is an extra layer of safety. Upstream release may be
outright broken, unusable or
On Thu, 26 Mar 2020 09:39:56 +1100, Dmitry Smirnov
wrote:
>On Thursday, 26 March 2020 3:45:21 AM AEDT Marc Haber wrote:
>> Software packages like kubernetes, docker, and many of the other "hip
>> tools of the day" are moving way too fast for our release scheme.
>
>It is worth remembering that
On Thursday, 26 March 2020 3:45:21 AM AEDT Marc Haber wrote:
> Software packages like kubernetes, docker, and many of the other "hip
> tools of the day" are moving way too fast for our release scheme.
It is worth remembering that Debian is not only a stable release.
Statically built Golang apps
On Thursday, 26 March 2020 7:38:12 AM AEDT Bernd Zeimetz wrote:
> ... you would know that it is only tested with the
> exact versions of the libraries as it was released with.
>
> Choosing different versions is prone to introduce subtle bugs and should
> never be done and accepted if that k8s
Russ Allbery schrieb:
> Michael Lustfield writes:
>
>> One last thing to consider... NEW reviews are already an intense
>> process. If this package hit NEW /and/ we allowed vendored libs, you
>> could safely expect me to never complete that particular review. I doubt
>> I'm the only one; that's
Hi,
> As a person who originally introduced Kubernetes to Debian I can say that it
> is indeed a lot of work to maintain this package and to reuse packaged
> libraries. But I've demonstrated that it is possible at least to some extent.
if you've maintained k8s you would know that it is only
❦ 25 mars 2020 15:57 +01, Jonas Smedegaard:
>> rpm packages record the package license information in a one-line License:
>> field.
>
> Is your point that 9 lines can be reduced to one, or that 100 lines can
> be reduced to one?
>
> It is legal in Debian to write debian/copyright files looking
On Tue, 24 Mar 2020 20:37:16 +, Jeremy Stanley
wrote:
>If this represents the actual state of building Kubernetes, it's
>unclear to me why Debian would package it at all. I don't see the
>value to users in consuming Kubernetes from a Debian package if the
>result is compromising on Debian's
Le mardi 24 mars 2020 à 19:08:23+, Janos LENART a écrit :
> [snip]
> I do think there is a good case for Kubernetes to be an exception from 4.13
> for
> now, just like other Go packages effectively are.
Using other examples to say "people do bas stuff elsewhere so I'm
entitled to do the
* Andrey Rahmatullin:
> Or you can look at the Redhat approach as a minimal working one.
> You know it can be done much easier and still work: in Redhat.
I think you are referring to a Fedora process, not a Red Hat process.
The Red Hat process does not seem much simpler than what ftpmaster are
On 25.03.20 15:14, Tomas Pospisek wrote:
> I can be sure that if stuff lands in Debian then I won't get screwed
> by weird, dirty, missleading, underhanded licensing rules, which
> seems to be the standard outside the Open Source world and even on
> its fringes.
The only thing you can be sure
On Wed, Mar 25, 2020 at 03:57:29PM +0100, Jonas Smedegaard wrote:
> > > >> I'd contest this. Whenever Open Source standards come up in a
> > > >> discussion, Debian is always the gold reference. You know it can be
> > > >> done
> > > >> right and it is: in Debian.
> > > > Or you can look at the
Quoting Andrey Rahmatullin (2020-03-25 15:46:10)
> On Wed, Mar 25, 2020 at 03:32:20PM +0100, Tomas Pospisek wrote:
> > On 25.03.20 15:19, Andrey Rahmatullin wrote:
> > > On Wed, Mar 25, 2020 at 03:14:41PM +0100, Tomas Pospisek wrote:
> > >> On 25.03.20 14:43, Christian Kastner wrote:
> > >>
> >
On March 25, 2020 1:43:26 PM UTC, Christian Kastner wrote:
>Russ,
>
>On 25.03.20 03:25, Russ Allbery wrote:
>> I'll repeat a point that I made earlier but put a bit of a sharper
>point
>> on it: We should thoughtfully question whether the current approach
>to
>> license review that we as a
On Wed, Mar 25, 2020 at 03:32:20PM +0100, Tomas Pospisek wrote:
> On 25.03.20 15:19, Andrey Rahmatullin wrote:
> > On Wed, Mar 25, 2020 at 03:14:41PM +0100, Tomas Pospisek wrote:
> >> On 25.03.20 14:43, Christian Kastner wrote:
> >>
> >>> This is not to say that licensing is an unimportant issue
On Wed, Mar 25, 2020 at 03:32:20PM +0100, Tomas Pospisek wrote:
> On 25.03.20 15:19, Andrey Rahmatullin wrote:
> > On Wed, Mar 25, 2020 at 03:14:41PM +0100, Tomas Pospisek wrote:
> >> On 25.03.20 14:43, Christian Kastner wrote:
> >>
> >>> This is not to say that licensing is an unimportant issue
On 25.03.20 15:19, Andrey Rahmatullin wrote:
> On Wed, Mar 25, 2020 at 03:14:41PM +0100, Tomas Pospisek wrote:
>> On 25.03.20 14:43, Christian Kastner wrote:
>>
>>> This is not to say that licensing is an unimportant issue -- it clearly
>>> is. But our analyze-and-document down-to-the-file
On Wed, Mar 25, 2020 at 03:14:41PM +0100, Tomas Pospisek wrote:
> On 25.03.20 14:43, Christian Kastner wrote:
>
> > This is not to say that licensing is an unimportant issue -- it clearly
> > is. But our analyze-and-document down-to-the-file approach is on the
> > other extreme end of the
On 25.03.20 14:43, Christian Kastner wrote:
> This is not to say that licensing is an unimportant issue -- it clearly
> is. But our analyze-and-document down-to-the-file approach is on the
> other extreme end of the spectrum, and it causes lots of tiresome work
> that nobody apart from us seems
Russ,
On 25.03.20 03:25, Russ Allbery wrote:
> I'll repeat a point that I made earlier but put a bit of a sharper point
> on it: We should thoughtfully question whether the current approach to
> license review that we as a project ask ftpmasters to do is a correct
> investment of project
On Tue, Mar 24, 2020 at 07:25:49PM -0700, Russ Allbery wrote:
> I'll repeat a point that I made earlier but put a bit of a sharper point
> on it: We should thoughtfully question whether the current approach to
> license review that we as a project ask ftpmasters to do is a correct
> investment of
On Wednesday, 25 March 2020 2:34:03 PM AEDT Michael Lustfield wrote:
> With regard to the kubernetes package, I don't see anything to indicate it
> was abandoned.
Sorry if I did not make it clear: the package was orphaned as per #886739.
The takeover was only technological. I don't dispute the
Ehm... perhaps we should practice some de-escalation techniques, please. :/
On Wed, 25 Mar 2020 13:55:50 +1100
Dmitry Smirnov wrote:
> On Wednesday, 25 March 2020 6:08:23 AM AEDT Janos LENART wrote:
> > Debian Policy, paragraph 4.13 states:
>
> There are several problems with how you did it
On Tue, 24 Mar 2020 19:25:49 -0700
Russ Allbery wrote:
> Michael Lustfield writes:
>
> > One last thing to consider... NEW reviews are already an intense
> > process. If this package hit NEW /and/ we allowed vendored libs, you
> > could safely expect me to never complete that particular
On 2020-03-24 19:08 +, Janos LENART wrote:
> Hi Dimitry, FTP masters and others,
> 4. TESTING. The Kubernetes releases are meticulously tested, with far greater
> technical resources that Debian can collectively muster.
On how many architectures? Debian's support of multiple architectures
On Wednesday, 25 March 2020 6:08:23 AM AEDT Janos LENART wrote:
> I know Dimitry was fighting an uphill battle with kubernetes between 2016
> and 2018 and he experienced first hand the problems posed by vendored code.
No. This is a incorrect. Largest chunk of work that I did on Kubernetes was
in
Michael Lustfield writes:
> One last thing to consider... NEW reviews are already an intense
> process. If this package hit NEW /and/ we allowed vendored libs, you
> could safely expect me to never complete that particular review. I doubt
> I'm the only one; that's essentially ~200 package
On Wed, 25 Mar 2020 02:07:13 +0100
Marco d'Itri wrote:
> On Mar 24, Russ Allbery wrote:
> [...]
> The main reason for mostly forbidding vendored libraries has been that
> the security team rightly argues that in the event of a security issue
> it would be too much work to 1) hunt each package
On Mar 24, Russ Allbery wrote:
> (The Rust team is trying the package everything approach with some success
> but is uncovering other limitations in our processes and tools.) But
"Some" success indeed. My personal experience with trying to package
routinator has been awful, and there is still
Jeremy Stanley writes:
> If this represents the actual state of building Kubernetes, it's
> unclear to me why Debian would package it at all. I don't see the
> value to users in consuming Kubernetes from a Debian package if the
> result is compromising on Debian's vision and values so that they
On 2020-03-24 19:08:23 + (+), Janos LENART wrote:
> I know Dimitry was fighting an uphill battle with kubernetes
> between 2016 and 2018 and he experienced first hand the problems
> posed by vendored code.
>
> We see more and more software making excessive use of vendored
> code. Pretty
Hi Dimitry, FTP masters and others,
I know Dimitry was fighting an uphill battle with kubernetes between 2016
and 2018 and he experienced first hand the problems posed by vendored code.
We see more and more software making excessive use of vendored code. Pretty
much everything that is written in
* Paul Wise:
> On Tue, Mar 24, 2020 at 6:17 AM Vincent Bernat wrote:
>
>> Kubernetes is already using Go modules. They happen to have decided to
>> keep shipping a `vendor/` directory but this is not uncommon. It is
>> often considered as a protection against disappearing modules. So, there
>> is
Hello,
On Tue 24 Mar 2020 at 05:37AM -05, Michael Lustfield wrote:
> The 'go vendor' approach is especially bad within the Debian context because
> it
> will download any/all modules that are referenced. In some cases, 'go get
> [..]'
> can go from downloading a single repository to
❦ 24 mars 2020 14:18 +01, Julien Puydt:
>> There are other reasons, notably that you speed up builds by having
>> all the source code ready.
>
> Sorry, I don't know much about how go works, but : can't the developer
> just have the deps ready -- and just not commit them to the repo and
> not
Le mardi 24 mars 2020 à 14:03 +0100, Vincent Bernat a écrit :
>
> There are other reasons, notably that you speed up builds by having
> all
> the source code ready.
Sorry, I don't know much about how go works, but : can't the developer
just have the deps ready -- and just not commit them to the
❦ 24 mars 2020 05:37 -05, Michael Lustfield:
>> > Kubernetes is already using Go modules. They happen to have decided to
>> > keep shipping a `vendor/` directory but this is not uncommon. It is
>> > often considered as a protection against disappearing modules. So, there
>> > is nothing to be
❦ 24 mars 2020 10:14 +00, Paul Wise:
>> Kubernetes is already using Go modules. They happen to have decided to
>> keep shipping a `vendor/` directory but this is not uncommon. It is
>> often considered as a protection against disappearing modules. So, there
>> is nothing to be done upstream. And
On Tue, 24 Mar 2020 10:14:08 +
Paul Wise wrote:
> On Tue, Mar 24, 2020 at 6:17 AM Vincent Bernat wrote:
>
> > Kubernetes is already using Go modules. They happen to have decided to
> > keep shipping a `vendor/` directory but this is not uncommon. It is
> > often considered as a protection
On Mon, 23 Mar 2020 18:47:18 -0700
Sean Whitton wrote:
> Hello Dmitry, Janos, others,
>
> On Mon 23 Mar 2020 at 05:32PM +11, Dmitry Smirnov wrote:
>
> > What would be best to do in such situation?
>
> [...]
>
> I think that I would start by filing an RC bug.
+1
If you run into issues,
On Tue, Mar 24, 2020 at 6:17 AM Vincent Bernat wrote:
> Kubernetes is already using Go modules. They happen to have decided to
> keep shipping a `vendor/` directory but this is not uncommon. It is
> often considered as a protection against disappearing modules. So, there
> is nothing to be done
On Mon, Mar 23, 2020 at 05:32:54PM +1100, Dmitry Smirnov wrote:
> Something interesting just happened. An inexperienced DD adopted a very
> complicated package (kubernetes) and uploaded it with changes that would have
> never been accepted by ftp-masters.
file bugs then. maybe that new
❦ 24 mars 2020 03:11 +00, Paul Wise:
>> Specifically, as README.Debian states, the vendor/ subdirectory of the
>> source package contains more than two hundred Go libraries.
>
> There are a *lot* of embedded code/data copies in Debian already.
> While it would be nice to remove them, sometimes
On Tue, Mar 24, 2020 at 1:47 AM Sean Whitton wrote:
> Specifically, as README.Debian states, the vendor/ subdirectory of the
> source package contains more than two hundred Go libraries.
There are a *lot* of embedded code/data copies in Debian already.
While it would be nice to remove them,
Hello Dmitry, Janos, others,
On Mon 23 Mar 2020 at 05:32PM +11, Dmitry Smirnov wrote:
> Something interesting just happened. An inexperienced DD adopted a very
> complicated package (kubernetes) and uploaded it with changes that would have
> never been accepted by ftp-masters.
Specifically, as
Something interesting just happened. An inexperienced DD adopted a very
complicated package (kubernetes) and uploaded it with changes that would have
never been accepted by ftp-masters.
What would be best to do in such situation?
The problem is not with DD's qualification (although this
88 matches
Mail list logo
