[
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