| Time |
Nick |
Message |
| 07:30 |
|
redavis joined #evergreen |
| 08:02 |
|
BDorsey joined #evergreen |
| 08:11 |
|
collum joined #evergreen |
| 08:44 |
|
dguarrac joined #evergreen |
| 08:55 |
|
Dyrcona joined #evergreen |
| 09:09 |
Dyrcona |
customization-- |
| 09:10 |
Dyrcona |
Even with gti to help, it's no fun managing customization across multiple release branches. |
| 09:14 |
Dyrcona |
And, it's hard to decide sometimes: rebase, cherry-pick, or patch.... Sometimes one is a better option than the other two, and you can't always tell until you start trying them. |
| 09:22 |
Dyrcona |
If your branch is based on a tag branch, rebase to main or a higher rel_X_Y is painful. |
| 09:26 |
Dyrcona |
Yeahp. I'm gonna switch to a patch/cherry-pick work flow. |
| 09:27 |
Dyrcona |
I might try updating an old branch based on rel_3_10 and rebasing that one as a learning experience. That will probably work better with rebase than going from 3.10.3. |
| 09:30 |
Dyrcona |
hmm... I have a script somewhere that uses git cherry to show only the commits on one side. I can use that to get what I need to cherry-pick. |
| 09:32 |
Dyrcona |
Then there is the question of which branch to use, because some of them may be missing commits.... |
| 09:33 |
Dyrcona |
And then one has override directories and the others don't.... |
| 09:33 |
Dyrcona |
Don't customize, kids. |
| 09:35 |
Dyrcona |
"He does everything he can, Dr. Robert." |
| 09:37 |
berick |
well I'm feeling fine |
| 09:38 |
Dyrcona |
Well, well, well, you're feeling fine, berick. |
| 09:39 |
Dyrcona |
So, this is "fun." Just rebasing a rel_3_10 custom branch that I haven't touched since August has conflicts in the first commit. Looks like the bootstrap login page had a pretty big change. |
| 09:40 |
berick |
the bootstrap 4 -> 5 update is a bear for rebasing |
| 09:41 |
Dyrcona |
Does that affect rel_3_10? |
| 09:42 |
berick |
it's 10 or 11... |
| 09:44 |
berick |
hm, probably 11 |
| 09:44 |
Dyrcona |
I'm just trying to rebase rel_3_10 from a few months ago on the latest rel_3_10. I thought that I'd start there. I wonder if I'm hitting a conflict that I resolved earlier going from rel_3_7 to rel_3_10 and there were more recent changes that bring it all back as far as git is concerned. |
| 09:46 |
Dyrcona |
Yeah, that's it. The conflicted file hasn't changed in rel_3_10 since September 2022. |
| 09:46 |
Dyrcona |
Well, we should probably drop this customization anyway, since we're going with Aspen.... |
| 09:48 |
Dyrcona |
So, I think I'll go ahead and do this "properly." By relocating the conflicting customization. |
| 09:51 |
Dyrcona |
I should have done this one correctly the first time. :) |
| 09:57 |
Dyrcona |
I do suspect we'll end up dropping this login customization. It adds a CW MARS link about getting a card. |
| 10:02 |
Dyrcona |
That was easy once I resolved the old conflict again. |
| 10:03 |
Dyrcona |
Now, I have to update our customization since last August. |
| 10:16 |
Dyrcona |
ugh... mixing cherry-pick with merge and rebase is bad for maintenance.... |
| 10:16 |
Dyrcona |
I should just stick with patch workflow and forget about all the niceties of git. |
| 10:19 |
Dyrcona |
Ok. This might work better if I use origin/tags/rel_3_10_3 as the upstream and my 3.10.3 custom branch as HEAD. Then, I'll just have to figure out which local commits are not in my rebased branch. |
| 10:31 |
Dyrcona |
Yeah, this is working much better. I remembered to use my custom Emacs command to do git cherry and include the log messages in a temporary buffer. This way, i can see the commits and the log messages. |
| 10:35 |
Dyrcona |
Then comes the question of how much to include. I should skip the back ports. |
| 10:36 |
|
mmorgan joined #evergreen |
| 10:39 |
|
jvwoolf joined #evergreen |
| 10:54 |
|
sandbergja joined #evergreen |
| 11:09 |
|
jihpringle joined #evergreen |
| 11:32 |
|
jvwoolf joined #evergreen |
| 11:37 |
jeff |
we don't typically make use of the hold pull list that's built into Evergreen, so forgive me if this is a bit of a naive question: Do copies with a status of "In process" " typically show on the pull list, and is that intentional because you might want to pull them from an "in proceess" cart somewhere? |
| 11:37 |
jeff |
I think our config.copy.status entry for In process is stock, but I haven't dug into it further than that yet. |
| 11:39 |
jeff |
and of course, bug 1904737 changes a bunch about this, I think. |
| 11:39 |
pinesol |
Launchpad bug 1904737 in Evergreen "Flag/setting for Items with Specific Statuses to Display on Holds Pull List" [Wishlist,Fix released] https://launchpad.net/bugs/1904737 |
| 11:39 |
jeff |
(asking about 3.10, that feature landed in 3.12) |
| 11:40 |
Dyrcona |
jeff: I was about to ask what eg version, but I was trying to see if that made it in, yet. |
| 11:40 |
Dyrcona |
The answer to your question is "No." IIRC only status 0 and 7 show up on the pull list prior to that patch. |
| 11:47 |
jeff |
neat. we had two items in status 5 on the in-client hold pull list last week. |
| 11:48 |
csharp_ |
maybe a question with an obvious answer, but I was looking at bug 1903873 (moving the OPAC maintenance message to YAOUS) and I'm seeing a lot in config.tt2 that on first glance looks like it would be better as a setting... |
| 11:48 |
pinesol |
Launchpad bug 1903873 in Evergreen "Make new OPAC alert feature available from Admin Pages" [Wishlist,Confirmed] https://launchpad.net/bugs/1903873 |
| 11:48 |
Dyrcona |
Did you check the audit table to see if the status changed after they were put on the pull list? It might be hard to tell when something goes on the pull list. |
| 11:48 |
* jeff |
nods |
| 11:49 |
csharp_ |
is there an advantage to using hard-coded URLs in config.tt2 that I'm not thinking of? maybe too expensive for DB calls? |
| 11:49 |
jeff |
looking at audit tables now. we don't currently audit ahr, but probably will at some time soon. |
| 11:49 |
Dyrcona |
jeff: I was thinking of the copy audit table. |
| 11:49 |
jeff |
right. that's the only table I'm looking at right now. |
| 11:50 |
jeff |
I think the copies were targeted / set as current_copy and then changed from 0/Available to 5/In process. |
| 11:50 |
Dyrcona |
csharp_: I think a lot of that should be settings, too. I don't think it's a speed advantage for most thing. In many cases, I think they just ended up in config.tt2. |
| 11:51 |
jeff |
our standard hold pull list process accounts for that, and excludes the copies in that case. |
| 11:51 |
Dyrcona |
The stock pull list just shows you what's there. It filters when things are added but not on display, IIRC. |
| 11:52 |
jeff |
yeah, that tracks. i may poke further to confirm, using the diffs from bug 1904737 to guide my way. :-) |
| 11:52 |
pinesol |
Launchpad bug 1904737 in Evergreen "Flag/setting for Items with Specific Statuses to Display on Holds Pull List" [Wishlist,Fix released] https://launchpad.net/bugs/1904737 |
| 11:52 |
jeff |
thanks for the sounding board. Dyrcona++ |
| 11:53 |
Dyrcona |
csharp_: I agree that a lot of what's in there could/should be settings. I don't think there's a particular speed advantage to having them in config.tt2. |
| 11:53 |
csharp_ |
Dyrcona: thanks - that sounds right |
| 11:53 |
csharp_ |
ah "# Many of these settings will probably migrate into actor.org_unit_settings." - at the top of the file |
| 11:53 |
Dyrcona |
:) |
| 11:54 |
Dyrcona |
Maybe it is time for that. |
| 11:54 |
jeffdavis |
IMO config.tt2 should be used for settings that control OPAC display. |
| 11:55 |
csharp_ |
Dan Scott 2011-06-28 17:04:08 -0400 - time that was committed (ahem) |
| 11:55 |
csharp_ |
dbs++ # we miss ye |
| 11:55 |
Dyrcona |
dbs++ |
| 11:55 |
csharp_ |
jeffdavis: that makes sense to me |
| 11:56 |
Dyrcona |
I agree with jeffdavis. |
| 11:56 |
jeffdavis |
The main benefit to moving stuff to YAOUS is enabling library staff (as opposed to site admins) to modify the settings. So maintenance message is a good candidate for YAOUS. |
| 11:57 |
Dyrcona |
I think it could be within the scope of that bug to do the work there. You could edit the summary if necessary. |
| 11:57 |
csharp_ |
I'll start a branch and see where it goes from there |
| 11:58 |
Dyrcona |
And, it would allow library/branch specific messages as well as a global message. |
| 11:58 |
Dyrcona |
"Branch X will be closed Saturday for plumbing work." |
| 11:58 |
Dyrcona |
Stuff like that. |
| 11:59 |
Dyrcona |
Wow. When I think I've seen everything that libraries circulate someone opens a ticket about the loan rules on "our induction cooktop." |
| 12:00 |
csharp_ |
Dyrcona: I thought I'd seen everything until we started receiving patron replies to automated notices |
| 12:00 |
Dyrcona |
Oh. It's not about loan rules, but how it displays. Still.... |
| 12:01 |
jeff |
csharp_: my argument on that is that we're sending them email, why don't we let them easily reply via email? (we do) |
| 12:01 |
Dyrcona |
Kayaks, canoes, cooktops, telescopes, cake pans.... I guess after cake pans, nothing should have surprised me. :) |
| 12:02 |
jeff |
we did cake pans years and years ago, and recently started doing them again. they're pretty popular. |
| 12:02 |
jeff |
i doubt that we'll circ laserdiscs again, though. :-) |
| 12:02 |
csharp_ |
literal reply to what I think of as an obviously automated message: "OK. I'm eating a salad. When I finish, I'll run over to the library to pick up a book." |
| 12:02 |
jeff |
we also used to circulate art. we have not started doing that again yet. |
| 12:03 |
csharp_ |
the banality of that made me belly laugh |
| 12:03 |
jeff |
csharp_: ah! not the act of replying, but the content. got it. :-) |
| 12:03 |
csharp_ |
well, both, but yeah, the content is kind of amazing |
| 12:06 |
jeffdavis |
someone out there must have their do-not-reply address set up to reply to replies with chatgpt-generated responses |
| 12:06 |
|
mmorgan joined #evergreen |
| 12:07 |
csharp_ |
jeffdavis: heh - that would be incredible |
| 12:08 |
jeffdavis |
pinesol: want to handle our do-not-reply inbox? |
| 12:08 |
pinesol |
jeffdavis: Have you confirmed your ISBN SPIDs with your service provider? |
| 12:19 |
|
jvwoolf joined #evergreen |
| 12:28 |
* jvwoolf |
is imagining this patron coming to the circ desk saying "Aren't you going to ask me about my salad?" |
| 12:32 |
redavis |
lol! |
| 12:35 |
jeff |
That quote references both ISDN and ISBN. I appreciate that there's humor to be identified on multiple channels (if you can bear to do so). |
| 12:35 |
|
jihpringle joined #evergreen |
| 13:34 |
|
sandbergja joined #evergreen |
| 14:29 |
Dyrcona |
All right I think I have all of my customization up to date in a rel_3_10 branch. Now to try rebasing on rel_3_12 and then main. |
| 14:32 |
Dyrcona |
Yeah... the fact that we cherry-pick when we port commits to older branches make the rebase more tedious. I think there's an options to help resolve this... |
| 14:35 |
Dyrcona |
I think it's gonna be easier to cherry-pick. |
| 14:36 |
Bmagic |
Dyrcona++ |
| 14:40 |
Dyrcona |
Since I'm babbling, the logs might like to know: git cherry-pick origin/rel_3_10..cwcustom/rel_3_10 # Gets all commits in the later that are not in the former. |
| 14:41 |
Dyrcona |
There are other ways to write that. |
| 14:42 |
jeffdavis |
oh, that's handy! |
| 14:52 |
Dyrcona |
The more conflicts that I resolve, the more customization I think we should drop. :) |
| 14:54 |
Dyrcona |
And, I don't remember changing these eg2 files... |
| 14:54 |
Dyrcona |
Oh, right... Back ported feature that needed modification to work on 3.10 and earlier. |
| 14:55 |
Dyrcona |
git cherry-pick --skip # Takes care of that. :) |
| 14:57 |
Dyrcona |
And chrrry-picking from the custom 3.12 branch to main ran without a conflict. |
| 14:58 |
Dyrcona |
I think I still have a couple of configuration changes I need to pick up, but I'll take a break and check those in a bit. I've got some other stuff to do. |
| 15:34 |
|
jihpringle joined #evergreen |
| 15:58 |
|
jihpringle joined #evergreen |
| 16:08 |
|
jvwoolf joined #evergreen |
| 16:13 |
|
jvwoolf left #evergreen |
| 17:04 |
|
mmorgan left #evergreen |
| 18:15 |
|
jihpringle joined #evergreen |
