DragonFly users List (threaded) for 2005-04
Re: Stable tag will be slipped Sunday and release engineering will begin Monday
0050405140241.GF1443@xxxxxxxxxxxxxxxxx> <42530abe$0$717$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <200504052232.j35MWID4086845@xxxxxxxxxxxxxxxxxxxx> <42531b26$0$720$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <42539c07$0$720$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4253c38e$0$718$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4253e2a4$0$719$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Trace: 1112796097 crater_reader.dragonflybsd.org 717 184.108.40.206
Xref: crater_reader.dragonflybsd.org dragonfly.users:2778
Erik Wikström wrote:
> "Bill Hacker" <wbh@xxxxxxxxxxxxx> wrote in message
>>Michel Talon wrote:
>>>Bill Hacker wrote:
>>I'm not suggestign that they 'go away'. I am suggesting that a
>>most 'commonly needed' sub-set be given elevated attention - a
>>committment or priority, if you will, secondary only to 'core'.
>>>You want to run exim, i want to run postfix and another guy wants to
>>> run sendmail,
>>All those and probably nearly every MTA of note, plus all the spam and
>>virus, POP and IMAP, webmailer, etc. would certainly be on any list I
>>made up. Likewise many httpds, databases, sysutils, editors.
>>All fertile ground, all with lots of users, contributors, followers,
>>active mailing lists of their own, large communities of interest.
>>These are not the problem!
> Why include those applications that are not the problem on the
> priority-list? As you said these are the ones that usually works and has lot
> of support available when they don't. Giving them even more attention
> wouldn't change much would it?
Actually, it would change a *lot*. Because they are widely used and
developed, they tend to outrun the rev levels in the tree very often.
of those newer release fix sometimes serious bugs that - again because they
are widely used - affect a lot of folks if left as-is.
Examples? Debian stable was building a 3-year-old Exim that folks on the
Exim list can't even rememeber well enough to give advice on.
Exim and courier-mta have, AFAIK, never been *less* than two full
the developer's current release. These are not alone. Little-used stuff,
OTOH, may not see a single change in multiple years.
> But as you also said there are lots of almost identical ports out there and
> removing most of them would probably not be noticed,
And/or combine the best features and keep the result up-to-date... as does
happen from time to time.
> this would also make it
> easier to perform QA should one choose to have that. The way I see things
> the soulution is both a tecnical one with a flexible and robust
> port/package-system but also to not include every application put there. If
> an application does not have any support and starts to cause trouble then
> that app should be dropped. Should there be many people wanting the app then
> there is probably enough compitent people to make it work too.
Oddly, a number of the ports *are* sort of 'dropped'. Security
problems, buffer overflow,
can get a port marked as 'broken' and its Makefile short-circuited to do
than print the message. wget, lynx, and other old favorites have been
there and back.
Yet these remain in the tree for months if not years before a fix is
That indicates both a lack of userland need, and a shortage of developer
resources - yet they count against the '12,000 ports'.
500 Gold 'Tier One' ports/packages, 2,000 Silver 'Tier Two', and the
rest Bronze 'Tier Three' or
"Here there be Dragons (that don't fly...)", would be more honest as
well as sustainable.
*IF* the framework is right, and the QC is fair and robust, there might
be an attracton to more devel folks to sort out problems up-front, need
no patching, and feel they have won - better yet *earned* - the
approval of the community professionals if/as/when their app is granted
addmission to the upper tiers.
When that happens, they get more help as well as attention.
> The last problem, that of very complex/big applications such as Gnome and
> KDE I'm afraid I don't have any idea on how to solve.
Shell terminal on an OS/2 or OS X box solves all X problems ;-)
Seriously - the only hope with either of those is constant close linkage
devel communities. Mind-boggling in their complexity when you look at
what QNX or AosBluebottle accomplish with a fraction of the code and