Back in November there was discussion on how to backport in CVS. How about SVN? I have one old change that hasn't made it to the RCs yet.
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"Time is an illusion - lunchtime doubly so."
- Ford Prefect
William Kyngesburye wrote:
Back in November there was discussion on how to backport in CVS. How
about SVN? I have one old change that hasn't made it to the RCs yet.
http://svnbook.red-bean.com/en/1.4/svn.branchmerge.copychanges.html
--
Glynn Clements <glynn@gclements.plus.com>
Markus,
Are there any policies on developers backporting their changes to release branches? Do it theirselves? Ask another to do it (ie you) to keep some review sanity?
I don't want to mess it up in attempting to do it myself. I was hoping it would be as simple as "apply this trunk changeset to that branch", but it looks like I now need to have a local copy of the branch so I can commit the merges. Though, mine are simple enough (mostly), and isolated, that I could just do a diff and commit.
On Mar 24, 2008, at 1:19 AM, Glynn Clements wrote:
William Kyngesburye wrote:
Back in November there was discussion on how to backport in CVS. How
about SVN? I have one old change that hasn't made it to the RCs yet.http://svnbook.red-bean.com/en/1.4/svn.branchmerge.copychanges.html
--
Glynn Clements <glynn@gclements.plus.com>
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."
- Marvin
William,
On Wed, Mar 26, 2008 at 1:53 AM, William Kyngesburye
<woklist@kyngchaos.com> wrote:
Markus,
Are there any policies on developers backporting their changes to
release branches?
Yes.
Do it theirselves? Ask another to do it (ie you)
to keep some review sanity?
It depends: preferably a developer should be able to
backport him/herself but
- do not break the release branch
- make tests
- only fix bugs, do not introduce new features
If the latter is unclear, it should be discussed on this list.
I don't want to mess it up in attempting to do it myself. I was
hoping it would be as simple as "apply this trunk changeset to that
branch", but it looks like I now need to have a local copy of the
branch so I can commit the merges. Though, mine are simple enough
(mostly), and isolated, that I could just do a diff and commit.
If someone doesn't want to or cannot commit him/herself, a diff
is appreciated.
See new page
http://trac.osgeo.org/grass/wiki/HowToBackport
Markus
Thanks for the clarifications. I'll go ahead with some backport fixes.
On Mar 26, 2008, at 6:23 AM, Markus Neteler wrote:
Do it theirselves? Ask another to do it (ie you)
to keep some review sanity?It depends: preferably a developer should be able to
backport him/herself but
- do not break the release branch
- make tests
- only fix bugs, do not introduce new features
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
First Pogril: Why is life like sticking your head in a bucket filled with hyena offal?
Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal?
First Pogril: I don't know either. Wretched, isn't it?
-HitchHiker's Guide to the Galaxy
Markus:
> It depends: preferably a developer should be able to
> backport him/herself but
> - do not break the release branch
> - make tests
> - only fix bugs, do not introduce new features
William Kyngesburye wrote:
Thanks for the clarifications. I'll go ahead with some backport fixes.
At this point in the RC cycle, it is best to play it very conservative as
RC6 was most likely be the last before 6.3.0 and so any changes you make
in the release branch will go into 6.3.0 with little to no community
testing.
Hamish
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
I backported some minor Mac-only bugfixes. They have worked well for me so far. And I did manually apply them to my recent RC binaries, and haven't heard of any problems. A couple were build fixes, so they would only affect those that compiled SVN source.
A pair I haven't done yet (ran out of time this morning), that are companions to Glynn's r29926 and r30066, which were applied to the release branch:
http://trac.osgeo.org/grass/changeset/30347
http://trac.osgeo.org/grass/changeset/30704
These affect some lib/init stuff, but are important to return what Glynn removed, in another form. These also have worked well for me so far, and are in my binaries, and no reports of problems yet.
Comments?
On Mar 26, 2008, at 5:44 PM, Hamish wrote:
Markus:
It depends: preferably a developer should be able to
backport him/herself but
- do not break the release branch
- make tests
- only fix bugs, do not introduce new featuresWilliam Kyngesburye wrote:
Thanks for the clarifications. I'll go ahead with some backport fixes.
At this point in the RC cycle, it is best to play it very conservative as
RC6 was most likely be the last before 6.3.0 and so any changes you make
in the release branch will go into 6.3.0 with little to no community
testing.Hamish
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
Earth: "Mostly harmless"
- revised entry in the HitchHiker's Guide to the Galaxy
William Kyngesburye wrote:
I backported some minor Mac-only bugfixes. They have worked well for
me so far. And I did manually apply them to my recent RC binaries,
and haven't heard of any problems. A couple were build fixes, so they
would only affect those that compiled SVN source.A pair I haven't done yet (ran out of time this morning), that are
companions to Glynn's r29926 and r30066, which were applied to the
release branch:http://trac.osgeo.org/grass/changeset/30347
http://trac.osgeo.org/grass/changeset/30704These affect some lib/init stuff, but are important to return what
Glynn removed, in another form. These also have worked well for me so
far, and are in my binaries, and no reports of problems yet.Comments?
Platform-specific targets should be implemented using make
conditionals, rather than an unconditional target which performs the
test within the commands. IOW:
ifneq ($(MACOSX_APP),)
FILES += \
$(ETC)/grass-xterm-mac \
$(ETC)/html_browser_mac.sh
endif
--
Glynn Clements <glynn@gclements.plus.com>
On Mar 27, 2008, at 4:44 AM, Glynn Clements wrote:
Platform-specific targets should be implemented using make
conditionals, rather than an unconditional target which performs the
test within the commands. IOW:ifneq ($(MACOSX_APP),)
FILES += \
$(ETC)/grass-xterm-mac \
$(ETC)/html_browser_mac.sh
endif
Thanks for the tip. I'll work on that.
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history."
- Hitchhiker's Guide to the Galaxy
On Mar 27, 2008, at 4:44 AM, Glynn Clements wrote:
William Kyngesburye wrote:
A pair I haven't done yet (ran out of time this morning), that are
companions to Glynn's r29926 and r30066, which were applied to the
release branch:http://trac.osgeo.org/grass/changeset/30347
http://trac.osgeo.org/grass/changeset/30704These affect some lib/init stuff, but are important to return what
Glynn removed, in another form. These also have worked well for me so
far, and are in my binaries, and no reports of problems yet.Comments?
Platform-specific targets should be implemented using make
conditionals, rather than an unconditional target which performs the
test within the commands. IOW:
OK, add this to the above list, to be backported (if OK) as a unit:
http://trac.osgeo.org/grass/changeset/30773
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
Earth: "Mostly harmless"
- revised entry in the HitchHiker's Guide to the Galaxy
William Kyngesburye wrote:
>> A pair I haven't done yet (ran out of time this morning), that are
>> companions to Glynn's r29926 and r30066, which were applied to the
>> release branch:
>>
>> http://trac.osgeo.org/grass/changeset/30347
>> http://trac.osgeo.org/grass/changeset/30704
>>
>> These affect some lib/init stuff, but are important to return what
>> Glynn removed, in another form. These also have worked well for me
>> so
>> far, and are in my binaries, and no reports of problems yet.
>>
>> Comments?
>
> Platform-specific targets should be implemented using make
> conditionals, rather than an unconditional target which performs the
> test within the commands. IOW:OK, add this to the above list, to be backported (if OK) as a unit:
One minor point:
$(INSTALL) -m 755 grass-xterm-mac $(ETC)
Makefiles shouldn't hard-code the permissions. The user should be able
to override this by setting INSTALL. Typically. $(INSTALL) will use
755 while $(INSTALL_DATA) will use 644.
--
Glynn Clements <glynn@gclements.plus.com>
On Mar 28, 2008, at 4:43 PM, Glynn Clements wrote:
One minor point:
$(INSTALL) -m 755 grass-xterm-mac $(ETC)
Makefiles shouldn't hard-code the permissions. The user should be able
to override this by setting INSTALL. Typically. $(INSTALL) will use
755 while $(INSTALL_DATA) will use 644.-- Glynn Clements <glynn@gclements.plus.com>
Ah, I must have done that as a quick fix a while back (and it propogated to later changes) without reading the install docs completely (and missed that install defaults to 755).
I have that in my osx makefiles also... on to cleanup...
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history."
- Hitchhiker's Guide to the Galaxy
Oh, looks like all the installs there hardwired the -m 755 flag. I'll let you take care of cleaning up the init makefile if you want.
On Mar 28, 2008, at 4:43 PM, Glynn Clements wrote:
One minor point:
$(INSTALL) -m 755 grass-xterm-mac $(ETC)
Makefiles shouldn't hard-code the permissions. The user should be able
to override this by setting INSTALL. Typically. $(INSTALL) will use
755 while $(INSTALL_DATA) will use 644.--
Glynn Clements <glynn@gclements.plus.com>
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
Earth: "Mostly harmless"
- revised entry in the HitchHiker's Guide to the Galaxy