Current status / development schedule of trajdata

[Leon0402]

I'm opening this up as a response to my two other closed tickets because I'm unsure if you receive notifications for these.

First of all, thank you for your quick and detailed response. Good to hear that both issues are at least partially already addressed internally.

I'm currently evaluating whether I use this software for my current project for my bachelor thesis. As this will happen in the following weeks, I would be thankful for some insights regarding the schedule of this project.

• Is the current release (as is) considered alpha or already beta?
• Will the development of the library still happen internally after this rollout and be released public? Or will development from now on be directly public?
• Does the current release (perhaps including the mentioned fixed that will arrive soon) support everything needed for being used in Trajectron++? Or are there some crucial features missing at the moment?
• When will the mentioned features / fixes (and other important features / bug fixes) be released? Are we talking about days or multiple weeks?

My goal is to use it for trajectron++ with some custom dataset. I will experiment with this library in any case because I think this is the way to move forward (at least in the long term). Some additional insight help me evaluate if the library might be used already now (within this month) or if it's something to watch out for in the long term rather. Thanks for your help! Very appreciated!

[BorisIvanovic]

Hi @Leon0402 , thanks again for your interest (and for the pull request!) in the project! Let me try and answer your questions below...

• I personally view the current release as a late-alpha, since it can already support basic usecases like training models on single and multiple datasets, albeit improvements can always be made in terms of dataloading time, preprocessing time, etc. and the amount of testing or documentation is not extraordinarily high (yet!).
• The development of the library is still going on internally, and I periodically sync changes between the internal and external versions (I don't plan for them to go out of sync for longer than a week or so). The core idea I have in mind is that any changes or new features are first beta-tested by us internally before rolling out the (hopefully) more stable code externally.
• Yes, I actually already use this codebase to train T++ internally. The only changes required to support training T++ are changes to the encoder of T++ to accept the new data format from the dataloader.
• Days (for now). I plan to actively make changes to, e.g., flesh out the README and documentation, fix bugs, and make sure the base features work/are fast. Once those core elements are set, I'll probably slow down with updates myself (but still actively review and follow up on pull requests!).

Hopefully these answer your questions!

[Leon0402]

Hi @BorisIvanovic, thank you for the very detailed answer and insights. Based on this and my own experiments I decided to stick with the library. Not everything works perfectly yet (obviously), but I see it as a huge improvement compared to all manual converting scripts, evaluation scripts and other stuff.

Just a quick note on one of your comments:

The development of the library is still going on internally, and I periodically sync changes between the internal and external versions (I don't plan for them to go out of sync for longer than a week or so). The core idea I have in mind is that any changes or new features are first beta-tested by us internally before rolling out the (hopefully) more stable code externally.

I see the idea behind this. But I think it would be very helpful to even upstream the internal main branch on a separate development / alpha development branch or something like that. This way users (me as of now :-)) see what bugs you already found / fixed. This avoid me opening up issues or Pull Request for things you already fixed. This might be especially helpful at this early stage, where there are more features / bug fixed to come.

[BorisIvanovic]

First of all, thank you for the vote of confidence! I'm glad to hear you plan to continue using this :)

Regarding synchronizing changes: I like the idea in theory, unfortunately I don't know if it can be done in practice. The only reason I say this is because I don't believe it is possible for me to automatically mirror our internal repo with this public repo since they are hosted on separate services (we do not use GitHub internally).

Having said that, I will do my best to be vigilant and ensure that any bugs we fix or features that we implement internally are quickly brought out publicly!

[Leon0402]

Some providers include functionality for that. For instance syncing from GitLab to Github is quite easy. Others might have similar solutions. I think there are a few though that don't support it natively like Azure Devops. Having said that, it should be quite easy to implement it via a pipeline.

Having said that: I'm very thankful that new features / bug fixed arrive so quickly as well as responses to open issues / PRs. It's awsome to wake up in the morning (european timezone) and see new progress :-)