Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Jul 2012 00:26:33 +0200
From: magnum <>
Subject: Re: magnum-jumbo and magnum-bleeding (NOT J7), and the
 source() function

On 2012-07-09 23:52, jfoug wrote:
>> From: magnum []
>>> 3.       Get jumbo-bleed updated with these changes.
>>> 4.       Move these changes into magnum-jumbo  (since we have a Jumbo-
>> 7RC
>>> branch of git).   Once this is done, bleeding and jumbo should be back
>> to
>>> being much more 'similar' to each other.
>> Thinks that should be in magnum-jumbo should enter the tree in magnum-
>> jumbo, and propagate to bleeding. The other way round works too but is
>> trickier to merge, and history looks weird afterwards (patches listed
>> twice).
> I do not know enough about how git will merge this to comment 'too' much
> about this.  The reason I listed it this way, is that it already IS in
> bleeding, although with wrong name.  Thus, it would be trivial to get
> bleeding as it stands updated. 

You are absolutely right, this did not occur to me. Let's start with
bleeding. I'm not sure we should even bother merging it to magnum-jumbo
now - bleeding will be a released Jumbo within reasonable time, and at
that time, bleeding-jumbo will practically change name to magnum-jumbo.
And there will be no bleeding until core diverts again.

> However if bleeding is simply a set of patches 'OFF' of the magnum-jumbo
> branch, then yes, I think you are right, and we should change the
> magnum-jumbo branch, and then the bleed would simply contain fewer changes. 

For other things, this is the better approach. So, for example, sha-2
changes should be based on magnum-jumbo because that stuff is there already.


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.