Hi Bjoern,

bjoern gohla wrote on Sat, Nov 28, 2020 at 12:27:47PM +0000:

> i'm fairly new to openbsd. and i've run into the following problem,
> where i want to hack a project (most recently trying to fix a possible
> issue with i3status), but building the from the git source
> tree fails.
> 
> now, in the specific case, i'm trying to build a version that,
> also exists in ports, so we know it can be built on openbsd; and i
> presume the various patches included with the port are what makes it
> work.
> 
> i could of course try to apply those patches and fix my issue. but then
> when i submit a PR upstream i'd have to remove them again. that seems
> cumbersome, expecially if done repeatedly.
> 
> so what is the best practice in this situation? should i just upstream
> the ports patches?

It really depends on the case at hand.

Some patches can be upstreamed, only nobody did the work yet.
Some patches cannot be upstreamed because upstream never makes releases.
Some patches cannot be upstreamed because OpenBSD developers
  disagree with upstream about whether they are needed/useful/right.
Some (few) patches cannot be upstreamed because they deliberately
  change functionality in the OpenBSD port only.

So, let's assume you end up with some patches that will have to
stay or at least to stay for now.

Some of those may be required in the port, but the upstream build
system may at least be able to do builds without them.  Sometimes,
development for upstream purposes can be done without having such
patches in your upstream development tree.

But you may well end up in a situation where a small number of
patches may be required in your checkout of the upstream code to
do upstream-style builds at all.  In that case, you just need to
be careful to not include these patches when sending patches upstream.
And whenever sending patches upstream, you should of course consider
whether those are indeed independent of any other patches you can't
help having in your tree.

Nobody can save you from the work of understanding every single
patch you use before trying to send anything upstream...

These ideas are good enough for a port with moderate amounts of
patches (like textproc/groff).  The x11/i3status port might be of
a similar category.  I have no idea whether working on a behemoth
of the www/chromium kind (which has over 750 patches) and submitting
patches upstream without causing mixups would be feasible on OpenBSD.
There is certainly a limit to practicality, somewhere.

Yours,
  Ingo

Reply via email to