Plan for 3.0

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Plan for 3.0

Jorge Villaseñor
Hi all,

I would like us to focus more on the 3.0 release and I think it worth to define how we want 3.0 to look like, what we want to get by that and what we accept doing later. I want to get inputs from you all so we can create an actual roadmap with a goal and start coding towards it.

The problem I see is that so far we have been trying to include everything on 3.0 which makes it a moving target. This make it hard to know where to invest energies and this could also demotivate current and potential developers to work on the project. To solve this problems, I want to get all of us on the same page on what we want to achieve on 3.0.

This is my proposal of what to include on our 3.0 release. The main idea is to prepare our public API and release, then do the specific fixes/refactoring on the micro and minor versions. We can target another major release in a couple of years, so we can do the necessary API changes "soon enough" that we don't want to rush everything to this release.

This are the specific things that I think we should focus on for a 3.0 release
General:
* Define our what is our public and private API.
* GObject based public API
* Prepare our API to make changes during the 3.0  life cycle (not fix everything, just prepare the API, when possible)
* Migrate our API to GIO whenever possible
* Remove all code that can be provided by our dependencies (mostly glib).
* Upgrade to recent version for our dependencies.

Libpurple:
* Non-blocking I/O
* Resolve UIOps/signals and unify them.
* Change the signals we have identified require changes to implement features/bugfixes.

Pidgin:
* PidginWebview stable API (so we can migrate to GtkWebkit 2 and fix regressions later).
* Do all public API changes needed for clean GTK3 migration (Eg icon themes).


This can be done *after* 3.0, so lower priority now.
General:
* Internal refactor/cleanup that doesn't affect public API.
* Leverage new features on upgraded dependencies to simplify our code.

Pidgin:
* Explore building GtkWebkit 2 on windows and migrate to it.
* Fix Gtk style warnings.
* Fix Webview regressions.
* Fix Gtk3 regressions.

What do you want to add or remove from this lists?
Once I get feedback from you, I plan to move this list to a wiki.

--
Masca

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

_______________________________________________
Devel mailing list
[hidden email]
https://pidgin.im/cgi-bin/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: Plan for 3.0

Niklas Andersson
Hi Jorge,

 Thanks for doing this. It is important to get 3.0 out.

 Perhaps it would make sense to track these issues in the tracker. I.e to sort out the release blockers for 3.0 (after consensus with the rest of the developers)

Best regards,
Niklas

On 26/06/16 07:52, Jorge Villaseñor wrote:
Hi all,

I would like us to focus more on the 3.0 release and I think it worth to define how we want 3.0 to look like, what we want to get by that and what we accept doing later. I want to get inputs from you all so we can create an actual roadmap with a goal and start coding towards it.

The problem I see is that so far we have been trying to include everything on 3.0 which makes it a moving target. This make it hard to know where to invest energies and this could also demotivate current and potential developers to work on the project. To solve this problems, I want to get all of us on the same page on what we want to achieve on 3.0.

This is my proposal of what to include on our 3.0 release. The main idea is to prepare our public API and release, then do the specific fixes/refactoring on the micro and minor versions. We can target another major release in a couple of years, so we can do the necessary API changes "soon enough" that we don't want to rush everything to this release.

This are the specific things that I think we should focus on for a 3.0 release
General:
* Define our what is our public and private API.
* GObject based public API
* Prepare our API to make changes during the 3.0  life cycle (not fix everything, just prepare the API, when possible)
* Migrate our API to GIO whenever possible
* Remove all code that can be provided by our dependencies (mostly glib).
* Upgrade to recent version for our dependencies.

Libpurple:
* Non-blocking I/O
* Resolve UIOps/signals and unify them.
* Change the signals we have identified require changes to implement features/bugfixes.

Pidgin:
* PidginWebview stable API (so we can migrate to GtkWebkit 2 and fix regressions later).
* Do all public API changes needed for clean GTK3 migration (Eg icon themes).


This can be done *after* 3.0, so lower priority now.
General:
* Internal refactor/cleanup that doesn't affect public API.
* Leverage new features on upgraded dependencies to simplify our code.

Pidgin:
* Explore building GtkWebkit 2 on windows and migrate to it.
* Fix Gtk style warnings.
* Fix Webview regressions.
* Fix Gtk3 regressions.

What do you want to add or remove from this lists?
Once I get feedback from you, I plan to move this list to a wiki.

--
Masca

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


_______________________________________________
Devel mailing list
[hidden email]
https://pidgin.im/cgi-bin/mailman/listinfo/devel


_______________________________________________
Devel mailing list
[hidden email]
https://pidgin.im/cgi-bin/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: Plan for 3.0

Jorge Villaseñor
On Mon, Jun 27, 2016 at 1:04 AM, Niklas Andersson <[hidden email]> wrote:
Hi Jorge,

 Thanks for doing this. It is important to get 3.0 out.

 Perhaps it would make sense to track these issues in the tracker. I.e to sort out the release blockers for 3.0 (after consensus with the rest of the developers)

Best regards,
Niklas
 
<snip>

Hi Niklas, yes, that is the plan.

After we get to some consensus here, I want to cleanup the 3.0 milestone and just keep what we want to get done and track them there. I want to see the tickets there and probably split them between API changes and actual bugfix. We can do the first one for 3.0 and the second for after it. This way we can focus more.

--
Masca

_______________________________________________
Devel mailing list
[hidden email]
https://pidgin.im/cgi-bin/mailman/listinfo/devel