ideally, trunk. If they're accepted On Thu, Jan 23, 2014 at 12:01 PM, Erik Pearson <e...@adaptations.com> wrote: > Thanks. That was what I was afraid of, but is sensible. From my point of > view, I guess I could have a spare copy of 2.4.x to which I apply one patch > at a time, purely for the purposes of patch submission? I probably can't > hold up my work by waiting for 5 or 6 patches to be processed sequentially. > Since patches are not submitted via svn, here is how I understand the > process of patch submission: > > 1. obtain copy of 2.4.x via svn checkout > 2. edit files involved in one change > 3. create patch files with svn diff > 4. submit patch files via bugzilla > 5. via bugzilla engage with httpd developers to get the patch accepted (or > not) > 6. after patch is accepted and applied, the local copy needs to be reverted > and updated (or just deleted and checked out again) so that future edits are > against the newly patched codebase.
ideally work based on trunk. This will also shorten how long it takes to get rid of your local changes. You can back them out after you create the diff and accept what gets committed, which might have minor changes that would conflict with your stuff > > For multiple patches, just repeat. > yes, and send an email if not getting any attention in bugzilla.
