Stable tag will be slipped Sunday and release engineering will begin Monday

[Bill Hacker]

0050405140241.GF1443 at xxxxxxxxxxxxxxxxx> <42530abe$0$717$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <200504052232.j35MWID4086845 at xxxxxxxxxxxxxxxxxxxx> <42531b26$0$720$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <42539c07$0$720$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4253c38e$0$718$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4253e2a4$0$719$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <4253e2a4$0$719$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 102
Message-ID: <4253ebc0$0$717$415eb37d at 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 at xxxxxxxxxxxxx> wrote in message
> news:4253c38e$0$718$415eb37d at 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