RE: [eclipselink-dev] 2:00pm EST Meeting Agenda: Wed Oct 31.

["Gordon Yorke" <gordon.yorke@xxxxxxxxxx>]

Patches offer a lot of value to reviewers and for archiving especially with the tooling available.  A patch filed in bugzilla offers a nice gui view of the patch as applied to the orginal version of the file and the patch.  A patch file in an email allows a reviewer to easily see the differences if using the tortoise "apply patch" tool ( but not applying the patch)

1.  The patch does contain enough information to place the changes in context.  It contains the original revision number and the difference.  The tools within tortoise (and I assume Subclipse) use this information to show the differences based on the original file not current working copy.  Try it and see for yourself.

2.  A reopend bug yes, a bug that is reviewed on closure should have the final patch added and the closer should mark the old un-reviewed patch obsolete.  Only applied patches should appear in a bug.

We should be verifying behaviours before making decisions and suggestions.
--Gordon

-----Original Message-----
From: eclipselink-dev-bounces@xxxxxxxxxxx
[mailto:eclipselink-dev-bounces@xxxxxxxxxxx]On Behalf Of Andrei Ilitchev
Sent: Wednesday, October 31, 2007 12:59 PM
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] 2:00pm EST Meeting Agenda: Wed Oct 31.


A couple of suggestions:

1. "Code changes should be attached to the bug in the form of an SVN patch
and a notification should be sent to the eclipselink-dev mailing list".
My understanding that the patch is just a collection of diffs for all
changed files (btw, what about added, removed). If that's true then it
pretty useless unless you have the original source to which the diffs to be
applied.
Suggestion: unless the patch allows to see old code vs new code don't attach
it to bug.

2. "If the code goes through multiple iterations, not only should the new
patch be attached to the bug, but the old patch should be obsoleted in
bugzilla"
I suggest to add new patches in this case - not to delete the existing one
and create a new "combined" one.
Creating the "combined" patch in the best case is time consuming, in the
worst case (smbd has added more changes between the patches) is impossible.

----- Original Message -----
From: "Tom Ware" <tom.ware@xxxxxxxxxx>
To: "Dev mailing list for Eclipse Persistence Services"
<eclipselink-dev@xxxxxxxxxxx>
Sent: Tuesday, October 30, 2007 2:04 PM
Subject: Re: [eclipselink-dev] 2:00pm EST Meeting Agenda: Wed Oct 31.


> Here is the strawman for the dev process.  Please feel free to send me
> comments or add comments to the wiki.
>
> I'll assume silence means you are happy with the proposal.
>
> http://wiki.eclipse.org/EclipseLink/Development/Process
>
> -Tom
>
> Peter Krogh wrote:
>
>>I am going to try structuring these meetings a little better than I have
>>in the past.  They will be capped at 1 hour, and proposed agendas will be
>>sent out a day earlier to be agreed on by the group.  The time cap means
>>that people who are talking will have a fixed amount of time, and will be
>>cut off if they are going over time.  Lengthy open issues and action items
>>will likely need to be addressed outside of the meeting, and brought back
>>in to discuss outcomes at the next meeting.
>>
>>I will accept agenda changes until about 11:00am EST Wed.
>>
>>I propose that the meeting be done in two parts, status updates, and
>>general issues.  The name beside the status update indicate that it is
>>that person's responsibility to give the update.  The general issues will
>>generally be given as a proposal by the person with the name beside it.
>>
>>
>>Proposed Agenda: Wed Oct 31
>>---
>>Time: 2:00pm EST Phone: 1-888-967-2253
>>Conf ID/Password: 486546/486546
>>
>>Status updates
>> - M1
>>   - Status on putting TopLink changes into EclipseLink - Peter K
>>   - Build and Installer Status - Tom W
>>   - Download, wiki, www - Doug C
>>   - Status on OXM, JAXB, SDO - Dave M
>>   - Documentation Status Update - Rick S.
>>   - Sign off on packaging/zip name - Doug
>>- Update on Testing Status - Chris D and Mike N
>>
>>General Issues
>> - Current Dev Process - Tom
>>   - Min Requirements
>>   - Bugzilla
>>   - Specs
>> - Goals M2 - Doug and Peter
>> - Where to put Workbench - Doug
>>   - Utils Component
>>
>>
>>_______________________________________________
>>eclipselink-dev mailing list
>>eclipselink-dev@xxxxxxxxxxx
>>https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev