[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2a9faa9cac550055e0735ce064e9af9@smtp.hushmail.com>
Date: Sat, 14 Apr 2012 00:43:50 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: jumbo
On 04/14/2012 12:29 AM, Samuele Giovanni Tonon wrote:
> On 04/13/12 23:54, magnum wrote:
>> Jeeez, we currently have exactly three hundred patches upon latest
>> relased jumbo in the git tree, though most if them are tiny. While I do
>> not personally care about releases, especially now that we have the git
>> repo as a(nother) baseline, I really fear the day we have to wrap this
>> up and describe the changes. December 2011? I have no clue. Did I write
>> that? Naaaah? Oh, I did?
>
> what about "freezing" current status and get rid of every format,
> everything that is not working or can't be fixed in - say - two weeks.
>
> After those two weeks release the new jumbo and merge back all those new
> features so at least we have something new released ?
Sounds reasonable, except I hate code freezes :)
A bigger problem is that nearly all GPU formats are very immature, but
Solar wants them in there (and I do not object to that in general) for
next Jumbo. So what should we do to make them better? Personally I took
great care that the RAR format would "behave" for any OpenCL target I
could produce (including CPU) but regardless, it just fails very ugly on
Solar's 7970. And this is a problem with most of the GPU formats. Should
we just ignore this? Or should we go through heaps to make them better
in this aspect?
magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
