Re: Queuing solution for merging patches
Sorry wrong link: [2] - the discussion was moved to LEGAL and I asked it in the legal one: [2] https://issues.apache.org/jira/browse/LEGAL-599 On Wed, Jul 6, 2022 at 7:19 PM Jarek Potiuk wrote: > I added my comment to [1]. I think there are good reasons why the decision > about rejecting the "Merge Queue'' feature from GitHub should be revised > (and I asked for it). > > IMHO it was partially based on misunderstanding how "merge queue" works > and partially because we did not have the precedent. Now we have the > Dependabot precedent which is IMHO basically doing the same thing, and I > explained that explicit act of committer is still necessary for the merge > queue to work (which was the basis for rejection). > > I keep my fingers crossed that we can have it as we also suffer from > having to do back-forth with PRs > > [1] https://issues.apache.org/jira/browse/INFRA-22804 > > On Thu, Jun 30, 2022 at 3:13 PM tison wrote: > >> Hi Sheng, >> >> I think you're right that I can remove 'required_status_checks.strict' in >> .asf.yaml to disable up-to-date requirements and then find other way to >> resolve logic conflict issue. At least the committers should be aware of >> which case should merge main branch. >> >> Hi Martinjn, >> >> Good to know that you meet similar requirements and those previous >> discussions. I think one possible way is finding a sponsored bors-ng >> deployment and ask INFRA to setup webhook, or ask INFRA to enable bors-ng / >> mergify app on the repo. I don't know whether it's a good fit but some >> thoughts. >> >> BTW, GitHub provides an option to always show "Update Branch" but not >> require to be up-to-date. I'll ask INFRA whether there's an option to >> configure. See also https://issues.apache.org/jira/browse/INFRA-23432. >> >> Best, >> tison. >> >> >> Martijn Visser 于2022年6月29日周三 21:13写道： >> >>> Hi Tison, >>> >>> I asked a couple of months ago [1] if Infra could enable Github's Merge >>> Queue Functionality [2]. That was rejected unfortunately. I'm also >>> curious >>> if others think of a solution that would be compliant with the ASF rules. >>> >>> Best regards, >>> >>> Martijn >>> >>> [1] https://issues.apache.org/jira/browse/INFRA-22804 >>> [2] >>> >>> https://github.blog/changelog/2021-10-27-pull-request-merge-queue-limited-beta/ >>> >>> Op wo 29 jun. 2022 om 13:53 schreef Sheng Wu >> >: >>> >>> > Hi >>> > >>> > I think the key is you set up to date for main branch, which makes CI >>> has >>> > to rerun. >>> > >>> > tison 于2022年6月29日 周三19:39写道： >>> > >>> >> Hi Sheng, >>> >> >>> >> Yes. I do _not_ ask INFRA to support it, but to see if there is >>> existing >>> >> practice. >>> >> >>> >> Best, >>> >> tison. >>> >> >>> >> >>> >> Sheng Wu 于2022年6月29日周三 19:33写道： >>> >> >>> >> > Hi Tison >>> >> > >>> >> > I think there is no hard requirement from infra or Apache >>> perspective. >>> >> The >>> >> > PMC could decide what they like, and ask Infra team to set them up. >>> >> > >>> >> > tison 于2022年6月29日 周三19:25写道： >>> >> > >>> >> > > Hi, >>> >> > > >>> >> > > There're several solutions around GitHub ecosystem to queuing >>> patches >>> >> > > passed reviews and waiting for merged, especially in case to avoid >>> >> > semantic >>> >> > > conflict; e.g., Mergify or Bors-NG. >>> >> > > >>> >> > > After enabled branch must be up-to-date with main branch, it >>> >> introduces >>> >> > an >>> >> > > issue that multiple patches can race each other and cause >>> unnecessary >>> >> CI >>> >> > > tasks rerun - two patches can be verified simultaneously, after >>> one >>> >> > merged, >>> >> > > the other should rerun, which generally cause O(n^2) task instance >>> >> while >>> >> > > with queuing only O(n) is required. >>> >> > > >>> >> > > Given that there're existing solutions, I'd like to ask what the >>> best >>> >> > > practice for Apache projects host developments on GitHub on this >>> >> topic. >>> >> > Or >>> >> > > what support does INFRA provide for the certain case. >>> >> > > >>> >> > > Best, >>> >> > > tison. >>> >> > > >>> >> > -- >>> >> > Sheng Wu 吴晟 >>> >> > >>> >> > Apache SkyWalking >>> >> > Apache Incubator >>> >> > Apache ShardingSphere, ECharts, DolphinScheduler podlings >>> >> > Zipkin >>> >> > Twitter, wusheng1108 >>> >> > >>> >> >>> > -- >>> > Sheng Wu 吴晟 >>> > >>> > Apache SkyWalking >>> > Apache Incubator >>> > Apache ShardingSphere, ECharts, DolphinScheduler podlings >>> > Zipkin >>> > Twitter, wusheng1108 >>> > >>> >>
Re: Queuing solution for merging patches
I added my comment to [1]. I think there are good reasons why the decision about rejecting the "Merge Queue'' feature from GitHub should be revised (and I asked for it). IMHO it was partially based on misunderstanding how "merge queue" works and partially because we did not have the precedent. Now we have the Dependabot precedent which is IMHO basically doing the same thing, and I explained that explicit act of committer is still necessary for the merge queue to work (which was the basis for rejection). I keep my fingers crossed that we can have it as we also suffer from having to do back-forth with PRs [1] https://issues.apache.org/jira/browse/INFRA-22804 On Thu, Jun 30, 2022 at 3:13 PM tison wrote: > Hi Sheng, > > I think you're right that I can remove 'required_status_checks.strict' in > .asf.yaml to disable up-to-date requirements and then find other way to > resolve logic conflict issue. At least the committers should be aware of > which case should merge main branch. > > Hi Martinjn, > > Good to know that you meet similar requirements and those previous > discussions. I think one possible way is finding a sponsored bors-ng > deployment and ask INFRA to setup webhook, or ask INFRA to enable bors-ng / > mergify app on the repo. I don't know whether it's a good fit but some > thoughts. > > BTW, GitHub provides an option to always show "Update Branch" but not > require to be up-to-date. I'll ask INFRA whether there's an option to > configure. See also https://issues.apache.org/jira/browse/INFRA-23432. > > Best, > tison. > > > Martijn Visser 于2022年6月29日周三 21:13写道： > >> Hi Tison, >> >> I asked a couple of months ago [1] if Infra could enable Github's Merge >> Queue Functionality [2]. That was rejected unfortunately. I'm also curious >> if others think of a solution that would be compliant with the ASF rules. >> >> Best regards, >> >> Martijn >> >> [1] https://issues.apache.org/jira/browse/INFRA-22804 >> [2] >> >> https://github.blog/changelog/2021-10-27-pull-request-merge-queue-limited-beta/ >> >> Op wo 29 jun. 2022 om 13:53 schreef Sheng Wu : >> >> > Hi >> > >> > I think the key is you set up to date for main branch, which makes CI >> has >> > to rerun. >> > >> > tison 于2022年6月29日 周三19:39写道： >> > >> >> Hi Sheng, >> >> >> >> Yes. I do _not_ ask INFRA to support it, but to see if there is >> existing >> >> practice. >> >> >> >> Best, >> >> tison. >> >> >> >> >> >> Sheng Wu 于2022年6月29日周三 19:33写道： >> >> >> >> > Hi Tison >> >> > >> >> > I think there is no hard requirement from infra or Apache >> perspective. >> >> The >> >> > PMC could decide what they like, and ask Infra team to set them up. >> >> > >> >> > tison 于2022年6月29日 周三19:25写道： >> >> > >> >> > > Hi, >> >> > > >> >> > > There're several solutions around GitHub ecosystem to queuing >> patches >> >> > > passed reviews and waiting for merged, especially in case to avoid >> >> > semantic >> >> > > conflict; e.g., Mergify or Bors-NG. >> >> > > >> >> > > After enabled branch must be up-to-date with main branch, it >> >> introduces >> >> > an >> >> > > issue that multiple patches can race each other and cause >> unnecessary >> >> CI >> >> > > tasks rerun - two patches can be verified simultaneously, after one >> >> > merged, >> >> > > the other should rerun, which generally cause O(n^2) task instance >> >> while >> >> > > with queuing only O(n) is required. >> >> > > >> >> > > Given that there're existing solutions, I'd like to ask what the >> best >> >> > > practice for Apache projects host developments on GitHub on this >> >> topic. >> >> > Or >> >> > > what support does INFRA provide for the certain case. >> >> > > >> >> > > Best, >> >> > > tison. >> >> > > >> >> > -- >> >> > Sheng Wu 吴晟 >> >> > >> >> > Apache SkyWalking >> >> > Apache Incubator >> >> > Apache ShardingSphere, ECharts, DolphinScheduler podlings >> >> > Zipkin >> >> > Twitter, wusheng1108 >> >> > >> >> >> > -- >> > Sheng Wu 吴晟 >> > >> > Apache SkyWalking >> > Apache Incubator >> > Apache ShardingSphere, ECharts, DolphinScheduler podlings >> > Zipkin >> > Twitter, wusheng1108 >> > >> >
Re: Giving our PMs and contributors triage rights on GitHub
Few comments, needs of the Apache Airflow project. In short: big +1 on enabling the "triage role". On 2020/08/13 18:43:06, Julian Hyde wrote: > By PM, I presume that you mean either Product Manager or Program Manager. > I’ve worked at a few companies that practiced “commercial open source”, and > there is inherent tension in the relationship with the “business” people. I read that as Project Manager as well. I think when there are many issues in a project, it is often useful that the teams working on a project also have a Project Manager that helps the team to remove obstacles (this is, I think the main role of great Project Manager). This is the case, where several companies have whole teams dedicated to improve the OSS project. The developers still act as sole contributors on the OSS project, but they are paid by another organisation to do so and the Project Manager is there to make sure the teams work well together as well as individuals. We have some great example of that in our company where we have teams of contributors (also committers and PMCs) working on Apache Airflow and Apache Beam projects (among others) and there are PMs for those projects. What's more - those PMs are not there to provide "Business direction" but to make people working "well" together and there are some good example of people like that who learned how to do it in the open-source cases. Quite recently at the Airflow Summit, our PM Karolina - gave (together with our CTO) great talk about it and explained the challenges and benefits of having a PM in such team: https://www.youtube.com/watch?v=KIEMEYM2PEs&list=PLGudixcDaxY3RGLSlWoN_cEEXhIT1OPmj&index=37 . I can heartily recommend the talk to everyone who is interested in the subject! What's more - if you have great PMs who are really part of the team, they are super happy to contribute to the whole OSS project - and being able to help with the teamwork (for example by organixing issues and helping with tracking the progress) might be a huge help for both - the teams and the project. I think we are really blessed by having such people in our company, but I think there are more people like that. > The key questions are whether a PM can participate in the community (which > means being active on the dev list), make contributions of value to the > project (‘earn merit’), and can put aside their professional affiliation and > act solely in the interests of the project. This is precisely what we require > committers to do. Yes. It's possible and I think it's the same for different people. Actually this statement makes me quite a bit uncomfortable. It somehow implies developer's "superiority" in terms of being able to comply with the rules of Apache regarding professional affiliation. It hurts my way of thinking about people being individuals and I personally think that there is a "discriminating" thought hidden in this statement. Being developer myself I could also feel that way, but I think personal integrity is not really related to the role you have in any company or your job description or affiliation with the company. I know both "business" people and "developers" with both excellent integrity and very poor one. So I totally don't see why "business people" would be inferior in this role. Both business people and developers have different kinds of commercial relation, sometimes ownership sometimes pay structure that might make it easier or more difficult to separate the affiliation from the organisation they are in - but I think it's eventually all the matter of personal integrity, peer pressure and a number of other factors that determine the actions of that individual - regardless of the job role they have. I - for one - have a significant ownership in the company i work in (being co-founder) but my role is purely engineering one - but my ownership could also influence decisions I make. > So, by this logic, a PM would earn committership in a few short months. But I > guess you’re running into a chicken-and-egg problem: if the only > contributions a PM can make are triaging bugs, then how can they earn enough > merit to be made a contributor? One solution is for them to contribute in > other ways, for example writing documentation and testing. That's the very thing - chicken and egg - I think it is very hot and important topic discussed recently that we should have more "non-code" committers in Apache projects and how valuable they are. I think we should make it easy for them to contribute. In our case - more often than not - PMs input to the documentation can be very, very limited. Most of the documentation we have should really be written down by the developers. For testing - we do everything possible to automate it in our project, and again - there is a limited help PMs can provide here. But this is entirely different story for organizing work (in whatever way). It's entirely different for Open Source proje
