On Wed, Dec 25, 2019 at 2:30 PM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > > 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. >
But since people work at the different timezone, it's better to hold the patch for one day at least, so people have a chance to review the change and express the different opinion if they want. It isn't a good practice to submit and then revert patch frequently, I think. > > 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 > > > > > > > >
