loujine: heard you ran into ruaok! We see you monday afternoon then? :)
D4RK-PH0ENiX joined the channel
d4rkie has quit
Leftmost
He's a real boy now, reo.
d4rkie joined the channel
Nyanko-sensei has quit
agentsim joined the channel
LordSputnik
reosarevok: not any more, last year I could've been a student but was a mentor instead
agentsim has quit
Nyanko-sensei joined the channel
d4rkie has quit
zas
samj1912: ping
samj1912
pong
zas: moin o/
zas
Moin
Are you available for the release this morning?
samj1912
yeah
we can release at 14:10 UTC?
suhas2go joined the channel
zas: can you mark it for 1.4.1?
we can build it then?
JonnyJD joined the channel
zas
Ok, coffee for now, then we start
samj1912
okay :D
Major_Lurker joined the channel
MajorLurker has quit
Freso
Will you merge Qt5 stuff today?
(Post-1.4.1 release.)
Sophist
Don't forget to create a 1.4.2 branch so we can spin off minor maintenance releases.
samj1912
Freso: I think we can
Sophist: yes
Sophist
Since we will need to redo the dev environment, it might make sense to merge the Qt5 and Py3 changes at the same time so that I only need to redo it once.
Good morning from my BTW.
samj1912
Sophist: actually we can merge the qt5 changes, I made the travis and other changes for it in the PR too
the qt5 PR is standalone
Sophist
Sorry - what I said was confusing - I mean our personal dev environments on our PCs.
samj1912
you just need pyqt5?
setting up the dev env for py3 is quite easy since everything is available on pip
so you can easily do it later
the py3 port will take some time to debug
plus the qt5 port alone offers better performance
and for any debugging in the qt5 part, someone will have to branch off of my PR
better to have the changes in master
arbenina joined the channel
Freso
No need to make a 1.4.2 branch before it's needed though.
samj1912
Freso we have a couple of pending PRs that can be merged into 1.4.2
Freso
Oh, okay.
samj1912
However I think they have to be opened again against 1.4.2 instead of master?
Freso would probably name the branch something like "1.4.x" rather than making it specific to .2
Yeah, works for me
Freso
samj1912: You can just cherry-pick or merge.
samj1912
👍
Freso
Esp. if you merge those after 1.4.1 release but before 2.0 breaking PRs.
Making 1.4.2 and 2.0 share common commit history as much as possible, instead of having duplicated commits due to cherry-picking. :)
samj1912
Well they'd be useless in 2.0 I think since all of that code might be rewritten
Let's see
Freso
Ah.
Well, you can always merge the PRs manually instead of doing it through the GH interface.
Then you are in completely control over which branches they get applied to.
samj1912
Yup
Freso
Also, if the code will get rewritten, it likely won't do any harm to have the PRs merged into the branch anyway.
Some people (e.g., me :)) are using Picard from latest/recent git/master, so until the 2.0 changes are actually done, the 1.4.2 ones might be nice to have.
navap: Happy birthday :)
Sophist
If we are happy to have 1.4.2 using Qt5, then we don't need a 1.4.2 branch yet. But if we want to stick with At4 for the 1.4.x releases we need to split off the maintenance branch before merging Qt5.
Freso: That is why I was asking about Qt5 in the 1.4.2 - people running from source will need to install Qt5.
Freso
Sophist: If they run raw, ie. straight from git, they will have to keep up with git and they should know as much.
zas
1.4.2 will stay on py2/qt4, and will only contain bug fixes
Freso
If they run from some package, say AUR's picard-git, then the packaging should handle that for them.
Sophist
zas: I think that is best too.
In which case we need to split off the 1.4.x branch before merging Qt5.
Freso
Sophist: Not really.
The 1.4.2 branch can be split off three years from now from a commit five years ago, if we wanted to.
Sophist
Oh. Perhaps I don;t understand Git that well then.
