Date: Fri, 24 Jan 2020 12:03:54 +0100
From: Natanael Copa <ncopa@alpinelinux.org>
To: "Drew DeVault" <sir@cmpwn.com>
Cc: "Ariadne Conill" <ariadne@dereferenced.org>,
 <~alpine/devel@lists.alpinelinux.org>
Subject: Re: Lets talk about apk-tools 3, and apk-tools in 2020 in general
Message-ID: <20200124120354.1d650b80@ncopa-desktop.copa.dup.pw>
In-Reply-To: <C03A5J4BZ2TN.2VO1P2UDDOI6Q@homura>
References: <1c4796e0cda2248c2de159d4d467421c@dereferenced.org>
	<C03A5J4BZ2TN.2VO1P2UDDOI6Q@homura>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 23 Jan 2020 10:36:10 -0500
"Drew DeVault" <sir@cmpwn.com> wrote:

> Thanks for writing this up, Ariadne. I agree with everything you said.
> I'd like to call attention to a few points:
> 
> On Thu Jan 23, 2020 at 3:13 PM, Ariadne Conill wrote:
> > * Changing the format in such a radical way brings significant
> > risk. The tar streams code has already been audited and a
> > few CVEs have been fixed over the years. Throwing that out
> > means we start over again, possibly reintroducing variations
> > of bugs we have already fixed. Many stakeholders have said
> > privately that they would rather not have exposure to this
> > risk and would prefer a more conservative approach.
> 
> We ought to be careful to avoid fixing things which aren't broken,
> noting that unoptimal != broken. I do NOT see APKv3 as an opportunity to
> scratch a bunch of itches. Let's keep the changes as small as possible
> and avoid throwing out lots of code, or introducing lots of new code.
> 
> We should structure these changes as slow, incremental improvements,
> where one change can be built and shipped and then fully battle tested
> before the next one lands. apk is used in many production systems today
> and has production-tier expectations of stability. The importance of a
> conservative approach is probably the most relevant take-away from this
> discussion.

I think this is good points. Slow incremental changes is to prefer.

However, I think we need to do some breaking, non-backwards compatible
changes like changing the index format. What I don't want is multiple
breaking changes, so we should try identify what changes that are
breaking, and try to do all those in one shot.

For example we don't want change the index and package formats multiple
times.

-nc