I think you forget that we have the ability to create branches. Having a single "clean" integration on the main trunk doesn't preclude us from using tracking branches for third party software. This can make it easy for folks to perform diffs, reintegrate, etc. I feel very strongly that we should not break our "1 commit per bug" policy on the main trunk.
The rest of the information can be made trivial available in the branches. For example, I created a local branch called mdocml-1.12.1 reflecting my integration of mdoc-1.12.1 solely. I'd be happy to push that branch up to the main repo, so other people could see it, and future maintainers could use it when figuring out how to merge against newer versions of the upstream. Thanks. On Wed, Jul 16, 2014 at 2:14 PM, Hans Rosenfeld via illumos-discuss < [email protected]> wrote: > [ moving to illumos-discuss, as this is no longer about mandoc review ] > > On Wed, Jul 16, 2014 at 01:43:23PM -0700, Garrett D'Amore via > illumos-developer wrote: > > Every bug has at most one commit (barring exceptional cases) for it. > Stuff > > is supposed to be integrated wholly functional, so that we never have a > > partially working gate -- sort of "always release ready". Of course we > do > > occasionally have bugs, but hopefully those are infrequent. > > What I was suggesting was adding mandoc as is, but not enabling it in > any Makefile, in the first commit. The gate is still fully working and > "release ready". The second commit would add our local patches on top > and change the Makefiles to actually build mandoc. > > > In general, I imagine this evolving into something like this: > > Assume we want to integrate tool XYZ version 1.2.3. The first commit > puts it as-is into usr/src/external/XYZ-1.2.3, then a second commit adds > reachover Makefiles to usr/src/cmd/XYZ and enables the build of the > tool. Of course we would want to integrate both at the same time to not > have unused code lingering around in the gate. > > When later someone wants to update tool XYZ to version 1.3.5, the first > commit adds it as-is to usr/src/external/XYZ-1.3.5. The second commit > ports our adaptations from the old version, adds any new adaptations, > and enables the build of the new version. A third commit could remove > usr/src/external/XYZ-1.2.3. Again, all of that would be put into the > gate in one go. > > > While that is obviously different from what we normally do for normal > changes, I think it makes sense for handling integration of externally > developed code. It does at no time break the build, and keeps all > information about the changes made against the original source. > > As far as I can tell, whenever we have taken foreign source into > illumos-gate, we have asked for a diff against the original in the > review process. I think thats very reasonable, so why not keep this > information in the gate? > > > Hans > > > -- > %SYSTEM-F-ANARCHISM, The operating system has been overthrown > > > ------------------------------------------- > illumos-discuss > Archives: https://www.listbox.com/member/archive/182180/=now > RSS Feed: > https://www.listbox.com/member/archive/rss/182180/22003744-9012f59c > Modify Your Subscription: > https://www.listbox.com/member/?&; > Powered by Listbox: http://www.listbox.com > ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
