David Sidrane <david.sidr...@nscdg.com>于2019年12月26日 周四03:18写道：
> Hi Duo, > > > What is the well known and documented WF of github? I've never heard > about > >it. Please be specific. > > https://guides.github.com/introduction/flow/ > > All I add on top of the above is the naming to keep it easy for me to > remember where the contributions was from and where it will go. (I have 8+ > remotes) and work on many branches at the same time all for nuttx. > > For this ASF project I would use: > > <parent name>-pr-<feature/bugfix/> > > master-pr-stm32h7_TX_DMA > master-pr-imxrt_bugfixes > > > What do you mean by pr-branches? > > See above link and my naming suggestions. > > >I still do not get your point why you > >stick to create branches in the offical repo? Why not just use your own > >fork? If you need multiple continuous commits to finish a big feature, you > >can open a branch, we call it a 'feature branch'. > > Can you push to my repo? No. Can I push to yours No. Why I need to push to your repo? I just push to my own forked repo and then I can create PR to your repo and you can decide whether to accept the PR. I’ve never created something like pr-branches when contributing to open source projects. And for NuttX, since I’m not a committer, I can not push to the repo directly then I can not contribute to the project? > > Let me ask you the counter question: What are you concerns with working in > the projects repo? Because contributors can not create branches on the repo. They do not have permission. And the project I’ve worked on do not use way either. > > > Is it repo hygiene. There are simple rules (guidelines) > > 1) Use clear un ambiguous naming for branches and branch protection. > 2) pr branches when merge get deteted. > 3) Always ask the branch before delete not you own content. > 4) Add a bot it will help > > >And this usually requires more powerful issue tracker system such as JIRA. > > Here is the question I would ask: Why re-invent the wheel or use disjoint > tools (I have used Jira with github - To me, there was not value add that > made it more it compelling, then issues and Project board in github[1]). Maybe GitHub issue is fine, not sure. Anyway, this is not important. Let’s stop. > > > Github issues and PR work sooooo well together and are cross linked > auto-magically. > > [1] > > https://help.github.com/en/github/managing-your-work-on-github/about-project-boards > > > > David > > > -----Original Message----- > From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com] > Sent: Wednesday, December 25, 2019 6:37 AM > To: dev@nuttx.apache.org > Subject: Re: Software release life cycle choices could have implications on > workflow (was RE: Single Committer) > > 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.. > > > What do you mean by pr-branches? I still do not get your point why you > stick to create branches in the offical repo? Why not just use your own > fork? If you need multiple continuous commits to finish a big feature, you > can open a branch, we call it a 'feature branch'. And this usually requires > more powerful issue tracker system such as JIRA. > > > 2) Have the option to use github's well know and document WF > > > What is the well known and documented WF of github? I've never heard about > it. Please be specific. > > > 3) add branch protection to master > > > Agree if the branch protection here means disable force push. > > > > > 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 > > >
