|
|
|
|
|
|
| Author |
Message |
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
 Posted: Tue Jun 04, 2002 4:44 am Post subject:
Re: Removing wait union
|
|
|
John Baldwin wrote:
| Quote: | Each port should be built once.
|
[ ... ]
| Quote: | Erm, nope, dependencies are pkg_add'd and then the port is built (IIRC).
If a port doesn't specify a dependency that it needs then that is an error.
|
No blood in that stone, then. Looks like option #4 wins. 8-(.
-- Terry
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 3:52 pm Post subject:
Re: Avoiding unnecessary breakage (was Re: Removing wait union)
|
|
|
| Quote: | I'm personally philosophically opposed to the idea of "bit rot":
|
Me too.
| Quote: | My participation in this thread is therefore about whether or not
it's possible to come up with some method of determining what
ports will be broken by a proposed change, before that change is
made, and in a reasonable time frame, with a reasonable amount of
effort, which it would be reasonable to expect a developer who is
contemplating such a change to expend.
In effect, this means that, if this idea is to go forward, there
are only a few obvious courses of action:
1) Build another "ports cluster" so that changes can be tested
before they are committed
2) Find another way around the problem, which has less overhead
than #1
3) Run all such changes through the existing ports cluster by
having Kris apply them locally on the machines, without them
having been checked into CVS, and giving a thumbs up/down to
the change.
4) Tell Kris "lump it": breakage is going to happen, and it's
up to you as the ports guy to mop out the rest rooms after
the concert, after we have peed all over the fixtures (i.e.
leave things as they are now).
|
Another possibility is to figure out a way to not cause so
much bit rot in the first place. Let me explain.
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. So there is
usually a group (or an individual) commited maintaining
compatibility. Breaking interfaces is not prohibited but it
is not taken lightly. Alternatives are explored to eliminate
or at least, reduce the pain a customer or 3rd party vendor
has to go through to upgrade. This is also why a lot of care
goes in documentation -- what is not promised doesn't have to
be maintained.
Such an entity seems to be missing in the FreeBSD camp (and
others too but we are only talking about FreeBSD here).
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).
In my view having an active architecture group that is
responsibile for user/system interfaces would help
tremendously. In order for it to be effective it needs
people who have developers' respect for their judgement,
experience and technical skills. They need to be persuasive
and tough enough to help convince developers to work toward a
common goal.
Whether this is doable in the FreeBSD world, I can't say. I
don't see most FreeBSD developers accepting such a change
easily even if you can find people with skills, sound
judgement and free time; but with over 7000 ports there needs
to be policy changes as well, not just mechanism changes
(which is what your #1, 2 & 3 are about).
Another mechanism idea to add to your list (I think
someone may have already mentioned it):
- 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!
Comments?
-- bakul
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: Tue Jun 04, 2002 4:34 pm Post subject:
Re: Avoiding unnecessary breakage (was Re: Removing wait union)
|
|
|
At 10:52 AM -0700 6/4/02, Bakul Shah wrote:
| 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.
| Quote: | Such an entity seems to be missing in the FreeBSD camp (and
others too but we are only talking about FreeBSD here).
Comments?
|
Note that some of the changes we are talking about are being
done to conform to standards. It isn't just "random bit rot",
it is fixing things to follow standards as those standards are
agreed upon. The idea of standards is to make it easier to
port an application between operating-systems.
And some of the changes are to correctly handle new platforms.
We (FreeBSD) could certainly expend more effort to try to make
these transitions go smoother. However, to do that would require
more effort, and someone who is willing to volunteer to do that
extra effort.
I realize it's a hassle when programs have to be changed to
match these standards-related system changes, but I'm kind of
annoyed that people characterize these changes as if they are
rash, meaningless changes. It's very easy to keep interfaces
consistent if you're not doing anything. It's tougher when
you're trying to shoot at several different targets, all of
which are moving as you're shooting at them. You have a
limited resource (the people volunteering to work on FreeBSD),
and you're trying to get the most out of that, without
discouraging people so much that they just leave.
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.
--
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 |
|
|
Kris Kennaway
*nix forums Guru
Joined: 28 Apr 2002
Posts: 634
|
| Posted: Tue Jun 04, 2002 7:09 pm Post subject:
Re: Removing wait union
|
|
|
On Mon, Jun 03, 2002 at 07:08:18PM -0400, Mike Barcroft wrote:
| Quote: | Bruce Evans <bde@zeta.org.au> writes:
On Sun, 2 Jun 2002, Mike Barcroft wrote:
Does anyone have any objections to removing the deprecated 4.2/4.3BSD
wait union in <sys/wait.h>? It's been deprecating since Rev 1.1 and
there are only a few consumers in the base system. Attached are two
patches, one to removing it from <sys/wait.h> and the other to remove
its consumers. Changes to lpd( sent directly to its maintainer.
I think the only potential problem is use of the compatibility cruft
in deprecware outside the base system. It would be useful to have a
quick way to determine how many ports a change in a standard header
affects.
Kris is going to do a test run of the ports build for me.
|
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.
Kris |
|
| Back to top |
|
|
Brian Somers
*nix forums beginner
Joined: 04 Apr 2002
Posts: 14
|
| Posted: Tue Jun 04, 2002 7:20 pm Post subject:
Re: Avoiding unnecessary breakage (was Re: Removing wait union)
|
|
|
On Tue, 4 Jun 2002 14:34:34 -0400, Garance A Drosihn <drosih@rpi.edu> wrote:
| 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.
|
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.
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.
--
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 |
|
|
Mike Barcroft
*nix forums beginner
Joined: 03 Apr 2002
Posts: 25
|
| Posted: Tue Jun 04, 2002 9:08 pm Post subject:
Re: Removing wait union
|
|
|
Kris Kennaway <kris@obsecurity.org> writes:
| Quote: | 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.
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 |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Tue Jun 04, 2002 9:09 pm Post subject:
Re: Avoiding unnecessary breakage (was Re: Removing wait union)
|
|
|
Bakul Shah wrote:
| Quote: | Another possibility is to figure out a way to not cause so
much bit rot in the first place. Let me explain.
|
[ ... ]
| Quote: | So there is usually a group (or an individual) commited
maintaining compatibility. Breaking interfaces is not prohibited
but it is not taken lightly.
|
[ ... ]
I think that I can safely characterize this as my "option #3",
where the changes are vetted by "vetting committee"/Kris/software.
I think this instantaneously creates a bottleneck. The emergent
properties of this bottleneck are undesirable, even if the intent,
to avoid breakage, is desirable.
| Quote: | 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.
| Quote: | In my view having an active architecture group that is
responsibile for user/system interfaces would help
tremendously. In order for it to be effective it needs
people who have developers' respect for their judgement,
experience and technical skills. They need to be persuasive
and tough enough to help convince developers to work toward a
common goal.
|
I'd agree with an architecture group, but I think the powers
you want to grant are perhaps to far-reaching.
Already, the mere existance of a tiered structure of core team,
committers, the unwashed masses, is externally seen as being
non-egalitarian in the extreme. There are also some intrinsic
properties of such a system. The political analogs are super
powers, the members of the "nuclear club", the unwashed masses;
the economic analogy is first world nations (the G-, second
world nations, and the unwashed masses. The business version
is executives. middle manage, the unwashed masses.
The overriding intrisic property is that such systems are tier
exclusionary, and they are self-perpetuating.
Adding another tier of management is probably not the answer
("Welcome to the Star Chamber").
| Quote: | Another mechanism idea to add to your list (I think
someone may have already mentioned it):
- 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!
|
Actually, that was me that already mentioned this one; it was
in the context of the "making BSD make into GNU make" thread.
This is antithetical to the use of "automake/autoconf/configure"
used by many ports. It's much closer to the "imake/xmkmf" way
of abstracting system differences as a list of manifest constants.
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.
-- Terry
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:11 pm Post subject:
Re: Avoiding unnecessary breakage (was Re: Removing wait union)
|
|
|
Garrett Wollman wrote:
| Quote: | In article <20020604222022.6f935871.brian@Awfulhak.org> you write:
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.
|
I think tha it has not been published that it was deprecated,
and that Brian's point is not being taken correctly here.
Saying that somthing is not going to be there in the future is
very different fron not saying that it will be.
-- 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: 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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Jan 08, 2009 6:18 am | All times are GMT
|
|
Free File Hosting | Debt Consolidation | Credit Cards | MPAA | Loans and 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
