Date: Tue, 4 Jun 2002 22:51:20 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Bakul Shah <bakul@bitblocks.com> Cc: arch@FreeBSD.ORG Subject: Re: Avoiding unnecessary breakage (was Re: Removing wait union) Message-ID: <p05111729b92324e697ef@[128.113.24.47]> In-Reply-To: <200206050051.UAA07971@renown.cnchost.com> References: <200206050051.UAA07971@renown.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 5:51 PM -0700 6/4/02, Bakul Shah wrote: > > Note that some of the changes we are talking about are being >> done to conform to standards. It isn't just "random bit rot", > >I am *not* suggesting people are making changes for the sake >of changes. What I am suggesting is that the common theme of >"making the customers' life easy" is either missing or there >is no agreement about just who the customer is. I should have added a bit more background in my previous message, so that what I was saying would make a bit more sense... I'm a relatively new committer to freebsd (IMO, at least). When I was learning the ropes, I did have several other committers who made a point of stating (to me) that incompatible changes had to be eased into the system. Thus, I do believe that there is some agreement on how such changes should be handled. It's even in the committers guide, iirc. If anyone *asks* how should such-and-such be changed, there is often much advice given on how to ease the change in. That's what is happening with the 'union wait' change, for instance. Kris *is* offering to do a ports-build to find most of the ports which would break, before the actual change is made. Mike *did* write up patches for all of the base-system things which would need to change, before making the major change. That's really the point I wanted to make. Sometimes we (as a project) *are* trying to do a good job, but we're so upset about "those other changes" that we don't give people credit when developers do make the extra effort to ease a change into place. If you want to make changes in a group of volunteers, then I think you need to encourage and commend the behavior you're looking for. I think that works better than proposing new rules, regulations, and bureaucracy to abolish the behavior that is troubling. >Brian Somers writes: > > Many software vendors would say that a published interface > > can only be removed after two major releases of the software. > >Right idea but I am not too keen on such hard and fast rules. >The issue is sticking to rules and self-policing just doesn't >work for most people. Aside: I would also say that I feel that "two major releases" might be a bit too painful for changes in the freebsd project, if you're talking about major releases being 3.0 vs 4.0. We have people who don't stay as active developers for the length of time it takes FreeBSD to make it thru two major releases... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05111729b92324e697ef>