Hi Joey,
I haven't had time to respond.
I don't know what the dependency method should be.
Your suggestion:
Is it acceptable to locally apply the earlier patch that has not yet
been committed and, in effect, include that patch in a new patch?
I think this is acceptable, because I don't think this new patch would get
reviewed until the first patch that it depends on gets checked in.
So then when we review the second patch, the differences won't be the
differences of both patches, just the second patch.
- Jeanne
Joseph Rozier wrote:
Hello,
I'm resending this since there was no response to the first one...
I'd particularly appreciate a response to what the desired way to
handle patch dependencies is, when one patch is dependent on another
patch that has not yet been committed. (The review/committing of the
outstanding PDA patches would be appreciated as well. :))
Thanks,
Joey
On 9/13/06, Joseph Rozier <[EMAIL PROTECTED]> wrote:
Hello,
The following two JIRAs have patches waiting to be reviewed/committed.
https://issues.apache.org/jira/browse/ADFFACES-167
Add 'autoSubmit' support for basic input components on PDAs
https://issues.apache.org/jira/browse/ADFFACES-110
Add Agent for BlackBerry Browser 4.0
(this has a fix to the original patch)
Would it be possible to get these two patches committed?
We have fixes for two other JIRAs (ADFFACES-172 and -173) ready to go,
but they have dependencies on these patches.
Also, for the future, what is the protocol for submitting patches that
have dependencies on earlier patches that have not yet been committed.
Is it acceptable to locally apply the earlier patch that has not yet
been committed and, in effect, include that patch in a new patch?
I can see how that would make patch reviewing a headache, but we're
running into the issue where a lot of the PDA patches have dependences
on earlier patches and it typically takes several days to get even
minor changes reviewed and committed.
Thanks,
Joey
