In gmane.comp.version-control.subversion.trac.devel, you wrote: > Doki Pen wrote: >> I want to revisit this topic[0]: >> >> I took over the abandoned AnnouncerPlugin[1] last year. I've been working >> on >> the AnnouncerPlugin quite a bit[2]. I'd like to know what we need to do to >> get this thing into trac. >> >> One thing that is becoming cumbersome is supporting backward compatibility >> with trac notifications. Specifically, other plugins use the Notification >> api >> to send their own notifications. This code has to be reimplemented using >> the >> AnnouncerPlugin api since the Notification api is not very extensible. >> >> I still think AnnouncerPlugin needs a good amount of work before being >> included in core, but I think it's at a point where I need specific feedback. >> The core API is very stable. The existing notification functionality is >> there. I think the arch is well described in api.py, but I'd be happy to >> write up a proposal on the wiki. >> > > Good timing, we're wrapping up for 0.12, so it's appropriate to start > discussing the steps ahead. As a notification overhaul has always been > on the table, I think your proposal is very welcome.
Great news! > I looked a bit in the code, without actually testing the plugin yet, but > I must say that at this point I'm already pretty much convinced by what > I've seen. The code is very clean (1), understandable, and its general > architecture seems sound. Great work, from both you and Stephen! Thanks. > Now we have to think about how we could integrate this in Trac itself, > as a replacement to the current notification system. I think the > separation we have introduced between trac and tracopt lately will be > very useful here, as a way to separate the core announcer components > from those which are not always required, like some subscribers. That's great. I'll take a look at the new code. > The question of backward compatibility is also worth mentioning, and > that can perhaps be done with a transition period where the legacy > modules are first part of trac.announcer.subscribers, then in a next > release moved to tracopt.announcer.subscribers, before their complete > removal(?). I just wanted to make it clear here that the announcer ticket_compat module was written to duplicate trac notification. It was also designed to be backword compatible so that announcer could be a drop in replacement. There is no other module that reproduces this functionality as of yet. We do have other modules that add additional features, however. And in the future there could be a module that replaces ticket_compat. > Concerning the producers, I'd welcome your opinion on the discussion > about IResourceChangeListener (http://trac.edgewall.org/ticket/8834), I > think it can be used to simplify things, eventually getting rid of the > producers entirely. I think it is a great idea and something everyone who writes announcer modules would really appreciate. I'll catch up on the tickets and give some input. This could potential remove some LOC from announcer. > But I think that the main issue here is not really about the code, more > generally about the contribution process. Integrating such a large > subsystem can't be done without integrating at the same time a dedicated > contributor ;-) Judging by the amount of support you've already done on > the Announcer, I see that you're able to undertake this task. Of course, > what I'm asking for is not a "lifetime commitment" on your part for > supporting the new notification / announcer subsystem in Trac, but > rather the dedication necessary to get a high quality starting point, in > the release of Trac where this feature will ship. The new system has to > blend naturally with the rest of Trac and the code must lend itself to > be easily extended and maintained. As I've said before, the plugin as it > stands now shows every promise for that. I expect to be around for a while. I really look forward to having the feedback of the core trac contributers on this feature. > Besides, we have a huge list of open tickets on t.e.o for the > notification component, so it would be useful if you could update them > and put them in perspective of the announcer merge. You could also > create a new TracDev/Proposals page (.../AnnouncerIntegration?), which > can be used to document the integration plan, as it evolves. The later > steps would be to get an overview ticket where we could get the initial > patches, then a branch in the sandbox and an associated sub-milestone, a > bit like we did for the multirepos feature (and let's hope that *this* > time, the branch won't take 2 years before being merged ;-) ). OK, so my next steps are: * update notification tickets with regard to the announcer merge * create an Announcer proposal page * create overview ticket with initial patches Don't worry, it shouldn't take 2 years. One other thing I'd like to ask about is the name of the feature. Is evereyone happy with announcer? It feels strange to me. If we were to change it, now would be the right time. Anyway, it's not that important, just something to think about. -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
