Github "important" label

[LogicParrot]

Well, this was talked about in the post discussing versions and branches but I thought I should mention it:

The new dev cycle that was talked about is this:
Master ---> Testing ---> Stable

Minor bugs and features go into master, only important fixes go directly into testing, once testing is stable for a while, testing becomes stable, master becomes testing.

I created an "Important" tag in Github, it is meant to mark the fixes that should go directly into testing, these are typically crash-fixes and other critical stuff. All features not marked with "important" should go to Master. I hope you guys are ok with this.

Ideally, Testing should never become "stable" until we have no more "important" tagged issues for a while. Feel free to tag anything you think it must make it to the next stable.

I hope you're all ok with this.

[worktycho]

Only thing to add is that changes on testing will need to be merged back to master.

And missing features should never be marked with important, only bugs.

[ThuGie]

no nothing from testing will go back to master,
As you should not be working on testing..
It will just only hold a copy of master worth testing.
So all changes will go directory into master, if worth it into testing, if stable into stable..

[worktycho]

What about bugfixes? If we just merge from master for them we get everything, and I do not have confidence in our ability to produce a master that is capable of promotion to stable without changes.

Or do you mean that we merge to master then cherry-pick to testing, because that has the same end result and just gives us problems when we want to merge in master.

---

Also things should only be marked as important if they are in testing. Thinking about it, perhaps a better name would be release-blocking.

[ThuGie]

master is simply same as always all commits go there,
At a point when somebody finds its time to start testing roll outs aka pre-stable it gets put into testing.
any bugs found will be put into master at that time testing will just be updated and updated and updated, until master sync tester sync stable

This is just my understanding how it mostly go's.
There is no use in separating testing completely from master by implementing fixes into it and skipping master.

Its called master for a reason.

Of course as before big things that you test would probably still get there own spot like always, as it could break a lot of stuff in master.
If people start a re-write of (sample) the socket system.


But i might be wrong though, i am quite random..

[LogicParrot]

The idea of testing is to stabilize it and prepare it for release. Nothing goes there except critical stuff that have to be fixed before the next release. If nothing goes into testing at all, what's the point of testing?

[worktycho]

@ThuGie The problem is that model you then need to stop developing features into master, whilst you're stabilizing it for testing. because otherwise you will never get something that can be promoted to stable. Which means testing will either be a copy of master, or an imutable branch thats the same as release. There is never any point in having a testing branch. Its primarily for when master and testing are actually on different hardware, or when the release process is slow.

What we want to do is to go through the feature freezes on testing, and then master can keep working on features whilst testing stabilizes.