how do you maintain your patches?

PMc

PMc

As soon as you change a thing on the system, may it be base OS or may it be ports, you have some kind of a patch.
Now my question is: how do You handle these patches?

Considering that last year we had the 10th anniversary of my bug report (and patch) to the base-OS, PR 122519(*) (which is the reason I don't bother to get an account for the new bug tool), these patches can stay around for quite a while and during multiple releases. SVN does a nice job in merging those things in when upgrading to another release - but nevertheless, they lure around in the source tree, without proper documentation, and tend to get forgotten.

So, one can either live with that, or think about a solution...


(*) and this is not the only one, see e.g. here, or here:
https://stackoverflow.com/questions/53715647/ruby-bundler-fails-with-errnoerofs
https://groups.google.com/forum/#!topic/bareos-users/lAlWhIdXPXk
Probably, these people tend to expect that one becomes a member of their specific developer communities (and adhere to their specific buerocracy), in order to deliver fixes - which then may or may not help the issue. But then, we have some 25'000 ports, and I definitely do not want to become member in dozens of whatever things, just because some coding error decides perchance to hop into my face so that I need to fix it.
 
I tend to use local branches in Git.

I understand your frustration that your PR was not addressed. It sucks, but try not to take it personally. We have more PRs than human resources to deal with them all. You might get the attention of a developer familiar with that code by requesting attention on the appropriate mailing list.
 
jrm@ said:
I tend to use local branches in Git.
Click to expand...

Ah. There is this perspicious discussion that basically concludes that SVN cannot serve two masters, but git probably can. Sadly, I'm not familiar with git.

I understand your frustration that your PR was not addressed. It sucks, but try not to take it personally. We have more PRs than human resources to deal with them all. You might get the attention of a developer familiar with that code by requesting attention on the appropriate mailing list.
Click to expand...

No, I'm not frustrated! As shown, the matter is not limited to only the OS. And this can be managed by technical means - leading to a two-fold benefit: having transparency on what exactly is changed in the trees, and. in case somebody appears willing to look after some issues, not having the effect of "oh yeah, there was some issue and I posted it somewhere some time ago <ponder along>", but to have all such information as well with one grab.
 
I think the "technical approach" is quite feasible.

I have now some scripts in place that do:
  • maintain local patches to the source-tree (different for different machines, and including the KERNCONF and make.conf).
  • maintain local patches to the ports-tree (i.e. patches to any port).
  • maintain the list of ports to be built/installed
  • maintain the options files for the ports
  • maintain the actual dependencies between ports (in contrast to the mostly useless INDEX file)
  • and rebuild all respective things appropriately when something has changed.
All the material is put into a local SVN repo, with switchable branches to reflect usual workflow (new/current/old).

This is probably not a solution for people who do extensive development on the OS; I think it's best for managing a bunch of machines with certain local adjustments, while maintaining accountability on exactly what is or was configured where.
 
You must log in or register to reply here.
Back
Top