Dear train fans,
I have taken the freedom to set up advtrains mirrors at notabug.org. As agreed in the conference, bananach.space will remain the main repository nonetheless.
https://notabug.org/advtrains
I also migrated some issues from Hemiptera to the notabug.org bugtracker. There are quite a few threads from Hemiptera that I did not migrate, mostly because they have been inactive for so long that I am unsure whether the issue they are describing has been fixed in the meantime and I don't want to beat dead horses.
For our future bug and patch submission handling, I propose the following:
* Bugs and feature requests:
- We accept bug reports via advtrains-discuss mailing list
- If a submission comes in via mailing list, we create a notabug issue and link the mailing list thread. This way we can assign labels, assignees, milestones a.s.o if we want to and have a good overview on what is already fixed. We can do the actual discussion in the mailing list though, this way we won't lock anyone out.
* Patch submissions:
- Patches will in all cases be sent to the advtrains-devel mailing list and discussed there. If the patch is in response to a bug, this should be linked to the issue report on notabug.org.
We can also use the notabug issue list as informal tracker of "who is working on what".
Please tell me what you think.
Regards,
orwell
This is good in theory to allow us to attach labels to our issues and
assign people, but you need to set some of the key contributors up with
permissions to do those things first. Also it means we can see what
other people are working on and not duplicate effort, as long as people
are actually committed to doing something once they assign themselves.
You have been rather judicious in what you brought across to NotABug,
but I would move more over. Not so much has changed in advtrains that
would make a lot of older bugs invalid. As the author of #116 said:
>PS: please refrain from silently closing bugs - it gives the
>impression that bug reports are ignored and therefor useless
Some comments on specific bugs (sorry to turn this into bug triage, but
that's kind of what you have to do when migrating bugs/issues):
#11 - I would file this to NotABug and assign ywang
#84 - Decoupling long trains which I thought still stands, and would
post to NotABug
#85 - An RFE for direct ATC commands - maybe point the user to
ywang/Maverick's remote control and close
#111 - Close if not reproducible
#115 - Still stands. At the same time, maybe it is time to add a
collision box to track slope nodes?
#116 - Maverick2797 still often manages to get killed while driving
trains on LinuxForks, so this still stands.
#117 - Still a valid RFE. We have the door animation info from when the
each wagon was registered, we just need to collect the maximum door
animation length and send it to the train.
#123 - Still stands, and I would probably like to work on that in the
long term.
#124 - Still stands
#138 - Should still be reproducible with a slight modification to the
copy tool, but I'm not sure if that's a valid way to reproduce it 'in
the wild', but it's still a low-priority issue that should be fixed.
#144 - File this on NotABug since the 'signalbox view' project is very
much alive after the last conference.
#150 - If it can be reproduced, it should not be closed.
#155 - File an issue for someone to do some manual QA testing and tto
make it into an automated test I think.
#157 - Follow up, ask if they have a world where they have the issue. If
not, try to reproduce anyway.
#168 - Still probably a valid patch that needs consideration. BTW, Peter
Nerlich is a pretty cool guy
#173 - Still a valid RFE. Also relates to what gabriel was talking about
with passenger information displays that don't cost anything to run when
they aren't loaded.
#177 - Close if can't reproduce - checkout 5d372b1c on first test, then
current master again to see if there's a difference.
#178 - Not sure if we'll be able to reproduce this one easily. We should
ask the train table server people (so no longer VanessaE, probably
Edgy1?) if we can get their world file anyway I reckon.
#181 - Isn't this done already and ready to close?
#186 - Move this one along, should be an easy close without bothering to
add to NotABug.
#191 - Probably an easy fix, but still move it to NotABug
> #11 - I would file this to NotABug and assign ywang
Now that I think about it, I still need to add documentation on certain
behavior (especially with settings).
In addition, I would appreciate it if maintainer(s) of certain modules
could document the corresponding API themselves and send it as a
patch. It is a lot of work for me to document everything, and it is hard
for me to verify the correctness of such API documentation on my
own. At the moment, I am unlikely going to change the LaTeX internals
too much as it would mean a lot of work to update everything.
I could consider making a presentation on this topic.
> #85 - An RFE for direct ATC commands - maybe point the user to> ywang/Maverick's remote control and close
I would prefer pointing the user to Maverick's remote control. I
currently do not have the time to work on my own version at the
moment. It was also mainly a submission to a MT modding event. If
possible, I could remove my own entry on CDB and let Maverick2797
maintain it if he wants to.
> #115 - Still stands. At the same time, maybe it is time to add a> collision box to track slope nodes?
I could fix this in new-ks. This does not seem too hard in particular,
especially now that MT has a vector manipulation library. (I may also
need to rename the new-ks branch as it currently also includes changes
not directly related to Ks signals)
> #117 - Still a valid RFE. We have the door animation info from when> the each wagon was registered, we just need to collect the maximum> door animation length and send it to the train.
I think the problem here is with a command like "B0ORW" (this is not
something you usually want to use, but it _is_ valid unless we
explicitly require v=0 when doors are open)
> #123 - Still stands, and I would probably like to work on that in the> long term.
Actually such an example world could be useful for testing.
> #124 - Still stands
Isn't there an atc_send_to_train LuaATC function now?
> #144 - File this on NotABug since the 'signalbox view' project is very> much alive after the last conference.
I worked a bit on 2D graphics for the train HUD. I am not sure whether
that could help with the project though.
> #84 - Decoupling long trains which I thought still stands, and would> post to NotABug
This might possibly be mitigated by encasing the train-wagon icons in
a scrollcontainer? Haven't tested to verify though.
> #85 - An RFE for direct ATC commands - maybe point the user to> ywang/Maverick's remote control and close>> I would prefer pointing the user to Maverick's remote control. I>> currently do not have the time to work on my own version at the>> moment. It was also mainly a submission to a MT modding event. If>> possible, I could remove my own entry on CDB and let Maverick2797>> maintain it if he wants to.
I'd be happy to post my rc mod to CDB and call it a semi-official addon
> #116 - Maverick2797 still often manages to get killed while driving> trains on LinuxForks, so this still stands.
I haven't been killed for a fair while, but I've also had the
train-admin priv for a while too which (iirc) disables train-deaths.
> #124 - Still stands>> Isn't there an atc_send_to_train LuaATC function now?
Perhaps a new command to complement /at_whereis <train_id>?
E.g. /at_atc_send_to_train <train_id>,<ATC command>
(Which reminds me to submit my worldpos hud patch for /at_whereis,
Currently a CSM which reads the returned chat message instead)
> #157 - Follow up, ask if they have a world where they have the issue. If> not, try to reproduce anyway.
This was submitted by me. I've been able to leave trains running on
Linux-Forks with various shunting manoeuvres going automatically.
IIRC this was fixed somewhere around commit e7d0a5 ?
I have added gpcf, Montandalar and Maverick2797 to the Advtrains organization and to a team that has write access to the 3 mirror repositories. This should allow you to file, modify and label issues. I don't know the notabug accounts of others, especially ywang, so please kindly let me know so I can add you as well.
As for the issue migration: please just migrate what you think is worth migrating.
orwell
Am 30.04.22 um 19:10 schrieb Maverick2797:
>> #84 - Decoupling long trains which I thought still stands, and would>> post to NotABug> This might possibly be mitigated by encasing the train-wagon icons in> a scrollcontainer? Haven't tested to verify though.> >> #85 - An RFE for direct ATC commands - maybe point the user to>> ywang/Maverick's remote control and close>>> I would prefer pointing the user to Maverick's remote control. I>>> currently do not have the time to work on my own version at the>>> moment. It was also mainly a submission to a MT modding event. If>>> possible, I could remove my own entry on CDB and let Maverick2797>>> maintain it if he wants to.> I'd be happy to post my rc mod to CDB and call it a semi-official addon> >> #116 - Maverick2797 still often manages to get killed while driving>> trains on LinuxForks, so this still stands.> I haven't been killed for a fair while, but I've also had the> train-admin priv for a while too which (iirc) disables train-deaths.> >> #124 - Still stands>>> Isn't there an atc_send_to_train LuaATC function now?> Perhaps a new command to complement /at_whereis <train_id>?> E.g. /at_atc_send_to_train <train_id>,<ATC command>> (Which reminds me to submit my worldpos hud patch for /at_whereis,> Currently a CSM which reads the returned chat message instead)> >> #157 - Follow up, ask if they have a world where they have the issue. If>> not, try to reproduce anyway.> This was submitted by me. I've been able to leave trains running on> Linux-Forks with various shunting manoeuvres going automatically.> IIRC this was fixed somewhere around commit e7d0a5 ?
> I have added gpcf, Montandalar and Maverick2797 to the Advtrains> organization and to a team that has write access to the 3 mirror> repositories. This should allow you to file, modify and label> issues. I don't know the notabug accounts of others, especially ywang,> so please kindly let me know so I can add you as well.
My username on Notabug is y5nw.
> As for the issue migration: please just migrate what you think is worth migrating.
I have mostly worked on certain features instead of fixing bugs, so I do
not think there is much (if anything) to migrate from Hempitera in terms
of things related to what I work on.