Il giorno ven 24 apr 2026 alle ore 16:49 Yurii Palamarchuk < [email protected]> ha scritto:
> Hi everyone, > > To run the website tests, we must install the missing dependencies on the > remote runner. Can anyone help with this? > > > https://github.com/apache/zookeeper/actions/runs/24838423432/job/72730186177?pr=2373#step:5:7082 I would say that you have to update the CI job to setup the tools you need Enrico > > > Regards, > Yurii > > On Fri, Apr 17, 2026 at 4:27 PM Yurii Palamarchuk < > [email protected]> wrote: > > > Sure. I'm opening a PR now! > > > > On Thu, Apr 16, 2026 at 3:31 PM Andor Molnár <[email protected]> wrote: > > > >> Thanks David. > >> > >> Totally agree. > >> Can we move on with the new website Yurii? > >> What do you need to open pull request? What are the open questions? > >> > >> Andor > >> > >> > >> > >> > >> > On Apr 16, 2026, at 02:07, Dávid Paksy <[email protected]> wrote: > >> > > >> > Hi All, > >> > > >> > In the meantime the Apache Phoenix team merged the new website, you > can > >> see > >> > it here: https://phoenix.apache.org/. > >> > > >> > On the other day I had to wait for an hour and I only had my > smartphone > >> on > >> > me and I was able to read ZooKeeper documentation from the redesigned > >> > website and learn from it. While not impossible, it would be harder to > >> do > >> > this with the current documentation pages. > >> > > >> > Regarding security vulnerabilities, actually the current ZooKeeper > >> website > >> > page contains Bootstrap v4.1.3 which is end-of-life and contains one > >> known > >> > XSS vulnerability and jQuery v3.3.1 which contains 4 known security > >> > vulnerabilities, including the critical CVE-2019-11358 (Prototype > >> > Pollution) and multiple Cross-Site Scripting (XSS) issues. > >> > > >> > Personally I'd vote for technical modernization here to fix the > current > >> > CVE-s and because this also makes the documentation more easy to > >> approach. > >> > I can also offer my help in the website dependency updates. > >> > > >> > Best Regards, > >> > Dávid > >> > > >> > > >> > Yurii Palamarchuk <[email protected]> ezt írta (időpont: > >> 2026. > >> > ápr. 2., Cs, 10:48): > >> > > >> >> Here is the code: > >> >> > >> >> https://github.com/yuriipalam/zookeeper-website > >> >> > >> >> It's not a PR for the zookeeper repo yet. > >> >> > >> >> Regards, > >> >> Yurii > >> >> > >> >> On Thu, Apr 2, 2026 at 3:33 AM Christopher <[email protected]> > >> wrote: > >> >> > >> >>> Where is the code for the react version of the site? > >> >>> > >> >>> On Wed, Apr 1, 2026 at 2:53 AM Dávid Paksy <[email protected]> > >> wrote: > >> >>>> > >> >>>> Hi All, > >> >>>> > >> >>>> To have a sense about maintenance need, you can see the JavaScript > >> >>>> dependabot PR-s in the HBase repo here: > >> >>>> > >> >>>> > >> >>> > >> >> > >> > https://github.com/apache/hbase/pulls?q=is%3Apr+author%3Aapp%2Fdependabot+is%3Aclosed+label%3Ajavascript > >> >>>> > >> >>>> So yes, it requires some maintenance. > >> >>>> I'd also recommend to enable Dependabot dependency updates as they > >> are > >> >>>> helpful. But if not, running 'npm audit fix' manually is rather > easy. > >> >>>> > >> >>>> For how the sources look you can check here what Yuri implemented > for > >> >>> HBase: > >> >>>> > >> >>>> https://github.com/apache/hbase/tree/master/hbase-website > >> >>>> > >> >>>> > >> >>>> Best regards, > >> >>>> Dávid > >> >>>> > >> >>>> Christopher <[email protected]> ezt írta (időpont: 2026. márc. > >> 31., > >> >> Ke > >> >>>> 22:47): > >> >>>> > >> >>>>> It's also pretty easy to use dependabot on the website repo to > check > >> >>>>> for updated site dependencies. That should be easy to handle if > the > >> >>>>> assets are included in the repo itself, and not loaded from other > >> >>>>> domains, as per the ASF policy > >> >>>>> (https://privacy.apache.org/policies/website-policy.html) > >> >>>>> > >> >>>>> On Tue, Mar 31, 2026 at 11:05 AM Yurii Palamarchuk > >> >>>>> <[email protected]> wrote: > >> >>>>>> > >> >>>>>> I know about it, and we're not affected by it. This vulnerability > >> >>> allows > >> >>>>>> attackers to bypass the React's server authentication, but we > don't > >> >>> use > >> >>>>> it. > >> >>>>>> We don't have any runtime node.js server, so we aren't affected > by > >> >>> any of > >> >>>>>> these. > >> >>>>>> > >> >>>>>> Best Regards, > >> >>>>>> Yurii > >> >>>>>> > >> >>>>>> On Tue, Mar 31, 2026 at 4:38 PM Patrick Hunt <[email protected]> > >> >>> wrote: > >> >>>>>> > >> >>>>>>> this is from december :-) > >> >>>>>>> > >> >>> > >> https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182 > >> >>>>>>> > >> >>>>>>> Patrick > >> >>>>>>> > >> >>>>>>> On Tue, Mar 31, 2026 at 7:27 AM Yurii Palamarchuk < > >> >>>>>>> [email protected]> wrote: > >> >>>>>>> > >> >>>>>>>> You are right, there are almost no concerns. The entire website > >> >>> is > >> >>>>>>> static, > >> >>>>>>>> only the server providing the assets is running. The only issue > >> >>>>> could be > >> >>>>>>> if > >> >>>>>>>> some node.js package becomes vulnerable, allowing hackers to > >> >> run > >> >>>>> scripts > >> >>>>>>> on > >> >>>>>>>> users' machines, but this scenario is highly unlikely. > >> >>>>>>>> > >> >>>>>>>> Best Regards, > >> >>>>>>>> Yurii > >> >>>>>>>> > >> >>>>>>>> On Tue, Mar 31, 2026 at 4:22 PM Patrick Hunt <[email protected] > >> >>> > >> >>>>> wrote: > >> >>>>>>>> > >> >>>>>>>>> What are the security implications of running React on the ZK > >> >>>>> website? > >> >>>>>>> Is > >> >>>>>>>>> that going to mean additional concerns (eg cve tracking as > >> >>> well as > >> >>>>>>> source > >> >>>>>>>>> security bugs, tracking the "latest react" version and so > >> >>> on...). I > >> >>>>>>>>> believe right now we just have very simple static pages which > >> >>>>> require > >> >>>>>>>> very > >> >>>>>>>>> minimal oversight? > >> >>>>>>>>> > >> >>>>>>>>> Regards, > >> >>>>>>>>> > >> >>>>>>>>> Patrick > >> >>>>>>>>> > >> >>>>>>>>> On Tue, Mar 31, 2026 at 7:17 AM Yurii Palamarchuk < > >> >>>>>>>>> [email protected]> wrote: > >> >>>>>>>>> > >> >>>>>>>>>> Thanks everyone for your reviews! > >> >>>>>>>>>> > >> >>>>>>>>>> The only approach I considered for updating the > >> >> documentation > >> >>>>> version > >> >>>>>>>> is > >> >>>>>>>>> a > >> >>>>>>>>>> manual one. It looks like this: > >> >>>>>>>>>> 1) Checkout to the `website` branch. > >> >>>>>>>>>> 2) Build the latest change for the current version, right > >> >>> before > >> >>>>> the > >> >>>>>>>>>> update. > >> >>>>>>>>>> 3) Move the build to `public/released-docs/` and rename the > >> >>>>> directory > >> >>>>>>>> to > >> >>>>>>>>>> the corresponding version. > >> >>>>>>>>>> 4) Update the `CURRENT_VERSION` constant, so now it matches > >> >>> the > >> >>>>> new > >> >>>>>>>>>> version. > >> >>>>>>>>>> 5) Open a PR. > >> >>>>>>>>>> > >> >>>>>>>>>> The Java API docs are built by maven as far as I can tell, > >> >> so > >> >>>>> it's > >> >>>>>>> not > >> >>>>>>>>>> related to the website actually. > >> >>>>>>>>>> > >> >>>>>>>>>> Regarding the automatization of this process, I've never > >> >> done > >> >>>>>>> anything > >> >>>>>>>>> like > >> >>>>>>>>>> this before. Therefore, if you have any suggestions - I'm > >> >>> open to > >> >>>>>>> it, I > >> >>>>>>>>>> think it should be possible since the workflow is not > >> >>> complex at > >> >>>>> all. > >> >>>>>>>>> Most > >> >>>>>>>>>> likely a small bash script could be enough. > >> >>>>>>>>>> > >> >>>>>>>>>> Best Regards, > >> >>>>>>>>>> Yurii > >> >>>>>>>>>> > >> >>>>>>>>>> On Tue, Mar 31, 2026 at 3:09 AM Andor Molnár < > >> >>> [email protected]> > >> >>>>>>> wrote: > >> >>>>>>>>>> > >> >>>>>>>>>>> Exactly. My 2 cents are: > >> >>>>>>>>>>> > >> >>>>>>>>>>> 1. Storing the entire website at a single location is > >> >>>>> desirable. > >> >>>>>>>> Given > >> >>>>>>>>>> the > >> >>>>>>>>>>> proposed > >> >>>>>>>>>>> technology changes there’s no clear separation possible > >> >>> without > >> >>>>>>>>>> duplicating > >> >>>>>>>>>>> website core logic components which will be a maintenance > >> >>>>> nightmare > >> >>>>>>>> in > >> >>>>>>>>>> the > >> >>>>>>>>>>> long term. > >> >>>>>>>>>>> > >> >>>>>>>>>>> 2. Separate ‘website’ branch or versioned branches. As > >> >>> Patrick > >> >>>>>>>>> mentioned > >> >>>>>>>>>>> the docs are versioned and the ability to accompany doc > >> >>> changes > >> >>>>>>> with > >> >>>>>>>>>>> code changes in the same PR is a big advantage. > >> >>>>>>>>>>> > >> >>>>>>>>>>> Andor > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>>> On Mar 30, 2026, at 19:52, Patrick Hunt < > >> >>> [email protected]> > >> >>>>>>> wrote: > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> One reason I remember the docs/api/etc... are part of > >> >> the > >> >>>>> source > >> >>>>>>> is > >> >>>>>>>>>> that > >> >>>>>>>>>>>> they are versioned along with it. PRs -- doc changes > >> >>> along > >> >>>>> with > >> >>>>>>>> code > >> >>>>>>>>>>>> changes also part of the release process. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> Patrick > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> On Mon, Mar 30, 2026 at 5:39 PM Christopher < > >> >>>>> [email protected] > >> >>>>>>>> > >> >>>>>>>>>> wrote: > >> >>>>>>>>>>>> > >> >>>>>>>>>>>>> I think it looks great, but I would really like to see > >> >>> the > >> >>>>> SCM > >> >>>>>>>>> source > >> >>>>>>>>>>>>> for this new site, so I can understand the > >> >>> maintenance/build > >> >>>>>>>>> workflow > >> >>>>>>>>>>>>> for it, before I'd have any useful opinion other than > >> >>>>> regarding > >> >>>>>>>>>>>>> aesthetics. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> I definitely concur with moving the docs out to the > >> >>> site to > >> >>>>>>>>> centralize > >> >>>>>>>>>>> it. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> On Fri, Mar 27, 2026 at 3:03 PM Yurii Palamarchuk > >> >>>>>>>>>>>>> <[email protected]> wrote: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Thanks for your comment, Patrick. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Why React? > >> >>>>>>>>>>>>>> Building a website nowadays is not just HTML + CSS, > >> >>> because > >> >>>>>>> doing > >> >>>>>>>>> it > >> >>>>>>>>>>> this > >> >>>>>>>>>>>>>> way turns the developer experience into a nightmare. > >> >>> With > >> >>>>> React > >> >>>>>>>> we > >> >>>>>>>>>>>>>> effortlessly have consistent UI components across all > >> >>>>> pages, > >> >>>>>>>>>> including > >> >>>>>>>>>>>>>> buttons, tables, markdown rendering, colors, and much > >> >>>>> more. We > >> >>>>>>>> also > >> >>>>>>>>>> add > >> >>>>>>>>>>>>> the > >> >>>>>>>>>>>>>> interactivity much more easily with React. A static > >> >>> website > >> >>>>>>>> doesn't > >> >>>>>>>>>>> mean > >> >>>>>>>>>>>>> it > >> >>>>>>>>>>>>>> lacks interactivity; it often has significant > >> >>>>> interactivity, > >> >>>>>>>>>> especially > >> >>>>>>>>>>>>> in > >> >>>>>>>>>>>>>> the documentation section. The difference is that we > >> >>> don't > >> >>>>> need > >> >>>>>>>> any > >> >>>>>>>>>>>>> runtime > >> >>>>>>>>>>>>>> environment, we just return the files generated at > >> >>> build > >> >>>>> time, > >> >>>>>>>>> which > >> >>>>>>>>>>> are > >> >>>>>>>>>>>>>> ultimately just HTML, CSS, and JS. The website also > >> >> has > >> >>>>> dark > >> >>>>>>> mode > >> >>>>>>>>>>>>> support, > >> >>>>>>>>>>>>>> search in the documentation, smooth transitions > >> >> between > >> >>>>> pages > >> >>>>>>> (no > >> >>>>>>>>>> hard > >> >>>>>>>>>>>>>> reload), so it gives smooth and better user > >> >> experience > >> >>>>>>> overall. I > >> >>>>>>>>>> hope > >> >>>>>>>>>>>>> this > >> >>>>>>>>>>>>>> answers your question. Moreover, the website will > >> >> work > >> >>>>>>> absolutely > >> >>>>>>>>>> fine > >> >>>>>>>>>>>>> even > >> >>>>>>>>>>>>>> for those who have JS disabled, this is called > >> >>> progressive > >> >>>>>>>>>> enhancement. > >> >>>>>>>>>>>>>> Initially, the server returns HTML and CSS. The > >> >> browser > >> >>>>> renders > >> >>>>>>>>> them > >> >>>>>>>>>>> and > >> >>>>>>>>>>>>>> tries to fetch the JS files. If it doesn't succeed, > >> >> the > >> >>>>> page > >> >>>>>>>>> remains > >> >>>>>>>>>>>>>> accessible, though it obviously lacks interactivity. > >> >> I > >> >>> hope > >> >>>>>>> this > >> >>>>>>>>>>> answers > >> >>>>>>>>>>>>>> your questions, if not, feel free to ask more about > >> >> it! > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Is it hard for ZK devs to update the content? > >> >>>>>>>>>>>>>> Not at all! I tried to make it so the learning curve > >> >>> for > >> >>>>> non-JS > >> >>>>>>>>> devs > >> >>>>>>>>>> is > >> >>>>>>>>>>>>>> almost 0. For the documentation you still just need > >> >> to > >> >>>>> edit the > >> >>>>>>>> MDX > >> >>>>>>>>>>>>>> (Markdown Extended) files and run the build command. > >> >> I > >> >>> will > >> >>>>>>> also > >> >>>>>>>>> add > >> >>>>>>>>>> a > >> >>>>>>>>>>>>> bash > >> >>>>>>>>>>>>>> script to automate the build process. For the landing > >> >>>>> pages, > >> >>>>>>> you > >> >>>>>>>>>> still > >> >>>>>>>>>>>>>> mostly only need to modify the markdown files. Only > >> >> the > >> >>>>> main > >> >>>>>>> page > >> >>>>>>>>>> isn't > >> >>>>>>>>>>>>>> markdown, modifying something small wouldn't be a > >> >>> problem. > >> >>>>> In > >> >>>>>>> the > >> >>>>>>>>>> worst > >> >>>>>>>>>>>>>> case, if something more complex is required, you can > >> >>>>> handle it > >> >>>>>>>> with > >> >>>>>>>>>> the > >> >>>>>>>>>>>>> AI. > >> >>>>>>>>>>>>>> Nevertheless, the website hasn't been updated for > >> >>> years, > >> >>>>> so it > >> >>>>>>>>>> wouldn't > >> >>>>>>>>>>>>> be > >> >>>>>>>>>>>>>> a big loss :) > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Best regards, > >> >>>>>>>>>>>>>> Yurii > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> On Fri, Mar 27, 2026 at 4:19 PM Patrick Hunt < > >> >>>>> [email protected] > >> >>>>>>>> > >> >>>>>>>>>> wrote: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>> On Fri, Mar 27, 2026 at 3:32 AM Yurii Palamarchuk < > >> >>>>>>>>>>>>>>> [email protected]> wrote: > >> >>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>> Hi there, > >> >>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>> I am proposing an upgrade to the ZooKeeper website > >> >>> and > >> >>>>>>>>>>>>> documentation. We > >> >>>>>>>>>>>>>>>> are moving to a modern React.js stack, which allows > >> >>>>> landing > >> >>>>>>>> pages > >> >>>>>>>>>> and > >> >>>>>>>>>>>>>>>> versioned documentation to live in a single > >> >>> application > >> >>>>>>> sharing > >> >>>>>>>>> the > >> >>>>>>>>>>>>> same > >> >>>>>>>>>>>>>>> UI > >> >>>>>>>>>>>>>>>> components, libraries, colors, etc. > >> >>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>> The plan is to move all website and documentation > >> >>> source > >> >>>>> code > >> >>>>>>>> to > >> >>>>>>>>>> the > >> >>>>>>>>>>>>>>>> website branch and remove the zookeeper-docs Maven > >> >>>>> project > >> >>>>>>> from > >> >>>>>>>>> the > >> >>>>>>>>>>>>>>> master > >> >>>>>>>>>>>>>>>> branch. This decouples the Node/JS build > >> >> environment > >> >>>>> from the > >> >>>>>>>>> core > >> >>>>>>>>>>>>> Java > >> >>>>>>>>>>>>>>>> repository. > >> >>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>> Versioned docs will be managed via archived folders > >> >>>>> within > >> >>>>>>> the > >> >>>>>>>>>>>>> website > >> >>>>>>>>>>>>>>>> branch. Documentation updates would move from > >> >> master > >> >>> to > >> >>>>> PRs > >> >>>>>>>>> against > >> >>>>>>>>>>>>> the > >> >>>>>>>>>>>>>>>> website branch. Also I'm not planning to keep the > >> >>> app as > >> >>>>> a > >> >>>>>>>> maven > >> >>>>>>>>>>>>> project, > >> >>>>>>>>>>>>>>>> since it's fully JS based. To keep it simple, I > >> >> will > >> >>>>> write a > >> >>>>>>>> bash > >> >>>>>>>>>>>>> script > >> >>>>>>>>>>>>>>>> that installs the dependencies, runs the tests, and > >> >>> the > >> >>>>>>> build. > >> >>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>> What do you think about moving the docs out of > >> >>> master to > >> >>>>>>>>> centralize > >> >>>>>>>>>>>>> the > >> >>>>>>>>>>>>>>>> site? > >> >>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>> Preview: https://zookeeper-website.vercel.app/ > >> >>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>> Looks pretty slick - nice update and visual refresh! > >> >>>>> Question > >> >>>>>>>>>> though - > >> >>>>>>>>>>>>> why > >> >>>>>>>>>>>>>>> React? This is a static website, what are the > >> >> pro/con > >> >>> of > >> >>>>> React > >> >>>>>>>>>> based? > >> >>>>>>>>>>>>> Can > >> >>>>>>>>>>>>>>> you explain the impact on common use cases like > >> >> making > >> >>>>>>> updates? > >> >>>>>>>> ZK > >> >>>>>>>>>>> team > >> >>>>>>>>>>>>>>> includes a number of people, not all of whom might > >> >>> know > >> >>>>> React, > >> >>>>>>>> how > >> >>>>>>>>>>> hard > >> >>>>>>>>>>>>>>> will it be for them to make changes? Impact on the > >> >>> release > >> >>>>>>>>> process? > >> >>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>> Regards, > >> >>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>> Patrick > >> >>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>> Best regards, > >> >>>>>>>>>>>>>>>> Yurii Palamarchuk > >> >>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>> > >> >>>>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>> > >> >>>>>>> > >> >>>>> > >> >>> > >> >> > >> > >> >
