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
