29/09/14 17:55, intrigeri wrote:
> Hi,
>
> anonym wrote (29 Sep 2014 00:36:43 GMT) :
>> Ouch... I somehow thought that the 4.x bundles already had migrated to
>> ESR31.
>
> Ooops. Actually, the branch is also a 4.x release behind. You do read
> tbb-dev@ and tor-qa@, right?
I do. I'll try to stay more vigilant at bumping the TBB version. On the
bright side, though, now I feel more confident that we won't have issues
with the TBB upgrader. :)
>>> 2. the other major change (migration to Tor Browser) isn't ready for
>>> prime-time yet, [...]
>
>> Agreed. Right now there's only one ticket left, though. That said, there
>> may be some undiscovered issues...
>
> Yeah, I filed 10 tickets after having a quick look, so when I get to
> have a closer look, I wouldn't be surprised that more stuff is
> discovered to be broken. We expect a *lot* from this piece of
> software, and we only formally test (manually and automatically)
> a small subset thereof. Did you run the manual test suite on it yet?
I have done so twice now, once on 3.6.4 and yesterday on 4.0-alpha-3
(built from commit c05a24a). That also includes a full pass for the
complete automated test suite, in the latter run including the test for
for persistent bookmarks (and `block_disk` set).
>> Would you be available for this on 2014-10-07 (see below)?
>
> Yes.
Great!
>>> 2014-10-06 Finish the above, build and upload RC ISO/IUKs
>
>> I may be wrong, but given that we won't have to build our own Iceweasel,
>> I think only one day will be needed for all of the image preparation.
>> That is unless the ESR31 bump introduces issues for us, which it very
>> well may.
>
> I would actually be surprised if we had to fix only minor glitches,
> but I know I'm pessimistic on that one (due to past experience, even
> if this time we should be less affected by the kind of issues we had
> in the past).
Right. I know I tend to be overly optimistic about these things...
>>> The main problem with this is that it only leaves 4 days between the
>>> RC is out, and the time anonym builds the final ISO. The main
>>> advantages are that these 4 days can be used to test the actual code
>>> we want to see in 1.2, and that it leaves anonym and I (and maybe Kill
>>> Your TV too) seven more days to complete our work.
>
>> But it will be problematic for the translators...
>
> Well, at some point, we decided that whoever had a branch merged for
> the next release was responsible for sending a call for translators
> about it. We never implemented it. No big deal, but to implement the
> idea (rather than the word), you (as the RM) could *already* send
> a call for translations against the current state of the devel branch,
> so that translators can start working on it.
>> First of all, I'd hate it if your AppArmor work and kytv's remaining I2P
>> improvements wouldn't make it into 1.2, especially since that would
>> delay them for over four months (!) if we follow our
>> policy strictly.
>
> That's my feeling as well. OTOH, I'm concerned that we may have more
> good stuff in 3-8 weeks that will also have to wait a *long* time, so
> perhaps the root of the problem is having 2 point-releases in a row.
> I don't really remember why we've decided this (and to lazy/tired to
> dig through the archives of our private conversation about it right
> now).
We are actually only squeezing in one more point-release to get into
this situation. IIRC the current *point* release planned on 2015-01-06
was downgraded from a *major* release due to expected unavailability
around the holidays, not least for the RM (me). And the next release
slot after that is 2015-02-17.
>> Combine that with my unavailability and that my work on the TBB
>> migration probably will need some more polishing, and I feel open to
>> delaying our release a bit. I suggest the following new release schedule:
>
>> 2014-10-07 Tag 1.2-rc1 in Git
>> Build and upload 1.2-rc1 ISO/IUKs
>
> I think this new proposal makes much more sense than what we have in
> the calendar, but I don't think it's realistic to a) adjust things
> based on the new TBB / ESR 31, b) build and upload a RC, all that on
> the same day. So, I think this proposal needs a bit more refinement.
Ok then. This is the best I can do, I think:
2014-10-07 Integrate TBB 4.x pre-release based on Firefox 31 ESR
into Tails.
2014-10-08 Tag 1.2-rc1 in Git
Build and upload 1.2-rc1 ISO/IUKs
2014-10-09 Test and release 1.2-rc1
[Continuously deal with potential issues as new TBB's are released to
ease the work on 2014-10-15.]
2014-10-15 TBB 4.0 is hopefully officially released
Tag 1.2 in Git
Build and upload 1.2 ISO and IUKs
2014-10-16 Test and release Tails 1.2
Does this look better?
Cheers!