Hi, 2015-02-21 20:06 GMT+01:00 Ludwig Ortmann <ludwig.ortm...@fu-berlin.de>:
> Hi, > > On Sat, Feb 21, 2015 at 07:02:58PM +0100, Martine Lenders wrote: > > This is why I propose we change to a slightly adapted topic branch > workflow > > (also known as feature branch) workflow [1]: > > > > - the main RIOT-OS/RIOT repository will get the following branches > > - master: points to the stable version of our latest release > > - one stable branch for every major release (?) > > (I understand "stable" to denote non-changing APIs, and a "stable > branch" to denote a branch which is stable in this sense, and gets > bugfixes, and possibly new features.) > > We don't have enough people to support this at the moment. > Also, we would definitely need to make sure the releases are sensible > for this to make sense. > Let's keep this one open until there is a need, time and a codebase > that makes sense to put this effort into. > I don't get this argument: With my workflow the only new task is the merging of stable and devel and the maintenance of hot-fixes (which can be labeled as such and are thus easily spotable). The merging of devel into stable will happen at every release, and the merging of feature branches into devel if a milestone for the feature is reached. Or were you referring to my optional proposal of release branches? > > > - devel: points to current development version (what is currently > our > > master), hot fixes can be cherry-picked to the master from here. > > According to my first remark there is no need for a devel branch, we > just keep using master. > Sure we first need a stable version to have a stable branch, but my thinnking introducing it now was to avoid confusion we often encountered in the whole transceiver/netdev/ng_netdev situation. > > > - branching from devel: feature branch for every task force that is > > currently in active development, current changes will be merged > regularly > > from devel by the branches maintainers > > "will be merged regularly" sounds like the amount of merging will > increase in total. I'd rather leave it to the respective maintainers > how they work on their feature branch. > That's why I left it at "regularly" as in "when it's needed" (e. g. merge into devel would yield conflicts). Also: more merges mean less merging conflicts over time so why does it sound like you think merging is a bad thing ;-)? > > > - feature branches will be merged into devel if the feature reaches > > sufficient stability. > > What does "stability" mean in this context? > When a certain milestone is reached (e.g. the "current" (apart from two follow-up PRs ^^") state in netdev/netapi context, or when all critical protocols are ready) > > > I observed two extra benefits from that: > > > > - accidentally merged "SQUASH ME" commits can be squashed further > > upstream, before we add the commits to master or devel > > Actually, that is not the case as feature branches will also need to > be PR'd against master, and might need fixing as well. > The "dictator" (as suggested below) can do this on it's own computer, too. Sure a PR is more transparent but I don't agree that we NEED (from a technical standpoint) it. > Also, we could as well "fix" these accidental commits in our master branch. > And catch the fury of everyone on their next pull ;-). > > - we can make maintenance of features more granular (and maybe solve > our > > maintenance problem) by enacting the "Dictator and Lieutenants > Workflow", > > where the "Dictator(s)" are responsible for master and devel, and the > > feature branches can be maintained by the central persons of the Task > Force > > (the Lieutenants). > > We could just as well use the decentralized hierarchical development > model as performed by the Linux community. > https://www.kernel.org/doc/Documentation/SubmittingPatches > This would mean less visibility of the "feature branches" (in > possession of a "Lieutenant" in your terminology), but also less > stress on the "Dictators", because they don't constantly see what > doesn't need to concern them. At least I guess the GitHub interface > would make it much easier to only follow repositories one is concerned > with. > When you look at the text I've linked: they also give the Linux kernel as an example for the Dictator/Lieutenant workflow ;-). The terms branch and repository are more or less interchangable in this context (at least with Git). I guess in the end its a style choice if we decide for task force repositories or feature branches. I would welcome the visibility of development in the feature branch solution, but understand that some might not be interested in the development of some minor task force. Cheers, Martine
_______________________________________________ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
