[
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
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