Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for 4.1 Release #121

Closed
ProfFan opened this issue Sep 23, 2019 · 9 comments
Closed

Tracking Issue for 4.1 Release #121

ProfFan opened this issue Sep 23, 2019 · 9 comments
Milestone

Comments

@ProfFan
Copy link
Collaborator

ProfFan commented Sep 23, 2019

We are planning a 4.1 release, and this is the tracking issue to gather insights and feedbacks on that.

@jlblancoc
Copy link
Member

I think that using "milestones" is a much clearer way to keep track of pending issues before a new release... And there is already one for 4.1, so, should this one be closed?

@ProfFan
Copy link
Collaborator Author

ProfFan commented Sep 23, 2019

Milestones does not have a comment function. Also this method has been adopted by other large projects as well.

@varunagrawal
Copy link
Collaborator

Instead of commenting on every issue to track, we should instead link to issues here, as well as tag each of the linked issues with the GTSAM 4.1 milestone.

@ProfFan
Copy link
Collaborator Author

ProfFan commented Sep 24, 2019

This model is borrowed from Rust, where you just use comment commands to manage issues and Tracking issues. Difference is that they have a bot that automates this process and we currently do not.

@dellaert
Copy link
Member

@ProfFan is in charge of 4.1 and I defer to him as to what model to use...

@varunagrawal
Copy link
Collaborator

But this affects how we do things going forward. If everyone uses a different model for release cycles when they have control, we're going to end up with code smell like the kind we saw over the summer (students in a rush to graduate, etc).

@jlblancoc
Copy link
Member

<offtopic>

students in a rush to graduate

Ohhh, that sounds sooo familiar... It's sad to see that it's a universal thing in Academia
</offtopic>

@ProfFan
Copy link
Collaborator Author

ProfFan commented Sep 24, 2019

First sorry to everyone for being a bit aggressive on making changes here.

I agree with @varunagrawal on the release cycle part. However this has nothing to do with release cycles :) Similar situations happen all over the open source software community, which is exactly the the thing that I am trying to prevent.

In larger organizations, a Request-For-Comments (RFC) based flow has been established for quite a long time, where people draft RFCs that contains all the rationale for a new function or breaking change, and all devs vote for merge or not merge. We are smaller so IDK if that is too much hassle.

@dellaert
Copy link
Member

Ok, now 4.0.3 is pretty much ready? We should clean up this issue: IMHO it should just be the pybind wrapper in 4.1 as well as Removing deprecated methods/functions.

@ProfFan ProfFan closed this as completed Jul 19, 2021
varunagrawal added a commit that referenced this issue Sep 18, 2021
add6075e8 Merge pull request #121 from borglab/feature/constructor-templates
42d4145bb update instantiate_ctors to handle constructor level templates
455ce6169 update test fixtures
3c37fc2a0 update wrapper test fixtures
ffdad925d update interface_parser to pass the tests
bf7416213 add interface_parser test for templated constructor
9fe05d0c9 Merge pull request #120 from borglab/feature/templated-namespace
7622e6432 typo fix
88779c5e6 update instantiator to handle templates in the namespace
0ee86f9a3 add test for templated type in namespace

git-subtree-dir: wrap
git-subtree-split: add6075e8ec0e28d5f47d0a2ecab00deaa9a3da7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants