|
|
|
|
|
|
| Author |
Message |
David O'Brien
*nix forums beginner
Joined: 06 Jun 2002
Posts: 1
|
 Posted: Thu Jun 06, 2002 3:16 pm Post subject:
Re: Avoiding unnecessary breakage (was Re: Removing wait union)
|
|
|
On Wed, Jun 05, 2002 at 05:37:23PM -0400, Garance A Drosihn wrote:
| Quote: | I agree that we could do a better job of smoothing in the
transition of some incompatible changes. But it is my feeling
that "major releases" are probably not the best way to set the
timescale for those transitions. 2.0 -> 3.0 took four years,
|
"major releases" in the version 2 days were X.Y. Thus you need to
compaire 2.0[.0]->2.1.0->2.2.0->3.0.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Garance A Drosihn
*nix forums Guru Wannabe
Joined: 21 Mar 2002
Posts: 190
|
| Posted: Wed Jun 05, 2002 7:37 pm Post subject:
Re: Avoiding unnecessary breakage (was Re: Removing wait union)
|
|
|
At 7:24 PM +0100 6/5/02, Brian Somers wrote:
| Quote: | On Tue, 4 Jun 2002, Garance A Drosihn <drosih@rpi.edu> wrote:
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.
A company that develops software doesn't expect to have to
employ software engineers (to redevelop their software) for
an OS upgrade - an OS upgrade that we're essentially forcing
on them because of our frequent releases and our inability
to support all but the latest of those releases.
|
I agree that we could do a better job of smoothing in the
transition of some incompatible changes. But it is my feeling
that "major releases" are probably not the best way to set the
timescale for those transitions. 2.0 -> 3.0 took four years,
3.0 -> 4.0 took a little less than two years, and it looks
like 4.0 -> 5.0 will take more than two and a half years.
That rule would imply that if we decide right now to make an
incompatible change, then we couldn't stop supporting "the
old way" for at least four years (ie, for two major releases).
I agree would be very fine thing to do for our users, but
realistically I think that is *much* too big a job for us
(as a project) to commit to.
I am not sure what a good measure would be. Maybe "four official
releases" (ie, four of the .1 releases). Maybe "one major and
one minor release". Maybe just "two years worth of releases".
I don't know what would work best. But we should set it to
something that we really can achieve as a volunteer project,
and something we would expect to apply to the *entire* project,
consistently. There isn't any point in setting some target
which sounds good as a marketting claim, but which we would
never actually live up to.
Note that as a customer of freebsd, the oldest release I have
running in production is 4.2, and I'm getting uneasy about how
old that is. As a developer, I also have a 3.5.1 system that
I can boot up in vmware. If you talk about supporting anything
older than that, then you've crossed the line for how much
work I'm willing to do for this project.
Well, I've probably rambled on too long about this, without
really coming up with any good solution. Just some observations
and my opinions.
--
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 |
|
| Back to top |
|
|
Brian Somers
*nix forums beginner
Joined: 04 Apr 2002
Posts: 14
|
| Posted: Wed Jun 05, 2002 4:24 pm Post subject:
Re: Avoiding unnecessary breakage (was Re: Removing wait union)
|
|
|
On Tue, 4 Jun 2002 22:51:20 -0400, Garance A Drosihn <drosih@rpi.edu> wrote:
| Quote: | 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...
|
Well, if developers don't hang around long enough to see their changes
through to completion, that's our (FreeBSD's) problem. We can't push
the problem onto the users of our platform.
A company that develops software doesn't expect to have to employ
software engineers (to redevelop their software) for an OS upgrade - an
OS upgrade that we're essentially forcing on them because of our
frequent releases and our inability to support all but the latest of
those releases.
--
Brian <brian@Awfulhak.org> <brian.somers@sun.com>
<http://www.Awfulhak.org> <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Wed Jun 05, 2002 2:07 am Post subject:
Re: Removing wait union
|
|
|
Steve Kargl wrote:
| Quote: | On Tue, Jun 04, 2002 at 07:50:03PM -0700, Terry Lambert wrote:
Mike Barcroft wrote:
For anyone watching this thread, I just sent Kris 15 patches for these
ports. Most uses were far more trivial than in the base system.
Ugh. You are as bad as Alfred.
In what respect?
|
In supplying large numbers of patches quickly.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Alfred Perlstein
*nix forums addict
Joined: 19 Mar 2002
Posts: 67
|
| Posted: Wed Jun 05, 2002 1:15 am Post subject:
Re: Removing wait union
|
|
|
* Terry Lambert <tlambert2@mindspring.com> [020604 19:50] wrote:
| Quote: | Mike Barcroft wrote:
Kris Kennaway <kris@obsecurity.org> writes:
These are the ports which built on the last 5.0 run the other day but
failed this time around. There are others hidden by dependencies
which fail to build; I can give you an updated list once things like
XFree86 and C++ include directories get fixed.
[...]
For anyone watching this thread, I just sent Kris 15 patches for these
ports. Most uses were far more trivial than in the base system.
Ugh. You are as bad as Alfred.
|
heh,
*clang*
stupid
*clang*
round
*smash*
peg
*bang*
and
*crunch*
stupid
*smash*
square
*whack*
hole
*thunk*
!!!
--
-Alfred
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Steve Kargl
*nix forums beginner
Joined: 03 May 2002
Posts: 41
|
| Posted: Wed Jun 05, 2002 12:57 am Post subject:
Re: Removing wait union
|
|
|
On Tue, Jun 04, 2002 at 07:50:03PM -0700, Terry Lambert wrote:
| Quote: | Mike Barcroft wrote:
Kris Kennaway <kris@obsecurity.org> writes:
These are the ports which built on the last 5.0 run the other day but
failed this time around. There are others hidden by dependencies
which fail to build; I can give you an updated list once things like
XFree86 and C++ include directories get fixed.
[...]
For anyone watching this thread, I just sent Kris 15 patches for these
ports. Most uses were far more trivial than in the base system.
Ugh. You are as bad as Alfred.
|
In what respect?
At least Mike has supplied Kris some fixes for
problems while all you supply is commentary on
terryBSD.
--
Steve
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Garance A Drosihn
*nix forums Guru Wannabe
Joined: 21 Mar 2002
Posts: 190
|
| Posted: Wed Jun 05, 2002 12:51 am Post subject:
Re: Avoiding unnecessary breakage (was Re: Removing wait union)
|
|
|
At 5:51 PM -0700 6/4/02, Bakul Shah wrote:
| Quote: | 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.
| Quote: | 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 |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Wed Jun 05, 2002 12:50 am Post subject:
Re: Removing wait union
|
|
|
Mike Barcroft wrote:
| Quote: | Kris Kennaway <kris@obsecurity.org> writes:
These are the ports which built on the last 5.0 run the other day but
failed this time around. There are others hidden by dependencies
which fail to build; I can give you an updated list once things like
XFree86 and C++ include directories get fixed.
[...]
For anyone watching this thread, I just sent Kris 15 patches for these
ports. Most uses were far more trivial than in the base system.
|
Ugh. You are as bad as Alfred.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Mike Barcroft
*nix forums beginner
Joined: 03 Apr 2002
Posts: 25
|
| Posted: Wed Jun 05, 2002 12:12 am Post subject:
Re: Removing wait union
|
|
|
Kris Kennaway <kris@obsecurity.org> writes:
| Quote: | These are the ports which built on the last 5.0 run the other day but
failed this time around. There are others hidden by dependencies
which fail to build; I can give you an updated list once things like
XFree86 and C++ include directories get fixed.
[...] |
For anyone watching this thread, I just sent Kris 15 patches for these
ports. Most uses were far more trivial than in the base system.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Bakul Shah
*nix forums beginner
Joined: 04 Jun 2002
Posts: 17
|
| Posted: Tue Jun 04, 2002 10:51 pm Post subject:
Re: Avoiding unnecessary breakage (was Re: Removing wait union)
|
|
|
[Executive summary at the end]
| Quote: | Most systems companies understand the software they sell (and
around which their customers and 3rd party vendors add much
more software) exists to solve customers' problems and
breaking interfaces DOES NOT help that cause. ...
Most system companies who SELL software are also PAYING their
employees to work on that software.
|
Yes, paying makes it relatively easy to make people work
toward a common goal. In a volunteer organization this is
much harder but not impossible. You do need a leader (or
leaders) to articulate the common theme and you also need
someone to help people move toward a common goal.
| Quote: | 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. So what is
"right" at a micro level can some time end up creating more
pain at a macro level. What is "right" technically can also
end up being a royal pain to fix.
I am ambivalent about "standards". If conforming to a
published standard breaks a lot of things, I'd say that is a
bad standard and I wouldn't go out of my way to meet it.
| Quote: | I hope this is not sounding too sarcastic, because I do agree
with the general idea that we should "avoid unnecessary breakage".
It is pretty easy to say that, but it is hard to actually do it,
while still moving the operating system forward.
|
No disagreement here.
Brian Somers writes:
| Quote: | Many software vendors would say that a published interface can only be
removed after two major releases of the software. The first major
release should suggest that the interface is depricated and should no
longer be used (the documentation should probably suggest the (new?)
alternatives too). The following release can then remove the interface.
While this is painful for the developer, it's necessary for any API
provider in order to provide a *viable* platform for building upon.
|
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.
| Quote: | Whilst it would also be nice to have an Architecture group that could
control this sort of thing, I don't think that's at all practical for
FreeBSD.
|
I was thinking of an informal group where the *weight* of
your opinion in the group is a function of how well other
respect you and how well you continue making sense! But you
may be right -- one needs a mix of email and face-to-face
meetings to make this work.
Poul-Henning Kamp writes:
| Quote: | The FreeBSD project is about doing things right, and in doing so
we expose other pieces of software which didn't do things right.
|
The trouble is that X's idea of doing things right may not
meet Y's. And X may change his mind a year later. "Right"
is a judgement call. An example, moving an include file in
another directory may be "right" but that just creates a lot
of needless work for very little gain. This is different
from fixing a bug that got exposed (as opposed to a behavior
that broke due to a change in interface).
Terry Lambert writes:
| Quote: | I think this instantaneously creates a bottleneck. The emergent
properties of this bottleneck are undesirable, even if the intent,
to avoid breakage, is desirable.
Leaving such decisions solely upto developers doesn't work
because developers have their own agenda (which is frequently
at cross purposes with each others', and with the groups'
goals).
I think Kris would probably agree with this.  . I do.
|
The trouble is that if you don't leave such decisions to
developers you need something else.
| Quote: | Adding another tier of management is probably not the answer
("Welcome to the Star Chamber").
|
I'd say this would *be* the core group or its peer. It would
consist of mostly technical wizards. You can call them stars
if you want! But their role would be to create excitement,
set and explain guidelines and enforce them by mentoring,
cajoling, and so on. and facilitate the evolution process.
| Quote: | - create an index of which ports use what include files,
what system/library calls etc. If an interface needs to be
changed the developer can quickly find out what ports will
be affected. If the developer were forced to fix these
ports before allowed to commit an interface change, most
people will think harder about changes!
It's not that this approach won't work, it's that responsibility
for compliance is pushed off onto the third party code maintainers;
you are effectively telling them not to use certain tools that work
perfectly fine for them on their single OS environment, and which
help in making ports of their code -- at the expense of making the
code itself less portable.
|
I didn't explain well. I meant automatically running a
simple tool like mkid or glimpse or global or something from
the crontab once a week. There will be many false hits but
at least it would be a start.
| Quote: | To my mind, FreeBSD is losing ground to Linux in a number of
areas. One of these areas is in published technical references.
Linux has published technical references, and FreeBSD does not.
I'm going to argue that the reason these works have been able
to be written is stabilization of interfaces over time.
|
I'd have to agree.
To summarize,
The rate of change has been accelerating and it is becoming
harder and harder to get 3rd party apps working or
maintaining them in the working order. While many ports can
be fixed by hard work, I think it is worth debating just what
is "unnecessary" breakage and doing something about it.
We need
- some idea of just who the customers are
- what the freebsd community goals are
- a way to manage the os & ports growth
*while* maintaining as much anarchy as possible. My defn of
freebsd customers is _primarily_ the people who use it; not
just its developers. But the volunteer developers also must
get something back to want to work on FreeBSD. For that a
common vision and excitement needs to be articulated and the
process has to be such that fun far outweighs any grunge
work.
I am not against changes or even breakage, just "unnecessary"
breakage! IMHO interface changes should be carefully vetted.
Pros:
- having to justify can force developers to think harder
- frequently a better option suggests itself after a healthy
discussion
- tradeoffs are considered up front.
- global goals are paid attention
Cons:
- such a vetting process can be a real bottleneck.
- the weight of considering too many things will drive
people away.
- not easy to find people.
I don't know if this can be made to work but I sure hope so!
-- bakul
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Tue Jun 04, 2002 9:49 pm Post subject:
Re: Avoiding unnecessary breakage (was Re: Removing wait union)
|
|
|
Garance A Drosihn wrote:
| Quote: | At 10:20 PM +0100 6/4/02, Brian Somers wrote:
Many software vendors would say that a published interface
can only be removed after two major releases of the software.
[...]
Personally, I think FreeBSD should adopt such a strategy.
Note that there *is* some attempt to do that, for many of the
changes we do. That effort, when it happens, still does not
protect us from annoying people with "disruptive" changes.
|
Personally, I am all for disruptive changes, if they represent
progress toward an agreed upon goal.
| Quote: | Note, for instance, that the issue which triggered this thread
was the removal of 'union wait'.
|
Actually, it was the *proposal* to remove "union wait" that was
the trigger. It was an entre into the larger issue of the
acceptability of interface changes without "enviornmental impact
statements".
| Quote: | it seems like 'union wait' has been depreciated since 1994!
|
It has not been deprecated in the same way that "malloc.h" and
"struct.h" and "values.h" have been deprecated. The deprecation
has been comparatively very silent.
| Quote: | And yet here we have people all a flutter about how we are
making an incompatible change and we might be breaking ports.
|
I picked the subject carefully: "Avoiding unnecessary breakage".
As I said above: Personally, I am all for disruptive changes, if
they represent progress toward an agreed upon goal.
In other words "Embrace necessary breakage".
| Quote: | So, in short (who? me? short?), I think there are changes where
FreeBSD does a good job at trying to soften the transition --
and that we do not give ourselves enough credit when we do that.
At the same time, there are other changes which are more abrupt,
but sometimes the abrupt change is done because mapping a smooth
transition will require a great deal more work. And with a
volunteer group, it isn't always easy to find people who are
willing to do that extra work.
|
Historically, this has been David Greenman's job, as Architect.
When David efectively deactivated himself, as outside events ate
more and more of his time, the project has suffered.
I don't think there is a simple fix; maybe I'm wrong: I'd like to
be, in this case.
Raising awareness is short-term helpful: I think there are a lot
more people who are now considering the larger consequences of the
changes they would like to make. On the other hand, I have yet to
see one case of an epidemic that was cured solely by way of better
education.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Garrett Wollman
*nix forums addict
Joined: 08 May 2002
Posts: 59
|
| Posted: Tue Jun 04, 2002 9:30 pm Post subject:
Re: Avoiding unnecessary breakage (was Re: Removing wait union)
|
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In article <20020604222022.6f935871.brian@Awfulhak.org> you write:
| Quote: | Many software vendors would say that a published interface can only be
removed after two major releases of the software.
|
By that measure, `union wait' has been deprecated to the extent of not
being documented for almost ten years. 4.4-Lite only documented the
Standard interface.
- -GAWollman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)
iD8DBQE8/TGCI+eG6b7tlG4RAqxTAKCpGda3MrJR6m8VATZ+oUAgprKH6wCdELMC
iX0jPsvMP3DFrG55eijw3tg=
=si16
-----END PGP SIGNATURE-----
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Kris Kennaway
*nix forums Guru
Joined: 28 Apr 2002
Posts: 634
|
| Posted: Tue Jun 04, 2002 9:30 pm Post subject:
Re: Removing wait union
|
|
|
On Tue, Jun 04, 2002 at 07:08:13PM -0400, Mike Barcroft wrote:
| Quote: | Kris Kennaway <kris@obsecurity.org> writes:
19 ports failed, and 3152+465 port builds were attempted. Assuming
the same percentage of the rest will fail that comes to around 36
ports failing out of 7000 in the collection.
I'd be happy with the patch going in as long as someone commits to
fixing them.
I think <sys/wait.h> is currently C++ unsafe, so it's likely that the
C++ breakage isn't hiding additional bugs. As a side effect, I
believe this patch fixes C++, though I haven't checked.
I'm willing to investigate the ports that break, if you can provide a
list.
|
These are the ports which built on the last 5.0 run the other day but
failed this time around. There are others hidden by dependencies
which fail to build; I can give you an updated list once things like
XFree86 and C++ include directories get fixed.
+./44bsd-csh-20001106.log
+./fep-1.0.log
+./ile-2.0_1.log
+./ja-tcl-7.6.log
+./mailx-0.5.log
+./ncftp1-1.9.5.log
+./ngspice_rework-14.log
+./nntp-1.5.12.2_1.log
+./nntpbtr-1.7.log
+./oases-2.2.log
+./pmake-2.1.33.log
+./rmsg-1.64.log
+./scli-0.2.9.log
+./sup-2.0.log
+./tcl-8.0.5.log
+./tn3270-4.4.log
+./ttyrec-1.0.5.log
+./zh-hztty-2.0.log
Kris |
|
| Back to top |
|
|
Garance A Drosihn
*nix forums Guru Wannabe
Joined: 21 Mar 2002
Posts: 190
|
| Posted: Tue Jun 04, 2002 9:27 pm Post subject:
Re: Avoiding unnecessary breakage (was Re: Removing wait union)
|
|
|
At 10:20 PM +0100 6/4/02, Brian Somers wrote:
| Quote: | On Tue, 4 Jun 2002, Garance A Drosihn <drosih@rpi.edu> wrote:
I hope this is not sounding too sarcastic, because I do agree
with the general idea that we should "avoid unnecessary breakage".
It is pretty easy to say that, but it is hard to actually do it,
while still moving the operating system forward.
Many software vendors would say that a published interface
can only be removed after two major releases of the software.
[...]
Personally, I think FreeBSD should adopt such a strategy.
|
Note that there *is* some attempt to do that, for many of the
changes we do. That effort, when it happens, still does not
protect us from annoying people with "disruptive" changes.
Note, for instance, that the issue which triggered this thread
was the removal of 'union wait'. Mike Barcroft wrote some
updates to lpr to handle the complete removal of that. At
first I was a little uneasy about completely removing it,
but it turns out that freebsd *started* to depreciate that
union a long time ago. I found that I can compile the
'union-wait-less' changes on freebsd 3.5.1 (the oldest
snapshot I still have running). And if you look at:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/wait.h
it seems like 'union wait' has been depreciated since 1994!
And yet here we have people all a flutter about how we are
making an incompatible change and we might be breaking ports.
At the same time, it is true that lpr has sat there happily
using that depreciated interface for EIGHT YEARS, until Mike
forced the issue by being willing to actually remove the
union from wait.h. And that's for a program which is part
of the base freebsd image!
That's what I mean by saying "it's easier to say than to do".
If eight years is not long enough to convert applications,
then how long are we supposed to go? No matter what you do,
the fact remains that some people (particularly 3rd-party
apps) will not change their source code until you force them
to -- and the moment you *do* force them then you'll get a
thread about "freebsd developers should avoid unnecessary
breakage!".
- - - -
But again, despite all my passion at defending the 'union wait'
change, it's also painfully obvious that freebsd has seen other
changes which have not had a nice smooth transition. In the
above I coyly said that the 'union-wait-less' *changes* can
compile on freebsd 3.5.1. That is all well and good, but the
full story is that present version of lpr can *not* compile
on 3.5.1, because of the way the INET6 changes where handled.
So, in short (who? me? short?), I think there are changes where
FreeBSD does a good job at trying to soften the transition --
and that we do not give ourselves enough credit when we do that.
At the same time, there are other changes which are more abrupt,
but sometimes the abrupt change is done because mapping a smooth
transition will require a great deal more work. And with a
volunteer group, it isn't always easy to find people who are
willing to do that extra work.
--
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 |
|
| Back to top |
|
|
Mike Barcroft
*nix forums beginner
Joined: 03 Apr 2002
Posts: 25
|
| Posted: Tue Jun 04, 2002 9:18 pm Post subject:
Re: Avoiding unnecessary breakage (was Re: Removing wait union)
|
|
|
Brian Somers <brian@Awfulhak.org> writes:
| Quote: | Many software vendors would say that a published interface can only be
removed after two major releases of the software. The first major
release should suggest that the interface is depricated and should no
longer be used (the documentation should probably suggest the (new?)
alternatives too). The following release can then remove the interface.
While this is painful for the developer, it's necessary for any API
provider in order to provide a *viable* platform for building upon.
Personally, I think FreeBSD should adopt such a strategy.
|
We did. I added it to the Committers Guide a while ago.
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/rules.html#AEN1068
Best regards,
Mike Barcroft
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Jan 08, 2009 5:22 am | All times are GMT
|
|
PS2 Cheat Codes | Naruto shippuden | Find a Credit Card | Advertising | Looking for Credit Cards?
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
