mobrovac added a comment. In https://phabricator.wikimedia.org/T114443#1793775, @Ottomata wrote:
> Hi all, I talked to @gwicke a little bit more about this last Thursday. He > impressed upon me a couple of good points I hadn't fully taken in before, and > I want to recognize them. > > **Simplicity ** - Services is concerned that the REST service needs to be > very reliable and not buggy. restevent is simple, and if it never needs to > do anything beyond this MVP, it will not need many changes or deploys > throughout its lifetime. Conversely, EventLogging is a codebase that is > often worked on and improved. Using this established and more featureful > codebase provides a lot of benefit, but brings with it risk of instability > due to changes. > > **EventLogging deprecation** - A big concern expressed at the RFC was > proliferations of systems and the effort needed to port old systems over to > EventBus if we were to use restevent. EventBus is about 2 things: > standardizing WMF events, and getting valid events into a pub/sub for many > consumers to use. The scope of this MVP does not include consumption of > events, and much of the EventLogging codebase is about consuming, not > producing. Using restevent does not mean that EventLogging will be > deprecated. EventLogging does much more than restevent ever would. There > will be other systems that will need to be ported to EventBus, but this is > true independent of the EventLogging vs restevent discussion. I'd also add to this list the out-of-the-box support for: - worker monitoring / automatic restarting - easy configuration - logging and metrics support - easy and quick deployment in production > I think this is one of the sources of conflict. I originally proposed a very > generic solution to an org wide problem, and Analytics has committed to work > on the initial infrastructure MVP that solves the generic problem this > quarter. Services wants to use the solution that solves the org wide > problem, but has additionally committed to an additional goal that depends on > the generic solution. Services wants something that works for them now, and > will make it work for others later. Analytics is interested in the more > generic problems first. We are too, but we need the change-propagation system not only because it's our QG, but also because it allows us to continue our work in the services segment (most notably, pre-generation for back-end services). > @gwicke, @mobrovac, @eevans, and @nuria, I propose we set up a > twice-a-week-EventBus-standup-sync-up-party-meeting to help us better > collaborate and be in sync. How about Monday and Thursdays? Having weekly meetings seems like a good idea. How about we start once per week and take it from there? TASK DETAIL https://phabricator.wikimedia.org/T114443 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ottomata, mobrovac Cc: Milimetric, RobLa-WMF, brion, intracer, Smalyshev, mark, MZMcBride, Krinkle, EBernhardson, bd808, Joe, dr0ptp4kt, madhuvishy, Nuria, ori, faidon, aaron, GWicke, mobrovac, Eevans, Ottomata, Matanya, Aklapper, JAllemandou, jkroll, Hardikj, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, daniel, Mbch331, Jay8g, Ltrlg, jeremyb, Legoktm _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
