Is pkg quarterly really needed?

[Kurt Jaeger]

Hi!

> >> 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.
[how stable the repos appear for the users]

> I hardly remember a single upgrade to 
> the longest set that didn't result in some packages being broken. [...]
> most of those breakages resulted from me selecting non-standard options 

Ah, options. Leads to exploding complexity.

> So, my experience is quite different to yours...

Indeed.

> If the whole repository builds doesn't it mean by default that any 
> subset also builds?

If we defined a repo build only as valid if everything builds,
the whole repo is never valid, because approx. 10% of
the ports tree breaks at any given time. More, if you add options.

> My assumption was that only version 
> upgrades are progressed from CURRENT to STABLE to RELEASE.

Leads to a stagnating tree downstream, if you find maintainers for it.
That's the model Debian is using, and it has other issues. Especially
the load for the maintainers is huge, and users are unhappy
that the packages are getting old. Debian has approx. 6 times
more committers than we have, when I last looked, and more maintainers.

If we take from that that we have to grow our committer base, yes.
Can we reason that unless we have that base, we can't follow that
model ? Maybe.

> On the other hand developers would be more inclined to do changes in 
> CURRENT if they know that they are not going to break ports for the 
> majority of users who should use STABLE or RELEASE.

This fear to break something is not a big issue in general.
This is covered by build-tests using poudriere, most of the time.

It is an issue for those ports where lots of things depend on a
port, because of changes to that port that lead to cascading
failures.

> > It's just that asking the team that's barely keeping up
> > to do that *on top*, that will probably not work.

> That was supposed to be more like *instead* rather than *on top*.

As long as we're not plundering countries, we normally do not burn
the ships until it's safe to proceed 8-}

> >> From that short description it should be more or less
> >> obvious if that approach is better/doable when opposed to quarterly
> >> branches?

> > There's a way to find out: Try it.

> Not the best way TBH. I would rather hear some opinions first as I am 
> sure there are plenty of conditions and requirements I haven't even 
> imagined myself yet.

It's a good approach to learn about the requirements etc. Most
of the knowledge is, from what I understand, not documented
in a way that helps to write a requirements document. It's in
the code of the currently running system, like layers of
ashes in old cities. Reading those layers requires a certain mindset.

-- 
pi at opsec.eu            +49 171 3101372                         3 years to go !