Hi Martine! In general I like the concept and I think various people (including myself) proposed a similar workflow already in the past, but it was always rejected (IMO for good reasons), because of the introduced overhead and missing personal resources.
> 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. Cherry-picking of "hot-fixes" (which would probably occur quite often in current state of RIOT) might be some work - particular, since there will be probably a lot of conflicts. > > > - 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. I don't think this would help. Who would be willing to fix a problem in master with e.g. the transceiver interface while everyone's working on NSTF? Let's wait for RIOT 1.0, before we think about a "stable" master branch again. <snip> I still like the idea of feature branches. > > 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. I'm not in favor of a hierarchical development model. One important advantage of the current flat maintainer hierarchy in RIOT is that we're not dependent on a single person - and no one of us has enough time to be the "Dictator". I'm fine with having one, two, three people being responsible for a feature branch or repository (I think branches would be fine at current point of time), but the "Dictator" should stay the community. Cheers, Oleg -- panic("Alas, I survived.\n"); linux-2.6.6/arch/ppc64/kernel/rtas.c
pgpJ6Sbh4T13a.pgp
Description: PGP signature
_______________________________________________ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
