> After
reading I have an "interesting" proposal :) . Instead of looking
for single person why don't we do it in shifts - each release one of the
package maintainers does the work. IMHO it is:
+1. In the Eclipse
SDK we also use the rotation approach for Releng work.
Dani
From:
Aleksandar
Kurtakov <akurtako@xxxxxxxxxx>
To:
Cross
project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:
30.01.2020
16:20
Subject:
[EXTERNAL]
Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the
Tracks
Sent
by: cross-project-issues-dev-bounces@xxxxxxxxxxx
On Thu, Jan 30, 2020 at 5:01 PM Jonah
Graham <jonah@xxxxxxxxxxxxxxxx>
wrote:
I am not sure what happened to EPP for
M1 - but at the moment the chatter on the mailing list makes EPP look dead.
I tried to revive getting a +1s for M1 and to find out / understand
the process, but I was met with almost complete silence on the mailing
list https://www.eclipse.org/lists/epp-dev/msg05666.html.
Although this may be a case of transference
- I suspect that no one said anything on epp-dev because they were afraid
of putting their head about the parapet and becoming "it" for
EPP project lead without having any understanding of what that would entail.
I honestly don't know how Markus did
EPP for all these years single handedly* without having to delegate to
anyone - there is something to do generally on every third Thursday all
year round (sometimes even more often like RC times). Did Markus schedule
all his holidays and everything else about his life around the Eclipse
release schedule? Personally I have had to delegate my +1 for the
CPP package a handful of times because I am not able to reliably be around
for each and every release. For someone like me to take on the EPP role
would require a full rebuilding of consensus and delegating authority to
make it sustainable.
I am not even willing to engage in considering**
this as I still have no clarity what is required every third thursday,
is it just clicking a button, or is it hours and days of work to resolve
broken packages (I know Markus has had to do such resolutions in the past
and that is a non-trivial task)
* I am aware that there are others who
have done this too - but for the context of the future of the EPP I am
focusing on Markus' contribution.
** I have other issues with taking this
on - I am the new CDT project lead which is taking a lot of work to consolidate
the project and try to bring new contributors (and future committers!)
online. In addition, because of CDT's dependencies I am taking on more
and more work on those dependency projects.
I hope this helps explain why I can't
break the chicken-and-egg problem on my own - perhaps I am too chicken
:-)
After reading I have an "interesting"
proposal :) . Instead of looking for single person why don't we do it in
shifts - each release one of the package maintainers does the work. IMHO
it is:
* fair
* spreads the work
* will help with automation as every
package maintainer will have to do it at one point
There is the question what if given maintainer/project
doesn't want to do it - well, solution for this is simple drop that particular
EPP.
Jonah
On Thu, 30 Jan 2020 at 07:59, Ed Merks
<ed.merks@xxxxxxxxx>
wrote:On
30.01.2020 11:53, Aleksandar Kurtakov wrote:
> Well, focus on "what" is quite important as I still haven't
seen
> anywhere written what exactly is needed for the "who" decides
to take
> EPP. There won't be any "who" until "what" is
clearly defined.
That is indeed a good point. :-)
Markus didn't announce here despite being prompted, and while I'm sure
he's documented what exactly he does, even I don't know exactly what
that is. I don't expect it's all that onerous. In any case,
in this
thread you can see that he's offered to walk someone through the steps:
https://www.eclipse.org/lists/epp-dev/msg05676.html
I.e., Markus will clarify the "what" when there is a "who"
but if there
cannot be a "who" without a "what" then we have a classic
chicken-versus-egg problem...
Of course my natural reaction is to jump in and be the "who",
but I'm
quite sure that this is also pandering to complacency. That needs
to
end because it's not sustainable. But it would most certainly be
the
best course of action for the greater good...
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Alexander Kurtakov
Red Hat Eclipse Team_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev