On Saturday, 23 January 2021 3:18:52 AM AEDT Shengjing Zhu wrote:
> The real complex things are, dealing license and copyright and *NEW* queue.
> If this TC decision is that we just trust what upstream say, then why not
> just unvendor them. Then many pieces of libraries can be reused by others.
E
On Wed, Jan 20, 2021 at 12:28:46PM -0700, Sean Whitton wrote:
> Our consensus is that Kubernetes ought to be considered special in the
> same way that Firefox is considered special -- we treat the package
> differently from most other source packages because (i) it is very large
> and complex, and
I'm disappointed with TC's decision. IMHO it is lacking depth of judgement.
The original problem I reported is absolutism - "vendor everything".
And TC apparently considered only that without trying to find the balance.
What are the reasons for vendoring stable well maintained library like
Logrus
On Friday, 20 November 2020 4:35:23 PM AEDT Elana Hashman wrote:
> Kubernetes is a very large and active project. It has about 600
> members,[0] 1000 voters,[1] 100 committers (which I define as members of
> the milestone-maintainers team),[2] and over 50,000 contributors.[3] The
> project has its
]] Philip Hands
> Tollef Fog Heen writes:
>
> > ]] Shengjing Zhu
> >
> >> Firefox is special, since for Debian desktop users, they need a browser. Is
> >> kubernetes same here?
> >
> > FWIW, the lack of Kubernetes or a similar orchestration platform (mesos,
> > nomad, docker swarm) in stable h
Tollef Fog Heen writes:
> ]] Shengjing Zhu
>
>> Firefox is special, since for Debian desktop users, they need a browser. Is
>> kubernetes same here?
>
> FWIW, the lack of Kubernetes or a similar orchestration platform (mesos,
> nomad, docker swarm) in stable has been keeping back development of
]] Shengjing Zhu
> Firefox is special, since for Debian desktop users, they need a browser. Is
> kubernetes same here?
FWIW, the lack of Kubernetes or a similar orchestration platform (mesos,
nomad, docker swarm) in stable has been keeping back development of the
next generation way of handling
Dear interested parties,
I would like to express my appreciation for everyone's valuable input; the
time and effort put into this matter. I doubt there is much left to be
added as both sides argued at length.
Speaking from a technological point of view, I want to restate that I also
do not like t
Hi Josh
On 2020/11/20 01:30, Josh Triplett wrote:
> In particular, with my upstream Rust/Cargo hats on, I would love to work
> with you and others on questions of what software packaging could look
> like, and how to maintain the quality and curation *and* package
> availability of Debian in colla
On Wed, Nov 18, 2020 at 11:36:09AM -0600, Gunnar Wolf wrote:
> ...
> I'm pasting here a bit of the discussion that happened later during
> the meeting: having this discussion K8S-specific, Elana mentioned that
> "that is a big part of the tension. sometimes, you have an upstream
> where the authors
On Wed, Nov 18, 2020 at 10:26:21AM -0800, Russ Allbery wrote:
> There are a lot of fascinating edge cases and precedents and philosophical
> questions about the function of a distribution here, and I think they
> rightfully attract a lot of energy, but I'm worried this is at the cost of
> losing si
On Wed, Nov 18, 2020 at 10:26:21AM -0800, Russ Allbery wrote:
>
> I maintain a bunch of Kubernetes clusters as part of my job. Those
> clusters are run by other people (cloud providers, data centers, etc.). I
> need clients to talk to those clusters. When I first started working with
> Kubernet
Russ Allbery writes ("Bug#971515: Status as of last tech-ctte meeting"):
> [much stuff]
Oh, wow, Russ. Thank you very much. What an excellent piece of
writing. I agree entirely with all of it.
Ian.
(And I speak as someone who thinks that this newfangled "vendor
everything&q
This is an excellent discussion and a good summary. Thank you, Gunnar!
Gunnar Wolf writes:
> There is a course of action that's unlikely to leave everybody happy,
> but is worth considering: Phil said:
> Phil>
> that makes it seem like what we actually need is a decent way of
> let
Hello all,
On Wed 18 Nov 2020 at 11:36AM -06, Gunnar Wolf wrote:
> So... It's not like we reached a conclusion, but I do feel the meeting
> was interesting and the discussion very much worthy. Yes, this will
> surely end up in reinforcing the notion that the Technical Committee
> is a slow and bu
Hello world,
When we had our last tech-ctte meeting, 2020.10.21¹, I volunteered to
write up a summary of our positions regarding this bug. Then... Well,
life happened, and I have not had the time to sit down and write until
today -- A couple of hours before our next meeting. Several other
discussi
* Moritz Mühlenhoff:
> On Sun, Nov 08, 2020 at 10:49:31PM +0100, Florian Weimer wrote:
>> * Moritz Mühlenhoff:
>>
>> > * Follow a scheme similar to Firefox ESR where in case of a security
>> > the update either happens to the latest minor release of
>> > the current branch or if that has stop
On Sun, Nov 08, 2020 at 10:49:31PM +0100, Florian Weimer wrote:
> * Moritz Mühlenhoff:
>
> > * Follow a scheme similar to Firefox ESR where in case of a security
> > the update either happens to the latest minor release of
> > the current branch or if that has stopped, happens to the next
> >
Catching up on this...
> > This leaves Debian with two options:
> > * Keep it out of a stable release and accept that it's good enough
> > if people just install whatever deb they currently find in testing/sid
> > (works out well enough for most given that blob nature of Go!)
>
> IMHO this
* Moritz Mühlenhoff:
> * Follow a scheme similar to Firefox ESR where in case of a security
> the update either happens to the latest minor release of
> the current branch or if that has stopped, happens to the next
> major release. To map this to specific k8s releases: Let's assume bullseye
On Wednesday, 28 October 2020 6:13:41 AM AEDT Moritz Mühlenhoff wrote:
> The bigger issue here (independent of the whole vendoring aspect) is
> how kubernetes can be supported in a stable release to begin with.
> This was raised by Shengjing Zhu in #959685 before.
If Kubernetes can be supported th
On Wed, Oct 21, 2020 at 08:22:11AM -0700, Sean Whitton wrote:
> Hello security team,
>
> The TC are being asked about src:kubernetes, and it would be good to
> hear from you about whether and how security support is a relevant
> consideration in determining whether the level of vendoring in that
>
On Friday, 23 October 2020 4:20:37 AM AEDT Shengjing Zhu wrote:
> However kubernetes is also a library, and the maintainer doesn't provide
> it. It becomes headache for other maintainers.
Yes we have to vendor "k8s.io/" all the time in multiple packages but I doubt
it would be of help if Kubernet
On Thursday, 22 October 2020 2:22:11 AM AEDT Sean Whitton wrote:
> The TC are being asked about src:kubernetes, and it would be good to
> hear from you about whether and how security support is a relevant
> consideration in determining whether the level of vendoring in that
> package is acceptable.
On Tue, Oct 20, 2020 at 12:16:03PM -0700, Sean Whitton wrote:
>
> - are people trying to do cross-archive work going to find the packaging
> of kubernetes getting in their way? (e.g. other Go team members
> trying to update things, improve our binNMU techniques and machinery,
> etc.)
>
Th
On Thursday, 22 October 2020 2:16:16 AM AEDT Sean Whitton wrote:
> I think that we can all agree with everything you've written about the
> reasons why packaging components separately is better.
Thank you.
> The problem is
> that in this case the choice seems to be between not having recent
> K
On Wednesday, 21 October 2020 8:56:53 PM AEDT Felix Lechner wrote:
> How is the second one inferior, please? I think it includes a crucial
> missing feature (co-installable versions).
To reduce maintainers burden, you want maintainers to look after not one but
multiple versions of libraries. This
Hello security team,
The TC are being asked about src:kubernetes, and it would be good to
hear from you about whether and how security support is a relevant
consideration in determining whether the level of vendoring in that
package is acceptable. Could you take a look at #971515 and perhaps
give
Hello,
On Tue 20 Oct 2020 at 06:52pm -07, Felix Lechner wrote:
> I think our response to the vendoring explosion is at odds with the
> trends in many languages.
>
> It's time to retool. At the two ends of the solution spectrum, I see
>
> 1. Fully vendored source packages; or
> 2. A packa
Hello Dmitry,
On Wed 21 Oct 2020 at 11:21am +11, Dmitry Smirnov wrote:
> On Wednesday, 21 October 2020 6:16:03 AM AEDT Sean Whitton wrote:
>> I think that my message [1] is what makes you think that the package
>> would not have got through NEW?
>
> It was not your message but my own experience w
Hi Dmitry,
On Wed, Oct 21, 2020 at 12:50 AM Dmitry Smirnov wrote:
>
> Yes, at first there will
> be a significant effort but then it will become easier.
I know you put a lot of effort in (as did Michael Stapelberg, with
whom I spent some time before he left), but I don't think our current
approa
Hi Felix,
On Wednesday, 21 October 2020 12:52:40 PM AEDT Felix Lechner wrote:
> > We favour technical elegance often in expense of maintainers' comfort.
>
> Is our approach really either one of those? I think our response to
> the vendoring explosion is at odds with the trends in many languages.
Hi Dmitry,
On Tue, Oct 20, 2020 at 5:24 PM Dmitry Smirnov wrote:
>
> Let's not attempt to fabricate perception of consensus please.
Consensus is a worthy goal and perhaps even possible, per below.
> We favour technical elegance
> often in expense of maintainers' comfort.
Is our approach really
On Wednesday, 21 October 2020 6:16:03 AM AEDT Sean Whitton wrote:
> I think that my message [1] is what makes you think that the package
> would not have got through NEW?
It was not your message but my own experience with introducing of 100+
packages through NEW, especially those ones with large
Hello Dmitry, others,
On Thu 01 Oct 2020 at 11:15am +10, Dmitry Smirnov wrote:
> I seek your judgement regarding excessive, unnecessary and unjustifiable
> vendoring of private libraries in Kubernetes package:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970717
>
> Some relevant argume
Package: tech-ctte
Severity: normal
X-Debbugs-CC: o...@debian.org
Control: block 970717 by -1
Dear Technical Committee,
Apologies that we were not able to resolve the problem without your help.
I seek your judgement regarding excessive, unnecessary and unjustifiable
vendoring of private librarie
36 matches
Mail list logo
