Looks good. If you like git more you can also use git (http://git.apache.org/httpd.git) create local branches for each patch and submit the diffs.
Regards Rüdiger Von: Erik Pearson [mailto:[email protected]] Gesendet: Donnerstag, 23. Januar 2014 18:01 An: [email protected] Betreff: Re: mod_session and friends need some help 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. For multiple patches, just repeat. Is that about it? On Thu, Jan 23, 2014 at 4:11 AM, Eric Covener <[email protected]<mailto:[email protected]>> wrote: On Thu, Jan 23, 2014 at 1:35 AM, Erik Pearson <[email protected]<mailto:[email protected]>> wrote: > Would it be acceptable to submit a related set of patches to code and > documentation, accompanied by a comment or document that describes the whys > and wherefores? Would that make the process of patch evaluation too > complicated? Generally, that makes things harder on the potential reviewer and slows things down. -- Erik Pearson Adaptations ;; web form and function
