Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Apr 2017 19:03:22 +0000
From:      Grzegorz Junka <list1@gjunka.com>
To:        freebsd-ports@freebsd.org
Subject:   Re: Is pkg quarterly really needed?
Message-ID:  <127a5f89-93ba-aee4-14d3-41e2f2d71892@gjunka.com>
In-Reply-To: <20170420171119.GJ74780@home.opsec.eu>
References:  <58F61A8D.1030309@a1poweruser.com> <CALfReyctL3vTt756oyh1ZTf%2BkgpAOHwp_SUZQCFQiZDccFNMow@mail.gmail.com> <ljhffcphq3bqr8dk2lrlld11ola28b7gqp@4ax.com> <29e44642-e301-f07c-afe3-bad735d8ee5e@freebsd.org> <20170420053722.GD31559@lonesome.com> <b9d24938-5502-cc69-30ed-1941c2517849@gjunka.com> <20170420084452.GH74780@home.opsec.eu> <99a57878-ae39-d2a4-fe35-023dae8b320b@gjunka.com> <20170420171119.GJ74780@home.opsec.eu>

next in thread | previous in thread | raw e-mail | index | archive | help

On 20/04/2017 17:11, Kurt Jaeger wrote:
> Hi!
>
>> Fine, but would that be a good approach? Doesn't it look more like a
>> process change than a code change?
> For me, it does not look like a process-change only.
>
> I haven't thought through all the details, I'm going with my
> intuition here (because thinking it through takes a long time).
>
> One number: I made approx. 40 commits to quarterly trees in 2 years,
> and broke it one least once, probably more often. Go to
>
> https://secure.freshbsd.org/search?committer=pi
>
> and then limit the view to the 8 quarterlies and check those commits.
> It might as well be my sloppiness, but...
>
>> Surely, some code would need to be
>> changed but then again, wouldn't that be mostly configuration?
> My gut feeling says it's more than a little change and a bit
> of configuration.
>

I understand that the main problem with quarterly branches is that they 
start from an unstable edge and mature with time, then after three 
months at the most mature point they are being deleted and replaced with 
a new unstable edge. So, there is no good point of reference to use as a 
source of packages.

What I described is taking the good points (maturing the code through 
progressing version upgrades from CURRENT, through STABLE to RELEASE) 
while keeping good builds as reference points (monthly in CURRENT since 
it changes more often and partial builds may be too often for the server 
to handle, fortnightly in STABLE, and weekly in RELEASE since it is 
expected to contain least breaking changes and full builds are preferred 
over partial builds). Only X last builds would be kept for each of these 
three branches. From that short description it should be more or less 
obvious if that approach is better/doable when opposed to quarterly 
branches?

Grzegorz



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?127a5f89-93ba-aee4-14d3-41e2f2d71892>