20XXQN ports branches [was: [HEADSUP] pkg(8) is now...]

[Ben Morrow]

Quoth Paul Mather <paul at gromit.dlib.vt.edu>:
> 
> Fairly recently, there was launched a "stable" ports branch.  This is 
> updated quarterly, and seems akin to the quarterly releases of pkgsrc 
> in that the given branch receives only security updates after it is 
> created.  It appears to be fairly low-key.  I remember seeing an 
> announcement on several FreeBSD mailing lists about its initial 
> release, but haven't seen anything since (even though I believe it is 
> now in its second quarter, at least).
> 
> My question is this: does anyone have experience of tracking ports via 
> these branches?  Does it work well?  I can see that it would be 
> advantageous to those wanting less frequent churn.  I wonder, though, 
> whether it doesn't just postpone the headaches to a quarterly basis, 
> when the next branch is made.  It would seem that all the churn would 
> come all at once.  Some people recommend not going too long between 
> ports updates because there's an increasing probability something will 
> fail to update the longer you wait.  Is a quarter just right in terms 
> of time?

I'm tracking these branches, though not in any sort of 'enterprise'
environment, just for a couple of servers and a couple of desktops. I
have to say it's a huge improvement, at least with the time I have to
dedicate to keeping things up-to-date: given the amount of general churn
in the ports tree at the moment, I had actually taken to keeping a local
stable branch of the tree in git, and cherry-picking specific ports as I
needed them. (The fact that I switched from portmaster to poudriere,
which insists on rebuilding everything that's changed, didn't help.)

Needless to say, this was a tiresome process: I had some scripts which
would take a port, find its deps, and try to cherry-pick what was
needed; but it often didn't work right, and I had to just bite the
bullet and merge the main ports tree in. (At which point I had lots of
merging fun to deal with.)

So, having someone else do this work, in a somewhat more organised
manner, is a big win for me :). (Thank you, bapt@ and everyone else
involved.) So far I've only gone through one rollover (Q2->Q3), and,
while it took a bit of effort to merge forward my local changes and
while I ended up rebuilding nearly everything, it was relatively
painless. Certainly a great deal easier than having to run around
chasing deps every time a security advisory came out.

One thing I'm not entirely clear about, though, is the policy about what
gets MFHed. I was expecting that any port with a current SA would be
updated (and nothing else would), but currently I have firefox-esr,
nginx-devel, serf and subversion showing advisories and they don't
appear to be going to be updated in 2014Q3. Firefox, in general, puzzles
me: I've had to backport FF updates several times because of advisories,
and yet Chromium (say) seems to get regular MFHs.

> I don't believe the "stable" ports branches are completely like the 
> pkgsrc quarterly releases.  As far as I know, the pkgsrc quarterly 
> releases are a chosen subset of the regular pkgsrc rolling release 
> version, whereas the "stable" ports branch is a snapshot of ports at a 
> given time.  I don't know what measures are taken to ensure that one 
> version of the "stable" ports branch can upgrade to the next "stable" 
> ports branch.  Is it left as an exercise for the reader to pore through 
> /usr/ports/UPDATING and work out what is needed to be fixed by hand?

I'm not quite sure what you mean here: yes, you still have to read
UPDATING whenever a port actually gets updated. The ports tree in
general goes to a lot of effort to make upgrades work in spite of
occasional upstream stupidity; when this can't be done automatically,
UPDATING is the only option. 

Ben