Feature #11988
Update Vagrant boxes management design doc with meeting notes
100%
Description
We had a good meeting and came up with an updated design.
The blueprint must be updated to reflect that.
Subtasks
History
#1 Updated by intrigeri 2016-11-22 14:01:24
- Parent task set to
Feature #5630
#2 Updated by bertagaz 2017-02-28 16:09:40
- Status changed from Confirmed to In Progress
- Assignee changed from bertagaz to intrigeri
- % Done changed from 0 to 50
- QA Check set to Ready for QA
Ok, I’ve added what I had in the notes to the blueprint. It was too difficult to rewrite the section so I created a new one. Hope I didn’t miss anything. Assigning to intrigeri for reviewing, but anonym is welcome if willing.
#3 Updated by intrigeri 2017-03-02 08:41:21
- Target version set to Tails_2.12
#4 Updated by intrigeri 2017-03-05 18:32:48
- Assignee changed from intrigeri to bertagaz
- % Done changed from 50 to 80
- QA Check changed from Ready for QA to Info Needed
> Ok, I’ve added what I had in the notes to the blueprint.
Looks good to me, thanks!
I’ve pushed some improvements, referencing this ticket so they’ll show up on Redmine. I really don’t know anymore what to do about the recurring “please set up a spellchecker in your preferred $EDITOR so that I don’t waste my time doing work software can do better than me” topic :(
> It was too difficult to rewrite the section so I created a new one.
OK, fair enough. So let’s get rid of “the section” so we don’t confuse the reader (e.g. ourselves in 2 years) with outdated info. I can do that once you tell me which section you were referring to.
> Hope I didn’t miss anything. Assigning to intrigeri for reviewing, but anonym is welcome if willing.
Frankly, that was months ago, and I have no clue if you missed anything. The text looks good anyway, and it didn’t strike me as obviously wrong, which is the best I can check today. The next steps will validate the design anyway :)
#5 Updated by anonym 2017-03-06 07:07:16
What you wrote, bert, contains what I remember of our discussion. It looks good!
Something that struck me, though, is that the complexity introduced by allowing the same VM instance to be used for more than one build (see bullets 6 and 7) perhaps isn’t worth the small time saving it will yield when repeatedly building the same branch. It was probably me that pushed for having that, but I think I can live with repeated builds taking a minute longer if that simplifies the design.
#6 Updated by intrigeri 2017-03-06 08:30:00
> Something that struck me, though, is that the complexity introduced by allowing the same VM instance to be used for more than one build (see bullets 6 and 7) perhaps isn’t worth the small time saving it will yield when repeatedly building the same branch. It was probably me that pushed for having that, but I think I can live with repeated builds taking a minute longer if that simplifies the design.
Agreed! IMO let’s not include this feature in the initial iteration. The design shouldn’t prevent us from adding it later if needed.
#7 Updated by bertagaz 2017-03-07 14:45:41
- Assignee changed from bertagaz to intrigeri
intrigeri wrote:
> > It was too difficult to rewrite the section so I created a new one.
>
> OK, fair enough. So let’s get rid of “the section” so we don’t confuse the reader (e.g. ourselves in 2 years) with outdated info. I can do that once you tell me which section you were referring to.
I was referring to this section: https://tails.boum.org/blueprint/reproducible_builds/#index4h2, but I’m not sure it’s worth removing it. It could remain there, as it’s just rationales, and the section I added is more about the concrete implementation.
> Frankly, that was months ago, and I have no clue if you missed anything. The text looks good anyway, and it didn’t strike me as obviously wrong, which is the best I can check today. The next steps will validate the design anyway :)
I’ve included all I had in my notes, so we should be good. That was just in case one of you had something in mind that was not written in the blueprint.
intrigeri wrote:
> anonym wrote:
> > Something that struck me, though, is that the complexity introduced by allowing the same VM instance to be used for more than one build (see bullets 6 and 7) perhaps isn’t worth the small time saving it will yield when repeatedly building the same branch. It was probably me that pushed for having that, but I think I can live with repeated builds taking a minute longer if that simplifies the design.
> Agreed! IMO let’s not include this feature in the initial iteration. The design shouldn’t prevent us from adding it later if needed.
That’s probably no surprise that I agree too! :)
I’ve updated the blueprint to reflect this.
#8 Updated by intrigeri 2017-03-13 12:19:24
- Assignee changed from intrigeri to bertagaz
- QA Check changed from Info Needed to Dev Needed
> I was referring to this section: https://tails.boum.org/blueprint/reproducible_builds/#index4h2, but I’m not sure it’s worth removing it. It could remain there, as it’s just rationales, and the section I added is more about the concrete implementation.
Indeed, this section is still useful.
However, https://tails.boum.org/blueprint/reproducible_builds/#index8h2 (“Static build environment”) seems to duplicate most of what you wrote, and what’s not duplicated might be obsolete.
#9 Updated by bertagaz 2017-04-06 08:51:22
- Assignee changed from bertagaz to intrigeri
- QA Check changed from Dev Needed to Ready for QA
intrigeri wrote:
> However, https://tails.boum.org/blueprint/reproducible_builds/#index8h2 (“Static build environment”) seems to duplicate most of what you wrote, and what’s not duplicated might be obsolete.
Ok, then I removed this “section” in commit:006c187b5af87cbe9ee0d0572d4b36e5ed4eb632
Was it what you had in mind?
#10 Updated by intrigeri 2017-04-09 11:15:51
- Status changed from In Progress to Resolved
- Assignee deleted (
intrigeri) - % Done changed from 80 to 100
- QA Check changed from Ready for QA to Pass
Thanks.