[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-planning-council] Opt-in is broken
|
Martin,
Getting anyone to do anything is challenging at best.
We've gone from 7 bad licenses to 5, so that's minor progress:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/releases/2019-09/index.html
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/releases/2019-12/index.html
But there's no response to these Bugzillas:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=551550
https://bugs.eclipse.org/bugs/show_bug.cgi?id=551591
I opened this today:
https://github.com/eclipse/eclipse-collections/issues/763
I did that because it doesn't appear that folks actually monitor
cross-projects or even if they do, no action is taken.
Unfortunately we've also increased the number of unsigned artifacts
significantly...
Good citizens might start by looking at the report for their contribution:
https://download.eclipse.org/oomph/archive/simrel/
And those with good intentions will often need to spin a new build to
address the reported problems; that will force them to touch their
contribution.
Its clear to me that many people are not really not paying attention,
not doing new builds, and not testing. As such the train gradually is
becoming a mixture of cool new features, along with cruft that should be
dumped into a recycling container.
Regards,
Ed
On 21.10.2019 13:25, Martin Lippert wrote:
Hey Wayne,
I might not be the best person to discuss this (since I am not deeply involved with projects that participate in the train), but I would like to ask a question:
- Why do you hunt down those projects that haven’t signaled their intention (by modifying their aggrcon file)?
- What would happen if you (or someone else who might be responsible for this in the future) would stop doing this?
My assumption is:
- if a project want to be part of a release, it has to pay attention and test their piece in the context of the release
- modifying the aggrecon file in this case doesn’t sound like a lot of extra burden for those projects (and the “good citizens" that you mention already do that and don’t suffer from it, right?)
- I think the simrel deserves that much attention from the participating projects. It is not asking for “too much” (IMHO).
Bugs might happen, some projects will for sure forget this in the future. But I think it is their responsibility to fix “this bug” in the future and to make sure that they do not forget again.
Maybe the “good citizens” can share with the community how they manage to touch the file in a timely manner.
Just a few thoughts…
See you at EclipseCon Europe - and happy to chat in person… :-)
Cheers,
-Martin
Am 02.10.2019 um 20:31 schrieb Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>:
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.
_______________________________________________
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.
_______________________________________________
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.
