Patch applied, thanks! Please also see https://chris.beams.io/posts/git-commit/ From taschentuch at posteo.de Wed Apr 15 13:20:53 2020 From: taschentuch at posteo.de (taschentuch at posteo.de) Date: Wed, 15 Apr 2020 13:20:53 +0200 Subject: [profanity] [PATCH] change mailinglist, delete obsolete entries, usability fixes In-Reply-To: <20200415131721.3f0311b9@maitreya.fritz.box> References: <20200415100643.21262-1-taschentuch@posteo.de> <20200415131721.3f0311b9@maitreya.fritz.box> Message-ID: On 15/04/2020 13:17, Michael Vetter wrote: > Patch applied, thanks! > Please also see https://chris.beams.io/posts/git-commit/ It is okay for me to reject PR's until such things are fixed btw. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x3A4012957FA7272B.asc Type: application/pgp-keys Size: 660 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From taschentuch at posteo.de Wed Apr 15 13:34:07 2020 From: taschentuch at posteo.de (taschentuch at posteo.de) Date: Wed, 15 Apr 2020 13:34:07 +0200 Subject: [profanity] [PATCH] add openbsd as a supported OS Message-ID: <20200415113406.665-1-taschentuch@posteo.de> From: taschentuch --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index fb64d96..caa8195 100644 --- a/index.html +++ b/index.html @@ -28,7 +28,7 @@

- Available on Linux, FreeBSD, OSX, Windows and Android (Termux)
+ Available on Linux, FreeBSD, OpenBSD, OSX, Windows and Android (Termux)

Do you like Profanity?
Consider donating! -- 2.26.1 From jubalh at iodoru.org Wed Apr 15 17:50:59 2020 From: jubalh at iodoru.org (Michael Vetter) Date: Wed, 15 Apr 2020 17:50:59 +0200 Subject: [profanity] [PATCH] add openbsd as a supported OS In-Reply-To: <20200415113406.665-1-taschentuch@posteo.de> References: <20200415113406.665-1-taschentuch@posteo.de> Message-ID: <20200415175059.18f2f8f2@maitreya.fritz.box> On Wed, 15 Apr 2020 13:34:07 +0200 taschentuch at posteo.de wrote: > From: taschentuch > > --- > index.html | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/index.html b/index.html > index fb64d96..caa8195 100644 > --- a/index.html > +++ b/index.html > @@ -28,7 +28,7 @@ > > >

> - Available on Linux, FreeBSD, OSX, Windows and Android > (Termux)
> + Available on Linux, FreeBSD, OpenBSD, OSX, Windows and > Android (Termux)

