Firstly, if you feel this shouldn't be discussed any further, please let me know so I won't be bugging you by stressing my arguments.

David Laight <david@l8s.co.uk> wrote:

> Factoring anything back to be MI is actually a problem due to the
> number of ports that have inconsequental changes to certain functions,
> and some differences between the ports (eg major numbers and the location
> of the disklabel on an MBR disk) that really shouldn'y have been allowed

I thought that point would be addressed quite well in that factoring out certain ports would basically allow to ignore them during further work on -current, thus especially having to factor back less, possibly messed up, code to be MI.

Jason Thorpe <thorpej@shagadelic.org> wrote:

> ...then the platform would never be able to benefit from improvements  
> to MI code.

That's certainly true. My belief was that "finished" ports are mature enough that they don't need improvements neither to user interface (which in my experience is very convenient at least on i386 already), nor under the hood. I guessed most of such improvements would end up as micro-optimizations on these platforms. I honestly don't know how much that matters on slow hardware. According to the admittedly mostly not pretty verbose ports' pages, there is a number of ports with only few lasting issues, so finally calling them "finished" appeared achievable to me.

> Plus, maintaining all those branches for bug fix / security update  
> releases sounds like a lot of EXTRA work.

Concerning this matter, I reckoned this could be handled by the corresponding portmasters on their owns, given that there are already little flaws to be (or rather: that are) fixed in the release branches. Maybe I underestimate the work this would cause, and I would agree that this might depend too much on single persons, but on the other hand, certain breaks that were undetected for a long time on several occasions let me think that this is already the case today.

Best regards,

Dennis den Brok