"Julian H. Stacey" <j...@berklix.com> wrote: Firstly, apolgies for the delay in replying.
> I wrote a tool in 1993 I still use > http://www.berklix.com/~jhs/bin/.csh/customise > to apply trees of generic & personal diffs to src & ports, for multi releases > http://www.berklix.com/~jhs/src/ > to apply diffs, where some are submitted, some committed > for some versions, some diffs still needed for older versions, & > some not submitted or committed. Thanks, I'll look at that. > I guess many, especially non-commiters, maintain trees of uncommited > diffs & there's probably other applicator scripts, numerous > re-inventing of wheels for decades, 'cos send-pr / > https://bugs.freebsd.org/bugzilla/enter_bug.cgi & volunteer unpaid > commiters can't keep up with submissions. Yep :-( And to the committers: I'm not meaning to complain - I know it's a volunteer effort, but sometimes it can be frustrating. This particular bug I've highlighted is laughably trivial and inconsequential, but as Julian says, there must be many people who end up doing the same thing, and that all adds up to lots of wasted work that could be better channeled. What can we do to help? > FreeBSD hackers(especially non commiters who must wait for commits > to reduce their heap of candidate diffs) would benefit from a unified > set of tools & directory formats to allow individuals to maintain > & export trees of candidate diffs etc to some common standards. > > It wouldnt obviate / replace send-pr & > https://bugs.freebsd.org/bugzilla/enter_bug.cgi & git etc, but would > be an optional normalied convenience, especially beneficial to those > who are Not commiters but who have growing heaps of uncommited patches. > > Maybe a summer of code or other person might look at Jamie's & my > applicator scripts, & diff tree shapes, not for our actual current diffs, > but to design common unified standards to export trees of candidate diffs > that can be applied by one common applicator tool ? > > Hacker who are not committers presumably accumulate an an ever > growing heap of diffs, a burden best normalised & automated. That's a good idea. I'm happy to describe/publish my mechanisms - I've been meaning to publish all my tools in case they help anyone, but time keeps getting in the way! As for the patches, it's quite basic: for src, all patch-files in a common directory-tree (synced to my machines along with other common directories/tools) are applied after each git sync. The tree contains directories for "all versions" patches, and then directories for differing FreeBSD versions. For ports, I have 3 sets of common patch directories: 1) Patches to the port-templates (i.e. the build files under /usr/ports) 2) Patches to the ports source itself. 3) "Overrides" - directories containing the port-templates for a port that are installed after a port-sync. These are usually "deleted" ports that I actually still use, local-port hacks that no-one else would care about, and less-often complete overrides of ports for various reasons. There is glue code to ensure these are all automatically actioned. I'd love to get involved with anything that can help streamline this, whether src or ports. Cheers, Jamie
