| Thread Previous • Date Previous • Date Next • Thread Next |
Linas,
Argh. What policy? Where?
Search your email archives. I suggest we post a policy description in the opencog wiki after the next IRC discussion tentatively scheduled for Wednesday, but, really, the current policy is pretty simple:
1. It doesn't matter whether a developer keeps one or more long-lived branches or not, they should merge with staging when appropriate -- this may be frequently for tasks or people for which frequent merges make sense, or whenever a major task is done, for tasks which are less appropriate to frequent merging. The task "owner" should decide.
2. Code merged into staging should work at the software level (builds and automated tests run). If it doesn't, the maintainer can roll back any commits.
3. Periodically, code from staging will be tested at the AI level (ideally we'll have automated tests for this, but intelligence testing is tricky and time consuming) and, if it passes, it can be ported to main (or "release", or whatever) with an appropriate release tag, announcements, etc.
I believe that's pretty much it. Of course it can be refined further -- for instance, we should define which platforms does "staging" have to build & run tests successfully at all times. But the above outlines the broad strokes. I hope it's clear. If there's anything that prevents you from understanding or following these policies, let us know.
We are also talking a lot about some "staging" branch, but as of this instant in time, I see only *TWO* branches, in total, that have been published in launchpad.
If you go to https://launchpad.net/opencog and click on "Code" you get a list of branches:
https://code.launchpad.net/opencog Cassio
| Thread Previous • Date Previous • Date Next • Thread Next |
