This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Pending setup patches (issue 10)

Robert Collins wrote:
> On Sat, 2003-03-15 at 23:51, Max Bowsher wrote:
>> Robert Collins wrote:
>>> On Sat, 2003-03-15 at 23:38, Max Bowsher wrote:
>>>> I've prepared a list of changes from to 2.332. (I took
>>>> the ChangeLog, and stripped everything that was already on the
>>>> branch) 
>>>> It's long!
>>>> I was just about to "make snapshot" when your cvs commit notice
>>>> arrived. I'll redo from 2.333.
>>> Thanks. I'll branch CVS tomorrow sometime and generate an RC.
>> Is there any need to create a branch until there is a non-bugfix
>> change ready for application?
> There are non-bugfix changes all-but ready. branching is easy, and it
> makes the RC version numbers distinctive.
>> Holding off till then reduces merge work, and doesn't hold up
>> development at all if we create the branch promptly when a
>> non-bugfix does how up. 
> Merging is trivial. cvs diff > patchforhead before commiting a RC
> bugfix, and then patch -p0 in HEAD followed by cvs ci.


>>>> MD5summing takes *too long*!
>>>> I've been running with it turned off in the source since I can
>>>> remember!
>>> Well, it's better than nothing :}.
>> No, seriously, I believe this issue is a release blocker.
> I throw it open for review then. Personally, with a 110Mb local cache,
> md5 checking took 18 seconds - from a reboot, so the disk cache was
> empty.

Too long, IMO. And my cache is bigger.

> I will *consider* patches to change this. The requirement is:
> * don't show packages for local install that aren't available.
> * corrupt package files aren't available.
> Now, perhaps we should only check the md5's immediately before
> install, 

I think this will be less irritating.
I'll see what I can do.

> and with the recent changes to not uninstall replacements with corrupt
> packages, this is a feasible change.
> Still, I strongly favour reliability over speed in this case.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]