[openib-general] OpenSM Issues of the last couple days

[Michael S. Tsirkin]

> > > > > Eitan, how is it hard for you to prepare procmail's rule which will
> > > > > automatically apply the patches from emails to the local pre-trunk
> > > > > tree? Or do you think it is insufficient?
> > > >
> > > > This sounds like a fragile process. It seems much easier to just
> > > > have an unstable branch with untested patches. No?
> > >
> > > Untested is an overexaggeration. They are tested but not by Eitan's
> > > regression.
> > 
> > Sorry, I'm not trying to influence any policy decisions here, I'm coming
> > purely from git angle. *If* you want Eitan to test and Ack some patches,
> > *and want to automate the testing part*, the simplest thing to do is
> > to apply them on some git branch.
> 
> Couldn't he also back off the head on the "trunk" if that doesn't work
> too ? That (which version) could be taken as input to the automatic
> regression with less overhead than another branch to have to track or
> figuring out how to apply patches automagically.

No, this is backwards - rewinding history in trunk branch will break git pull for anyone
who tries to base his work on that, so that's not a good idea.
Or you get a lot of little
"feature X"
"unbreak feature X"
...
"fix feature X"
commits that just make the history log messy and unreadable.

Guys, don't be so scared of branches, they don't really have
any significant overhead in git: branch (and tag) are basically
just symbolic names for commit.

There's not "maintainance" associated with it that I know of. Try it.
This is how e.g. git itself seems to be developed: there's a main branch for next release,
next branch for less stable stuff and "pu" branch for experimental stuff,
and there's a bugfix branch for last stable release.

-- 
MST