| Time |
Nick |
Message |
| 01:50 |
|
sleary joined #evergreen |
| 06:00 |
|
redavis joined #evergreen |
| 08:02 |
|
BDorsey joined #evergreen |
| 08:06 |
|
kworstell-isl joined #evergreen |
| 08:07 |
|
redavis_reboot joined #evergreen |
| 08:13 |
|
cbrown-isl joined #evergreen |
| 08:32 |
|
mmorgan joined #evergreen |
| 08:37 |
|
mantis1 joined #evergreen |
| 08:40 |
|
collum joined #evergreen |
| 09:03 |
|
cbrown-isl joined #evergreen |
| 09:05 |
|
dguarrac joined #evergreen |
| 09:19 |
|
sandbergja joined #evergreen |
| 09:20 |
|
Dyrcona joined #evergreen |
| 09:26 |
Dyrcona |
heh. "action_tigger.event_output" :) |
| 09:36 |
|
rlefaive joined #evergreen |
| 09:51 |
|
kworstell-isl joined #evergreen |
| 10:01 |
Dyrcona |
I'm looking for the MessageBee export code if anyone has it in a repo somewhere. |
| 10:02 |
|
sleary joined #evergreen |
| 10:06 |
berick |
Dyrcona: the code I originally posted is here: https://github.com/berick/evergreen-xml-notices |
| 10:07 |
berick |
our local copy has evolved some, but not too much. i still need to copy the updated code into our public repo. |
| 10:07 |
Dyrcona |
berick++ I was just looking at that and thought it might have something to do with. |
| 10:25 |
|
jeff joined #evergreen |
| 10:38 |
|
sandbergja joined #evergreen |
| 10:58 |
|
cbrown-isl joined #evergreen |
| 11:31 |
|
Christineb joined #evergreen |
| 11:38 |
|
cbrown-isl joined #evergreen |
| 12:02 |
|
jihpringle joined #evergreen |
| 12:17 |
|
cbrown-isl joined #evergreen |
| 13:09 |
|
cbrown-isl joined #evergreen |
| 14:01 |
|
kworstell_isl joined #evergreen |
| 14:09 |
|
cbrown-isl joined #evergreen |
| 14:35 |
|
kmlussier joined #evergreen |
| 14:42 |
|
redavis joined #evergreen |
| 14:54 |
|
jvwoolf joined #evergreen |
| 14:55 |
|
shulabear joined #evergreen |
| 14:59 |
Bmagic |
dev meeting incoming |
| 15:00 |
Bmagic |
#startmeeting 2024-05-14 - Developer Meeting |
| 15:00 |
pinesol |
Meeting started Tue May 14 15:00:02 2024 US/Eastern. The chair is Bmagic. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:00 |
pinesol |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:00 |
pinesol |
The meeting name has been set to '2024_05_14___developer_meeting' |
| 15:00 |
Bmagic |
#info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2024-05-14 |
| 15:00 |
|
sandbergja joined #evergreen |
| 15:00 |
Bmagic |
#topic Introductions |
| 15:00 |
Bmagic |
#info Bmagic = Blake GH, MOBIUS |
| 15:00 |
Dyrcona |
#info Dyrcona = Jason Stephenson, CW MARS |
| 15:00 |
kmlussier |
#info kmlussier = Kathy Lussier, NOBLE |
| 15:00 |
sandbergja |
#info sandbergja = Jane Sandberg, PUL |
| 15:00 |
dluch |
#info dluch = Debbie Luchenbill, MOBIUS |
| 15:00 |
mmorgan |
#info mmorgan = Michele Morgan, NOBLE |
| 15:00 |
jeffdavis |
#info jeffdavis = Jeff Davis, BC Libraries Cooperative (Sitka) |
| 15:01 |
jvwoolf |
#info jvwoolf= Jessica Woolford, Bibliomation |
| 15:01 |
shulabear |
#info shulabear = Shula Link, GCHRL |
| 15:01 |
mantis1 |
# info mantis = Gina Monti, Bibliomation |
| 15:02 |
scottangel |
#info scottangel = Scott Angel, MOBIUS |
| 15:02 |
berick |
#info berick Bill Erickson, KCLS |
| 15:03 |
Stompro |
#info Stompro = Josh Stompro, Lake Agassiz Regional Library (LARL) |
| 15:03 |
Bmagic |
feel free to add yourself as you arrive |
| 15:03 |
Bmagic |
#topic Action Items from Last Meeting |
| 15:03 |
|
collum joined #evergreen |
| 15:03 |
Bmagic |
#info gmcharlt - create a Git commit message type and update bug 2051946 |
| 15:03 |
pinesol |
Launchpad bug 2051946 in Evergreen "institute a Git commit message template" [Wishlist,New] https://launchpad.net/bugs/2051946 - Assigned to Galen Charlton (gmc) |
| 15:04 |
Bmagic |
gmcharlt_ may not be here atm |
| 15:04 |
Bmagic |
carry forward |
| 15:04 |
Bmagic |
#action gmcharlt - create a Git commit message type and update bug 2051946 |
| 15:04 |
Bmagic |
#info mmorgan will explore moving LP stats to community site and automating same |
| 15:04 |
collum |
#info collum = Garry Collum, KCPL |
| 15:04 |
mmorgan |
Nothing new this month, please carry forward. |
| 15:05 |
Bmagic |
#action mmorgan will explore moving LP stats to community site and automating same |
| 15:05 |
Bmagic |
#info Bmagic will write announcement+blog post for deprecation of open-ils.circ.title_hold.is_possible and open-ils.circ.holds.create[.override] |
| 15:05 |
Bmagic |
This was done, albeit, revised by the community and re-blog-posted |
| 15:05 |
Bmagic |
I think we can mark it off :) |
| 15:06 |
Bmagic |
#info JBoyer will throw a branch on lp 1017990 to loudly inform the logs something is still calling that ^ |
| 15:06 |
pinesol |
Launchpad bug 1017990 in Evergreen "Possible to bypass holds placement limits via direct API calls" [Medium,Confirmed] https://launchpad.net/bugs/1017990 |
| 15:06 |
Bmagic |
hmmm, I feel blind sided by this one. It's not merged for 3.13 (yet) |
| 15:07 |
Bmagic |
JBoyer++ |
| 15:07 |
Bmagic |
csharp++ |
| 15:07 |
Bmagic |
Stompro++ |
| 15:08 |
redavis |
#info redavis = Ruth Davis, ECDI |
| 15:09 |
Bmagic |
gmcharlt++ jeffdavis++ berick++ kmlussier++ phasefx++ # shoulda taken stake of the full list before I started karma-ing |
| 15:10 |
Dyrcona |
Uh huh. So is someone going to review it and commit it? Maybe after beta is official? |
| 15:11 |
Bmagic |
Haven't seen Thomas Berezansky's nick in a long time, not sure what it is |
| 15:11 |
kmlussier |
tsbere++ |
| 15:11 |
Bmagic |
Dyrcona: I think it needs to be merged for 3.13 |
| 15:11 |
kmlussier |
Honestly, I feel like the staute of limitations has run out for some of to receive karma for that bug. |
| 15:12 |
Dyrcona |
:) |
| 15:12 |
Bmagic |
:) |
| 15:12 |
kmlussier |
So somebody needs to take that as an action item? |
| 15:12 |
Bmagic |
good idea |
| 15:12 |
Bmagic |
anyone want to? |
| 15:13 |
Dyrcona |
I'll take it if no one else wants to. |
| 15:13 |
Bmagic |
sold |
| 15:13 |
mmorgan |
Dyrcona++ |
| 15:13 |
sandbergja |
Dyrcona++ |
| 15:13 |
kmlussier |
Dyrcona++ |
| 15:13 |
Bmagic |
#action Dyrcona will take a look at bug 1017990 for merging into main and 3.13 |
| 15:13 |
pinesol |
Launchpad bug 1017990 in Evergreen "Possible to bypass holds placement limits via direct API calls" [Medium,Confirmed] https://launchpad.net/bugs/1017990 |
| 15:13 |
shulabear |
Dyrcona++ |
| 15:14 |
Bmagic |
thank you Dyrcona! |
| 15:14 |
Bmagic |
I suppose that wraps that one for now |
| 15:14 |
Bmagic |
#info eeevil will open a bug for cross-column stats targets |
| 15:15 |
Bmagic |
not here, anyone else have a bead on that? |
| 15:15 |
eeevil |
ah! here now |
| 15:15 |
Bmagic |
!! |
| 15:16 |
eeevil |
I will do that soon (for some definition of "soon") |
| 15:16 |
Bmagic |
carrying it then |
| 15:16 |
eeevil |
+1 |
| 15:16 |
Bmagic |
#action eeevil will open a bug for cross-column stats targets |
| 15:16 |
Bmagic |
eeevil++ |
| 15:17 |
Bmagic |
skipping down the agenda unless anyone wants to ad hoc plug into OpenSRF/Evergreen/Hatch/Documentation (yes, I refreshed the page, nothing added as of 3 seconds ago) |
| 15:18 |
Bmagic |
It's probably worth mentioning: |
| 15:19 |
Bmagic |
#topic Evergreen 3.13 beta release tarball is available |
| 15:19 |
redavis |
!!! |
| 15:19 |
Bmagic |
#link https://evergreen-ils.org/downloads/Evergreen-ILS-3.13-beta.tar.gz |
| 15:19 |
sandbergja |
nice! woohoo! |
| 15:20 |
Bmagic |
If anyone has some time, testing that would be sweet |
| 15:20 |
mmorgan |
Bmagic++ berick++ shulabear++ sleary++ abneiman++ |
| 15:20 |
dluch |
releaseteam++ |
| 15:20 |
redavis |
Bmagic++ berick++ shulabear++ sleary++ abneiman++ |
| 15:21 |
kmlussier |
Bmagic++ berick++ shulabear++ sleary++ abneiman++ |
| 15:21 |
dluch |
Bmagic++ berick++ shulabear++ sleary++ abneiman++ |
| 15:21 |
Dyrcona |
I'll have a look at it. |
| 15:21 |
shulabear |
bmagic++ sleary++ berick++ abneiman++ |
| 15:21 |
jvwoolf |
Bmagic++ berick++ shulabear++ sleary++ abneiman++ |
| 15:21 |
Bmagic |
berick++ shulabear++ sleary++ abneiman++ |
| 15:21 |
Bmagic |
karma party! |
| 15:22 |
Dyrcona |
Bmagic++ berick++ shulabear++ sleary++ abneiman++ |
| 15:22 |
Bmagic |
next up |
| 15:22 |
Bmagic |
#topic Launchpad Status (as of noon Eastern) |
| 15:22 |
Bmagic |
incoming paste |
| 15:22 |
Bmagic |
#info Open Bugs - 3087 |
| 15:22 |
Bmagic |
#info Pullrequests - 88 |
| 15:22 |
Bmagic |
#info Signedoff - 8 |
| 15:23 |
Bmagic |
#topic Launchpad Status since last meeting |
| 15:23 |
Bmagic |
#info Bugs Added - 47 |
| 15:23 |
Bmagic |
#info Pullrequest tag Added - 30 |
| 15:23 |
Bmagic |
#info Signedoff tag Added - 22 |
| 15:23 |
Bmagic |
#info Fix Committed - 36 |
| 15:23 |
Bmagic |
#topic New Business - LP#2042158 - should we recommend disabling Postgres JIT? |
| 15:23 |
Bmagic |
#link https://bugs.launchpad.net/evergreen/+bug/2042158 |
| 15:23 |
pinesol |
Launchpad bug 2042158 in Evergreen "Postgres 12+ needs to have JIT disabled" [Undecided,Confirmed] - Assigned to Galen Charlton (gmc) |
| 15:24 |
jeffdavis |
I think the consensus at the last meeting was that we should recommend disabling it for now. Not sure if there is more to discuss? |
| 15:25 |
Bmagic |
I remember some good nuggets from eeevil on this one. The jist was "we wrote Evergreen to basically do jit before jit existed, and now that PG has this feature, it's jit on top of jit, which is anti-jit (slow)" |
| 15:25 |
csharp_ |
so the effect of JIT is slow queries? |
| 15:25 |
Bmagic |
The one place that caused me pain was saving a MARC record, timed out! |
| 15:25 |
csharp_ |
ah - just read the eeevil quote |
| 15:25 |
eeevil |
heh ... csharp_, no, not necessarily |
| 15:26 |
eeevil |
(that isn't a direct quote, fwiw :P) |
| 15:26 |
Dyrcona |
Bmagic: Saving MARC records can be slow regardless of JIT. |
| 15:26 |
redavis |
lol |
| 15:26 |
Bmagic |
right, I was paraphrasing |
| 15:26 |
csharp_ |
(we're still on PG 11 fwiw) |
| 15:26 |
csharp_ |
"twasn't me" --eeevil |
| 15:26 |
eeevil |
JIT introduces the possibility of plan instability, depending on ... details |
| 15:27 |
Bmagic |
the branch for that bug updates a single documentation file, fyi |
| 15:28 |
Dyrcona |
Well, push it, then. :) |
| 15:28 |
redavis |
not as a derail question, but out of curiosity, would it be a worthwhile endeavor to eventually unravel the "jit"ing behavior from EG and leverage JIT in Postgres? |
| 15:28 |
csharp_ |
push it real good |
| 15:29 |
Bmagic |
ok, lol, I typed some stuff, then waited, then backspaced, the waited |
| 15:29 |
csharp_ |
redavis: maybe worth experiments for someone with the tuits |
| 15:29 |
eeevil |
redavis: yes, but JIT is a level 10 spell and I would council that we should figure out the level 3 spells of better stats generation first |
| 15:29 |
csharp_ |
(and the knowledge) |
| 15:30 |
Bmagic |
redavis: yes! I think the general idea is that "we" could see about what sort of speeds we could get using it |
| 15:30 |
Bmagic |
eeevil++ # level 10 spell, lol |
| 15:30 |
eeevil |
but if anyone wants to deep dive on JIT, please! |
| 15:30 |
redavis |
That was my thinkin's. Cool. Thanks for the spell wisdom. Makes sense. |
| 15:30 |
Bmagic |
ok, that's another branch to merge..... |
| 15:30 |
Bmagic |
someone else should probably do it |
| 15:30 |
Dyrcona |
FWIW, I don't disable JIT on my test db with Pg12+. |
| 15:31 |
csharp_ |
I would have to watch a tutorial - my scant reading doesn't have me grokking it yet |
| 15:31 |
Bmagic |
(since I authored it) - anyone want to take the action item? |
| 15:31 |
csharp_ |
could be one of those things that tests fine but causes havoc at scale |
| 15:31 |
Bmagic |
or I guess I should back up and ask if it needs* to make it in before 3.13 is official |
| 15:32 |
csharp_ |
I think since PG11 is dead, we should push it asap |
| 15:32 |
Dyrcona |
csharp_: Depends on a number of factors from what I understand. |
| 15:32 |
Bmagic |
IMO it's worth pointing it out in our documentation for folks to "remember" it's there |
| 15:32 |
eeevil |
Bmagic: I'll doublecheck the branch and merge if there's nothing sticking out to me |
| 15:32 |
csharp_ |
eeevil++ |
| 15:32 |
Bmagic |
eeevil++ |
| 15:32 |
redavis |
eeevil++ |
| 15:32 |
kmlussier |
eeevil++ |
| 15:33 |
Dyrcona |
eeevil++ |
| 15:33 |
Bmagic |
#action eeevil will see about merging bug 2042158 |
| 15:33 |
pinesol |
Launchpad bug 2042158 in Evergreen "Postgres 12+ needs to have JIT disabled" [Undecided,Confirmed] https://launchpad.net/bugs/2042158 - Assigned to Galen Charlton (gmc) |
| 15:33 |
* eeevil |
engages karma generator, apparently |
| 15:33 |
redavis |
yeah boi |
| 15:33 |
Bmagic |
lol |
| 15:33 |
Dyrcona |
Meetings are for karma. |
| 15:33 |
csharp_ |
actual_evil-- |
| 15:33 |
shulabear |
eevil++ |
| 15:33 |
Bmagic |
the next thing is a multi-part thing |
| 15:33 |
shulabear |
eeevil++ |
| 15:34 |
Bmagic |
#topic New Business - commit formatting and "infrastructure" commits (see discussion in LP#2039609) |
| 15:34 |
Bmagic |
#link https://bugs.launchpad.net/evergreen/+bug/2039609 |
| 15:34 |
pinesol |
Launchpad bug 2039609 in Evergreen "wishlist: Acquisitions Sprint A - Z39.50 and other fixes" [Wishlist,Fix committed] |
| 15:34 |
Bmagic |
#info Should LP bug references be required in commit messages? |
| 15:34 |
Bmagic |
I'll stop here for discussion |
| 15:34 |
Dyrcona |
Yes. |
| 15:35 |
kmlussier |
@quote add <Dyrcona> Meetings are for karma |
| 15:35 |
pinesol |
kmlussier: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
| 15:35 |
Bmagic |
I also think: yes |
| 15:35 |
redavis |
Yes - if LP is forever(ish) |
| 15:35 |
kmlussier |
+1 from me. |
| 15:35 |
dluch |
+1 |
| 15:35 |
mmorgan |
+1 |
| 15:35 |
eeevil |
I mean, sure. but that only matters at the final merge/pick |
| 15:35 |
csharp_ |
@quote add <Dyrcona> Meetings are for karma |
| 15:35 |
pinesol |
csharp_: The operation succeeded. Quote #244 added. |
| 15:35 |
kmlussier |
csharp_++ |
| 15:36 |
kmlussier |
I often use the LP numbers in the commit to refer back to whatever discussion may have happened around the commit. |
| 15:36 |
Bmagic |
dont we have a wiki page with this mentioned? |
| 15:36 |
berick |
huh, thought we agreed on that like 12 years ago |
| 15:36 |
csharp_ |
there's lots o' text on that bug - can someone summarize the context? |
| 15:36 |
Dyrcona |
Following up on what eeevil said, don't be afraid to tell the author to fix their commits. |
| 15:36 |
kmlussier |
Bmagic: I added a link to that wiki page in the agenda. |
| 15:37 |
kmlussier |
#link https://wiki.evergreen-ils.org/doku.php?id=dev:git#commit_messages |
| 15:37 |
Bmagic |
kmlussier: lol, we're not to that part yet, which is why I didn't see it |
| 15:37 |
Bmagic |
lol |
| 15:37 |
Bmagic |
kmlussier++ |
| 15:37 |
jeffdavis |
I think in the context of the bug, there were some changes to shared components, and the question was whether to tag those changes with the LP bug of the feature that the changes were made for, given that the effects of the changes are broader than that. |
| 15:38 |
csharp_ |
jeffdavis: thank you |
| 15:38 |
Bmagic |
right! jeffdavis++ |
| 15:38 |
jeffdavis |
Mike didn't want to bury shared component changes in a big commit focused on other stuff, but the result was that folks weren't sure which commits they were supposed to look at. |
| 15:38 |
eeevil |
I'm not convinced that every commit needs an LP prefix, tbh ... some commits happen because of, but not for, an LP bug ... but ... well, what jeffdavis just said |
| 15:39 |
csharp_ |
I hates omnibus bugs because tracking that kind of thing can be very time consuming |
| 15:39 |
Bmagic |
I like the commits to mention the bug in the title line, so I know how far back to cherry pick :) |
| 15:39 |
eeevil |
csharp_: the flip side, of course, is that 50 tiny bugs never get synchronized and committed |
| 15:39 |
redavis |
An omnibus bus is better than no bug though. And in the case of some new features, they grew out of some bugs but have way more. |
| 15:39 |
mmorgan |
When reviewing branches, it has sometimes been confusing if the number of commits isn't specified, and there are no lp numbers in the commits. |
| 15:40 |
csharp_ |
1 bug <--> 1 issue is the kind of granularity I try for |
| 15:40 |
mmorgan |
Commits can get missed. |
| 15:40 |
csharp_ |
but I'm not developing big ol' UIs and things |
| 15:40 |
kmlussier |
But if the commit with the shared component is added to a specific launchpad bug, and then somebody has feedback on that shared component as part of testing, won't that discussion be on that specific LP bug even if it's for a distinct feature? |
| 15:40 |
csharp_ |
mmorgan: I agree |
| 15:41 |
kmlussier |
csharp_: So are you saying those shared components should get their own distinct bug? |
| 15:41 |
redavis |
(s/omnibus bus (that's funny)/omnibus bug) |
| 15:41 |
Bmagic |
omnibug bus |
| 15:41 |
kmlussier |
redavis: lol. I hadn't even noticed! |
| 15:41 |
csharp_ |
kmlussier: I'm not sure... |
| 15:42 |
sandbergja |
I think distinct bugs for shared components can be helpful |
| 15:42 |
csharp_ |
I think mmorgan expressed my problem with omnibugs |
| 15:42 |
Dyrcona |
I don't mind the number of commits so long as there's nothing extra in the branch. |
| 15:42 |
Bmagic |
if the commit was needed for a bug you're working on, but does something to shared components, I still think it needs some* LP number on the title line. And if your bug is the only one that exists, tag it! |
| 15:42 |
redavis |
It seems like there is a need for flexibility. Of course some things are harder to track than others. But a good faith attempt to corral the infos is worthwhile. |
| 15:42 |
|
smayo joined #evergreen |
| 15:42 |
eeevil |
to be clear, I'm not saying I refuse to add LP prefixes. the example has context, which jeffdavis pointed out -- "here's some prereq stuff. it changes shared components and should be considered outside the feature targeted by LPxyz" |
| 15:43 |
Dyrcona |
I think if the change is made because of a LP bug, then it should get tagged with that LP bug number. |
| 15:43 |
redavis |
Dyrcona++ |
| 15:43 |
mmorgan |
Agree |
| 15:43 |
eeevil |
I didn't want to anyone (including myself, selfishly) to have to engage in extra intermediate work /at that moment/ to review things |
| 15:44 |
Bmagic |
I'm not sure, but this doesn't seem like a vote |
| 15:44 |
redavis |
lol |
| 15:44 |
Dyrcona |
Well, it's not hard to review things honestly. Just checkout the branch and rebase it on main if its not up to date. |
| 15:44 |
csharp_ |
there's not a consensus for anything |
| 15:45 |
mmorgan |
Extra intermediate work may save work further down the line... |
| 15:45 |
csharp_ |
yeah, and hints in the bug comments usually say "the top 10 commits on <branch>" |
| 15:45 |
eeevil |
if all commits on a branch attached to an LP must have that LP prefix before being pushed to working, I'm fine with that rule. but that's not ... what I though the rule was, and wanted to avoid extra work that would 1) delay testing 2) make everyone that wanted to look at it move to another branch |
| 15:45 |
redavis |
Does it need to be a vote? since it's already in the guidelines? |
| 15:45 |
berick |
i don't think we're talking about working bracnches eeevil |
| 15:45 |
berick |
just the final product |
| 15:45 |
csharp_ |
can we just keep it as a guideline and just strongly recommend or something? |
| 15:46 |
Dyrcona |
I think we're talking a bit about both. Some find it difficult to review a working branch if the commits are not tagged. |
| 15:46 |
csharp_ |
obvs this isn't my issue, so I'm hoping that's not a bad suggestion |
| 15:46 |
eeevil |
berick: ok, that was my understanding too ... and that was a working branch. as in, pushed to the working/Evergreen repo |
| 15:47 |
kmlussier |
If you don't have the LP bug numbers in the working branch, then you're expecting the core committer to udpate the commit message before merging it? |
| 15:47 |
jeffdavis |
I don't think working branches need to be in a final state with proper LP tagging and everything... |
| 15:47 |
csharp_ |
I will say that the untagged commit messages in the code can get confusing when trying to retrace history |
| 15:47 |
jeffdavis |
...but maybe that should be the expectation at review/pullrequest time? |
| 15:47 |
Dyrcona |
I think they should be before the pullrequest tag is added, or I might tell you to fix it. :) |
| 15:47 |
berick |
OK, so it should have them by the time the pullrequest tag is added. |
| 15:47 |
csharp_ |
"the code" == "main" |
| 15:48 |
berick |
jinx |
| 15:48 |
kmlussier |
OK, got it. That makes sense to me. |
| 15:48 |
Bmagic |
yes, I like the pullrequest rule |
| 15:48 |
csharp_ |
also, use squash/fixup where possible |
| 15:48 |
mmorgan |
+1 to the pullrequest rule |
| 15:48 |
csharp_ |
nobody needs to see your process :-) |
| 15:48 |
Bmagic |
Anyone want to clairify this in our guideline wiki page? |
| 15:48 |
kmlussier |
I can do that. |
| 15:48 |
mmorgan |
Also, as csharp_ said, "the top 10 commits on <branch>" type comments are helpful |
| 15:48 |
redavis |
kmlussier++ |
| 15:49 |
dluch |
kmlussier++ |
| 15:49 |
mmorgan |
kmlussier++ |
| 15:49 |
Dyrcona |
kmlussier++ |
| 15:49 |
Bmagic |
#action kmlussier will update wiki (commit message standards) to include details about shared components/pullrequest rule for LP tagging on multi-commits |
| 15:50 |
kmlussier |
As far as missing commits for those big omnibus branches, Dyrcona, didn't you have a special command to pick the whole branch? quickpick? |
| 15:50 |
shulabear |
fwiw, the newdevs:git wiki suggests a good practice is prefacing your working branch with the related launchpad bug |
| 15:50 |
shulabear |
https://wiki.evergreen-ils.org/doku.php?id=newdevs:git:create |
| 15:50 |
eeevil |
(and, yeah, I do think the committer can amend the commits as appropriate -- or ask the author for a cleanup "final" branch) |
| 15:50 |
Dyrcona |
kmlussier: I do, but I don't use it any more. I do this `git cherry-pick ^HEAD working/user/whoever/branch` |
| 15:51 |
Dyrcona |
Or, I check out the branch and rebase on master. That's why I don't like extraneous commits, i.e. not related to what's being tested. |
| 15:51 |
csharp_ |
I've been doing 'git cherry-pick commit1^..commit10', but I'll experiment with Dyrcona's method |
| 15:52 |
Bmagic |
Dyrcona: I could see an issue with that command if the working branch was based on a different working branch? That would bring in more than just the feature you wanted to checkout? |
| 15:52 |
Dyrcona |
Yes, you have to start from the same or similar bases. |
| 15:53 |
csharp_ |
ah - then I'll keep doin' what I'm doin' :-) |
| 15:53 |
Dyrcona |
You can also specify another branch: git cherry-pick ^main remote/branch |
| 15:53 |
Dyrcona |
Or a specific commit hash. |
| 15:53 |
csharp_ |
git++ |
| 15:54 |
Bmagic |
anywho, great work yall! kmlussier is going to galvanize it on the wiki. The rest of the sub-bullets were basically discussed as spawned from the first sub-bullet, go us |
| 15:54 |
Bmagic |
#topic New Business - Scheduling a release discussion - https://doodle.com/meeting/participate/id/av9JXRme - Kathy |
| 15:55 |
jeffdavis |
I do want to say there is value in sharing your work early even before you've had time to clean it up, especially for a huge job like the Angular acq sprint. So like, "here's my working branch, fyi it's not cleaned up/ready for pullrequest yet" is still a good thing to do. |
| 15:55 |
kmlussier |
I extended an offer a while back to help facilitate a discussion around our release process with actions coming out of the discussion. The above link is the scheduling poll. |
| 15:55 |
Bmagic |
jeffdavis++ |
| 15:55 |
csharp_ |
jeffdavis: I agree |
| 15:56 |
kmlussier |
I wanted to do it before July, but meeting time is limited, especially when working around the other community meetings. If we don't get much participation, I can try to schedule it at another time. |
| 15:56 |
Bmagic |
kmlussier++ # thanks for taking the lead |
| 15:56 |
kmlussier |
If anyone wants to help me prep, let me know. I've already recurited sandbergja. |
| 15:57 |
Bmagic |
sandbergja++ |
| 15:57 |
mmorgan |
kmlussier++ |
| 15:57 |
mmorgan |
sandbergja++ |
| 15:57 |
shulabear |
kmlussier++ sandbergja++ |
| 15:57 |
sandbergja |
kmlussier++ |
| 15:57 |
Bmagic |
this meeting is working out to exactly an hour, super duper |
| 15:58 |
Bmagic |
#topic Announcements |
| 15:58 |
Bmagic |
#info 3.14 has a roadmap |
| 15:58 |
Bmagic |
#link https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:3.14 |
| 15:58 |
redavis |
Thanks to sleary for that |
| 15:58 |
dluch |
kmlussier++ sandbergja++ |
| 15:58 |
redavis |
sleary++ |
| 15:58 |
Bmagic |
You heard right! 3.14 already! |
| 15:58 |
Bmagic |
sleary++ |
| 15:59 |
dluch |
sleary++ |
| 15:59 |
shulabear |
sleary++ |
| 15:59 |
kmlussier |
sleary++ |
| 15:59 |
mmorgan |
sleary++ |
| 15:59 |
Bmagic |
and if you like these: |
| 15:59 |
Bmagic |
#info Next Meeting is Tuesday, June 11th 2024 |
| 15:59 |
csharp_ |
<sam_gamgee>SHARE THE LOAD</sam_gamgee> |
| 15:59 |
Bmagic |
csharp_++ |
| 16:00 |
Bmagic |
#endmeeting |
| 16:00 |
pinesol |
Meeting ended Tue May 14 16:00:10 2024 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:00 |
pinesol |
Minutes: http://evergreen-ils.org/meetings/evergreen/2024/evergreen.2024-05-14-15.00.html |
| 16:00 |
pinesol |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2024/evergreen.2024-05-14-15.00.txt |
| 16:00 |
pinesol |
Log: http://evergreen-ils.org/meetings/evergreen/2024/evergreen.2024-05-14-15.00.log.html |
| 16:00 |
dluch |
Bmagic++ |
| 16:00 |
mmorgan |
Bmagic++ |
| 16:00 |
Dyrcona |
Bmagic++ |
| 16:00 |
kmlussier |
Bmagic++ |
| 16:00 |
redavis |
kmlussier, holla. I filled out the survey. |
| 16:00 |
berick |
Bmagic++ |
| 16:00 |
redavis |
Bmagic++ |
| 16:01 |
kmlussier |
redavis: You were the first! As a reward, you get a cookie, but you have to come up to Danvers for the hack-a-way to get it. |
| 16:01 |
redavis |
You know I'll be there. (so long as it's in my power) |
| 16:01 |
kmlussier |
Actually, Beverly, not Danvers. |
| 16:01 |
Bmagic |
thanks all, meetings suck. But the dev meeting rocks like Brett Michaels |
| 16:01 |
redavis |
Also, while I do love cookies, and will eat one...I'd do this without any cookies. |
| 16:02 |
kmlussier |
redavis: Of course! |
| 16:02 |
redavis |
But also...cookies. |
| 16:03 |
|
cbrown_isl joined #evergreen |
| 16:05 |
|
mantis1 left #evergreen |
| 16:10 |
eeevil |
(my process for both rebase and general incorporation of a working branch is: 1) find how many commits I need 2) ~/Evergreen$ for i in `git log --pretty=oneline -$NUMBER_OF_COMMITS|tac|cut -f1 -d' '`; do git cherry-pick -s $i; done # ... though with a bunch of bash aliases to simplify the command line |
| 16:11 |
eeevil |
(re: mid-meeting tangent about commit picking) |
| 16:11 |
|
sleary joined #evergreen |
| 16:11 |
Bmagic |
tac, new one on me. it's cat backwards |
| 16:11 |
redavis |
eeevil++ |
| 16:12 |
eeevil |
I'm sure there's a direct git command to get a reverse list of the top X hashes, but, get off my lawn ;) |
| 16:13 |
redavis |
lol!! boomer |
| 16:13 |
Dyrcona |
I used to use this: https://gist.github.com/Dyrcona/4629200 |
| 16:13 |
Dyrcona |
git list --reverse |
| 16:13 |
Dyrcona |
with a commit range added. |
| 16:13 |
Dyrcona |
`git help revisions` is enlightening. |
| 16:14 |
Dyrcona |
It's easy to just checkout the branch and rebase it on main or whatever. |
| 16:14 |
* eeevil |
tries to think like Linus, screams, runs away |
| 16:15 |
Dyrcona |
Well, somehow who uses gdb as a programmable assembler is not someone to be trifled with. :) |
| 16:17 |
Dyrcona |
s/somehow/someone/ |
| 16:18 |
pinesol |
News from commits: LP#2042158 Postgres 12+ needs to have JIT disabled <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=28615c2ca6658fad48eaccc4a05ca10b154215e8> |
| 16:22 |
|
jvwoolf left #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 18:02 |
|
kmlussier left #evergreen |
| 19:14 |
|
rlefaive joined #evergreen |
| 20:15 |
|
rlefaive joined #evergreen |
| 20:26 |
|
sandbergja joined #evergreen |
| 23:51 |
|
rlefaive joined #evergreen |
