[Chris requested that I explicitly respond to each part of his message. I will do so even though I have little that is constructive to add]
On Sun, Jan 08, 2023 at 04:06:07AM +0000, Chris Morley wrote: > Why would we change to 'main' ? > How does the name change fix merge problems? > It does create doc and web reference problems. In the long run, it's better to match standard github practice. However, I agree that we need not do this right now. It just seemed like a nice hack to avoid re-winding the master branch while still removing the bad merge from project history. > I disagree with having to use pull requests for devs. (if I understood that > right) > We already have problems getting pull request reviewed and aproved. I will not change this without consensus. In the long run, though, successful projects are able to review and merge (or, when necessary, reject) pull requests in a timely fashion. In this respect, our project's health is poor. I think that the way that "core developers" can simply ignore the pull request process if they choose to do so contributes to this. These core developers can both bypass this speed bump if they choose, and ignore pull requests from others even where their expertise can accelerate the PR's inclusion. In other projects where I participate (incuding my work, which is all public on github) working via pull request is the default. It works well, and by numbers I believe that most PRs come from external contributors but admittedly "the it works" depends on having ~4.5 paid FTEs on the project. A small number of reviewers are able to make short work of most PRs, especially when there's a culture of doing it. I spend maybe 5% of my time reviewing PRs, while some of my colleagues probably spend substantially more. (And FWIW thanks for the work you did reviewing PRs over the last year, I see you commented on or reviewed more than a few) However, it's impossible to single-handedly establish such a culture when a different culture is entrenched. The project would have to want to change. > These things seem like radical responses to an uncomon mistake. > This will be only be the second time in about 15 years something like this > happened. You're right, in that I would like to use this as an opportunity to move the project in a direction I think is good. The term "radical" is charged, of course. From my point of view, I'm promoting styles of working that are what I do everyday and which I perceive as working well. > If you want to talk merge strategies see my other maillist talk. > The jest of is - why merge released branches into master at all. As my colleague said, the idea to end the project's long-standing policy of merging from stable to main seems like a "radical [response] to an uncomon mistake." I do not require a response to any of these points. Jeff _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
