Yes, I agree that we shouldn't make the workflow too hard to scare people for contribution. NuttX isn't a new project, it's open source for more than ten years and has a mature workflow, the whole community is already familiar with it. Let me summary the current workflow: 1.User send patch against master to https://groups.google.com/forum/#!forum/nuttx or 2.User send PR against master to https://bitbucket.org/nuttx/nuttx/src/master/ 3.Greg review and merge the change to master(with some modification if needed) 4.Greg make a official release and create a tag to mark the point every two(or three?) months To "be apache way", the required change is only item 3&4: all committer need involve the reviewing and release process. So, I suggest that we adapter the current workflow with as minimal changes as possible: 1.User send patch against master to dev@nuttx.apache.org or 2.User send PR against master to https://github.com/apache/incubator-nuttx 3.Committer review and merge the change to master(with some modification if needed) 4.Committer make a official release and create a tag to mark the point every two(or three?) months We only need to disscuss how committer review the change and make the release. Since we have two month for the next release, let's focus on the review process in this time. Here are some questions I have, other may add more: a.How many committers need approve the patch before it can merge? b.How much time give the committer the chance to say no? Once all questions get the resonable answer, we can make a vote. If anyone has a new idea(e.g. submodule, dev/pr/release branch, backport, LTS) send your proprosal to dev list and let community discuss and vote. But before the proprosal is accepted by the community, why we stop to use the current workflow and make our work stuck?
Thanks Xiang On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean <jus...@classsoftware.com> wrote: > > Hi, > > Some observations that might apply. > > I've used GitFlow on a few projects here at Apache and elsewhere, it does > have some downsides, it’s overly complex and confuses beginners (particularly > those unfamiliar with git),tends to create long lived branches (which are > hard to merge), master and develop (or whatever you call the main two > branches) tend to subtly get out of sync over time. > > You can change the GitHub default branch (you need to ask infra). A bigger > issue with having master / develop and if you don’t merge frequently is that > people don’t think the committers are that active, external people don't tend > to look at activity on the branches. > > Note that Apache Git/GitHub has some restrictions, we don’t want history to > be rewritten for legal and provenance reasons so a couple of things you may > be used to doing outside of Apache may not be possible. Squashing commits in > some projects tends to be frowned on for this reasons. Similarly we need to > know the author of any change. > > Thanks, > Justin > >
