Note: this page should be about the discussion that took place during the conference itself. Comments should be written elsewhere, e.g. on the mailing list.

The conference started at 20:00 UTC.

• gpcf pointed out the lack of testing system in advtrains. The lack of testing has, according to gpcf, slowed down the development of advtrains to an extent.

(notes by @ywang)

• The timetable system proposal was brought up again, as in the previous conference.
• dario23 requested a user-friendly API for the timetable system.
• gpcf noted that a timetable system could make it easier to create information systems.
• dario23 suggested creating a new track to inform trains and stations. It was also proposed that trains could address train delays, such as with more intense braking.
• orwell said that a user interface would be appreciated. Blockhead mentioned a formspec editor.
• gpcf suggested implementing timetable “buffers”.
• gpcf suggested a “subtrain system” that allows splitting trains.
• orwell mentioned SimSig, where the resulting trains from shunting can get separate timetables.
• gpcf thinks it may be interesting to see how the timetable system affects shunting.
• There was a discussion between Blockhead, gpcf, and dario23 on the use of timetables for shunting operations. LuaATC may be involved.
• orwell wanted a system of “guaranteed connections”, where a train would wait for another train.
• Some features do not need to be implemented in the first iteration. Implementation details can be discussed later.
• Support for LuaATC (e.g. timetable-specific events) may be added.
• gpcf could start working on the timetable system.

(notes by @blockhead)

dario23: A more noob-friendly timetable system.

• orwell: Is it necessary? Basic ATC should be useable for this purpose.
• dario23: To bring a proposal for additional track type that makes other tasks easier.

orwell: Timetable

• Recording based entirely on relative times. The first train arrives, it sets a time. No need to program a railway time to start the timetable on.
• gpcf: There should be editing features for after the timetable is recorded.
• orwell: GUI with Tabs, one tab per line
  • Blockhead: Instead of headers, maybe a selection list
  • Blockhead: Use luk3yx.gitlab.io/minetest-formspec-editor to help drafting
• gpcf: Provision built in for sub-train/train splitting system
  • orwell: Do it like SimSig where there are 'split train into new timetable id' and 'wait for a train to join' commands.
• gpcf: Fitting regular shunting into a schedule for, for example, through-coaches
  • Maverick2797: Can the timetable simply send a LuaATC interrupt.

(notes by @dario23, via @Blockhead) Dario23 proposed a new track with the following specifications:

• give infos to stations
• give infos to train
• more easy
• more user-friendly interface
• track takes infos from train and give them to stations about traffic, delay ecc…
• make the train find a way to reduce the delay
• track should be before station/stop rail
• this track IS connected to the station stop rail like a tcb
• train does not stop at this track
• if train hasn’t delay can let pass through

(back to notes from @Blockhead) Describing dario's proposal in my own words

• Tracks that go before the station/stop rail. It is connected on a 1-1 basis like a TCB. that give information to the trains such as:
  • Which station is next, how long the stop is for
  • Ways to catch up if timetable is too far behind.
    • For example, do not turn ARS off so the train will not be late departing the station.
    • Brake harder
    • Less time on the doors
    • Accelerate faster
    • orwell: Setting a quite low minimum stop time would naturally have this type of effect in his proposal

orwell: Request for someone to step forward and work on the timetable system because he has not got the time. Some sign of commitment from gpcf but nobody else.

(mixed notes by @ywang and @Blockhead)

• Orwell is working on the route_prog_rework branch. The goal of the branch is to improve the experience of route programming.
• Ideally, the user only needs to specify the starting and ending point of the route.
• The idea is to reduce problems caused by erroneous route programming.
• Blockhead pointed out that pathfinding may become a problem for complicated junctions. The solution suggested by Blockhead and Maverick2797 is to mark a 'waypoint' or point that the route must travel through. This would work like dragging a specific point on the route suggested by Google Maps.
• Maverick2797 (and many others previously) requested for a way to edit routes instead of making them again from scratch.

(notes by @ywang and @Blockhead)

• The advtrains_itrainmap mod could be revived, but orwell would not like to see it return in its previous form.
• itrainmap ran very slowly for larger areas.
• orwell said that it would be interesting to have actual working signalboxes.
  • He proposed that there should be a view like a train dispatcher can see, similar to SimSig or a physical train control board based on relays. The exact method for constructing these was not explained in detail.

(notes by @ywang)

• Hemiptera is currently problematic because of spamming. It is also blocked by certain email providers.
• gpcf: continuing the work on Hemiptera is mainly reinventing the wheel.
• gpcf chose sourcehut because of the email-centric workflow (as opposed to requiring everyone to log in).
• gpcf: the issue tracker is mainly internal (i.e. for developers). Discussions take place on the mailing list.
• gpcf: self-hosting could be an option.
• Blockhead: one advantage of Hemiptera is that it is not as easy to accidentally start new threads in cases where it is not desired.
• gpcf: Hemiptera lacks a proper web UI.
• orwell: notabug.org is also an option.
• orwell: the email-based workflow is not particularly integrated.
• [Some points on notabug.org and sourcehut were mentioned and not listed here.]
• This topic may need to be discussed in the future.

