You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(23) |
2
(15) |
|
3
|
4
|
5
|
6
|
7
(3) |
8
(22) |
9
(12) |
|
10
|
11
|
12
(1) |
13
(13) |
14
(4) |
15
(12) |
16
|
|
17
(5) |
18
(13) |
19
(6) |
20
(10) |
21
(17) |
22
|
23
(3) |
|
24
(18) |
25
(17) |
26
(12) |
27
|
28
(1) |
29
(3) |
30
(12) |
|
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: 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: 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: 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: 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 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: Philippe W. <phi...@sk...> - 2013-11-20 21:39:22
|
On Wed, 2013-11-20 at 13:24 +0100, Bart Van Assche wrote: > On 11/19/13 21:20, Philippe Waroquiers wrote: > > On Tue, 2013-11-19 at 09:08 -0800, Patrick J. LoPresti wrote: > > > >> When partial-loads-ok is working correctly, I believe all of > >> Valgrind's str/mem intercepts are technically unnecessary. True, they > >> are faster... But that is an argument for intercepting every function > >> in the C library :-). > > Not too sure I understand. The str/mem interceptions will usually > > run slower than the C lib functions (as in most cases, these > > interceptions run fully on the simulated cpu and are not as > > optimised as the c lib functions). > > If any of the str/mem intercepts would turn out to run significantly > slower than their optimized equivalents in the C library I will be happy > to optimize the relevant str/mem intercepts further. Fair enough. Would be worth doing perl perf/vg_perf --vg=../trunk --vg=../new --tool=helgrind,drd --reps=5 to have first indications of a possible performance impact. Philippe |
|
From: Bart V. A. <bva...@ac...> - 2013-11-20 12:24:30
|
On 11/19/13 21:20, Philippe Waroquiers wrote: > On Tue, 2013-11-19 at 09:08 -0800, Patrick J. LoPresti wrote: > >> When partial-loads-ok is working correctly, I believe all of >> Valgrind's str/mem intercepts are technically unnecessary. True, they >> are faster... But that is an argument for intercepting every function >> in the C library :-). > Not too sure I understand. The str/mem interceptions will usually > run slower than the C lib functions (as in most cases, these > interceptions run fully on the simulated cpu and are not as > optimised as the c lib functions). If any of the str/mem intercepts would turn out to run significantly slower than their optimized equivalents in the C library I will be happy to optimize the relevant str/mem intercepts further. >> In my opinion, "--partial-loads-ok=yes" should be the default. It >> would make 90% of the intercepts and default suppression rules >> unnecessary. OK that is just a guess... But this is certainly a >> pervasive source of Valgrind false positives. > You could try to run all the regression tests giving > --partial-load-ok=yes > and use -v to look at the used suppressions and see which one > are not used anymore. I will have a look at this but after this patch is in the Valgrind source code tree. Bart. |
|
From: <sv...@va...> - 2013-11-20 11:54:49
|
Author: mjw
Date: Wed Nov 20 11:54:38 2013
New Revision: 13715
Log:
dwz compressed alternate .debug_info and .debug_str not read correctly.
Bug #327837. The buildid from the .gnu_debugaltlink section was parsed
incorrectly (from the wrong offset). Causing the debug alt file not to
be found.
Modified:
trunk/coregrind/m_debuginfo/readelf.c
Modified: trunk/coregrind/m_debuginfo/readelf.c
==============================================================================
--- trunk/coregrind/m_debuginfo/readelf.c (original)
+++ trunk/coregrind/m_debuginfo/readelf.c Wed Nov 20 11:54:38 2013
@@ -2609,7 +2609,8 @@
vg_assert(aimg == NULL);
if (debugaltlink_escn.img != NULL) {
- UInt buildid_offset = ML_(img_strlen)(debugaltlink_escn.img, 0)+1;
+ UInt buildid_offset = ML_(img_strlen)(debugaltlink_escn.img,
+ debugaltlink_escn.ioff)+1;
vg_assert(buildid_offset < debugaltlink_escn.szB);
|
|
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 |