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 <[EMAIL PROTECTED]> wrote: >> >> On 5/19/06, Ivan Volosyuk <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: >> > > 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: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