(notes by @Blockhead) A few systems were discussed, mostly for what could replace hemiptera, but source control and contribution also inevitably came up.

• Hemiptera
  • Anonymous by design, but it gets confusing
    • Has a profile picture system, maybe also pseudonyms? Too hard to come up with something
  • Already in place
  • Suggested by Blockhead that it could continue to be worked on.
  • gpcf: If it has to be reworked, do these:
    • Web submission form (current one is totally broken)
    • Admin tools: Delete spam etc.
    • However, he sees this as more like reinventing the wheel.

* SourceHut

• No login
• More like a TODO-tracker.
• Seemed to require manual filing of issues by developers.

* Notabug or self-hosted gitea

• Can be hooked to run SourceHut CI.
• Does require an account. However, when polled, most of us said we already had an account at NotABug.
• Allows PRs which might aid contributions.
• Does not work inside the 'git via email' workflow that is the preferred method for project maintainers so far.
• Could have reliability problems given its history.

orwell would like to keep the sourcehut mailing lists in any case as a reliable point of contact.

Among source repositories, although it was clear that there are many mirrors, the consensus was to keep bananach.space as the authoritative repository, under gpcf's control rather than a third party. No clear consensus emerged on what to do about improving bugtracking or making contributing easier.

gpcf: For push access to bananach.space, email him. Contributors can be given push access to only specific branches and only a few have access to master.

(notes by @ywang)

• Blockhead suggested and Maverick2797 seconded suggested creating a dev branch for testing and then merging it into the master branch.
• gpcf: more feature branches are needed.
• Blockhead: The dev and master branch differ in that the dev branch cannot be broken. It would be nice to be able to apply patches to the development branch.
• orwell: The dev branch could be tested on (for example) LinuxForks and then merged into the master branch.
• gpcf: People should use the releases for stability.
• [Some discussions follow.]
• orwell: thing could be left this way for now. The dev branch currently does not need to be introduced as there is not much activity.
• Blockhead: there is a lack of tests.

(notes by @Blockhead) Proposal from Blockhead to add a 'dev' branch that is ahead of or equal to master where we can merge without worrying about whether something is broken and that broken state has gone into master.

1. Advantage: Merge patches faster without worrying about breakage.
2. Advantage: Merge several feature branches before going to master
3. Disadvantage: Bureaucracy, doesn't fit our existing workflow.

gpcf: Master is not expected to be unbroken. Only releases. Adding this branch would not help us but instead overcomplicate the existing workflow.

ywang, 56independent: would prefer master to be unbroken, but can agree it is not necessary. 56independent said he was running master on his server but could move to stable release.

Blockhead, gpcf: Server owners should not be running master unless they are prepared to beta test advtrains. Linuxforks is the main public test server.

orwell concludes: Probably more work than benefit. The project does not move fast enough to warrant it. Our current methodology works. Feature branches work well for our purposes so far.

(notes by @ywang and @Blockhead)

• orwell: remap the inventory button?
  • Potentially unify onboard computer with other controls.
    • Blockhead (in retrospect only): The formspec would be getting quite huge, which is not small-screen friendly.
• ywang thought about changing the controls, but some things may need to be improved.

• Blockhead: “wagon transition”: similar to “aliases” that convert certain wagons to other types.
• This appears to be implemented by both gpcf and Blockhead.
• gpcf: There could be a conference on the livery system

(notes by @Blockhead and @gpcf)

• gpcf: There should be smaller conferences for those interested in only certain parts of the project, such as livery, timetabling or i18n.
  • Blockhead: Volunteered to lead a livery conference and prepare a presentation for that.
  • dario23: Expressed interest in an Italian localisation. Was asking to also be prepared to maintain it
  • ywang: Merged French translation recently.
• Blockhead: We should try to use the wiki and engage with proposals more frequently between conferences.

(notes by @Blockhead)

• ywang: Requested people to read and give feedback on his documentation branch, which has gotten quite substantial.
• Blockhead: Need to start working on the ATC video…
• Blockhead: Can we really be using MBB's stuff? Most of it isn't licensed. Also he has renamed to mbruchert on GitHub.
  • Various people suggested various licenses from WTFPL to LGPL and CC, but nothing certain.
  • Repositories have no licence statements.
  • orwell: Clearly he doesn't mind us using them because he isn't suing.
    • Blockhead (only in retrospect): Yes, and he also has merged some changes recently.