It has experimental features which are not ready to be rolled into production, such as SRC and ARIAC.
It has features which we want to try before rolling into production, like bug fixes.
The reason for the two uses is mostly historical. Before production existed, default was a place for everything which has been peer reviewed.
But the fact that default has things which are not being tested to be rolled into production means we can't just merge default into production when we know things are working. So we have to cherry-pick changes which will go into production.
Note that this is a problem only for the widgets server. Portal, auth and keys all have default and production branches in sync, so default is only being used for #2 above and can be merged directly into production.
I'd like to propose we clean default and remove anything which is currently not being considered to go into full production (mainly SRC and ARIAC). After this, our work-flow would be like it is for the other servers:
Develop a feature in a branch off default
Make PR against default
Wait for peer review
Once merged and deployed, check that it works on the live server
Make a pull request merging default into production
It shouldn't be necessary for peer review again, the PR would be mostly to keep track of changes
This leaves the question about what to do with features which need to be tested in a live server, but aren't ready to go into production yet. I don't think we have a use case for this coming any time soon, so we can tackle it when it comes up.
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
The way our branches are organized is a bit messy. Currently we have:
production -> deployed to https://cloudsim.io
This is the version which gets to the final users.
default -> deployed to https://dev.cloudsim.io
This is being used in two different ways:
It has experimental features which are not ready to be rolled into production, such as SRC and ARIAC.
It has features which we want to try before rolling into production, like bug fixes.
The reason for the two uses is mostly historical. Before production existed, default was a place for everything which has been peer reviewed.
But the fact that default has things which are not being tested to be rolled into production means we can't just merge default into production when we know things are working. So we have to cherry-pick changes which will go into production.
Note that this is a problem only for the widgets server. Portal, auth and keys all have default and production branches in sync, so default is only being used for #2 above and can be merged directly into production.
I'd like to propose we clean default and remove anything which is currently not being considered to go into full production (mainly SRC and ARIAC). After this, our work-flow would be like it is for the other servers:
Develop a feature in a branch off default
Make PR against default
Wait for peer review
Once merged and deployed, check that it works on the live server
Make a pull request merging default into production
It shouldn't be necessary for peer review again, the PR would be mostly to keep track of changes
This leaves the question about what to do with features which need to be tested in a live server, but aren't ready to go into production yet. I don't think we have a use case for this coming any time soon, so we can tackle it when it comes up.