Actually, the more I've delved and actually used mod_session and friends, the more fundamental the changes have become. For instance, a lot of the code that lives in mod_session_cookie and mod_session_dbd seems more appropriate for mod_cookie -- including session name, session caching, session object creation. With such changes, it is quite difficult to isolate into single issue diffs. On the other hand, the changes may be fundamental and breaking enough that should I share them back it might be better for them to become new modules. The incompatibilities are mostly in configuration, but there is one element of the session load hook that would be slightly different. The interface with session consumers is not changed, of course. What do you think?
On Thu, Jan 23, 2014 at 10:41 AM, Plüm, Rüdiger, Vodafone Group < ruediger.pl...@vodafone.com> wrote: > 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:e...@adaptations.com] > *Gesendet:* Donnerstag, 23. Januar 2014 18:01 > *An:* dev@httpd.apache.org > *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 <cove...@gmail.com> wrote: > > On Thu, Jan 23, 2014 at 1:35 AM, Erik Pearson <e...@adaptations.com> > 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 > -- Erik Pearson Adaptations ;; web form and function
