1.6 release?

[Ryan Schmidt]

On Nov 11, 2007, at 23:01, Juan Manuel Palacios wrote:

> On Nov 6, 2007, at 3:41 PM, Ryan Schmidt wrote:
>
>> On Nov 5, 2007, at 15:16, Juan Manuel Palacios wrote:
>>
>>> 	It's very pleasing to see the amount of work that has gone into  
>>> base since our last release, but the negative side of that is  
>>> that our current code delta between trunk and the last release  
>>> branch is huge. Therefore I propose we make a 1.6 release with a  
>>> new release branch from scratch, cut off from trunk ToT.
>>
>>> -) on the other hand, is there anything in particular anyone  
>>> would like to see *NOT* released to the public just yet?
>>
>> I could think of one controversial change in trunk: the removal of  
>> the "cd" command.
>>
>> I estimate[1] that we have 339 ports (about 8% of our 4353 ports)  
>> that still use the "cd" command. These ports break without the  
>> "cd" command. If I have some time I'll see if I can fix up some of  
>> the nomaintainer ones; others should do the same if possible. If  
>> we find that we're close to the date when we want to release 1.6  
>> and we still have many ports using "cd", we should delay removing  
>> the "cd" feature.
>
> 	I greatly appreciate your effort to reduce the number of "cd  
> casualties", Ryan!
>
> 	At 331 ports potential casualties and a ports tree sporting 4364  
> entries, almost 10% of casualties is not that acceptable to me.  
> Other than introducing workarounds for these Portfiles, or flat out  
> shelling out when we can't avoid it, don't we have an alternative  
> that'll give us the freedom Tcl's "cd" gave us, but without it's  
> ugliness (changing the underlaying working directory of the Tcl  
> interpreter, nasty!)?
>
> 	Kevin, at one point you said you'd give a MacPorts native "cd"  
> equivalent some thought (at the pextlib level, like fs-traverse?).  
> Did you manage to get anywhere? Landon, any idea you might have for  
> us, to minimize the bloodshed?
>
> 	If there's nothing up our sleeves on this respect, then I'm afraid  
> that for the time being we're gonna have to resort to shelling out  
> for those ports that have no alternatives to get around calling  
> "cd" (like smart paths usage).... but maybe we can do that as  
> breakage reports start coming in...? thoughts? Should we delay 1.6  
> solely for these ports if we have no other solution for them?

I fixed a handful of ports one evening, then got distracted with  
other MacPorts issues the next days. I'll continue working on cd  
issues as I can, but it'll take awhile. Also, only half of the  
affected ports are nomaintainer, so maintainers will have to step up  
and fix their ports. But they probably don't read this list and/or  
probably aren't running trunk so they haven't become aware of the  
problem yet. We could send a mass email to the maintainers of all  
these ports, and maybe some of them would then get into gear. I could  
send such an email if you want.

I don't like the idea of releasing 1.6 as is and waiting for the bug  
reports to come in. I currently have a bad impression of Leopard due  
to all the bug reports we're getting from Leopard users. Even if  
sometimes the affected software is the problem, I blame Leopard.  
Leopard "broke" these ports. In the same way, if users install  
MacPorts 1.6 and are suddenly unable to install ports they depend on,  
they'll consider MacPorts 1.6 the problem, even if individual ports  
should be fixed.

So I would like to either delay 1.6 until all these ports are fixed,  
or change 1.6 so that the cd command is available again. There was, I  
suspect, a single commit which removed the cd command from trunk.  
Simply don't merge that commit to the 1.6 branch. Oh wait, you  
haven't branched 1.6 yet. Ok, so branch for 1.6, then reverse-merge  
that specific commit. Wait to remove the cd command from MacPorts  
until the ports are fixed.