On Sat, Nov 02, 2019 at 02:35:28PM +0100, Solene Rapenne wrote: > On Sat, Nov 02, 2019 at 01:18:53PM +0000, Stuart Henderson wrote: > > On 2019/11/01 19:16, Theo de Raadt wrote: > > > Ted Unangst <t...@tedunangst.com> wrote: > > > > > > > Theo de Raadt wrote: > > > > > What about all the other users who aren't in staff? > > > > > > > > > > I think the approach is right. Push non-interactive down. > > > > > > > > The same then for src build user? > > > > > > Well, that's different. Most of us building the src tree are waiting > > > eagerly for it to finish aren't we? > > > > That's the same for ports building! > > > > if you don't do anything else than compiling ports, that shouldn't be > slower. > If you are doing something else (GUI user, web server, community server > with people connected doing IRC) , then you don't get angry due to > unresponsive system. > > Lowering staff priority would only help the one user case.
I agree with solene on that one. This is actually useful even if you're just building ports, because you get a more responsive text-editor and stuff like that which is useful when you're fixing things that broke while dpb is still going. I see a noticeable difference in vim showing me syntax coloring correctly while dpb is running. Source is somewhat different. make build/release is sequential by nature, as you can't really fix a part while something else is still building.
