[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <9C8493CB-89E8-4700-A3BE-73797668548D@shinnok.com>
Date: Mon, 25 May 2015 18:41:42 +0300
From: Shinnok <admin@...nnok.com>
To: john-dev@...ts.openwall.com
Subject: Re: Johnny: plan of releases
> On May 22, 2015, at 10:45 PM, Aleksey Cherepanov <lyosha@...nwall.com> wrote:
>
> Shinnok, Mathieu,
>
> According to Mathieu's proposal, there should be a release of johnny
> with 1.4 and 1.5 soon. Summary of progress and current meeting on irc:
>
> ....
>
> - Shinnok considered to not include 1.5 into the release,
>
> - Shinnok would like to include his 1.2 and 1.3 into the release but
> he may be not able to implement them due to his other tasks in the
> beginning of June.
>
> So it is unlikely that the release will be done in time.
Exactly. We don't have enough resources to spend on releasing for every point in the development roadmap, since it does involve more than just git tagging the repo(and it would be a waste of development time). Given that the Roadmap was devised before Mathieu was an option and all tasks were assumed to be handled at leisure time by myself, my Roadmap fails to scale with the current team and workflow. The way I'd like to proceed is to mass all features up to 1.4 and possibly 1.5 into a single release, namely 2.0. Points to consider:
1. Quick jump to 2.0 signals fresh start and outlook for Johnny.
2. It buys me time to complete my tasks and Mathieu to focus more on code for now. It also buys us time to properly coordinate the release and also start considering endorsing Johnny more officially(as per Solar's earlier recommendation).
3. Once we have a proper release plan in place, it should be easier for us to be more agile in releasing point releases above 2.0.
>
> We discussed that the deviation from proposal is not a problem for
> Mathieu. I'd like to add: practical results should be delivered some
> day. Preferably at least one stable release should be done before
> midterm evaluation.
I don't see how this would affect Mathieu's work. As I recommended, he should look at the roadmap as development sprint codenames. After all, as long as we have quality and timely code flowing in, I'm not concerned by much else.
I agree that the first release should happen before the midterm evaluation. I think there's enough time for us to do that, we're about one month away form the midterm, read more bellow.
>
> Rearrangements of releases does not seem a problem. But unclear plan
> of releases seems a problem to me. So I'd like to see a clarification:
> when the release is planned? What's included? What should Mathieu do
> after implementation of code for release and before actual release?
> (Current probable case: the release includes 1.2-1.4 and Mathieu works
> on 1.5 and 1.6 when he finishes 1.4.)
>
> But we don't know how much time the release will take. So it would be
> safe to put 1 week onto testing, fixing bugs, packaging.
We are already onto the right track for achieving this release by discussion. One week for doing the release is a reasonable and sufficient amount of time to book. So by then, we have to:
1. Crop the release action plan (includes platforms, packages, roadmap points to include)
2. Reserve that week for the end of June for acting the plan
3. Keep up the good work on 1.5 and 1.6 tasks, we keep everything that's Out-of-band with a scheduled release on separate git branches as discussed until it's time to merge them into master
Aleksey, I need to know what tasks you can or are planning to handle and when, as far as I know you didn't take responsibility for any? Either tasks in the roadmap or tasks related to the release. If you don't plan on doing anything direct for Johnny and thus continue acting as the buffer between Johnny and JtR that's fine(I am aware of the work you're doing there and we'll probably need more of that), but I need to know so that I can measure up my plans and properly consider what's ahead.
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.
