ChanServ changed the topic of #mlpack to: "mlpack: a fast, flexible machine learning library :: We don't always respond instantly, but we will respond; please be patient :: Logs at http://www.mlpack.org/irc/
< yashwants19[m]> Hi [rcurtin](https://matrix.to/#/@freenode_rcurtin:matrix.org) [zoq](https://matrix.to/#/@freenode_zoq:matrix.org) shoukd we also update CLI11 and catch headers during release process via release script?
ImQ009 has joined #mlpack
user183 has joined #mlpack
user183 has left #mlpack []
< zoq> yashwants19[m]: Sounds like a good idea, not sure if it should be included in the release script directly, maybe it should be more of a continues process of checking if there is a new version, test it over some time, and if we don't encounter any issues, let's include it into a new release. Like for catch this is easy, we have a bunch of PR's that could act like a test bench.
< zoq> yashwants19[m]: So if anything is wrong with a new catch version I guess we will see it right away.
ib07 has quit [Ping timeout: 240 seconds]
< yashwants19[m]> I was thinking about release script because It will open a PR before the release process which helps us to check the issues regarding the updated headers.
< yashwants19[m]> But i guess that release PR might not be the correct place to check those updated headers.
< yashwants19[m]> May be we can use github actions for the process.
< yashwants19[m]> Via github actions we can run scheduled cron workflow which can open a PR if detects version bump for those headers.
< yashwants19[m]> I am not sure azure devops provides the same functionality.
< yashwants19[m]> As for opening the PR from github actions we might have to use github action app.
ib07 has joined #mlpack
ib07 has quit [Max SendQ exceeded]
ib07 has joined #mlpack
< rcurtin> ok, irc logs on the website are fixed :)
ib07 has quit [Ping timeout: 240 seconds]
< rcurtin> yashwants19[m]: I think something like what zoq suggested could work; at least with ensmallen, we're always by default testing on the latest version (since the autodownloader downloads ensmallen-latest.tar.gz)
< rcurtin> so, at release time, we'll already know that the latest version of ensmallen works, and so the release scripts just set the version being downloaded to whatever ensmallen-latest.tar.gz points to at the moment of release
< rcurtin> (so that later ensmallen releases don't break old mlpack releases)
< rcurtin> but right now we just have static versions of CLI11 and catch... it would be great to incorporate bugfixes from upstream, but we don't currently have a good way to do this except manually (which isn't great)
chopper_inbound[ has quit [Quit: Idle for 30+ days]
< yashwants19[m]> If [rcurtin](https://matrix.to/#/@freenode_rcurtin:matrix.org) [zoq](https://matrix.to/#/@freenode_zoq:matrix.org) agrees with scheduled cron github actions workflow which can open a PR if header version bumps, then I can come up with PR soon.
< yashwants19[m]> [rcurtin](https://matrix.to/#/@freenode_rcurtin:matrix.org) for Rcereal issue should we provide a cereal copy, or should we go for autodownloader.
< zoq> yashwants19[m]: Some sort of cron job sounds good to me, maybe we can do this for boost as well, so that we can update https://github.com/mlpack/mlpack/blob/master/CMakeLists.txt#L421 as well?
< yashwants19[m]> Agreed.
< jeffin143[m]> Yes I think that's a good thing :)
ib07 has joined #mlpack
ib07 has quit [Max SendQ exceeded]
ib07 has joined #mlpack
ib07 has quit [Ping timeout: 240 seconds]
ib07 has joined #mlpack
< RishabhGarg108Gi> Hey, I was working on a file and when I hit save, my editor changed the formatting of the code, which inside commit shows that the whole file has changed, while in reality i just changed a couple of them. So, do I need to make the formatting as it was earlier, or it would be acceptable when I make a PR ? The only formatting that my editor changed was the tab indentation, in my editor it is 2 while generally it is 4
< RishabhGarg108Gi> spaces.
< zoq> RishabhGarg108Gi: The PR should follow the coding style guidelines - https://github.com/mlpack/mlpack/wiki/DesignGuidelines which means one tab = two spaces.
< RishabhGarg108Gi> ok thanks @zoq I will make sure that the code follows this guideline.
< RishabhGarg108Gi> Also, I wanted to know how should I make a PR. I am absolutely new and this would be my very first PR. Do I need to make a separate branch and then work on that or I just work on the master branch of my fork and directly make a PR ?
< zoq> RishabhGarg108Gi: Better to use a branch, so you can open more than one PR without including the changes from another one.
< RishabhGarg108Gi> Ok. Thanks for helping :).
< zoq> Happy to help :)
ImQ009 has quit [Quit: Leaving]