cvs commit: src/sys/netinet6 frag6.c icmp6.c in6.c in6_ifattach.c in6_pcb.c in6_proto.c in6_rmx.c in6_src.c ip6_input.c ip6_mroute.c ip6_output.c mld6.c nd6.c nd6_nbr.c nd6_rtr.c raw_ip6.c udp6_usrreq.c

[Peter Wemm]

On Jan 8, 2008 11:39 AM, Max Laier <max at love2party.net> wrote:

> On Tuesday 08 January 2008, David E. O'Brien wrote:
> > obrien      2008-01-08 19:08:58 UTC
> >
> >   FreeBSD src repository
> >
> >   Modified files:
> >     sys/netinet6         frag6.c icmp6.c in6.c in6_ifattach.c
> >                          in6_pcb.c in6_proto.c in6_rmx.c in6_src.c
> >                          ip6_input.c ip6_mroute.c ip6_output.c
> >                          mld6.c nd6.c nd6_nbr.c nd6_rtr.c
> >                          raw_ip6.c udp6_usrreq.c
> >   Log:
> >   un-__P()
>
> Do we do that again w/o immediate need and other changes to that file?  I
> was under the impression that it is deemed repo churn.  That aside, I'm
> all for the change.
>

Once apon a time (before cvsup) we used CTM - CVS-through-email - as the
only way to get the cvs repository.  The previous state of the tree was
stored and a series of diffs were generated relative to the last run. The
more that was touched, the larger the email update.  When I first started
developing on freebsd, that was how I got it.  CTM chunks over a UUCP link.
Other folks with real internet connections (ppp or maybe even a 64K link..
perhaps even a (gasp!) T1 link at the unimaginable speed of 1.5mbit/sec -
they used this thing called 'SUP'.  If you changed one character in a file,
it downloaded the entire file from scratch.

Those were the days that the 'avoid needless changes' policy was really
critical.  Roto-tilling the tree was painful for people downstream.

Now, we have cvsup, anoncvs and rsync.  It is a night-and-day difference.
For the most part, we can afford cosmetic fixes and cleanups.  There are
people still getting CTM deltas, but it isn't as bad as SUP (which died the
death it deserved).

The main remaining constraints are concessions to the limitations of our SCM
system and politeness to other developers.  We need to avoid trivial changes
for:
1) code that involves branches due to the suckiness of cvs, and
2) merge conflicts cause everybody pain.  It is no fun getting 100 conflicts
because somebody just did a de-__P() sweep.

Having said that, we have grown overly sensitive to both 1) and 2).    1)
will be fixed soon enough, and 2) is mostly a big deal only on stuff that
other people are actively developing on.  I'm not sure that we have too much
activity in the ipv6 stack, and it certainly isn't vendor code anymore (the
vendor has gone away).

Now doing a roto-till of something like __P() in the ipv4 stack wouldn't be
such a hot idea because there are lots of projects in progress that are
already stomping on each other's toes.  There isn't much room for gratuitous
changes in there.   However, ipv6 previously missed the tree-wide de-__P()
sweep because (at the time) it was vendor code.

For what its worth, I'm glad it was cleaned up.

Also, I think we've gone too far in avoiding changes to vendor branched code
"at all costs".  It isn't *that* broken.  I like what NetBSD(?) does these
days by using the new -X flag(?) to cvs import, which takes the files off
the vendor branch INSTANTLY.  This is a very good thing as it gets the pain
out of the way and fills a few huge holes in the vendor branch metadata.

PS: and a pox on anybody who uses this as an excuse to revive the VCS
bikeshed.  If you do, I will forward a copy of every single email message
that has been said on the subject since 1995.  Individually.

-Peter
-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5