[Ns-developers] Request to commit -fvisbility=hidden pythonbindings patch

[Ruben Merz]

craigdo at ee.washington.edu wrote:
>> BTW, I guess the result of yesterday's discussion regarding regression
>> testing / bug 370 is that maintainers DON'T need permission to push
>> changes during this phase.  We will however, transition to that mode
>> of operation at some point in the future, say the last week or two of
>> this month
> 
> I found there were two periods when it was extremely helpful to lock down
> the dev repo and run *all* the tests before continuing.  It's not as
> critical at other times ...
> 
> 1) When major merges were happening -- I called this merge week.  We really
> want to demonstrate that a new feature is going run on all of our supported
> platforms (yes, including Cygwin and osx ppc, not just on a subset of
> compilers).   We want to make sure that new bits will run properly and not
> break existing code.  It's really impossible to determine this against a
> moving target.  I had times in which virtually everyone was committing
> changes to this or that module while we were trying to merge something new
> in.  It's extremely painful at a minimum.  I believe you have had the
> pleasure of experiencing this kind of thing, Raj :-)

I don't have lots of experience with this kind of issues, so maybe there
is something I'm missing... Why don't you use a separate branch when
this kind of merge happens? I.e. having a merge branch where you
selectively apply and test each new feature separately?

Best,
Ruben

> 2) During the code freeze/RC period.  We are really striving for stability
> here.  It is a really, really bad sign for the system to be broken in any
> way during this time.  It would be bad for RC-n to come due and to have the
> release manager run the tests and discover that the system was broken the
> week before by a "bug fix."  I think the release manager really needs help
> from the developers to make sure this doesn't happen; and I think we should
> start helping out perhaps a week before RC1 by starting to run all of these
> tests when we make changes.  More testing eyes make for less catastrophic
> problems, so to speak.
> 
> FWIW
> 
> -- Craig
> 
>