[quagga-dev 7787] Re: [RFC] quagga 1.1.0-dn42.11 in last-minute fixes process

David Lamparter equinox at diac24.net
Tue Feb 9 22:10:10 GMT 2010


Am Dienstag, den 09.02.2010, 19:24 +0000 schrieb paul at jakma.org:
> On Fri, 5 Feb 2010, David Lamparter wrote:
> 
> >  http://git.spaceboyz.net/equinox/quagga.git
> 
> This is great!
> 
> However, it isn't pullable into Quagga upstream as it stands, given 
> the free form commit messages versus the desired commit messages 
> documented in HACKING (along with the rationale).

Being pullable wasn't even remotely something I aimed for - the purpose
of this batch is to get bugreports and feedback on as many patches as
possible. While the point of this release running stable on some fifty*
routers doesn't prove anything, it certainly did exhibit some bugs
already. (This also is why I pulled almost every patch that went over
the ML during the last 7 months)

Also, the merges by themselves have some value; some of the patches
diverge quite a bit, but it seems most of them can be reconciled.

(* the number is at 8 right now and increasing slowly as dn42 people
update their routers)

btw, fixing commit messages is easy :)

btw(2), did you take a look at the actual git tree structure of branches
and merges? i tried to keep stuff cleanly separated, everything starts
on the same base commit and is then merged, this way there is a choice
of cherry-picking not only patches but also branches

> It'd be a nice if we got a consensus on updating HACKING, and it'd 
> perhaps be nice if commit messages followed the requested format 
> until then, regardless of personal opinion (cause otherwise the 
> committing maintainer may have to write the message - and that does 
> not scale).

I rewrote parts of the commit messages already; some of the patches
predate the last change of HACKING and some come from occasional
developers not familiar with it


Regards,

-David


P.S.: i didn't perceive the comment about HACKING as "snarky", i'd go
even farther and think about clarifying CodingStyle a bit and having a
policy about whitespace & stuff. While I don't even remotely like the
GNU style, consistency is a requirement. this also extends to some major
cosmetics that are due IMHO, like cleaning up vtysh DEFUNs, sorting out
some macro excess & stuff. or even, heavens beware, documentation (user
_and_ API).





More information about the Quagga-dev mailing list