The label "bug" is good enough for any bugs. I was also thinking of other non-bug requirements, for example, the persistence refactor. Yufei
On Mon, Feb 17, 2025 at 8:38 AM Robert Stupp <sn...@snazy.de> wrote: > > On 12.02.25 21:03, Yufei Gu wrote: > > Thanks, Robert, for chiming in. Production readiness is indeed a crucial > > point, and I'm open to any proposals that can help us achieve it. I also > > believe this is the right time to identify any blockers. To help with > > tracking, I'd suggest we add a dedicated label so we can tag related > issues > > and PRs. > > As implicitly mentioned, I think it would be good if we all tackle the > issues labeled as "bug". > > > > Automated releasing sounds really exciting—do we have any timeline in > mind > > for when we might see that implemented? > > > > > > Yufei > > > > > > On Wed, Feb 12, 2025 at 10:20 AM Robert Stupp <sn...@snazy.de> wrote: > > > >> Related to the “production readiness”, we all agreed a while ago on > >> focusing on bugs, stability and everything around that. > >> I propose to really focus on those things instead of new functionality, > >> because features require a "rock solid” foundation. Once we have that, > we > >> can resume work on new features. It doesn’t mean to stop on higher-level > >> proposals though. > >> > >> > >>> On 12. Feb 2025, at 08:09, Robert Stupp <sn...@snazy.de> wrote: > >>> > >>> Just want to note that there are still a lot of things to do before. > >>> > >>> WRT “production readiness”, as JB said, we need consensus on some > things > >> _quickly_. The details can only be sorted out _with_ a consensus. April > is > >> therefore too tight IMHO - I’d really prefer the date: “it’s ready, when > >> it’s ready”. Instead of committing to a release deadline, I’d really > prefer > >> a strong commitment to security, stability and ease of use and release > when > >> it’s really ready and _everybody_ is happy with the state. > >>> I also advocate to focus on the important things, not have any open > >> serious bugs or even security issues. > >>> Also noteworthy is the upcoming ASF requirement to have automated > >> reproducible builds/releases. I’ve already started the work for that - > and > >> IMHO we should prefer automated releases over anything manual. > >>>> On 11. Feb 2025, at 06:58, Jean-Baptiste Onofré <j...@nanthrax.net> > >> wrote: > >>>> Hi Yufei > >>>> > >>>> Thanks for volunteering for the 1.0 release ! I've started to review > >>>> the legal aspect for this release as it will include binary > >>>> distributions. > >>>> The milestone scope looks good to me and makes sense. > >>>> > >>>> My only comment is about the dates. I think it's a bit early to > >>>> strongly commit to specific dates. Regarding 1.0, April 2025 is > >>>> do-able I think, assuming we are able to have consensus "quickly" on > >>>> some proposals (I'm thinking about persistence layer improvements for > >>>> instance). > >>>> As these proposals are discussed within the community, sometimes it > >>>> takes time to discuss all the points and find a consensys. > >>>> > >>>> So, if we say, "as best effort, we target 1.0 on April 25", that's > >>>> totally fine to me. But I'm not very comfortable with "1.0 will be > >>>> available on April 25". > >>>> > >>>> Just my $0.01 :) > >>>> > >>>> Regards > >>>> JB > >>>> > >>>> > >>>> On Mon, Feb 10, 2025 at 5:01 PM Yufei Gu <flyrain...@gmail.com> > wrote: > >>>>> Hi folks, > >>>>> > >>>>> Great news—Apache Polaris 0.9 is nearly ready! Huge thanks to JB, > Ryan, > >>>>> Russell, Robert, Tyler and everyone who contributed. Your efforts > made > >> this > >>>>> first release possible. > >>>>> > >>>>> With each release, we hit a major milestone, and now it’s time to > >>>>> focus on *Apache > >>>>> Polaris 1.0*. Based on our recent community discussions (issue 584 > >>>>> <https://github.com/apache/polaris/issues/584>), we’re shaping 1.0 > to > >> be > >>>>> the *first production-ready release*. You can check out the milestone > >>>>> details here <https://github.com/apache/polaris/milestone/2>. > >>>>> > >>>>> 1.0 will include all the key features you rely on—*credential vending > >> (S3, > >>>>> ADLS, GCS), RBAC, and more*—plus new capabilities like *S3-compatible > >>>>> storage support, policy management, and persistence layer > >> improvements*. > >>>>> We’re excited to make Polaris even more powerful for the community. > >>>>> > >>>>> I’d also like to *volunteer as the release manager* for 1.0 and look > >>>>> forward to working with you all to ensure a smooth launch. > >>>>> > >>>>> Thanks again for your support and contributions! > >>>>> > >>>>> > >>>>> Yufei > >> > -- > Robert Stupp > @snazy > >
