|Re: [eclipse.org-planning-council] Opt-in is broken|
Hey Mélanie, I missed the meeting somehow, apologize for that. Thanks so much for the summary, this is very much appreciated. Cheers, -Martin > 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. >> > _______________________________________________ > 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.
Back to the top