Opened 4 months ago

Closed 5 days ago

#27102 closed task (implemented)

gather feedback re decoupling bootstrap progress numbers from BOOTSTRAP_STATUS enum values

Reported by: catalyst Owned by: catalyst
Priority: Medium Milestone: Tor: 0.4.0.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: usability, ux, ux-team, bootstrap, 035-roadmap-subtask, 035-triaged-in-20180711, s8-bootstrap
Cc: brade, mcs, linda, isabela, iry, intrigeri Actual Points:
Parent ID: #28018 Points:
Reviewer: Sponsor: Sponsor8

Description

If we start reporting intermediate bootstrap phases, for example when reporting PT status when connecting to the Tor network through a PT bridge (#25502), there aren't many numbers remaining to insert between some existing phases (if we stick to integers).

We should decouple these so we don't have to cram everything into a tiny portion of the progress bar. It also doesn't make sense to report progress phases that we will never need to execute.

Alternatively, renumber the enums to give us more space toward the beginning of the progress bar.

Child Tickets

Change History (11)

comment:1 Changed 4 months ago by catalyst

Keywords: s8-bootstrap added
Sponsor: Sponsor8

comment:2 Changed 4 months ago by nickm

I favor renumbering over decoupling, but I don't feel too strongly about it.

comment:3 Changed 4 months ago by intrigeri

Cc: intrigeri added

comment:4 Changed 3 months ago by catalyst

Milestone: Tor: 0.3.5.x-finalTor: 0.3.6.x-final

Move my post-freeze 0.3.5 items to 0.3.6.

comment:5 Changed 2 months ago by nickm

Parent ID: #22266#28018

comment:6 Changed 6 weeks ago by catalyst

Type: defectenhancement

comment:7 Changed 6 weeks ago by nickm

Milestone: Tor: 0.3.6.x-finalTor: 0.4.0.x-final

Tor 0.3.6.x has been renamed to 0.4.0.x.

comment:8 Changed 4 weeks ago by mcs

catalyst, can you clarify what is meant by "decouple?" Would control port clients potentially receive different PROGRESS numbers each time bootstrapping occurs? For example, would it ever be the case that BOOTSTRAP PROGRESS=80 would mean something different across different runs of tor? Or is this ticket concerned with an internal renumbering and/or rearchitecture, after which the PROGRESS numbers would be continue to be stable and predictable?

comment:9 in reply to:  8 ; Changed 11 days ago by catalyst

Replying to mcs:

catalyst, can you clarify what is meant by "decouple?" Would control port clients potentially receive different PROGRESS numbers each time bootstrapping occurs? For example, would it ever be the case that BOOTSTRAP PROGRESS=80 would mean something different across different runs of tor? Or is this ticket concerned with an internal renumbering and/or rearchitecture, after which the PROGRESS numbers would be continue to be stable and predictable?

Some discussion about the renumbering approach is in #28281. We might not try to do the decoupling in the 0.4.0 timeframe.

Could you please describe what risks you see from having the numbering possibly change from one run to another?

comment:10 in reply to:  9 Changed 11 days ago by mcs

Replying to catalyst:

Could you please describe what risks you see from having the numbering possibly change from one run to another?

I think it is fine for the numbering to change if the user has modified their configuration, e.g., if they added a PT bridge. But I don't think it will meet user's expectations if "50% done" means something very different the second time bootstrapping occurs vs. the first time. But it isn't clear to me what kind of decoupling you are considering, so maybe this is not a likely outcome.

comment:11 Changed 5 days ago by catalyst

Resolution: implemented
Status: assignedclosed
Summary: decouple bootstrap progress numbers from BOOTSTRAP_STATUS enum valuesgather feedback re decoupling bootstrap progress numbers from BOOTSTRAP_STATUS enum values
Type: enhancementtask

Thanks for all the feedback. I think we'll probably stick to the approach of adding new or additional fixed numbers (possibly renumbering some) for now. We can open a new ticket if we want to revisit the idea of dynamically changing bootstrap progress scaling based on configuration changes, etc.

Note: See TracTickets for help on using tickets.