|
From: Philippe W. <phi...@sk...> - 2013-11-14 19:08:33
|
Up to now, I have seen various "methods" used to update NEWS when a bug is fixed or a new feature is implemented. A. NEWS is not modified when the bug is fixed or when the feature is implemented, but a little bit before the release, some research is done to find what was fixed or what was implemented, and then NEWS is update. B Some other changes (bug fixed or new feature) are accompanied with the NEWS modification (in the commit that brings the change in svn) C Sometimes, NEWS is modified slightly after the commit that fixed the bug or implemented the new feature. D Also, various markers (for bugs) were used in NEWS e.g. to indicate which revision fixed the bug and/or what was the release in which it was fixed. These markers are then removed before the release. E maybe some other conventions I have not seen/detected/... I think it would be cleaner/more understandable/... to have all of us using the same technique. I have a strong preference for B, for the following reasons: * NEWS in SVN is always up to date * the code is always in sync with NEWS * no need to dig into up to one year of past changes to discover what was changed which is worth a NEWS entry. The NEWS entry can then be reviewed/commented as part of the review (or post-commit review if it was deemed no pre-commit review was needed) * the fixed bug can be marked as fixed in bugzilla, with the comment containing the revision that fixed the bug. * svn annotate on NEWS will indicate which revision fixed the bug. * I cannot see any disadvantage in doing B. It looks to be less work for a better/always up to date result. (and of course, fallback to C if NEWS was forgotten to be updated in a commit :). Feedback/opinion/... ? If there is only enthusiastic opinions that B is the way to go, (or alternatively zero horrified shouting that B is unacceptable), I suggest that for the next release (3.10 ? 4.0 ?), we start to use technique B (and that we recover asap the not yet done NEWS changes for the recently fixed bugs in SVN). If ok to go for B, I will add a file README_DEVELOPERS_processes (or any better name?) in SVN to document the "process" with which a change is NEWS-documented as part of the commit. We might then later add descriptions of other processes (e.g. how to make a release maybe ?). Note that it would be preferable to have the 3.9.0 branch merged into the trunk to start editing NEWS for the next release. Not clear to me if there is a reason to delay this merge. Philippe |
|
From: Florian K. <fl...@ei...> - 2013-11-15 07:47:01
|
On 11/14/2013 08:09 PM, Philippe Waroquiers wrote: > A. NEWS is not modified when the bug is fixed or when the feature > is implemented, but a little bit before the release, some research > is done to find what was fixed or what was implemented, and then > NEWS is update. > B Some other changes (bug fixed or new feature) are accompanied > with the NEWS modification (in the commit that brings the change in > svn) > C Sometimes, NEWS is modified slightly after the commit that fixed > the bug or implemented the new feature. > D Also, various markers (for bugs) were used in NEWS e.g. to indicate > which revision fixed the bug and/or what was the release in which it > was fixed. These markers are then removed before the release. > E maybe some other conventions I have not seen/detected/... > > I think it would be cleaner/more understandable/... to have all of us > using the same technique. > > I have a strong preference for B, for the following reasons: Same here. Updating NEWS as you go is also preferable because you can come up with a description of the work that makes sense to a user. That is more difficult to do at a later point in time. If you bulk-edit NEWS at release time you end up copying the bug summary line which is often not very descriptive. Of course, you will still have to cross-check BZ and do A at release time, to make sure nothing was left out. > * svn annotate on NEWS will indicate which revision fixed the bug. Not so, if that was a VEX-only change. Unfortunately. Yet another reason to merge those repositories. Florian |
|
From: Mark W. <mj...@re...> - 2013-11-20 11:39:50
|
On Thu, 2013-11-14 at 20:09 +0100, Philippe Waroquiers wrote: > Up to now, I have seen various "methods" used to update NEWS > when a bug is fixed or a new feature is implemented. > > > A. NEWS is not modified when the bug is fixed or when the feature > is implemented, but a little bit before the release, some research > is done to find what was fixed or what was implemented, and then > NEWS is update. > B Some other changes (bug fixed or new feature) are accompanied > with the NEWS modification (in the commit that brings the change in > svn) > C Sometimes, NEWS is modified slightly after the commit that fixed > the bug or implemented the new feature. > D Also, various markers (for bugs) were used in NEWS e.g. to indicate > which revision fixed the bug and/or what was the release in which it > was fixed. These markers are then removed before the release. > E maybe some other conventions I have not seen/detected/... > > I think it would be cleaner/more understandable/... to have all of us > using the same technique. > > I have a strong preference for B, for the following reasons: > * NEWS in SVN is always up to date > * the code is always in sync with NEWS > * no need to dig into up to one year of past changes to discover what > was changed which is worth a NEWS entry. The NEWS entry can then > be reviewed/commented as part of the review (or post-commit review > if it was deemed no pre-commit review was needed) > * the fixed bug can be marked as fixed in bugzilla, with the comment > containing the revision that fixed the bug. > * svn annotate on NEWS will indicate which revision fixed the bug. > * I cannot see any disadvantage in doing B. It looks to be less work > for a better/always up to date result. > (and of course, fallback to C if NEWS was forgotten to be updated > in a commit :). > > Feedback/opinion/... ? In general I like this proposal. But some nitpicks... The valgrind/VEX split makes B technically not always fully workable. That is also why sometimes you want to document which revision in which repo really fixed something. I would very much like us to merge the repos just for this reason. It isn't totally clear to me how we will use the NEWS file for major and minor releases. Where minor would be e.g. 3.9.1 which contains cherry-picked bug fixes from the trunk (which itself will become 3.10.0 or 4.0.0 at some point). The bug list is not just NEWS, but also the release managers (currently Julian's) notepad about the status of various bugs on various branches (minor/major). For this reason we might want to have both a BUGS file, which then contains current status of various bugs and a NEWS file which only contains descriptions of the bugs actually fixed (on the current branch?). > If ok to go for B, I will add a file README_DEVELOPERS_processes > (or any better name?) in SVN to document the "process" > with which a change is NEWS-documented as part of the commit. > > We might then later add descriptions of other processes > (e.g. how to make a release maybe ?). Yes please! :) Is there a description of how minor release branches in svn work (I am a bit of a svn noob, using a local git/svn bridge to actually push commits). I am slowly accumulating some patches for the fedora valgrind package which I think might make a good start for a minor 3.9.1 branch. > Note that it would be preferable to have the 3.9.0 branch merged > into the trunk to start editing NEWS for the next release. > Not clear to me if there is a reason to delay this merge. And maybe in the future swap the updating of NEWS. All changes to NEWS should first go onto trunk and only then backported/cherry-picked into a release branch NEWS version? Cheers, Mark |
|
From: Philippe W. <phi...@sk...> - 2013-11-20 21:51:31
|
On Wed, 2013-11-20 at 12:39 +0100, Mark Wielaard wrote: > In general I like this proposal. But some nitpicks... > > The valgrind/VEX split makes B technically not always fully workable. > That is also why sometimes you want to document which revision in which > repo really fixed something. I would very much like us to merge the > repos just for this reason. Yes, merging the repos would make sense. Before that, I think a VEX only fix should be committed first, and then a second commit of NEWS document the change. > > It isn't totally clear to me how we will use the NEWS file for major and > minor releases. Where minor would be e.g. 3.9.1 which contains > cherry-picked bug fixes from the trunk (which itself will become 3.10.0 > or 4.0.0 at some point). Not completely clear to me. I would imagine NEWS is updated in the minor release branch, indicating which bugs were fixed there. After that, merging from minor release branch to trunk should bring the minor release NEWS update in the trunk, to have NEWS having the full history. > > The bug list is not just NEWS, but also the release managers (currently > Julian's) notepad about the status of various bugs on various branches > (minor/major). > > For this reason we might want to have both a BUGS file, which then > contains current status of various bugs and a NEWS file which only > contains descriptions of the bugs actually fixed (on the current > branch?). Maybe we better use bugzilla to maintain not yet fixed bug status ? But if a BUGS file under svn helps to maintain some info for not yet fixed bugs, that is for sure possible. To be seen with Julian what he deems needed. Maybe we could look at what other projects are doing ? (e.g. what is gdb doing for their major and minor release ?) > > > If ok to go for B, I will add a file README_DEVELOPERS_processes > > (or any better name?) in SVN to document the "process" > > with which a change is NEWS-documented as part of the commit. > > > > We might then later add descriptions of other processes > > (e.g. how to make a release maybe ?). > > Yes please! :) Is there a description of how minor release branches in > svn work (I am a bit of a svn noob, using a local git/svn bridge to > actually push commits). I am slowly accumulating some patches for the > fedora valgrind package which I think might make a good start for a > minor 3.9.1 branch. > > > Note that it would be preferable to have the 3.9.0 branch merged > > into the trunk to start editing NEWS for the next release. > > Not clear to me if there is a reason to delay this merge. > > And maybe in the future swap the updating of NEWS. All changes to NEWS > should first go onto trunk and only then backported/cherry-picked into a > release branch NEWS version? Or updated in branch and merged in trunk ? Unclear to me what is the best way to proceed (lack of svn knowledge being a problem to judge what would work well). Philippe |
|
From: Yan <ya...@ya...> - 2013-11-20 22:02:29
|
So I'm rather new to the list, and VEX development in general, but I wanted to chime in. Feel free to ignore me. I've been using VEX for static analysis, and am putting together a set of patches to make VEX more usable to this goal. However, my stuff is purely using VEX, not Valgrind, as the latter is completely geared for dynamic analysis. If there's interest in keeping VEX friendly for such uses, merging the VEX and Valgrind repositories would be counter-productive to that goal. In the security realm, there are a few projects (specifically, Vine and BAP) that forked VEX several years back to do non-Valgrind things with it. While it might be too late for BAP and Vine, I think keeping VEX in a separate repository (and maybe even individualizing VEX and Valgrind slightly more) could encourage future projects like these to keep upstreaming their changes, as opposed to forking off on their own. - Yan On Wed, Nov 20, 2013 at 1:51 PM, Philippe Waroquiers < phi...@sk...> wrote: > On Wed, 2013-11-20 at 12:39 +0100, Mark Wielaard wrote: > > > In general I like this proposal. But some nitpicks... > > > > The valgrind/VEX split makes B technically not always fully workable. > > That is also why sometimes you want to document which revision in which > > repo really fixed something. I would very much like us to merge the > > repos just for this reason. > Yes, merging the repos would make sense. > Before that, I think a VEX only fix should be committed first, > and then a second commit of NEWS document the change. > > > > > > It isn't totally clear to me how we will use the NEWS file for major and > > minor releases. Where minor would be e.g. 3.9.1 which contains > > cherry-picked bug fixes from the trunk (which itself will become 3.10.0 > > or 4.0.0 at some point). > Not completely clear to me. I would imagine NEWS is updated in the > minor release branch, indicating which bugs were fixed there. > After that, merging from minor release branch to trunk should > bring the minor release NEWS update in the trunk, to have NEWS > having the full history. > > > > > > The bug list is not just NEWS, but also the release managers (currently > > Julian's) notepad about the status of various bugs on various branches > > (minor/major). > > > > For this reason we might want to have both a BUGS file, which then > > contains current status of various bugs and a NEWS file which only > > contains descriptions of the bugs actually fixed (on the current > > branch?). > Maybe we better use bugzilla to maintain not yet fixed bug status ? > But if a BUGS file under svn helps to maintain some info for not > yet fixed bugs, that is for sure possible. > To be seen with Julian what he deems needed. > Maybe we could look at what other projects are doing ? > (e.g. what is gdb doing for their major and minor release ?) > > > > > > If ok to go for B, I will add a file README_DEVELOPERS_processes > > > (or any better name?) in SVN to document the "process" > > > with which a change is NEWS-documented as part of the commit. > > > > > > We might then later add descriptions of other processes > > > (e.g. how to make a release maybe ?). > > > > Yes please! :) Is there a description of how minor release branches in > > svn work (I am a bit of a svn noob, using a local git/svn bridge to > > actually push commits). I am slowly accumulating some patches for the > > fedora valgrind package which I think might make a good start for a > > minor 3.9.1 branch. > > > > > Note that it would be preferable to have the 3.9.0 branch merged > > > into the trunk to start editing NEWS for the next release. > > > Not clear to me if there is a reason to delay this merge. > > > > And maybe in the future swap the updating of NEWS. All changes to NEWS > > should first go onto trunk and only then backported/cherry-picked into a > > release branch NEWS version? > Or updated in branch and merged in trunk ? > Unclear to me what is the best way to proceed (lack of svn knowledge > being a problem to judge what would work well). > > Philippe > > > > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up > now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Philippe W. <phi...@sk...> - 2013-11-20 22:14:32
|
On Wed, 2013-11-20 at 14:01 -0800, Yan wrote: > So I'm rather new to the list, and VEX development in general, but I > wanted to chime in. Feel free to ignore me. > > > I've been using VEX for static analysis, and am putting together a set > of patches to make VEX more usable to this goal. However, my stuff is > purely using VEX, not Valgrind, as the latter is completely geared for > dynamic analysis. If there's interest in keeping VEX friendly for such > uses, merging the VEX and Valgrind repositories would be > counter-productive to that goal. > > > In the security realm, there are a few projects (specifically, Vine > and BAP) that forked VEX several years back to do non-Valgrind things > with it. While it might be too late for BAP and Vine, I think keeping > VEX in a separate repository (and maybe even individualizing VEX and > Valgrind slightly more) could encourage future projects like these to > keep upstreaming their changes, as opposed to forking off on their > own. Can you elaborate why having one single repository would be counter-productive ? I guess that we just need to ensure that VEX (and its library) can be used without the rest of valgrind. But that does not seem to be "hard-linked" with having one or two repos ? There are other "engineering" constraints which have to be ensured e.g. in the Valgrind repository, the tools can depend on coregrind, but coregrind cannot depend on tools. So, maybe what we need to see is how VEX could/should be made more "valgrind independent". Philippe > > > - Yan > > > On Wed, Nov 20, 2013 at 1:51 PM, Philippe Waroquiers > <phi...@sk...> wrote: > On Wed, 2013-11-20 at 12:39 +0100, Mark Wielaard wrote: > > > In general I like this proposal. But some nitpicks... > > > > The valgrind/VEX split makes B technically not always fully > workable. > > That is also why sometimes you want to document which > revision in which > > repo really fixed something. I would very much like us to > merge the > > repos just for this reason. > > Yes, merging the repos would make sense. > Before that, I think a VEX only fix should be committed first, > and then a second commit of NEWS document the change. > > > > > > It isn't totally clear to me how we will use the NEWS file > for major and > > minor releases. Where minor would be e.g. 3.9.1 which > contains > > cherry-picked bug fixes from the trunk (which itself will > become 3.10.0 > > or 4.0.0 at some point). > > Not completely clear to me. I would imagine NEWS is updated in > the > minor release branch, indicating which bugs were fixed there. > After that, merging from minor release branch to trunk should > bring the minor release NEWS update in the trunk, to have NEWS > having the full history. > > > > > > The bug list is not just NEWS, but also the release managers > (currently > > Julian's) notepad about the status of various bugs on > various branches > > (minor/major). > > > > For this reason we might want to have both a BUGS file, > which then > > contains current status of various bugs and a NEWS file > which only > > contains descriptions of the bugs actually fixed (on the > current > > branch?). > > Maybe we better use bugzilla to maintain not yet fixed bug > status ? > But if a BUGS file under svn helps to maintain some info for > not > yet fixed bugs, that is for sure possible. > To be seen with Julian what he deems needed. > Maybe we could look at what other projects are doing ? > (e.g. what is gdb doing for their major and minor release ?) > > > > > > If ok to go for B, I will add a file > README_DEVELOPERS_processes > > > (or any better name?) in SVN to document the "process" > > > with which a change is NEWS-documented as part of the > commit. > > > > > > We might then later add descriptions of other processes > > > (e.g. how to make a release maybe ?). > > > > Yes please! :) Is there a description of how minor release > branches in > > svn work (I am a bit of a svn noob, using a local git/svn > bridge to > > actually push commits). I am slowly accumulating some > patches for the > > fedora valgrind package which I think might make a good > start for a > > minor 3.9.1 branch. > > > > > Note that it would be preferable to have the 3.9.0 branch > merged > > > into the trunk to start editing NEWS for the next release. > > > Not clear to me if there is a reason to delay this merge. > > > > And maybe in the future swap the updating of NEWS. All > changes to NEWS > > should first go onto trunk and only then > backported/cherry-picked into a > > release branch NEWS version? > > Or updated in branch and merged in trunk ? > Unclear to me what is the best way to proceed (lack of svn > knowledge > being a problem to judge what would work well). > > Philippe > > > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech > innovation. > Intel(R) Software Adrenaline delivers strategic insight and > game-changing > conversations that shape the rapidly evolving mobile > landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > |
|
From: Stephen M. <sm...@al...> - 2013-11-20 22:53:42
|
>>>>> "Y" == Yan <ya...@ya...> writes: Y> So I'm rather new to the list, and VEX development in general, but Y> I wanted to chime in. Feel free to ignore me. Y> I've been using VEX for static analysis, and am putting together a Y> set of patches to make VEX more usable to this goal. However, my Y> stuff is purely using VEX, not Valgrind, as the latter is Y> completely geared for dynamic analysis. If there's interest in Y> keeping VEX friendly for such uses, merging the VEX and Valgrind Y> repositories would be counter-productive to that goal. Y> In the security realm, there are a few projects (specifically, Vine Y> and BAP) that forked VEX several years back to do non-Valgrind Y> things with it. While it might be too late for BAP and Vine, I Y> think keeping VEX in a separate repository (and maybe even Y> individualizing VEX and Valgrind slightly more) could encourage Y> future projects like these to keep upstreaming their changes, as Y> opposed to forking off on their own. I wouldn't call Vine's use of VEX (or BAP's, which has been similar though I think they're moving away from it) a fork. We do have a few patches that we haven't gotten merged (cf. https://github.com/bitblaze-fuzzball/fuzzball/blob/master/vex-r2737.patch ), but Vine mostly wraps around VEX with new code to get something that's more suitable for non-Valgrind purposes. If there was a larger community of people building non-Valgrind tools from VEX, there would be some value on collaborating more closely, but I don't know if Yan's project plus Vine is yet getting close to a critical mass. I think from my perspective the layout of the repository is not a critical factor. Doing a larger "svn checkout" but then ignoring most of it would not be a major burden. Changing the build process so that it's necessary to build all of Valgrind would make other uses a bit slower, but there's a recurring inconsistency problem with the current two separate build processes so it might not be a loss overall. Obviously keeping VEX compiling as a separate library is important for external users, but I don't see anyone proposing to change that. Conversely external uses would be easier if VEX's interface were more stable (our code has a lot of #if VEX_VERSION > xxxx directives). But as long as Valgrind is by far the predominant use of VEX I think us external users are getting a pretty good deal. -- Stephen |
|
From: Mark W. <mj...@re...> - 2013-11-21 10:56:17
|
On Wed, 2013-11-20 at 22:51 +0100, Philippe Waroquiers wrote: > On Wed, 2013-11-20 at 12:39 +0100, Mark Wielaard wrote: > > > In general I like this proposal. But some nitpicks... > > > > The valgrind/VEX split makes B technically not always fully workable. > > That is also why sometimes you want to document which revision in which > > repo really fixed something. I would very much like us to merge the > > repos just for this reason. > Yes, merging the repos would make sense. > Before that, I think a VEX only fix should be committed first, > and then a second commit of NEWS document the change. Yes, that is the way to do it. And testcases. I think that is even more of a problem with the current split. When you fix something in VEX you cannot immediately add a testcase, but have to add that afterwards to the other repo in a separate commit. It also makes bi-secting problems really hard, since I haven't found a good way to make any bi-secting work with split repos (that might be because I am using a git mirror of the svn repos though, I don't actually know how to do svn bisecting, it might work with submodules just fine). > > It isn't totally clear to me how we will use the NEWS file for major and > > minor releases. Where minor would be e.g. 3.9.1 which contains > > cherry-picked bug fixes from the trunk (which itself will become 3.10.0 > > or 4.0.0 at some point). > Not completely clear to me. I would imagine NEWS is updated in the > minor release branch, indicating which bugs were fixed there. > After that, merging from minor release branch to trunk should > bring the minor release NEWS update in the trunk, to have NEWS > having the full history. That is one way to do it. You can also say that fixes should always go onto the trunk first and only then get backported to a (minor) release branch. That would be my personal preference to make sure trunk always has all the fixes. > Unclear to me what is the best way to proceed (lack of svn knowledge > being a problem to judge what would work well). That might be another discussion. My own knowledge of svn is also somewhat limited. I started using fully distributed version control like mercurial and git for all other projects I work on. CVS and SVN really feel somewhat limited. But that might be because I refused to learn them properly. Would people like moving to something like git? Or is that too big a change? Cheers, Mark |
|
From: Yan <ya...@ya...> - 2013-11-20 22:32:19
|
Right, the core issue is VEX-Valgrind independence, which is already quite good. I guess, from a philosophical prospective, it makes more sense to me to have VEX in a separate repo if it's independent anyways. This way, projects that use VEX and not Valgrind wouldn't have to pull the whole Valgrind repo and so forth. Seems cleaner to me. However, I realize that there are other issues, from a project perspective and so on, that make it less clear-cut than that. On Wed, Nov 20, 2013 at 2:14 PM, Philippe Waroquiers < phi...@sk...> wrote: > On Wed, 2013-11-20 at 14:01 -0800, Yan wrote: > > So I'm rather new to the list, and VEX development in general, but I > > wanted to chime in. Feel free to ignore me. > > > > > > I've been using VEX for static analysis, and am putting together a set > > of patches to make VEX more usable to this goal. However, my stuff is > > purely using VEX, not Valgrind, as the latter is completely geared for > > dynamic analysis. If there's interest in keeping VEX friendly for such > > uses, merging the VEX and Valgrind repositories would be > > counter-productive to that goal. > > > > > > In the security realm, there are a few projects (specifically, Vine > > and BAP) that forked VEX several years back to do non-Valgrind things > > with it. While it might be too late for BAP and Vine, I think keeping > > VEX in a separate repository (and maybe even individualizing VEX and > > Valgrind slightly more) could encourage future projects like these to > > keep upstreaming their changes, as opposed to forking off on their > > own. > > Can you elaborate why having one single repository would be > counter-productive ? > > I guess that we just need to ensure that VEX (and its library) > can be used without the rest of valgrind. > But that does not seem to be "hard-linked" with having one or two > repos ? > > There are other "engineering" constraints which have to be ensured > e.g. in the Valgrind repository, the tools can depend on coregrind, > but coregrind cannot depend on tools. > > So, maybe what we need to see is how VEX could/should be made > more "valgrind independent". > > Philippe > > > > > > > > > - Yan > > > > > > On Wed, Nov 20, 2013 at 1:51 PM, Philippe Waroquiers > > <phi...@sk...> wrote: > > On Wed, 2013-11-20 at 12:39 +0100, Mark Wielaard wrote: > > > > > In general I like this proposal. But some nitpicks... > > > > > > The valgrind/VEX split makes B technically not always fully > > workable. > > > That is also why sometimes you want to document which > > revision in which > > > repo really fixed something. I would very much like us to > > merge the > > > repos just for this reason. > > > > Yes, merging the repos would make sense. > > Before that, I think a VEX only fix should be committed first, > > and then a second commit of NEWS document the change. > > > > > > > > > > It isn't totally clear to me how we will use the NEWS file > > for major and > > > minor releases. Where minor would be e.g. 3.9.1 which > > contains > > > cherry-picked bug fixes from the trunk (which itself will > > become 3.10.0 > > > or 4.0.0 at some point). > > > > Not completely clear to me. I would imagine NEWS is updated in > > the > > minor release branch, indicating which bugs were fixed there. > > After that, merging from minor release branch to trunk should > > bring the minor release NEWS update in the trunk, to have NEWS > > having the full history. > > > > > > > > > > The bug list is not just NEWS, but also the release managers > > (currently > > > Julian's) notepad about the status of various bugs on > > various branches > > > (minor/major). > > > > > > For this reason we might want to have both a BUGS file, > > which then > > > contains current status of various bugs and a NEWS file > > which only > > > contains descriptions of the bugs actually fixed (on the > > current > > > branch?). > > > > Maybe we better use bugzilla to maintain not yet fixed bug > > status ? > > But if a BUGS file under svn helps to maintain some info for > > not > > yet fixed bugs, that is for sure possible. > > To be seen with Julian what he deems needed. > > Maybe we could look at what other projects are doing ? > > (e.g. what is gdb doing for their major and minor release ?) > > > > > > > > > If ok to go for B, I will add a file > > README_DEVELOPERS_processes > > > > (or any better name?) in SVN to document the "process" > > > > with which a change is NEWS-documented as part of the > > commit. > > > > > > > > We might then later add descriptions of other processes > > > > (e.g. how to make a release maybe ?). > > > > > > Yes please! :) Is there a description of how minor release > > branches in > > > svn work (I am a bit of a svn noob, using a local git/svn > > bridge to > > > actually push commits). I am slowly accumulating some > > patches for the > > > fedora valgrind package which I think might make a good > > start for a > > > minor 3.9.1 branch. > > > > > > > Note that it would be preferable to have the 3.9.0 branch > > merged > > > > into the trunk to start editing NEWS for the next release. > > > > Not clear to me if there is a reason to delay this merge. > > > > > > And maybe in the future swap the updating of NEWS. All > > changes to NEWS > > > should first go onto trunk and only then > > backported/cherry-picked into a > > > release branch NEWS version? > > > > Or updated in branch and merged in trunk ? > > Unclear to me what is the best way to proceed (lack of svn > > knowledge > > being a problem to judge what would work well). > > > > Philippe > > > > > > > > > > > ------------------------------------------------------------------------------ > > Shape the Mobile Experience: Free Subscription > > Software experts and developers: Be at the forefront of tech > > innovation. > > Intel(R) Software Adrenaline delivers strategic insight and > > game-changing > > conversations that shape the rapidly evolving mobile > > landscape. Sign up now. > > > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > > > > > > |
|
From: Florian K. <fl...@ei...> - 2013-11-20 23:10:52
|
On 11/20/2013 11:31 PM, Yan wrote: > > I guess, from a philosophical prospective, it makes more sense to me to > have VEX in a separate repo if it's independent anyways. This way, projects > that use VEX and not Valgrind wouldn't have to pull the whole Valgrind repo > and so forth. Seems cleaner to me. No need to check out the whole tree just to get some subdir. E.g. svn co svn://svn.valgrind.org/valgrind/trunk/tests tests will just check out the 'tests' subdirectory. Florian |
|
From: Mark W. <mj...@re...> - 2013-11-21 12:33:39
|
On Wed, 2013-11-20 at 14:31 -0800, Yan wrote: > Right, the core issue is VEX-Valgrind independence, which is already quite > good. > > I guess, from a philosophical prospective, it makes more sense to me to > have VEX in a separate repo if it's independent anyways. This way, projects > that use VEX and not Valgrind wouldn't have to pull the whole Valgrind repo > and so forth. Seems cleaner to me. I agree in theory, but not in practice :) Yes, we should keep VEX usable independently if people are using it. But IMHO the testsuite is very important, and that is driven by the valgrind tools ATM. In general it looks like practically all development is driven by valgrind. That said, how can we attract other VEX contributors? Would be loose such contributors when we stop using the "split repo" setup (to be honest I didn't know till you spoke up recently that there were any such contributors). Would some alternative setup bring in more contributors? Can we do something else to make it easier to incorporate any forks/patches from non-valgrind VEX hackers? Cheers, Mark |