There are still many issues labelled as "bug" that are not bugs but feature requests or requests for some refactoring, e.g. (1 <https://github.com/apache/polaris/issues/564>, 2 <https://github.com/apache/polaris/issues/779>, 3 <https://github.com/apache/polaris/issues/759>). I do not think that we should necessarily always be prioritizing these over material features.
Moreover, there is of course not a single "focus" that we as a community must have. Some people may contribute features, while others work on bug fixes. The question is, on a case-by-case basis, which "Issues" must block a release. We can perhaps leverage tags to track this. On Mon, Feb 17, 2025 at 9:47 AM Yufei Gu <flyrain...@gmail.com> wrote: > 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 > > > > >
