svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Robert N. M. Watson]

On 24 Apr 2011, at 12:49, Alexander Motin wrote:

>>> Reverting is not an option. _Constructive_ propositions are welcome.
>> 
>> It is the policy of this project that the release engineering team has
>> final authority over what ships in a release. It is entirely within
>> scope to revert this change for 9.0 if issues with the upgrade path are
>> not addressed. My hope also that this path can be entirely avoided
>> through a rapid addressing of upgrade path issues that have been known
>> (and discussed on the mailing lists extensively) since you posted about
>> the work on the public mailing lists.
>> 
>> I agree with Bjoern that it is critical to address these issues in a
>> timely manner -- our users depend on reliable and easy upgrades, and it
>> seems (on face value) that significant work remains to be done to make
>> that possible. Our release is increasingly close, and it's important we
>> keep the tree as stable as possible so that merges of other straggling
>> features can go uneventfully.
> 
> I am asking for excuse if my tone was overly strict. It was not my real intention to offend anybody. May be inside I am indeed overreacting a bit on proposition to revert with no alternative things that I have put my heart into, which are broadly accepted by users, which I announced on the list few days ago and got no objections. I am sorry for that.
> 
> I do worry about possible complications during migration process. And obviously this is not an easy question, as soon as it wasn't solved during so much time. I will gladly accept any help or real ideas people can provide. I just don't like to feel it my own problem. I am not doing it for myself. It would be nice to see some friendly support instead.

Let's be clear: Bjoern didn't say you should revert it immediately. He said that the migration path needs to be fixed in the next month (2-4 weeks). That leaves plenty of time to resolve these issues, which I think the consensus is should have been resolved before committing the switch, not after. But given that it's in the tree, let's leave it there for now to continue to improve our testing exposure, and try to get it fixed as quickly as possible.

Robert