Is pkg quarterly really needed?

[Grzegorz Junka]

On 20/04/2017 05:37, Mark Linimon wrote:
> I understand that having the quarterlies is not meeting your use case.
> You've said that.  We get it.
>
> So you want some kind of running -quarterly branch.
>
> But where are the N hours of work per week to QA all the patches to
> the -quarterly branch, or a -stable branch, or whatever people seem
> to demand, to come from?
>
> This is a serious -- if very irritated -- request.
>
> We've moved from a "we don't have enough person-power to manage a ports
> branch" to "we kinda have enough person-power to manage both head and a
> kinda-branch."  OK.  That isn't meeting all the use cases.  Understood.
> (...)
>
> Honestly without some volunteers to do the _hard_, _unrewarding_, work
> to QA the ports tree, this is all either a) just talk, or b) people
> wanting volunteers to provide professional-level support, for free.
>
> tl;dr: provide some resources, or don't.  I am getting to the point where
> I don't care either way.  All I see is the people who are doing actual work
> get poked in the eye.
>

I am not sure if this is a rant in favour or against quarterly branches. 
And this discussion comes up again and again quite regularly. I wonder 
why ports don't follow the development model of the FreeBSD kernel? In 
short:

1. CURRENT - latest upgrades from upstreams, a broken port or a port 
that breaks other ports shouldn't be committed but not all option 
combinations are fully tested. Don't rebuild all ports, at least not 
often (maybe once a month), but rebuild all dependant ports of a port 
whenever a change in that port has been made.

2. STABLE - Only upgrade ports to the version from CURRENT when users 
haven't reported any issues with any combination of options for that 
port for some agreeable period of time since the upgrade in CURRENT 
(e.g. 2 weeks, a month). Rebuild all ports more often than in CURRENT 
(e.g. fortnight) but also not too often. Like in CURRENT rebuild all 
dependant ports whenever a port on which they depend has changed.

3. RELEASE (optional) - Like STABLE - only upgrade ports to the version 
from STABLE if no issues with any combination of options has been 
reported for some agreeable period of time since the upgrade in STABLE 
(e.g. 2-3 months this time). Rebuild all ports more often than in STABLE 
(e.g. once a week). Also like in STABLE rebuild all dependant ports when 
a port on which they depend changes.

Each branch would keep X latest full rebuilds (one, two, three - 
depending on resource availability) and the partial rebuilds in between 
them when dependant ports are rebuild - I think poudriere would copy 
them to the latest directory with packages by default.

This could give something folders like:

CURRENT month 1
any partial rebuilds on top of month 1
CURRENT month 2
any partial rebuilds on top of month 2
...

STABLE week 1
any partial rebuilds on top of week 1
STABLE week 3
any partial rebuild on top of week 3

RELEASE week 1
any partial rebuilds on top of week 1
RELEASE week 2
any partial rebuilds on top of week 2
RELEASE week 3
any partial rebuilds on top of week 3

etc.

Then it would be a matter of creating a scheme for url addresses for 
easy access to these folders with build packages.

Grzegorz