X-Original-To: alpine-aports@mail.alpinelinux.org Delivered-To: alpine-aports@mail.alpinelinux.org Received: from mail.alpinelinux.org (dallas-a1.alpinelinux.org [127.0.0.1]) by mail.alpinelinux.org (Postfix) with ESMTP id 63A09DC0EE6 for ; Mon, 25 Apr 2016 10:51:49 +0000 (UTC) Received: from zimbra13.linbit.com (zimbra13.linbit.com [212.69.166.240]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id E7A48DC07D9 for ; Mon, 25 Apr 2016 10:51:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra13.linbit.com (Postfix) with ESMTP id 71C7A40B1AA; Mon, 25 Apr 2016 12:51:47 +0200 (CEST) Received: from zimbra13.linbit.com ([127.0.0.1]) by localhost (zimbra13.linbit.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id EtbjFfPEh2HH; Mon, 25 Apr 2016 12:51:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra13.linbit.com (Postfix) with ESMTP id 520B740B1D3; Mon, 25 Apr 2016 12:51:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at linbit.com Received: from zimbra13.linbit.com ([127.0.0.1]) by localhost (zimbra13.linbit.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3VO_pZqbT0tL; Mon, 25 Apr 2016 12:51:47 +0200 (CEST) Received: from localhost (chello213047144126.1.15.vie.surfer.at [213.47.144.126]) by zimbra13.linbit.com (Postfix) with ESMTPSA id 1DC1740B1AA; Mon, 25 Apr 2016 12:51:47 +0200 (CEST) Date: Mon, 25 Apr 2016 12:51:46 +0200 From: Roland Kammerer To: alpine-aports@lists.alpinelinux.org Cc: Natanael Copa Subject: Re: [alpine-aports] [PATCH 2/2] testing/drbd9-grsec: upgrade to 9.0.2 Message-ID: <20160425105146.GZ1371@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> <20160425122202.0717a996@ncopa-desktop.alpinelinux.org> X-Mailinglist: alpine-aports Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160425122202.0717a996@ncopa-desktop.alpinelinux.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Apr 25, 2016 at 12:22:02PM +0200, Natanael Copa wrote: > On Fri, 22 Apr 2016 15:07:32 +0200 > Roland Kammerer 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 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. In that case I suggest the following: Let's move drbd9 to main. Security fixes and don't break the upgrade path is something our (Linbit's) customers expect anyways. It should always be save to upgrade drbd (kernel side and user space). Drbdmanage is a relatively young project and while basically the same rules apply, I simply don't want to make these guarantees. We are close to 1.0, but who knows, there might be a 2.0 in a few months which breaks the dbus API, configuration files, and what not. This should not happen, but I don't want to maintain old crap I then don't really care about anymore... So for now I think we should keep it in testing. While drbdmanage makes using drbd a lot more comfortable, drbd backing devices can be manually created and configuration files can be scp'ed. Not having drbdmanage in main is no show stopper for drbd itself. Regards, rck --- Unsubscribe: alpine-aports+unsubscribe@lists.alpinelinux.org Help: alpine-aports+help@lists.alpinelinux.org ---