[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 9 Dec 2012 04:27:26 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: self-test duration vs. GPU benchmarks
On 9 Dec, 2012, at 2:40 , Solar Designer <solar@...nwall.com> wrote:
> On Wed, Dec 05, 2012 at 11:12:05PM +0100, magnum wrote:
>> On 5 Dec, 2012, at 21:27 , Solar Designer <solar@...nwall.com> wrote:
>>> On Wed, Dec 05, 2012 at 01:40:40AM +0100, magnum wrote:
>>>> As core John development has come to a full halt I have now merged this
>>>> patch to unstable-jumbo instead of just to bleeding. We'll want it in
>>>> Jumbo-8 anyway.
>>>
>>> I'm not so sure about jumbo-8, but it appears that you've decided for
>>> me, and I have no grounds to object - it is my fault that I haven't
>>> released a new core version yet. I am sorry about that. I do intend to
>>> resume core John development.
>>
>> I'm perfectly fine with going directly towards 1.8-jumbo-1, if that is what you mean. In fact I would prefer that. I assumed you'd want a jumbo-8 given the huge difference between J7 and unstable. OTOH we never manage to "feature freeze" the tree anyway - it always makes people commit more :-)
>
> I meant that we could leave 1.7.9-jumbo-8 without some of the fixes
> prepared for 1.8'ish core (and corresponding jumbo). Nevermind.
The only thing I merged was the tiny self-test patch. It does not change any interface.
>>> Aren't you merging the patch that
>>> adds done() now? Anyhow, you're the one to decide on this, as someone
>>> more active at JtR development than I am. ;-)
>>
>> I was going to merge them long ago, and in hindsight I'm really glad I never did. I really want those patches but merging them [to bleeding but not unstable] will lead to a lot of trouble until next core is actually released. And that could be a year from now from all I know (no offense!). Keeping two (let alone three as we had for a while) git trees apart is a constant source of confusion and extra work. I need to back-port and forward-port stuff that people commit to different (wrong) branches. It was much worse when we had jumbo-6-fixes. Currently it's just the v10 format struct and that's OK. If I merge the done/reset/etc patches now, it would get out of hands.
>
> I'm not sure what you did merge now, then.
I merged john-1.7.9.6-selftest-1.diff and nothing else. It doesn't do a lot except presenting accurate c/s rates early on when running GPU. And the punchline is it does not change any interface anywhere.
> As to my plans for releasing a new core version, this should happen no
> later than April 2013.
That is ages from now, but OK. It's not a problem as long as we (at least I) abandon 1.7.9-jumbo now, or fairly soon. I feel I have to do one thing or the other and I would rather spend time on future code than on soon-to-be-history one.
>> So the best solution for me would be to freeze (and just forget) the current unstable-jumbo branch right away and continue work in bleeding-jumbo only. This conclusion was not clear to me until right now, as I wrote this %-)
>
> OK, so what do we base 1.7.9-jumbo-8 on, if we release that (some time
> before 1.8)? Would it be unstable-jumbo or bleeding-jumbo?
Do we need to release a J8 at all? Just before a core release - which is then followed by a J1? I'm not so sure.
The bottom line is I would like to merge all your patches to bleeding, but I just can't do that and still maintain a tree without them. After the jumbo-6-fixes experience I am absolutely sure it will end up a mess. We need to have *one* tree for people like Dhiru or Claudio to commit to. If that is bleeding, someone need to backport patches. If it's unstable, someone need to forward-port them. I do not wish to do either, I want to write formats.
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.
