Hi Duo, I am sorry I broke my own rule. I should have defined it.
BD: Benevolent dictator for life (BDFL) is a title given to a small number of open-source software development leaders, typically project founders who retain the final say in disputes or arguments within the community. On 2019/12/25 14:26:47, 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > 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? I was speaking of the past (pre ASF) model and the last few days, Specifically not acting like a team and having PR closed without consideration of taking the commit that was not in dispute that made the tool more useful by adding parse-able output. That does not foster community, it stifles it. > Or you say #3 and #4? These are what we want to change. This 3 & 4? 3.Committer review and merge the change to master(with some modification if needed) (with some modification if needed) - this should only happen on a PR as one separate commit to be traceable. There is nothing more off putting the 250 style changes to a users 2 line PR. The changes I want are to support collaboration in the repo. 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in the upstream repo. This works well for "drive-by PRs". This is the term given to what you described as a PR with value, that Author does not want to take the effort to make changes to do it the best way for the system. We can tag team on getting things like this in. If we do not do this we have to give N committers write access to N committers repos. That does not scale well and will encourage forks. 2) Have the **option*** to use github's well know and document WF Give the people the freedom to work in the most efficient way a person chooses (GREEN and CLEAN)[1] 3) add branch protection to master Avoid any accidents - we are all human. 4.Committer make a official release and create a tag to mark the point every two(or three?) months This is fine, but we will need the process documents to be consistent results. We have time for that. > > 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 > > > [1] https://www.youtube.com/watch?v=z8MylQ_VPUI
