|
From: Dirk M. <dm...@gm...> - 2005-08-08 16:38:09
|
Hi, whats the policy on branch backports? can everybody (me) do it or is it reserved for release preparation purposes? Dirk |
|
From: Julian S. <js...@ac...> - 2005-08-08 17:11:52
|
Hi Dirk. Unclear .. do you mean backporting to 2.4.X or to 3.0.X? J On Monday 08 August 2005 17:37, Dirk Mueller wrote: > Hi, > > whats the policy on branch backports? can everybody (me) do it or is it > reserved for release preparation purposes? > > Dirk > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Dirk M. <dm...@gm...> - 2005-08-08 17:47:25
|
On Monday 08 August 2005 22:29, Julian Seward wrote: > Hi Dirk. Unclear .. do you mean backporting to 2.4.X or to 3.0.X? 3.0.x actually. I know nobody else besides me cares about 2.4.x :) Dirk |
|
From: Nicholas N. <nj...@cs...> - 2005-08-08 18:35:49
|
On Mon, 8 Aug 2005, Dirk Mueller wrote: >> Hi Dirk. Unclear .. do you mean backporting to 2.4.X or to 3.0.X? > > 3.0.x actually. I know nobody else besides me cares about 2.4.x :) My only concern is that it would be good to have an official tracking mechanism for which changes have been backported and which are outstanding. If one person is assigned to this they would be the official 3.0.X maintainer, I guess, although it would be good if people committing bugfixes to the trunk tried to remember to commit them to 3_0_X as well. N |
|
From: Julian S. <js...@ac...> - 2005-08-09 19:17:07
|
> My only concern is that it would be good to have an official tracking > mechanism for which changes have been backported and which are > outstanding. So I made this file 3_0_BUGSTATUS.txt which I hoped would be at least a step in that direction. I do want to keep careful track of what the bug status is and what's outstanding. J |
|
From: Nicholas N. <nj...@cs...> - 2005-08-09 19:28:39
|
On Tue, 9 Aug 2005, Julian Seward wrote: >> My only concern is that it would be good to have an official tracking >> mechanism for which changes have been backported and which are >> outstanding. > > So I made this file 3_0_BUGSTATUS.txt which I hoped would be at > least a step in that direction. I do want to keep careful track > of what the bug status is and what's outstanding. Hmm, I think using SVN rather than CVS is a huge win here, because we can refer to individual bugfixes with a single revision number, ie. have a list of "to be merged" revisions. N |
|
From: Tom H. <to...@co...> - 2005-08-09 21:51:37
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Tue, 9 Aug 2005, Julian Seward wrote:
>
> >> My only concern is that it would be good to have an official tracking
> >> mechanism for which changes have been backported and which are
> >> outstanding.
> >
> > So I made this file 3_0_BUGSTATUS.txt which I hoped would be at
> > least a step in that direction. I do want to keep careful track
> > of what the bug status is and what's outstanding.
>
> Hmm, I think using SVN rather than CVS is a huge win here, because we can
> refer to individual bugfixes with a single revision number, ie. have a
> list of "to be merged" revisions.
That's partly why I started noting the SVN revision for a fix when
closing bugs, and likewise with the bug number in the SVN log.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-08-09 22:45:40
|
> > >> My only concern is that it would be good to have an official tracking > > >> mechanism for which changes have been backported and which are > > >> outstanding. > > > > > > So I made this file 3_0_BUGSTATUS.txt which I hoped would be at > > > least a step in that direction. I do want to keep careful track > > > of what the bug status is and what's outstanding. > > > > Hmm, I think using SVN rather than CVS is a huge win here, because we can > > refer to individual bugfixes with a single revision number, ie. have a > > list of "to be merged" revisions. > > That's partly why I started noting the SVN revision for a fix when > closing bugs, and likewise with the bug number in the SVN log. That's great, but .. could you also update 3_0_BUGSTATUS.txt with that info upon closing a bug, so all the relevant info is in one place? J |
|
From: Nicholas N. <nj...@cs...> - 2005-08-09 19:29:56
|
On Tue, 9 Aug 2005, Julian Seward wrote: > So I made this file 3_0_BUGSTATUS.txt which I hoped would be at > least a step in that direction. I do want to keep careful track > of what the bug status is and what's outstanding. And to answer Dirk's original question: I see no problem with you backporting bug-fixes from the trunk to the 3_0_X branch. N |
|
From: Julian S. <js...@ac...> - 2005-08-10 10:17:18
|
> And to answer Dirk's original question: I see no problem with you > backporting bug-fixes from the trunk to the 3_0_X branch. Me neither. Although it would be good if you could keep the 3_0_BUGSTATUS.txt file up to date. I'll do some vex-related fixing and merging today too. J |
|
From: Dirk M. <dm...@gm...> - 2005-08-10 11:24:53
|
On Wednesday 10 August 2005 12:23, Julian Seward wrote: > Me neither. Although it would be good if you could keep the > 3_0_BUGSTATUS.txt file up to date. I'll do some vex-related > fixing and merging today too. Can't merge the VEX changes because I don't have an account in that repository. started valgrind merging though, but I cannot do important changes because they rely on VEX adjustments :) Dirk |