[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BANLkTikiL8GRjAQUcMGAPx5Gn7sKXNqB4w@mail.gmail.com>
Date: Mon, 9 May 2011 13:38:38 +0300
From: Shinnok <admin@...nnok.com>
To: john-users@...ts.openwall.com
Subject: Re: Following all the patch activity, not uploading to
the wiki, which patches play well together, revising the wiki page to be better
I forgot to add the advantages to the solution I described since they might
not be that obvious for everyone:
-proper code versioning and history / instead of following mailing lists and
wiki pages
-proper code management / instead of passing around patches from mailing
lists and wiki pages
-proper branching / instead of naming patches and tarballs
-*which patches play well together* / this is ruled out by common sense or
ruling: if you want your branch pulled from, it must *build* and *be* tested
-integration offload from maintainers, if branch doesn't merge well when
pulling, you ask the developer to fix it by merging on his own copy and then
you pull when all is ok
-proper commit messages take care of loads of wiki pages that are hard to
browse, find, read and without context.
-reduce overhead / i for one would feel a little bugged by the fact that I
have to mail a mailing list and write to a wiki page for every patch I make.
On a side note, there's lots of room for improvement to the solution I
proposed and I'm waiting for yours. One such improvement would be some
ruling for tag and branch naming on the john-jumbo repository. For e.g.
instead of:
john-1.7.7-jumbo-1.diff
john-1.7.7-jumbo-1-rar-01.diff
john-1.7.7-jumbo-1-ssh-06-OpenMP.diff
john-1.7.7-jumbo-1-utf8-1.diff
john-1.7.7-SybaseASE-01.diff
We might have:
$cd john-jumbo/
$git branch -a
master
rar
ssh
utf8
openmp-unstable
sybase-testing
...
$git tag
jumbo-1
jumbo-2
jumbo-3
latest
Same for the main JtR repo.
On Mon, May 9, 2011 at 1:09 PM, Shinnok <admin@...nnok.com> wrote:
> Hi all,
>
> Since this discussion is taking place on john-users, may I state with
> respect, *wtf* are you talking about here? A *normal* average user would
> have no idea what you are talking about and this will make people go away,
> running batshit crazy from the list and JtR.
> Community separated edition, jumbo, jumbo patches, incompatible branches
> and patches, bootleg patches?? Nonononono
> There must be a better way of achieving this, instead of running around
> with patches and tarballs in bare hands and wikis, therefore I'll propose an
> alternative solution to the issue at stake, based on the upcoming git repos,
> written after magnum's reply for the sake of context:
>
> On Sat, May 7, 2011 at 12:00 AM, magnum <rawsmooth@...dband.net> wrote:
>
>>
>> On 2011-05-04 22:49, Robert Harris wrote:
>>
>>> I'm finding it more and more difficult to follow all the patch activity
>>> we
>>> have had lately!
>>>
>>
>> It will likely get even worse when Jim posts his "plumbing changes"
>> patches for 1.7.7 and we start to rebase to that. Then eventually it will
>> get much better.
>>
>>
>> Some but not all patches are posted on the patch's wiki
>>> page and some patches don't work well with others.
>>>
>>
>> Most patches work well with most others but there are ususally some manual
>> editing needed because all format patches modify the same places in
>> options.c and many other patches modify the version string in params.h. This
>> is a problem with diff/patch that is hard to work around.
>>
>> I have thought of ditching the format list in options.c and create it
>> automatically from the structs instead. This will save us from almost
>> certain collisions between formats.
>>
>>
>> Some patches are
>>> updated to the next version, and the wiki page may reflects this, but if
>>> you aren't paying close attention you'll miss it.
>>>
>>
>> If you subscribe to that wiki page, you'll get a mail whenever things are
>> added or updated. And maybe anyone updating a patch should move it to the
>> top of the list, so we always have newest first? I think that would help a
>> little. [EDIT: I started to do just that now with my patches.]
>>
>>
> The way I see it we have JtR official and JtR Jumbo which is a *community-enhanced
> *version with lots of other community improvements and fixes over the base
> JtR, which is kept separate from the official version because of quality and
> review reasons(?). On top of that, we have *patches* and tarballs floating
> around on the wiki pages and mailing lists, for JtR and for Jumbo. Please
> feel free to correct my current understanding of the JtR dev flow.
>
> However, all of this can be nicely grouped into the following git
> repositories:
> 1. The main official JtR repository, where only Solar(and other select
> few?) can commit. All others can pull. Branches for exp. dev and tags for
> releases. Master for main dev.
> 2. The main official JtR Jumbo repository, where only Solar(and other
> select few?) can commit. All others can pull. Branches for exp. integration
> work from Solar(and others?) based on 3. repo branches. Tags for releases.
> Master for main dev(if any).
> 3. [Distributed]Clones of 2. repo, where people work on new or old jumbo
> functionality like rar, ssh or utf. Branches are the recommended way of
> working on functionality, using the ones already existing for improving
> experimental code not already in master or new branches for new
> functionality that can be cloned from your public external repo on
> demand(github, gitorious) or by submitting patches(git-format-patch).
>
> Now all that remains to be done is a wiki page explaining all of this and
> where the actual repos reside. People can edit the public part of this wiki
> page(or another one) where links to their public repos along with the
> functionality they bring to the table and all other info required are added.
> I do realize that this solution still has some fragmentation attached to it
> which is mostly added by git's distributed nature(though this is also one of
> its main strengths), but this can be resolved by helping minimize the
> learning curve. I welcome any improvements to the above.
>
> With this solution the development flow is limited to committing and
> advertising repos(and patches for the stubborn), the integration flow is
> limited to pulling and merging(and patching+commit for the stubborn), and
> the user flow is limited to cloning at most.
> --
> User Joe to john-dev mailing list:
> Hey,,
>
> There's rumor flying around that JtR can crack bcrypt() passwords now,
> where can I grab that?
>
> Regards,
> UserJoe
>
> Reply:
>
> Hey UserJoe,
>
> Unfortunately, cracking bcrypt() passwords is not available in the official
> JtR at the moment, however you can grab a Jumbo version of Jtr that does
> that from here:
> git clone git.openwall.org/john-jumbo
> git checkout bcrypt
> ./configure
> make
> ./john
> ---
>
>
> Some patches are
>> updated to the next version, and the wiki page may reflects this, but if
>> you aren't paying close attention you'll miss it.
>>
>
> If you subscribe to that wiki page, you'll get a mail whenever things are
>> added or updated. And maybe anyone updating a patch should move it to the
>> top of the list, so we always have newest first? I think that would help a
>> little. [EDIT: I started to do just that now with my patches.]
>
>
> Since people tend to be lazy when it comes to documentation and such by
> nature, another proper approach would be to create something similar to
> nmap-svn mailing list, where commit e-mail messages are sent every time a
> commit is pushed to an important repo(with commit msg and diff). Openwall
> could have that for the 1. and 2. git repos, however, I don't know how that
> can be achieved with git(nmap uses svn, though most surely possible, at
> least with hooks).*insert research here*.
>
> Now to cool off the possible *rudeness* interpretation at the start of the
> e-mail, it was on purpose, in order to grab attention. Besides that, there's
> no perfect wording, other then the one taken, if I'm going to impersonate an
> average Joe anyway. :-)
>
> Regards,
>
> Shinnok
>
>
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.
