-----Original Message----- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Wednesday, December 25, 2019 6:55 AM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On Wed, Dec 25, 2019 at 9:55 PM David Sidrane <davi...@apache.org> wrote: > > 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. > Why is it become BD mode without PR branch? almost github project I contributed before don't create the branch for PR, here are some examples: https://github.com/curl/curl/pull/4756 https://github.com/esnet/iperf/pull/935 https://github.com/OpenAMP/open-amp/pull/184 I was referring to the past. Patches were directly applied to master. Anyone could make the comment and suggestion for PR through github UI directly, I don't think we can't review code without PR branch here. Even PX4 doesn't create the PR branch for each patch, for example: https://github.com/PX4/Firmware/pull/13787 you just send it 19 hours ago which against master but without PR branch. No. That is not the case Note its location the BRANCH is here https://github.com/PX4/Firmware/tree/master_SDIO_pu_fixes > 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.. I don't reject the branch on the official repo: if some big feature need to develop or some modification need involve multiple people, the new branch can be created for that after the disscussion. What I don't like is create the branch for every patch, which just make the process more complicated and mess the official repo. I just count PX4 repo: total 272 branches, 64 branches is old than 1 year, 150 branches is old than 1 month. > 2) Have the option to use github's well know and document WF > 3) add branch protection to master > Yes, before patch merge into master, it should go through the review process documented by the workflow. Of course, as Abdelatif note that we have to bypass the workflow in some special case. [DBS] Even in the extreme case You can still do the correct thing. Create a branch, open a PR and use the ADMIN override to merge it.!! > 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
