On Mon, Apr 25, 2016 at 12:22:02PM +0200, Natanael Copa wrote:
> On Fri, 22 Apr 2016 15:07:32 +0200
> Roland Kammerer <roland.kammerer_at_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_at_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
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.
Received on Mon Apr 25 2016 - 12:51:46 GMT