harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: DRLVM contribution - try this out!
Date Tue, 23 May 2006 18:41:03 GMT


Vladimir Gorr wrote:
> 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?

No.

:)

geir

> 
> 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
>>
>>
> 


---------------------------------------------------------------------
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
View raw message