> For me on HBase, this depends on lots of things. If it is only a typo then > I will merge it immediately. If it is a simple bug fix, I will wait a bit > long and if some committers are familiar with this part, I will try to ask > their opinions. And if this is a very big new feature, sometimes people > will even send an email to the mailing list to attract more reviews before > committing.
Some ASF projects define Obvious Fixes and Emergency Merges. Obvious Fixes are the like of typos, cosmetics, CS violations that slipped by the review, etc. Emergency merges are where nobody is around to review the change and some subsystem is broken and needs it. These can be merged by a committer without waiting for another review. Obvious fixes can be frequent during the release branch period. On Wed, Dec 25, 2019 at 12:59 PM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > > What I mean is that, nobody wants its patch to be reverted right? So you > will find a proper way to archive this. There is no straight forward rule > on how much time to wait. > > For me on HBase, this depends on lots of things. If it is only a typo then > I will merge it immediately. If it is a simple bug fix, I will wait a bit > long and if some committers are familiar with this part, I will try to ask > their opinions. And if this is a very big new feature, sometimes people > will even send an email to the mailing list to attract more reviews before > committing. > > So in general, I do not think there is an one-for-all rule. NuttX community > has its own culture, and the ‘rule’ will be set up though practice. > > Thanks. > > Xiang Xiao <xiaoxiang781...@gmail.com>于2019年12月25日 周三19:50写道： > > > 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 > > > > > > > > > > > > > > > >
