harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: DRLVM contribution - try this out!
Date Fri, 19 May 2006 16:26:59 GMT
We need to have a static base for the initial contribution, so that
people can review it, understand it, and vote upon it without it
changing underneath them.

In the meantime you can create a cumulative patch of your own work and
note in JIRA that is is obsoleting a previous issue.  That will provide
traceability and evidence that the updates are being made in the project.

Regards,
Tim

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

-- 

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