Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mylyn-dev] development process


I would like to ask how do you plan to review review patches that already been committed?

To my knowledge, in order to take a really good look at the patch you would need the appropriate workspace setup with no changes included into the patch. But then you can simply run synchronize and see the same changes grouped by the change sets and use the much more convenient comparisons editor from there. More over, the Eclipse Team/CVS integration allow to run comparison for the branch head with any other branch to get the same change sets and use same comparison editor without even having the branched code in your workspace.

So, unless I am missing something (which I very well may), the whole the patch idea is just an unpractical and unnecessary overhead, because the version control system provides the same information in a form more usable for review.

 regards,
 Eugene


Mik Kersten wrote:
+1 for the patches proposal

Mik

-----Original Message-----
From: mylyn-dev-bounces@xxxxxxxxxxx [mailto:mylyn-dev-
bounces@xxxxxxxxxxx] On Behalf Of Steffen Pingel
Sent: Tuesday, March 04, 2008 9:34 PM
To: Mylyn developer discussions
Subject: [mylyn-dev] development process

We are still in the process of figuring out the best strategy for the
maintenance branch. On today's call we agreed to the following:

- set the milestone to 2.3 for each bug that is fixed on the
maintenance
branch
- add the [m2.3.x] (x == maintenance revision) tag to the title of the
bug to
mark fixes that go into a particular release
- commit the fix to the branch as well as to head

My suggestion is that we also attach patches to the corresponding bugs
for all
changes that are committed to the maintenance branch. My thinking is
that it
makes it easy for other committers to review changes. It also helps to
track
if a change is committed to the branch as well as to head.

It is important that we don't introduce regressions for the maintenance
branch. Less committers will work bootstrapped from the branch and
weekly
builds will have less exciting changes. Meaning we are likely to get
less
feedback for changes made to the branch and run at higher risk to miss
regressions.

Steffen




Back to the top