Is pkg quarterly really needed?

[Grzegorz Junka]

Fine, but would that be a good approach? Doesn't it look more like a 
process change than a code change? Surely, some code would need to be 
changed but then again, wouldn't that be mostly configuration?

Grzegorz


On 20/04/2017 08:44, Kurt Jaeger wrote:
> Hi!
>
>> 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?
> - lack of developer time
>    We have bapt who develops pkg. bdrewery, who does poudriere.
>    A small group works on the ports framework.
>    There are a few who report issues and fixes.
>    I think that's it, and all work on huge workloads.
>    They add features that are even more important than
>    perfecting quarterly. Quarterly was not meant to fix all issues,
>    it was meant as a test to learn what comes up if one provides
>    some more stable pkg tree besides the HEAD.
>
> - lack of maintainer and committer time
>    maintainers and committers have to track lots of changes,
>    and it's already hard to keep up with HEAD and quarterly.
>    So many changes are never merged to quarterly, because
>    it's difficult to grasp side effects.
>
> About the 'lack-of-time': Please visit
>
> https://bugs.freebsd.org/bugzilla/page.cgi?id=dashboard.html
>
> and look at the numbers. Do it from time to time. Plot
> the trajectory 8-} Submit patches to the bugzilla project that allows
> us to track the trajectory 8-}
>
> So, in general: trust the folks who do the complicated work, and
> please react in a friendly way to issues you encounter. Report
> them using bugzilla.freebsd.org. Search on bugzilla for
> similar reports and add to them with additional tests,
> reports etc.
>
> If, after all this 'keeping-up' leaves you with spare brain cycles,
> start submitting patches, and learn the big picture. It's amazingly
> complex!
>
>> Then it would be a matter of creating a scheme for url addresses for
>> easy access to these folders with build packages.
> The scheme has to be implemented in the tools.
>