DragonFly users List (threaded) for 2005-04
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
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>
In-Reply-To: <4253e2a4$0$719$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 102
Message-ID: <4253ebc0$0$717$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 202.64.125.135
X-Trace: 1112796097 crater_reader.dragonflybsd.org 717 202.64.125.135
Xref: crater_reader.dragonflybsd.org dragonfly.users:2778
Erik Wikström wrote:
> "Bill Hacker" <wbh@xxxxxxxxxxxxx> wrote in message
> news:4253c38e$0$718$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
>>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!
>>
>>Bill
>
>
> 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
actively
developed, they tend to outrun the rev levels in the tree very often.
And many
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
releases behind
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
no more
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
provided.
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
between the
devel communities. Mind-boggling in their complexity when you look at
what QNX or AosBluebottle accomplish with a fraction of the code and
resources.
Bill
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]