Re: Notes on test suite reorganisation

On 11/12/2012 14:53 , James Graham wrote:
> I think that HTML5 vs HTML51 is a bad distinction to make in the
> filesystem (see the other branch of this thread).

Right. You'll note that I steered clear of using branches much in my 
proposal. That's not because I don't think we should use branches — we 
certainly should — but because I think we should be careful not to 
overdo them.

The reason for that is that one thing I've noticed with git projects is 
that it can easily happen that the contributors at some point discover 
just how awesome git branches are. This leads to a Cambrian explosion in 
branches that aren't strictly feature branches, which in turn brings 
about an extinction-level event (for productivity) as someone inevitably 
merges and pushes from and to the wrong branch.

Ideally branches (that aren't feature branches) should be limited to a 
number that you can keep in your head. More importantly, they should be 
organised as a flow and never as a matrix, i.e. you don't want to have 5 
and 5.1 crossed with submissions and approved as down that path lies if 
not madness, at least not seeing the forest for the branches.

With that in mind, here's a proposal: there are two primary branches 
called master and next. The master branch is for html5, canvas2d, 
microdata; the next branch is for html51, canvas2d2, and RDFa (just 
kidding!).

Beyond that we can have submissions as pull requests, which can indeed 
map onto feature branches. So long as those are clearly labelled as such 
("feature/foo", "PR/foo", whatever) I'm happy.

> Let's restate Option (B) as "use branches, one per submission (note: not
> one per file)". This then frees us from the idea that this option is
> particularly tied to github; pull requests are effectively just branches
> with a fancy name.
>
> The major advantage of this approach is that good code review tools (and
> even mediocre code review tools like the one built in to github) are
> commonly organised around the paradigm that a branch is the unit of code
> review. As issues are identified in the submission, you keep pushing
> fixes to the branch until you fixed all the problems, then you
> integrate. Indeed if we want git-based code review (rather than
> something custom like the CSSWG has) I think we *have* to use this
> option to some extent.

Sound your logic is.

> The net result will be that the approved tests are obvious — they are
> just mainline. The list of unapproved submissions is obvious; it's just
> the list of all open review requests. The only problem is that it's hard
> to run all approved + unapproved tests at once because that means
> creating a new branch that includes all the commits from the review
> branches. I suppose it isn't impossible to imagine automating the
> creation of such a thing, but there will inevitably be problems from
> merge conflicts and so on.

Actually I think that it can indeed be automated (though not entirely 
trivially). Most of the submissions will be overwhelmingly additive, 
which ought to help decrease the risk of conflicts. We can also attempt 
to rebase them each in turn, which might decrease the risks further (I 
need to think about that though). What's more, if we have conflicts 
between submissions it's probably not a bad idea that a tool would be 
able to tell us about it sooner rather than later.

I think I'm sold on that model.

>> Overall I have a slight preference for (C), but I could be convinced to
>> go with (B), especially if integration with epic (or whatever) is
>> particularly good there.
>
> Did you mean Critic? Certainly critic requires that you work that way.

Yeah I meant Critic, though I'm sure that it's EPIC too.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 11 December 2012 15:41:11 UTC