Re: What's in the NT branch

On Thu, 2008-03-13 at 20:48 +0100, Guido Serassio wrote:
> Too much times something like this is happened:
>
> - Update from CVS of my work dir
> - Fix of build problems
> - Commit of fixes
> - Finished the little time that I have available for development,
> usually during weekend
> - Hope to do some test/debug during the next weekend
> - During the next week someone commit changes in the source
> - Update from CVS of my work dir (again during weekend)
> - Fix of NEW build problems
> - Commit of fixes
> - Finished again the little time that I have available for
> development just for fix NEW problems .....

So why do you update your workdir if you only want to test the stuff you
had last weekend?

You'll get extact the same breakage when updating your branch (i.e.
running cvsmerge in the CVS setup, or bzr merge in the new bzr setup),
so I am sorry but I don't see why keeping a shared branch helps this.

I don't mind you having as many private branches for testing as you like
to support your own workflow (thats after all one of the points why we
selected bzr), but I do mind having stable binary releases made from a
possibly different tree, or including sources not seen in the main tree.

> >What aspect of Windows do you see as the most fragile part?
>
> The main problem is in the code that is touched from others developers.

I would say the main problem is code changes only tested on one
developers platform and not Windows..

> >- the socket/filedescriptor emulation?
>
> Many times very big problems here, and also with proprietary IPC and
> IPv6 support.
> This is the section where currently Squid 3.0 is failing on Windows.
> I think that the forward port of the all 2.6+ related enhancements
> could help the Squid 3.0 Windows support.

Which Squid-2 changes do you have in mind there?

> >- something else forgoten in the list above
>
> Different C/C++ compiler not always compatible with gcc and a totally
> different run time library not based on glibc and not Posix
> compliant. And many times this is a very big problem, true for both
> Visual Studio and MinGW native environments.

Yes, and this will always be seen for as long as we develop for more
than one platform and compiler. But see above for my counter argument
here..

Regards
Henrik
Received on Thu Mar 13 2008 - 14:09:41 MDT