Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Automating quality gates on contribution: Copyright header

Wayne,

It seems to me that on the bug itself, 559768, Gunnar suggested we should not overload the ECA check with this functionality and that Dani seconded that.  The suggestion there was that such checking could be enabled by the build process; the verification build does already vote on the on the Gerrit contribution, so that fits well with the existing processes.  By doing it in the verification build, one ensures that the existing code base already follows the high standard expected from the contributors and ensures that a contribution isn't simply rejected but rather continues down the contribution path where commits can be amended later.  This follows well with existing checks such as the platform's excellent API checks that ensure that bundle versions and poms are properly incremented as needed.  I personally see this as the best path forward...

I seems to me that this situation is another one of an unbalanced scale.  All the work burden is on the Foundation staff and all the benefit is on the other side of the scale.  Surely we must all recognize that the Foundation staff is not our exclusive resource to direct.  Of course the Foundation staff does an excellent job and that sets high expectations, but in the end, if we want this new feature, we could also implement it ourselves...

Regards,
Ed

On 19.03.2020 05:40, Wayne Beaton wrote:
I think that implementing this is a good idea in principle. I'm sold. Done well, this could make life easier for committers.

I'm not sure that it lowers the barriers for contributors, however: their pull requests will be met with yet another hurdle to jump. IMHO, we need to put more thought into how this impacts the contributor experience.

But with questions regarding expectations, I wasn't fishing for more requirements. I was querying your expectations with regard to the AC and EF's response.

My best guess is that the handful of AC members that have responded think that this is a good idea. I don't think that anybody other than me has actually said that explicitly, however. So you first step is to build consensus with the AC that this is something worth asking the EMO to invest in and maybe identify some folks to help with an implementation that the EMO can generalize and implement. This, frankly, is the best path forward: prove the concept with one project and then generalize (IT resources notwithstanding).

Regarding the EMO's response... As you well know, implementing a new service will require non-trivial (or at least non-zero) effort to research, implement, maintain, and support. Your characterisation of this as an "easy operation to automate" is unfair (and offensive) to the EF IT staff as trivializes the effort that this will actually take. Implementing this will require non-zero effort, and everything that we add to the stack is a liability that adds to the overall complexity and needs to be supported and maintained by an IT staff that is already working daily miracles.

Wayne

On Wed, Mar 18, 2020 at 7:42 PM Mickael Istria <mistria@xxxxxxxxxx> wrote:
On Thu, Mar 19, 2020 at 12:36 AM Jesse McConnell <jesse.mcconnell@xxxxxxxxx> wrote:
I think it is a part of the responsibilities of the project.

At the moment, it is.
But I think the AC is also about challenging the status quo and finding way to improve productivity of existing contributors, and "welcome-ness" of the project. I think such automation would improve both.

However, I reckon it's not trivial for some projects that are "non-standard".
PS: you know you don't have to update the copyright year after file creation?
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council


--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.


_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

Back to the top