search

HEnquist / camillagui

GNU General Public License v3.0
9 stars 1 forks source link

Fixed plot filters step and added nicer labels for frequency axis #26

Closed JWahle closed 3 years ago

JWahle commented 3 years ago

Depends on and includes the commit of #25.

bitkeeper commented 3 years ago

After switching to this branch the filters tab isn't accessible anymore. Probably something todo with changes in #25?

JWahle commented 3 years ago

Yes, the error was because of the unknown mute parameter for some filters. The fix for this was already included in #25. I just rebased the branch of this PR on #25 - it should work now.

HEnquist commented 3 years ago

I didn't have time to look at this yet, sorry. How about simplifying a little. We could keep master equal to the latest released (and tagged) version, and let all development until the next release is ready happen on the develop branch. You could merge changes yourself into develop (you should have permission now) instead of making many smaller PRs to master where each one depends on the previous. And same on the backend of course. Then once develop is at a good stage for a new release, then make a PR to master. Once merged, we tag it. When doing that in the backend it will build a release package including the frontend automatically.

JWahle commented 3 years ago

@HEnquist I have no problem waiting a couple of days for your review - even if that means to occasionally rebase to keep the PRs up to date. I lose hardly any time on this. However, if you prefer me working on the develop branch without or with much later review, I'm also fine with that. So, what do you prefer?

HEnquist commented 3 years ago

I think I prefer fewer but larger PRs. But it doesn't make sense to change anything right now, since master is already moving towards the next release. Once the next release is out, I would like to switch all development to develop (assuming you want to continue :)). Then for minor improvements or bugfixes, you can just merge them yourself to develop. For big changes it's better to work on a separate branch and then make a PR to develop once the thing is complete. Then it makes sense to open an issue first so we can agree on the general idea before starting. And for stuff in between these two, you can decide for yourself which way makes the most sense.

JWahle commented 3 years ago

Alright, that sounds good. After this, I have two big PRs upcoming for the mixers and pipeline tab, the rest will be rather small changes, which I will then merge to develop.

JWahle commented 3 years ago

I just rebased on #25. This PR is still just one small commit.