Should we start with a more release based workflow.

[CvRXX]

If we want to make kvasir usable for production code we should be more save. With more safe I mean using a git policy that allows us to indicate when a version is stable and ready for use.

We could implement this by using git flow. Als we should do code reviews before any master merge. Main work should be done off the master branch.

I think we have to discuss this and write a git and test plan for this repo and the whole kvasir idea. What do you think?

[odinthenerd]

yes I agree, this needs to go from a proof of concept to something people can rely on. After factoring out the chip file generator we should make a version 1 containing nothing but Kvasir::Register including the seams since that is the only thing I think is ready to freeze at this point. The question is if we want to put register in its own repo too. Register only depends on the chip files and brigand. The HAL of each peripheral as well as Kvasir::Io will depend on register but nothing above that. Our USB stack for example is entirely hardware agnostic above the HAL so there may be a legitimate argument at some point to put register somewhere else.

[Sickeroni]

we already use a modified gitflow
there was a cleanup in august. mainwork is already in the developmentbranch.
people tried until now new functions in there own fork (see odins and my forks with developmentbranches), thats why there were no functionbranches.
only small hotfixes (typos are fixings) were merged directly to dev.
In my opinion this is (for some time) a good strategy.
Registerfiles should in my opinion not be excluded. The main argument for Kvasir is that you just need one 'git clone' and one include.
The only good reasen to exclude is testing modifiings on the script. But a Jenkinsscript could put updated Registerfiles to one special branch that can be tested before merging it to development.

[CvRXX]

I'm not completely agreeing with this.

First of all, I don't think the forking is good final solution. For instance if two people want to implement atomic for all of the register abstraction library they should make a feature branch so they can cooperate. Another advantage of it is that you can see features in your gitflow.

Leaving the registerfiles in repo also doesn't seem like a good idea because you break the versioning. The good thing about git is that it's really easy to see what's changed in source. The registerfiles are like binaries, they bloat your diffs. You are right tough on the easyness thing. We should preserve the easy way to use kvasir. But maybe you could archive that with one bootstrap script or something. It's also possible to host a "compiled" kvasir (with the registerfiles) somewhere as a zip. That zip is made every commit. This will keep the git clean and pure.

addition: with registerfiles I mean the cpp files with the chip information...

[Sickeroni]

First of all, I don't think the forking is good final solution.

answer:

In my opinion this is (for some time) a good strategy.

i never said final solution. But first we should get Kvasir full working (as atomicoperations etc)

For instance if two people want to implement atomic for all of the register abstraction library they should make a feature branch so they can cooperate.

If two people must cooporate, they can so this. i never said never. But now there are not many maintainer and everyone is more testing new stuff.

Leaving the registerfiles in repo also doesn't seem like a good idea because you break the versioning.

answer:

But a Jenkinsscript could put updated Registerfiles to one special branch that can be tested before merging it to development.

Merging would be than manually.
maybe with something like this:
$ git merge --squash v1.0
this would merge many commits to one commit aka smaller diffs.

[...] doesn't seem like a good idea because you break the versioning.

manually = not breaking versioning

[odinthenerd]

I think decomposing into sub libraries may make initial "try it out" type use cases a bit harder but it makes it easier for people to contribute. If we structure the lib so that different code is in different libs it is less intellectual overhead to get up and running with one of the libs. Plus its easier to express code ownership in terms of repos and its easier to track module specific issues.
Essentially the project space that kvasir is aiming to cover is bigger than boost, looking at it that way its quite logical that we should not be one homogeneous lib. Plus why should someone working on memory management really care about SFRs, the two are orthogonal. We need to start thinking about the problem as a set of heterogeneous yet highly composable libraries.

[CvRXX]

It also allows for versioning the thing separately which means the stable/unstable tag is also separated...

[odinthenerd]

as soon as we have more than on lib there is no reason to have the "Chip" files in the same repo as other stuff.