Date: Mon, 25 Apr 2016 12:22:02 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Roland Kammerer <roland.kammerer@linbit.com>
Cc: alpine-aports@lists.alpinelinux.org
Subject: Re: [alpine-aports] [PATCH 2/2] testing/drbd9-grsec: upgrade to
 9.0.2
Message-ID: <20160425122202.0717a996@ncopa-desktop.alpinelinux.org>
In-Reply-To: <20160422130731.GU1371@rck.sh>
References: <1461273747-10283-1-git-send-email-roland.kammerer@linbit.com>
	<1461273747-10283-2-git-send-email-roland.kammerer@linbit.com>
	<20160422142444.358c4bd5@ncopa-desktop.alpinelinux.org>
	<20160422130731.GU1371@rck.sh>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 22 Apr 2016 15:07:32 +0200
Roland Kammerer <roland.kammerer@linbit.com> wrote:

> On Fri, Apr 22, 2016 at 02:24:44PM +0200, Natanael Copa wrote:
> > On Thu, 21 Apr 2016 23:22:27 +0200
> > Roland Kammerer <roland.kammerer@linbit.com> wrote:
> >   
> > > - New upstream release
> > > - Changed download url
> > > ---
> > >  testing/drbd9-grsec/APKBUILD | 12 ++++++------
> > >  1 file changed, 6 insertions(+), 6 deletions(-)  
> > 
> > This and drbdmanage was applied. Thanks!
> > 
> > I am about to do a v3.4 release. I wonder if you think we can move
> > drbd9-grsec and drbdmanage to main repository? can we expect upstream
> > bug fixes for at least 6 months (if any) and upstram sec fixes for
> > about 2 years?  
> 
> Hi Natanael,
> 
> How is the policy for "main" and a given release? Maybe I missed it, but
> at a first look I did not find a policy. Are version bumps allowed? If
> so, what are the rules? Guess "no regressions" would be one ;-). Or is
> it more like Debian stable where the version is pinned and only fixup
> patches are allowed?

The general rule is that if you use a stable repository (eg v3.3), then
you should be able to `apk upgrade -U` without need to worry that
anything breaks. that means, we cannot break ABI in a stable branch. We
can not introduce changes that requires user to change configuration to
make things work.

Generally speaking, only bugfixes should go there.

We prefer using upstream version bumps over backporting patches (Debian
style) because it is less work for us, but often we backport sec fixes
because upstream only provides version bumps that breaks things (break
abi or require user to reconfig things).

We also accept exceptions, where we backport new functionality if there
are good reasons to do so and if it does not break anything for
existing users.

So, for drbd, we would like minor version bumps for v3.4/main and sec
fix releases. Those should preferable not introduce new functionality,
but we may accept them if they don't introduce breakages.

I don't have the impression that drbd introduce big revolutions every
minor release so I don't think there will be any problem.

What I don't want is, that in 1.5 years in future, there show up a
critical sec issue in drbd9 and the *only* way to fix it is to upgrade to
drbd13 which require full reconfiguration and ABI incompatible libary
updates and recompile of half the world.

Bascially what I want is to be sure that we can minor sec fix release
bump or maybe even getting help in backporting sec fixes for 2 years if
needed.

Thanks!

-nc


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---