[V3dot10] Getting 3dot10 done [ was - Taking the blue pill ]

[Jerome Peace]

Getting 3dot10 done was [ Taking the blue pill ]

Hi Matt,

I had not been thinking about the amount of work
involved because with changesets (or going forward
delta streams ) there would be a minimal amount of
hassle. And it could be done in finite time.

The priority for 3dot10 should be in finishing up
without killing the release team. To that end I think
your idea of fixing by reverting the methods in 7158
would work well enough in practice. The versions were
available in 7158. That's how I found the bug. 

The timestamps for the methods that you choose not to
revert still need to be changed. So we can tell that
we have the "blessed" ones. This would mean touching
their packages etc. Lots of work. But anything less
would be hard to debug if the need arose.  (see my
comments in the mantis bug report).

Code review by several reviewers could be considered
sufficient "testing", for the purposes of commiting
the code. Then we can just go forward from the new
image and "deal with problems as they come up".   

In theory, theory and practice are the same. In
practice, they are not.

My earlier comments in this thread were from the lofty
realm of theory.  I have now thought a little on the
priority of getting 3dot10 done and shifted my pov
over into the nitty-gritty realm of practicality.

Yours in curiosity and service, --Jeorme Peace

***
>Matthew Fulmer tapplek at gmail.com 
>Sat Nov 3 00:10:31 UTC 2007 
>
>On Fri, Nov 02, 2007 at 02:05:16PM -0700, Andreas
Raab wrote:
>> Edgar J. De Cleene wrote:
>>> I afraid the blue pill way take a couple of years
for the 98% of 172 
>>> methods
>>> going to future releases.
>>
>> Maybe so. But why exactly is this a problem? The
changes are 
>> "beautifications" at best, they don't fix a
problem, they don't improve 
>> behavior, they don't add features. Why the pressure
to get them done 
>> immediately?
>
>For me, it is an urgent feature because it is the
fastest way to
>re-incorperate all the changes made between 7142 and
7158. With
>the current MCZ update stream, it is nearly
impossible to just
>take a buggy change set out of the update stream and
expect it
>the issue to disappear; you also have to re-do all
changes
>since, since each update can re-introduce the bug
thanks to the
>redundency inherent in packages. It would be easier
to review
>the update and patch it in 7159 than to redo the work
between
>7142 and 7158. Edgar is already over-worked.
>
***


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com