|Re: [eclipselink-dev] 2:00pm EST Meeting Agenda: Wed Oct 31.
Hi Andrei, Just sending out what we discussed to share with everyone.1. Some people are happy with just the diffs, so, for those people, the SVN patch is already usable. The patch, however, should contain enough information to recreate the changes on a repository. (i.e. it contains information about the versions of files the changes are derived from) Hopefully that will be enough so that everyone finds them useful. If we find this strategy does not work well, or if someone makes a better suggestion we can always do it another way.
2. You are right, in the case where we have a reopened bug, we should not obsolete the old SVN patch. We should just submit a new patch and leave both patches attached
-Tom Andrei Ilitchev wrote:
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
Back to the top