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 Fri, 19 May 2006 15:02:28 GMT
On 5/19/06, Andrey Chernyshev <a.y.chernyshev@gmail.com> wrote:
>
> On 5/19/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> > IMHO, I would prefer new patch attached. Say, named like:
> >  DRLVM-GCC-3.4_and_4.x-cumulative_v2.patch
> >  DRLVM-GCC-3.4_and_4.x-cumulative_20060519.patch
> >
> > It could help people if something is working with old patch and
> > suddenly stop working with new one. Please, write small description
> > with patch instructions. List of changes are also welcomed.
> > --
> > Ivan
>
> And I'm assuming each next patch would include the previous one, right?
> I think it should be possible to get the contribution, then apply just
> the latest _single_ patch and expect that the code most likely will be
> working.
>
> From that perspective, it probably may make sense to name the patches
> in a more or less generic way, say DRLVM_cumulative_patch_1,
> DRLVM_cumulative_patch_X, ...
> since not all of them will necessarily fix the GCC issues.
>
> And each new cumulative patch created should probably go to a separate
> JIRA, as Geir suggested.
>
> Folks, does anyone have more ideas what could be the most optimal way
> to maintain DRLVM for the interested parties while it isn't accepted
> in SVN?


Whether does it make sense, say, to create the temporary workspace
(incubator into incubator :-) )
where any of contributions can be placed untill voting happen? After it will
occur all changes made here
can be propagated in the parent workspace and the child one can be removed.
In this case there are no needs
to create a lot of patches and number them.

Gang, is such approach possible?

Thanks,
Vladimir.


Thanks,
> Andrey,
>
> >
> > 2006/5/19, Vladimir Gorr <vvgorr@gmail.com>:
> > > Small changes are required to fix the build issue for Fedora 5.
> > > I've prepared this patch and I'm ready to put it into JIRA.
> > > There are two ways to make this thing:
> > > - renew the cumulative patch created by Ivan (see JIRA issue below);
> > > - attach these changes as separate patch and adding it to the
> HARMONY-443.
> > >
> > > What way is more preferable?
> >
> > ---------------------------------------------------------------------
> > 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
>
>

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