[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-planning-council] Opt-in is broken
|
Hi,
Here is a small recap of what we discussed during the Planning Council
meeting which occurred at EclipseCon EU last week. We mostly discussed
about the opt-in process.
As explained previously in this thread, this is done today by Wayne and
it was done previously by David Williams. It takes too much time to
Wayne which has to follow and contact by hand the different projects to
be sure that they are paying attention.
We agreed that we have to work on improving our process to be more
"automatic". Today the opt-in process relies on the fact that the
projects touch their aggrcon file. Nothing exists to contact them
automatically if it is not the case. We discussed that it exists many
different things that can be done to automatically contact the projects
before removing them from the SimRel. The problem is that we could
automatically remove these unattentive projects but at some point it
might generate some issues for dependent projects that must be aware of
the removing of their parent's project.
We conclude that we need someone :
* to make this evolution to get a more automatic process
* and to be still there also to pay attention to contact the projects
None of the planning council members can do this for free.
So we discussed that we should be able to find some budget to hire
someone on this subject. Wayne proposed to create a working group but
after discussing this will not solve our main issue which is to find
some financial resources. It turns our technical issue to a business
development issue.
In the end the conclusion is that we have someone in the person of Ed
Merks who can take care of the Simrel by improving the process from a
technical point of view but none of the planning council member
companies can finance this role.
We finished the meeting then by saying that Ed will bring this topic to
the board to be an item for their next meeting.
If you attend the meeting and I forgot something feel free to add your
inputs else if you have any comment on this do not hesitate to reply to
this thread to continue the discussion.
Best regards,
--
Mélanie Bats
CTO
+33 7 87 69 42 84
+33 5 34 57 16 29
@melaniebats
*Obeo*
25 Boulevard Victor Hugo - Colomiers - France
http://www.obeo.fr
Le 02/10/2019 à 20:31, Wayne Beaton a écrit :
The opt-in process for the simultaneous release is, IMHO, broken. We've
taken several runs at this, and have not yet (again, IMHO) come to a
satisfying solution.
I'll start by saying that I believe that some amount of rigor is
desired. Specifically, I believe that shipping broken content is bad and
that some amount of rigor is required to avoid shipping broken content.
Bugs happen. With this discussion, I'm not focusing on bugs. Rather, I'm
focusing on the features provided by participating projects and whether
or not those features are kept current.
Historically, the opt-in process required that all project teams send an
email to cross-project-issues-dev to let everybody participating in the
simultaneous release know what projects were participating, what version
of their content was being contributed, and at what offset. This is
still the requirement today for projects that are new to the
simultaneous release. This actually works pretty well (IMHO); but only
because the volume is pretty low. Coordinating eighty opt-in statements
by email (and identifying those project teams that had neglected to
opt-in) was pretty time consuming.
Projects that participated in the previous release, signal their opt-in
by making any change to their aggrcon file. For the past two releases,
maybe half of the projects actually did this. It's worth noting that
even if every project did actually follow this process, identifying
those projects that neglect to to opt-in is still pretty time consuming.
It's completely reasonable for a project team to decide to let one
particular version of their bits stand for one, two, three, or even all
future releases. If a project team is paying attention, letting an
existing version's bits stand is fine; if they're paying attention and
properly testing aggregation builds, then we at least have a fighting
chance that they'll be prepared to fix problems should they arise. The
concern, then, is that without an explicit opt-in, we have no idea
whether a project team is leaving a particular version of their bits
stand, or that they've stopped paying attention.
Frankly, the most time consuming part of managing opt-in is hunting down
those projects that do not explicitly signal their intention. As I
stated, maybe half of the projects actually followed the opt-in
instructions in the last release. I spent a lot of time hunting down
projects (and identified two that actually had just walked away from the
simultaneous release without telling us), but eventually just gave up
and just added all of those projects that we hadn't heard from to the list.
It's worth noting that we do have some very strong participants who take
their participation very seriously. We need to take care to not add
undue burden on these project teams.
So... again, the opt-in process is IMHO broken. To date, this hasn't
bitten us too hard, but I'm concerned that it will. My sense is that
we're riding a wave of Eclipse IDE Love right now, and that we should do
everything that we can to improve and enhance that.
I'm going to complicate matters and restate that I cannot continue to
manage this. There may be some opportunities for automation, but
somebody is still going to have to step up and own this.
A first step for that somebody might be to open a bug to track
discussion (and open it up for community discussion). I thought that we
had one open already, but I can't find it...
Wayne
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
<https://www.eclipsecon.org/europe2019>
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