> Do you like Profanity?
> Consider donating! Merged, thanks! From stefan+xmpp at debxwoody.de Sat Apr 18 15:44:04 2020 From: stefan+xmpp at debxwoody.de (DebXWoody) Date: Sat, 18 Apr 2020 15:44:04 +0200 Subject: [profanity] Autoping response timed out Message-ID: <20200418134404.fdjv3llh6ediclhp@debxwoody.de> Hello, with one of my accounts I have had an issue with profanity. After connection with the XMPP Server, profanity started to join the autojoin MUCs. Everting was fine. Few seconds later, there was a message "Lost connection" and profanity started to reconnected. See Issue "Autoping response timed out - Lost connection" #1315 [1]. I changed some code and started to look into this issue. There was no disconnect / connection problem. It was just because of a very big OMEMO Device List of another XMPP account. The response of the device list takes 2min and the autojoin timeout is 20 sec. See [2]. Anyway, there is a second issue. This xmpp account with the big OMEMO device list, is not in by roster. I'm just in anonymous MUCS, but I'm owner or moderator in some of those MUCs. It seems that there is a Request of OMEMO Devices, of all members within a MUC, when you are able to see the JIDs of the members. Profanity will request all OMEMO devices and keys. I think there is no need and it also doesn't make senses to do this. I recommend to skip this for anonymous MUCs. This will not solve the issue with the big device list, but I will save traffic and resources and the issue may not occurs, if the account is not in your contact list. For this fix, I create a PR [3]. Maybe the author of OMEMO code can review the PR. diff --git a/src/xmpp/muc.c b/src/xmpp/muc.c index 1cc48b31..172bdb80 100644 --- a/src/xmpp/muc.c +++ b/src/xmpp/muc.c @@ -885,11 +885,13 @@ muc_members_add(const char *const room, const char *const jid) if (chat_room) { if (g_hash_table_insert(chat_room->members, strdup(jid), NULL)) { #ifdef HAVE_OMEMO - Jid *our_jid = jid_create(connection_get_fulljid()); - if (strcmp(jid, our_jid->barejid) != 0) { - omemo_start_session(jid); + if(chat_room->anonymity_type == MUC_ANONYMITY_TYPE_NONANONYMOUS ) { + Jid *our_jid = jid_create(connection_get_fulljid()); + if (strcmp(jid, our_jid->barejid) != 0) { + omemo_start_session(jid); + } + jid_destroy(our_jid); } - jid_destroy(our_jid); #endif } } During investigation I found some more issues. For example iq_handlers. This PR [4] should be reviewed or just drop the PR (see later). One example is here: https://github.com/profanity-im/profanity/blob/master/src/xmpp/session.c#L216 The function is called session_disconnect. 216 iq_rooms_cache_clear(); 217 iq_handlers_clear(); 218 219 connection_disconnect(); 220 message_handlers_clear(); 221 222 connection_clear_data(); 223 chat_sessions_clear(); iq_handlers_clear is removing the id_handlers from a hash_table: iq.c:253. 250 void 251 iq_handlers_clear() 252 { 253 if (id_handlers) { 254 g_hash_table_remove_all(id_handlers); 255 g_hash_table_destroy(id_handlers); 256 id_handlers = NULL; 257 } 258 } The disconnect isn't doing disconnecting directly, so we may not handle some things during disconnecting. I stopped investigating on this topic, because there is maybe a third problem "chat closure on autoreconnect?" #1275 [5]. I think a reconnect is not like a disconnect + connect. You may close everything for a disconnect. Maybe the user could like to connect with another account. For reconnect you may keep the context and just reconnect but not setup a new context (MUCs, dialog,...). Maybe we should check, if in such case line 223 (chat_sessions_clear - see above) is required for disconnect but maybe not for reconnect. [1] https://github.com/profanity-im/profanity/issues/1315 [2] https://github.com/profanity-im/profanity/issues/1315#issuecomment-613533797 [3] https://github.com/profanity-im/profanity/pull/1318 [4] https://github.com/profanity-im/profanity/pull/1316 [5] https://github.com/profanity-im/profanity/issues/1275 -- Mit freundlichen Gr??en, Stefan ---------------------------------------------------------------------------- Diese E-Mail wurde mit GnuPG digital signiert: Fingerabdruck: A602 F768 93F1 38B4 A8EF DDD5 C2DC 916F 3575 1C24 ---------------------------------------------------------------------------- -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 833 bytes Beschreibung: nicht verf?gbar URL : From jubalh at iodoru.org Mon Apr 20 13:02:07 2020 From: jubalh at iodoru.org (Michael Vetter) Date: Mon, 20 Apr 2020 13:02:07 +0200 Subject: [profanity] Autoping response timed out In-Reply-To: <20200418134404.fdjv3llh6ediclhp@debxwoody.de> References: <20200418134404.fdjv3llh6ediclhp@debxwoody.de> Message-ID: <20200420130207.3ccb5da9@maitreya.fritz.box> Hi, > I changed some code and started to look into this issue. There was no > disconnect / connection problem. It was just because of a very big > OMEMO Device List of another XMPP account. > > The response of the device list takes 2min and the autojoin timeout > is 20 sec. See [2]. Wow. That's not good that devices can do such things to disturb others. > For this fix, I create a PR [3]. Maybe the author of OMEMO code can > review the PR. I merged the PR. Changes look good to me. Thanks! > During investigation I found some more issues. For example > iq_handlers. This PR [4] should be reviewed or just drop the PR (see > later). Pasis reviewed your PR and left some comments on it where you need to take action. Thanks a lot for investigating these issues! Great job! Best, Michael From toogley at nixnet.email Thu May 14 00:02:27 2020 From: toogley at nixnet.email (toogley) Date: Thu, 14 May 2020 00:02:27 +0200 Subject: [profanity] amount of releases per year Message-ID: Hey, i wonder how many releases we should have per year? like openbsd does well with 2 releases per year. At least, i feel it would make sense to make a release soon, as quite a few user-visible things have happened since february: * Make /sendfile in OMEMO session configurable * omemo: switch to 12 byte IV * Expand omemo error message * Improve setting encryption char error handling * multiple memory leaks * slashguard * autocompletion of omemo/pgp/otr only when its features are built in * MAM things * OMEMO device list only for non-anonymous MUCs those improve the user experience of profanity dramatically, IMHO. That means, one release roughly every 3-4 months or so is good, i think. What do you think? From jubalh at iodoru.org Thu May 14 11:16:37 2020 From: jubalh at iodoru.org (Michael Vetter) Date: Thu, 14 May 2020 11:16:37 +0200 Subject: [profanity] amount of releases per year In-Reply-To: References: Message-ID: <20200514111637.1c00c42c@maitreya.fritz.box> Hi, > i wonder how many releases we should have per year? like openbsd does > well with 2 releases per year. I'm aiming at a major release every +/- 6 months. https://github.com/profanity-im/profanity/releases shows that so far this works well. Often being even quicker: 5 months. > At least, i feel it would make sense to make a release soon, as quite > a few user-visible things have happened since february: We use milestones to manage what we want in a new release and when it is finished: https://github.com/profanity-im/profanity/milestones So you can see that for 0.9.0 currently 13 tasks are still open: https://github.com/profanity-im/profanity/milestone/19 This is only a rough estimate, as I often work under different things under the hood and don't track it in GH. Also if I feel a release is taking too long I delay some issues to the next release and craft a new release now. > That means, one release roughly every 3-4 months or so is good, i > think. With few active developers a release every 3 months will be hard. Also there are only 2 people supporting Profanitys development with money (but many making requests) which means I can only spend few time on it. We have some brave users running Profanity from git (thanks guys!) and giving them the opportunity to run latest git for some weeks is also essential in finding the bugs early on since they don't use all features every single day. The 6 months release is only a guideline (that I aim for), but in the end we have a similar approach to Debian: it's ready when it's ready :-) Other info that might be of interest: - I was hoping to have experimental MAM support in 0.9.0 but not sure whehter it will happen. Some rough things work alreday since a couple of weeks though, but it's not finished yet. - 0.9.0 is planned to have some nice new features (like the ones you mentioned in your mail plus the ones still tracked in the milestone) and after it is released I hope that pasis and I can port libmesode things to libstrophe and then finally deprecating libstrophe. I also hope that pasis can wait to release a new libstrophe until this is done so we dont have to do backporting work for libmesode. - If this happens then the next release (either 0.10.0 or 1.0 depending on features and stability) is going bump some library version, like requiring the latest libstrophe (because we will switch to some functions that will only be in the new release), and newer glib. So 0.9.0 will run still nice on older distros but the release after will probably need a newer distro. - We will also remove some old Profanity code that is used to transform some very old configs for that new release. Hope this helps, Michael From martin at mdosch.de Thu May 14 11:27:46 2020 From: martin at mdosch.de (Martin Dosch) Date: Thu, 14 May 2020 11:27:46 +0200 Subject: [profanity] amount of releases per year In-Reply-To: References: Message-ID: <20200514092746.55fnhmdy27fbcucs@mdosch.de> On 14.05.2020 00:02, toogley via profanity wrote: >* omemo: switch to 12 byte IV This particular change was backported to 0.8.1 in Debian unstable and buster-backports. So you can always ask your distris maintainer to backport some important changes till the new release is ready. I was also writing about the milestones but I deleted it now as jubalh already wrote about it while I had my coffee break. :D Best regards, Martin -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 833 bytes Beschreibung: nicht verf?gbar URL : From toogley at nixnet.email Fri May 15 21:53:35 2020 From: toogley at nixnet.email (toogley) Date: Fri, 15 May 2020 21:53:35 +0200 Subject: [profanity] [PATCH docs] man: add new ml; remove personal mail from author to dump bugs Message-ID: <20200515195334.14329-1-toogley@nixnet.email> From: toogley at nixnet.email From: toogley The author expressed the wish to receive less emails and on a mailinglist someone elese might answer. So less mail for the author. --- docs/profanity.1 | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/docs/profanity.1 b/docs/profanity.1 index a4b364f9..9b3643a1 100644 --- a/docs/profanity.1 +++ b/docs/profanity.1 @@ -54,13 +54,7 @@ Bugs can either be reported by raising an issue at the Github issue tracker: or to the mailing list at: .br .PP - -.br -.PP -or by sending a mail directly to: -.br -.PP - + .br .SH LICENSE Copyright (C) 2012 \- 2019 James Booth . -- 2.26.2 From jubalh at iodoru.org Sat May 16 09:54:20 2020 From: jubalh at iodoru.org (Michael Vetter) Date: Sat, 16 May 2020 09:54:20 +0200 Subject: [profanity] [PATCH docs] man: add new ml; remove personal mail from author to dump bugs In-Reply-To: <20200515195334.14329-1-toogley@nixnet.email> References: <20200515195334.14329-1-toogley@nixnet.email> Message-ID: <20200516095420.470b0081@maitreya.fritz.box> Hi, On Fri, 15 May 2020 21:53:35 +0200 toogley via profanity wrote: > From: toogley at nixnet.email > > From: toogley > > The author expressed the wish to receive less emails and on a > mailinglist someone elese might answer. So less mail for the author. > --- > docs/profanity.1 | 8 +------- > 1 file changed, 1 insertion(+), 7 deletions(-) > > diff --git a/docs/profanity.1 b/docs/profanity.1 > index a4b364f9..9b3643a1 100644 > --- a/docs/profanity.1 > +++ b/docs/profanity.1 > @@ -54,13 +54,7 @@ Bugs can either be reported by raising an issue at > the Github issue tracker: or to the mailing list at: > .br > .PP > - > -.br > -.PP > -or by sending a mail directly to: > -.br > -.PP > - > + > .br > .SH LICENSE > Copyright (C) 2012 \- 2019 James Booth . Patch applied, thanks! If you insist on not using GitHub I would urge you again to learn to send proper patches. When I receive your patch and apply it with `git am the.patch` and afterwards run `git log` it looks like the following: ``` commit 55ac886cbc3a445ef0aeb81ecb594830d3299a4a (HEAD -> master) Author: toogley Date: Sat May 16 09:48:34 2020 +0200 The author expressed the wish to receive less emails and on a mailinglist someone elese might answer. So less mail for the author. commit c99a010e57dc32cd6e66b1112a85cef51a149e69 Author: Michael Vetter Date: Sat May 16 09:44:01 2020 +0200 Remove autocompletion for unanimous/regular color See 85520ecdc5d2e6ac6654817572b8fd99e43e25d9 commit 9c853d9f4644360e7f5065546f4738eb8daac87 Author: Michael Vetter Date: Thu May 14 19:13:27 2020 +0200 xep-0092: make it possible to ask servers or components for software This adds the new `/serversoftware` command. ``` /software user at domain.org/resource /serversoftware domain.org ``` Fix https://github.com/profanity-im/profanity/issues/1338 ``` As you can see there is no proper subject and separation from body. I think I linked you https://chris.beams.io/posts/git-commit/ in the past already. So this means I'll have to edit your commit manually again and give it a proper commit message. You can send patches as attachements if that is easier to not confuse the content of the mail with the commit message. Best, Michael From toogley at nixnet.email Sat May 16 11:15:17 2020 From: toogley at nixnet.email (toogley) Date: Sat, 16 May 2020 11:15:17 +0200 Subject: [profanity] [PATCH docs] man: add new ml; remove personal mail from author to dump bugs In-Reply-To: <20200516095420.470b0081@maitreya.fritz.box> Message-ID: On Sat May 16, 2020 at 11:54 AM CEST, Michael Vetter wrote: > Patch applied, thanks! > > If you insist on not using GitHub I would urge you again to learn to > send proper patches. Yes, sorry. The subject of this mail "man: add new ml;..." was intended to be the headline of the commit message > When I receive your patch and apply it with `git am the.patch` and > afterwards run `git log` it looks like the following: > > As you can see there is no proper subject and separation from body. > I think I linked you https://chris.beams.io/posts/git-commit/ in the > past already. > > So this means I'll have to edit your commit manually again and give it > a proper commit message. > > You can send patches as attachements if that is easier to not confuse > the content of the mail with the commit message. i think next time i will first send the patch myself and then to the mailinglist or so. Thanks for your patience From jubalh at iodoru.org Sat May 16 12:11:29 2020 From: jubalh at iodoru.org (Michael Vetter) Date: Sat, 16 May 2020 12:11:29 +0200 Subject: [profanity] [PATCH docs] man: add new ml; remove personal mail from author to dump bugs In-Reply-To: References: <20200516095420.470b0081@maitreya.fritz.box> Message-ID: <20200516121129.3c09c8dd@maitreya.fritz.box> > > If you insist on not using GitHub I would urge you again to learn to > > send proper patches. > > Yes, sorry. The subject of this mail "man: add new ml;..." was > intended to be the headline of the commit message I guessed so. > > You can send patches as attachements if that is easier to not > > confuse the content of the mail with the commit message. > > i think next time i will first send the patch myself and then to the > mailinglist or so. That's a good approach. I think the LKML also has something on their website regarding sending patches via git. > Thanks for your patience No worries. All contributions are very welcome! We all have to learn to get accustomed to our tools :) Best, Michael From jubalh at iodoru.org Tue Jun 9 22:10:42 2020 From: jubalh at iodoru.org (Michael Vetter) Date: Tue, 9 Jun 2020 22:10:42 +0200 Subject: [profanity] New release: Profanity 0.9.0 Message-ID: <20200609221042.4db74a65@maitreya.fritz.box> Hello! I'm happy to announce the release of 0.9.0! Get it on GitHub: https://github.com/profanity-im/profanity/releases/tag/0.9.0 Or from the website: https://profanity-im.github.io/profanity-0.9.0.tar.gz And read our blogpost: https://profanity-im.github.io/blog/post/release-090/ See https://github.com/profanity-im/profanity/milestone/19 or https://github.com/profanity-im/profanity/compare/0.8.1...0.9.0 for a complete list of changes. openSUSE Tumbleweed already contains the latest version. Other distros should follow soon. Best, Michael From pasis.uax at gmail.com Sun Jun 14 23:00:07 2020 From: pasis.uax at gmail.com (Dmitry Podgorny) Date: Mon, 15 Jun 2020 00:00:07 +0300 Subject: [profanity] libmesode functionality in Profanity Message-ID: Hi, I'd like to discuss the remaining difference between libmesode and libstrophe. As far as I understand, the only functional feature of libmesode is the ability to provide a callback to verify failed certificates manually. However, I don't like this approach. When a cert verification fails, we can't trust it, because any information can be fake there. And it's a bad idea to ask users if they trust cert checking just a few unreliable strings. Instead, I propose the following usecase: First, libstrophe continues working based on connection TLS flags (disable, mandatory, trust, etc). Then, on cert verification failure, connection disconnects, but with error code that indicates TLS failure. Notice that libstrophe has the same behaviour now, but error code needs to be unified. Finally, new function will be provided to retrieve the certificate from connection, so application will be able to display it. For Profanity it will look like this: when connection is disconnected due to cert failure, Profanity will show a help about danger and that user can use the "trust" flag at their own risk. The flag can be stored in the account configuration as well. What do you think about this? Best regards, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at debxwoody.de Mon Jun 15 20:48:52 2020 From: stefan at debxwoody.de (Stefan) Date: Mon, 15 Jun 2020 20:48:52 +0200 Subject: [profanity] libmesode functionality in Profanity In-Reply-To: References: Message-ID: <20200615184852.bqmcw655rrbveaww@debxwoody.de> Am Montag, den 15.06.2020 um 00:00:07 +0300 schrieb Dmitry Podgorny: > First, libstrophe continues?working based on connection TLS flags (disable, > mandatory, trust, etc). Then, on cert verification failure, connection > disconnects, but with error code that indicates TLS failure. Notice that > libstrophe has the same?behaviour now, but error code needs to be unified. > Finally, new function will be provided to retrieve the certificate from > connection, so application will be able to display it. I like this. It would be nice to have something like this: https://codeberg.org/xmpp-messenger/hawkbit-info/src/branch/master/src/HawkbitInfo.cpp#L110 > For Profanity it will look?like this: when connection is disconnected due to > cert failure, Profanity will show a help about danger and that user can use the > "trust" flag at their own risk. The flag can be stored in the account > configuration as well. +1 - I think there is already a "tls.policy" which can be used by the account settings. -- Mit freundlichen Gr??en, Stefan ---------------------------------------------------------------------------- Diese E-Mail wurde mit GnuPG digital signiert: Fingerabdruck: A602 F768 93F1 38B4 A8EF DDD5 C2DC 916F 3575 1C24 ---------------------------------------------------------------------------- Instant Messaging via Extensible Messaging and Presence Protocol (XMPP) ---------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jubalh at iodoru.org Tue Jun 16 14:47:19 2020 From: jubalh at iodoru.org (Michael Vetter) Date: Tue, 16 Jun 2020 14:47:19 +0200 Subject: [profanity] libmesode functionality in Profanity In-Reply-To: References: Message-ID: <20200616144719.7ec24e16@maitreya.fritz.box> Hi, On Mon, 15 Jun 2020 00:00:07 +0300 Dmitry Podgorny wrote: > For Profanity it will look like this: when connection is disconnected > due to cert failure, Profanity will show a help about danger and that > user can use the "trust" flag at their own risk. The flag can be > stored in the account configuration as well. > > What do you think about this? I think its a fine approach. Best, Michael From jubalh at iodoru.org Tue Jun 16 15:30:15 2020 From: jubalh at iodoru.org (Michael Vetter) Date: Tue, 16 Jun 2020 15:30:15 +0200 Subject: [profanity] 0.10.0 Roadmap Message-ID: <20200616153015.1ae93fd7@maitreya.fritz.box> Hi folks, I wanted to share some thoughts regarding the next release (0.10.0). I think a cleanup release would be nice. Some thoughts: * I think src/xmpp.message.c needs some cleanup. It's not as easy as it could be to add support for new messages. _handle_carbon _handle_chat etc need to get decoupled more. Some of those functions do things for other functions some are independent some do things twice. We should have cleaner main functions with individual helper functions that can be used from all the main functions. * src/event/server_events.c has a part with plenty of ifdefs. It makes it quite hard to read and even more to adapt. It's easy to actually change all the lines which you also compile but forget about the others. Once a new encryption method gets added it will get even worse. We need to find a way to improve this. DebXWoody encountered this problem too (probably when he started implementing OX) and has created WIP PR [1] for that purpose. * There are some stanza related functions that we have in Profanity and were not part of libstrophe 0.9.3. Some of them are libstrophe git but not in a release. Another function was added by pasis recently which DebXWoody needed for OX. Pasis mentioned in his last mail already the merge of libmesode functionality into libstrophe. I think this is a important step so we don't have to do double work. I assume that then libstrophe will get a new release (before profanity 0.10.0 comes out). Which means I also plan to remove the custom stanza functions and we depend on that latest version of libstrophe for those functions. * For the sql database we use some glib date functions. We use a workaround there to still rely on an older version of glib, because I wanted profanity 0.9.x to still build on Debian stable. I plan to remove the workaround and only use latest glib functions bumping glib quite some numbers (dont remember the details). * UI: I cleaned up UI related functions for the last release already. But there are some cases in src/ui/windows.c that still could be improved. About some of them I wasn't sure and before breaking something I left it as it was. Maybe we can revisit this. There are/were plenty of functions which did the same thing, just a bit different, and were all copy pasted. Also in the past we used to have jid, message, encryption method each as separate parameters. Some time ago ProfMessage was introduced (which might also need splitting into two structs) and most functions habe been adapted. But I'm not sure wheter all were. * Converting of old config files. We have some code being run on startup that makes it possible to import config files from before 0.4.7 times. I think we could also remove this. Worst case people need to do the setup again ;p * Prefer glib functions: Plenty of times we use strdup() and other functions when we actually have glib. Even worse we mix things so that a function allocates memory using glib and then free it with `free()`. We also mix gchar and char. This must have grown over time and we should take care to not introduce it in new code and at best fix all the old cases. I think these changes would be nice goals and I bet we find a lot more on the way. I think this could be the main goals for 0.10.0 Additionally people certainly will want new features and create PRs for them. It might be that OX is getting into or OMEMO file file transfer. And maybe more things that contributors are interested in. But all in all I think it might be a good idea to spend some time on improving. Especially now when it seems there are more developers present than ever before. So it means many eyes reviewing and detecing bugs. And it means one can discuss solutions when one doesn't fine a nice one. In the past I implemented several things were I wasn't sure whether I used a good solution ;) Let me know what you think about this plan, other ideas etc. Best, Michael 1: https://github.com/profanity-im/profanity/pull/1363 From taschentuch at posteo.de Sun Jul 5 15:31:10 2020 From: taschentuch at posteo.de (taschentuch at posteo.de) Date: Sun, 05 Jul 2020 15:31:10 +0200 Subject: [profanity] 0.10.0 Roadmap In-Reply-To: <20200616153015.1ae93fd7@maitreya.fritz.box> Message-ID: On Tue Jun 16, 2020 at 3:30 PM CEST, Michael Vetter wrote: > Hi folks, btw, i wanted to add: i like it a lot to have many smaller releases. i think this increases the development speed and stability of the project. thanks! From taschentuch at posteo.de Sun Jul 5 15:32:32 2020 From: taschentuch at posteo.de (taschentuch at posteo.de) Date: Sun, 05 Jul 2020 15:32:32 +0200 Subject: [profanity] 0.10.0 Roadmap In-Reply-To: <20200616153015.1ae93fd7@maitreya.fritz.box> Message-ID: On Tue Jun 16, 2020 at 3:30 PM CEST, Michael Vetter wrote: > Hi folks, > > I wanted to share some thoughts regarding the next release (0.10.0). > I think a cleanup release would be nice. Some thoughts: > > But all in all I think it might be a good idea to spend some time on > improving. Especially now when it seems there are more developers > present than ever before. So it means many eyes reviewing and detecing > bugs. And it means one can discuss solutions when one doesn't fine a > nice one. In the past I implemented several things were I wasn't sure > whether I used a good solution ;) Yes, i completely agree, this is great.