New versions release frequency

[wladimirleite]

I would like to share a few thoughts (some of them based on feedback from other users) about IPED new versions release frequency.

@lfcnassif, I know you have been quite busy and releases do take time.
However, I think the gap between 4.1 and 4.2 was too long, which caused too many changes to be included in a single release and a long delay to see new merged features being used in practice (which may trigger unpredicted issues).
Another point is that some features (e.g. UFDR, WhatsApp internal parser) require constant updates.

So, I would like to help try to make releases more frequent.
For me, something around 3 months would be great (IPED went from 3.0 to 3.18 in a few years, right?!).

Currently we have many pending PR's, some of them are ready for review for a very long time.
It would be nice if we can review to merge them (or reject in some cases), because as time goes by, merging conflicts may grow and some of the original developers are not "focused" in the project anymore.

Let me know which PR's (or open issues) I could work on.

[lfcnassif]

Hi @wladimirleite,

I really regret for delaying 4.2.0 for so long... I was waiting for #1341 to be reviewed and translated. But as I don't control translations done by external collaborators, I decided to cut it off the release and roll 4.2.0 (without other translations) so the time spent waiting for it was useless, I'm sorry...

So, I would like to help try to make releases more frequent.
For me, something around 3 months would be great (IPED went from 3.0 to 3.18 in a few years, right?!).

That would be great, thank you! If you also would like to help with the release process itself, that's fine to me, it's good so the release process wouldn't depend on only one person. I agree 3 months would be a good time frame for feature releases, fixing releases could be faster.

Currently we have many pending PR's, some of them are ready for review for a very long time.
It would be nice if we can review to merge them (or reject in some cases), because as time goes by, merging conflicts may grow and some of the original developers are not "focused" in the project anymore.

I totally agree. Long waiting PRs tend to cause many merging conflicts, making them harder to get in, and also to get help from the original collaborators. So, I agree we should put efforts to merge old and important PRs.

Let me know which PR's (or open issues) I could work on.

I took a look at them and, the most important PRs, in my opinion, in chronological order, are:

Case creation UI, important for new and non technical users, helping to increase the project adoption:
#1341

Processing optimization with remote transcription enabled:
#2023

Android Backup parser, but I think it is not very useful without #2095 below:
#2079

ALeapp integration to directly process Android extractions, could potentially speed up a lot mobile examinations, because we can decrease our dependency on non automated and interactive UI tools like PA:
#2095

Translation, important for terrorism cases, and we should review and hopefully merge it to encourage external collaborators:
#2188

UFDR imported chats dozens of improvements by @aberenguel:
#2287

I'm having conversations to put more developers to work on the project and @marcosammoura will start after Carnival. If I don't review your PRs until there, I will ask him to do, reviewing and merging your PRs is a priority too.

Furthermore, our high hierarchy levels are asking for faster examinations, so optimization improvements would be very welcome and I know you and me like them very much :-).

But please feel free to work on the PRs or features you think are more important or that make you more motivated to work on.

Thank you very much!