harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Gorr" <vvg...@gmail.com>
Subject Re: DRLVM contribution - try this out!
Date Sat, 06 May 2006 01:13:25 GMT
Certainly all I'll say is obvious but ...
Suppose the patches A & B should change same lines of sources code to fix
the different bugs.
They cannot be accepted independently. Other example when the B patch is
created after as A was accepted.
In this case we should describe the exact order these patches should will be
accepted in (a good example is JIRA-443).
I  had in mind these things speaking about the advisability to have one
patch for the user convenience.

Thanks,
Vladimir.

On 5/5/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>
> +1 to Geir's comments below (i.e. that's my preference too)
>
> Regards,
> Tim
>
> Geir Magnusson Jr wrote:
> >
> >
> > Leo Simons wrote:
> >> On Thu, May 04, 2006 at 04:50:28PM -0700, Rana Dasgupta wrote:
> >>>   We should probably hold off on patching right now?
> >>
> >> I don't see why you can't attach patches to the relevant jira issue,
> >> if the
> >> code is accepted then its likely the patch will be, too :-)
> >
> > Personally, I'd prefer that new JIRAs are created and linked to the
> > original submission issue, because then we can accept and close JIRAs
> > atomically.
> >
> > We ran into a problem when patches to patches were attached to the same
> > JIRA, and it becomes a bit confusing to try and figure out which is
> > right from the comments.
> >
> > It's much cleaner to say "This patch replaced the patch in HARMONY-XYZ"
> > rather than "this patch replaces the other one I did before I submitted
> > the extra build file" or whatever...
> >
> >>
> >> Patch management is going to be hard if there's a lot of patches, but
> >> that's
> >> just further incentive to get things integrated more quickly ;-)
> >>
> >>>   The submission compiles and runs fine with XP V2, msvc VC7 and with
> >>> SUSE
> >>> 9.2 and GCC 3.3.4.
> >>>   We should pick the Linux/GCC version that we  run Harmony builds
> >>> regularly on and make all the changes in one shot to fix the compile
> on
> >>> that. Has this version already been identified?
> >>
> >> Hmm. I think the key is in making the buildsystem and the code aware of
> >> the linux/gcc version and adapt behaviour based on that.
> >>
> >>>> Is it ok to attach patch here or should I use JIRA?
> >>
> >> In general sending patches through the mailing list is not all that
> >> bad, but
> >> the people integrating code (eg, Tim :-)) do seem to prefer to use
> >> JIRA, so
> >> after talking about things on the list, adding them to jira does make
> >> sense.
> >
> > Yep - JIRA makes it much easier to track and search and know status.
> >
> > geir
> >
> >>
> >> cheers!
> >>
> >> LSD
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message