Hi Folks, Created a label "1.0-blocker". Please use it to tag issues/PRs if you think they are blockers of 1.0 release.
Yufei On Mon, Feb 17, 2025 at 10:18 AM Michael Collado <collado.m...@gmail.com> wrote: > Yeah, we should remove the “bug” label from anything that’s not a bug. > Improving code quality and improving code and api abstractions are good > goals, but they’re not bug fixes. > > Mike > > On Mon, Feb 17, 2025 at 8:12 AM Eric Maynard <eric.w.mayn...@gmail.com> > wrote: > > > 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 > > > > > > > > > > > > > >
