Pardon me, what is a BD model? I do not get your point why requiring users to send a patch or open a PR against master will hindered the community growth? Or you say #3 and #4? These are what we want to change.
Thanks. David Sidrane <davi...@apache.org> 于2019年12月25日周三 下午9:55写道： > Hi Xiang, > > On 2019/12/25 05:36:14, Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > > 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: > > The above workflow was in support of a BD model who preferred to use > patches and refused to use github. (no disrespect intended). The value it > added was incredible quality (but in reality only in the areas important > to the BD). At the same time hindered community growth. This has got to > stop under ASF "Community before code". > We all have pressure driving our needs to get changes into master. We can > do this and it does not have to be the old way or no way or even only one > way. That is too controlling and it hinders Community. > > My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW & > HW group dynamics. He asked us to think about, and ask yourself "How can I > add value to any situation?" When thinking from this perspective it > removes Not Invented Here (NIH) and ego from the thinking. Some times the > answer is "I can not add value" let the others who can do it and trust > them. > > We have time to fine tune this. But we must keep it moving. > > The only thing I am suggestion > 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in > the upstream repo.. > 2) Have the option to use github's well know and document WF > 3) add branch protection to master > > This will not EXCLUDE anyone from doing it the OLD way or as you suggest > below. > > > 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 > > > > > > > > > > David >
