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 > > > > > > > > >
