View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004547 | GNUnet | ARM service | public | 2016-05-31 18:19 | 2019-02-28 11:17 |
| Reporter | lynX | Assigned To | lynX | ||
| Priority | low | Severity | text | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.11.0 | Fixed in Version | 0.11.0 | ||
| Summary | 0004547: UX: Better names for AUTOSTART vs FORCESTART | ||||
| Description | A year later I understand that "AUTOSTART" means it will be started "automatically" on demand rather than just start automatically. The semantic confusion meant some unnecessarily spent time. I suggest we rename S/AUTOSTART/ONDEMAND/g; I could easily do this with my global search and replace tools, but I know you would hate me for breaking all of your gnunet.conf's, so decide when to do this. Maybe together with other similar tweaks at next major release? Another option is to introduce a #define LEGACY that supports old config names... | ||||
| Tags | No tags attached. | ||||
|
|
it's indeed confusing, START_ONDEMAND and START_ALWAYS would be more intuitive |
|
|
No objections from my side, just make sure you change code, conf files, and documentation... |
|
|
We could introduce code that detects legacy configuration strings and dies on them, so the users are required to fix their configs… |
|
|
There's not enough legacy deployments to justify that. But we do need to change code/conf and docs. |
|
|
I was just going through the code to make the change, when I saw that configure has an AUTOSTART feature which describes it as what FORCESTART actually does. Also several code comments refer to AUTOSTART as actually starting up services rather than doing so on demand. Apparently AUTOSTART originally had the meaning of FORCESTART, then socket listen was introduced, then FORCESTART was introduced to bypass the socket listen feature. In practice this sounds very much like the history of unix. One patch on top of the other to bypass the effects of the previous patch. I start to get the feeling that if I'm not very careful I might actually break something. The number of occurances of the string AUTOSTART is staggering. |
|
|
Well, just try to be careful. We all break something sometimes ;-). |
|
|
e73402fc3a6f233b48330435f61ccd93722ac0e5 and… |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-05-31 18:19 | lynX | New Issue | |
| 2016-05-31 22:28 | tg | Note Added: 0010825 | |
| 2016-05-31 22:33 | tg | Note Edited: 0010825 | |
| 2016-05-31 22:51 | tg | Note Edited: 0010825 | |
| 2016-06-01 14:13 | Christian Grothoff | Note Added: 0010830 | |
| 2016-06-01 14:24 | lynX | Note Added: 0010831 | |
| 2016-06-01 19:11 | Christian Grothoff | Note Added: 0010836 | |
| 2016-06-01 19:11 | Christian Grothoff | Status | new => confirmed |
| 2016-06-01 21:29 | lynX | Assigned To | => lynX |
| 2016-06-01 21:29 | lynX | Status | confirmed => assigned |
| 2016-06-01 21:36 | lynX | Note Added: 0010838 | |
| 2016-06-01 21:43 | Christian Grothoff | Note Added: 0010839 | |
| 2018-06-07 01:14 | Christian Grothoff | Assigned To | lynX => |
| 2018-06-07 01:14 | Christian Grothoff | Status | assigned => confirmed |
| 2018-06-23 15:26 | dvn | Assigned To | => lynX |
| 2018-06-23 15:26 | dvn | Status | confirmed => assigned |
| 2018-06-23 17:16 | lynX | Status | assigned => resolved |
| 2018-06-23 17:16 | lynX | Resolution | open => fixed |
| 2018-06-23 17:16 | lynX | Fixed in Version | => Git master |
| 2018-06-23 17:16 | lynX | Note Added: 0013062 | |
| 2019-02-12 09:20 | Christian Grothoff | Target Version | => 0.11.0 |
| 2019-02-16 11:54 | Christian Grothoff | Fixed in Version | Git master => 0.11.0 |
| 2019-02-28 11:17 | Christian Grothoff | Status | resolved => closed |
