It does seem to introduce quite a bit of manual overhead. I’m personally
not a big fan of that, but I’m open to trying it out. That said, I believe
the release manager should have the ability to organize the changelog at
release time, since it’s quite difficult to maintain consistency from the
pers
My take on some of these issues:
* #777 (persistence concurrency) can be closed.
* #552 (odd locations) is not a 1.0 blocker (but needs to be addressed)
Additionally, I think https://github.com/apache/polaris/pull/1532 also
needs to be addressed for 1.0 at least in most aspects. In order to
enabl
Hi Yufei
Thanks for your message !
It looks good to me.
As prerequisite (obviously), we should also complete
0.10.0-beta-incubating release to be sure we are good there before
1.0.0.
Just a comment: I think we should limit the number of community
meetings. This topic should be typically discuss
Hi Dimitri
It's a good idea.
I think each committer should be responsible to update the CHANGELOG
if appropriate, and reviewer should point it out if needed.
It's the same as documentation, license update and header (when code
is copied from another project), etc.
Regards
JB
On Thu, May 15, 20
Hi folks,
Many users have been asking about the Polaris release, and I believe it's
critical to have a formal, production-ready 1.0 release ASAP. Thanks to the
community’s hard work, we’re very close with a few remaining blockers we
need to resolve.
To keep things moving, I scheduled a community
As commented in GH, I'm fine with closing
https://github.com/apache/polaris/issues/777 now.
Cheers,
Dmitri.
On Thu, May 15, 2025 at 4:13 PM Prashant Singh
wrote:
> Apologies for not getting back at this earlier. I somehow missed this email
> thread.
> To conclude the discussion we ended up doi
Who should own that consistency? Should the release manager normalize
entries at cut time, or should each PR author follow a template up front?
I'd think it's the reviewers' (committers') duty to ensure consistency.
PR authors are encouraged to add entries to CHANGELOG as needed,
but reviewers s
Apologies for not getting back at this earlier. I somehow missed this email
thread.
To conclude the discussion we ended up doing the following :
[1] The service tests run with JDBC / in-memory persistence
[2] Admin tests (JDBC / EclipseLink persistence)
Again thanks a ton everyone ! for your feedb
These seem like good ideas to me. I'd prefer things with minimal human
interactions in the loop but
having dev emails for changing intra-release breaking commits sounds good
to me.
On Thu, May 15, 2025 at 2:30 PM Yufei Gu wrote:
> Thanks for kicking this off, Dmitri—great idea!
>
> Looking at t
Hi all,
I would like to suggest removing the "realm_id" metric tag entirely.
My concern is that this tag has the potential for high cardinality, which
is generally considered a bad practice when dealing with metrics. High
cardinality can lead to performance issues and increased memory usage.
Gra
Thanks for kicking this off, Dmitri—great idea!
Looking at the current CHANGELOG, the entries range from PR-number
references to detailed feature write-ups and even small tweaks like “make
test less flaky.” To keep it useful, we probably need a consistent format.
Who should own that consistency?
Hi All,
As discussed in the community sync today, Polaris evolves quickly and
breaking changes are a reality we have to live with :)
However, I'd like to propose improving user and developer experience by
keeping a change log with a section for breaking changes.
We follow this practice in Nessie
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH
Hi Yufei
Thanks for the PR (I left one comment in there).
About naming, I think we should use polaris-{version}-bin for clarity.
I will work on LICENSE, NOTICE, DISCLAIMER for this distribution as it
has to be "merged".
Regards
JB
On Wed, May 14, 2025 at 8:32 PM Yufei Gu wrote:
>
> Hi Folk,
>
14 matches
Mail list logo
