Re: [Valgrind-developers] NEWS, new features, fixed bugs : when to update NEWS

[Mark W. <mj...@re...>]

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