DragonFly users List (threaded) for 2005-08
Re: Compatability with FreeBSD Ports
Chris Pressey wrote:
Allow me to submit a rebuttal (don't take this too seriously ;) speaking
from a theory of open-source as a self-organizing system of individuals
working strictly on their own time and strictly for their own interests:
Not taking it too seriously, just how it should be. :-)
The operative word there is theory, as long as you keep that in mind and
come back to the practical world. It is important to notice that when
resources are scarce, it is important to prioritize workload.
If we were to priotize operating system features over core system bugs, we
would be kidding ourselves into thinking that we are building something
stable and reliable. Same analogy applies with external packages as well.
Why should I fix Gnome if I don't use it?
> Why should I scratch an itch that I don't have?
If you were a user of DragonFly, you don't have to (careful choice of
words) fix issues for other people, but as a developer of DragonFly, in my
opinion, ones responsibility is to fix things of priority, provided one
has the time and energy.
Of course, I can't impose this type of thought on everyone, but this is
what I think how things should be done. Matt follows this same approach
if none of you have noticed before, unless it gets delegated. :-)
If lots of users use Foo, then lots of patches to get Foo working will
come in, and Foo will be well-maintained. If no users use Bar, then no
patches for Bar will come in, and Bar will rot. Problem solved - the
Here you are assuming that users of 'Foo' have any former development
packages that are well-maintained are exactly the ones that are in
demand. What need is there for a list? How is it not just another,
unnecessary level of organization on top of something that already
organizes itself automatically?
There is no such things as automatic organisation. Someone has to
organise so that others will align themselves accordingly.
I am NOT implying that we require a DETAILED list of packages, but an
overall vision of priority so that development resource, time and skill
are applied to the rightful place.
Priority of stabilisation and package fixing is more important than adding
features. I am sure a lot of people will agree with me here.