Xiang Xiao <xiaoxiang781...@gmail.com> 于2019年12月25日周三 下午1:36写道：
> 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? > Usually one committer is enough, the only different is that, if the patch is proposed by a committer, then you need another committer to approve it. We need to make sure that a patch has to be reviewed by a committer other than the author. > b.How much time give the committer the chance to say no? > This depends. In general, if a committer thinks it is fine to merge then it can merge the patch/PR. But other committers have the rights to revert the patch/PR, for example if you are not an expert of this area but he/she is, and you even do not ask for his/her comments. So I think during collaboration, you will find the suitable way to decide whether it is OK to merge a PR. We do not need to define everything explicitly. > 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 > > > > >
