This page explicitly says ‘your project’. For contributors other than committers, especial it is not their projects, the repo is not writable to them, and how can they create branches on the repo?
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. > > Let me ask you the counter question: What are you concerns with working in > the projects repo? > > 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]). > > 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 > > >
