Re: [Evolution-hackers] Reconsidering our release cycle
On Tue, Jul 23, 2013 at 7:40 PM, Matthew Barnes mbar...@redhat.com wrote: Increasingly I'm feeling like the traditional 6-month release cycle is just too short for Evolution. In terms of development, we have a pretty short window for landing major changes and allowing adequate time for testing before development freezes set in. I like the idea very much and had similar plans before, but never went forward with it before. I think I like the idea. My concern is that it could also be longer before new features and fixes actually make it into a release. For example, if we were on an annual schedule and people were still using Evolution 3.6 today instead of Evolution 3.8 we'd still be having to kill evolution-source-registry after connecting to the VPN if we actually want to see our calendars. And if a distribution ships a few weeks before a release, that now means they can be shipping a version of Evolution which is a *year* old, instead of only six months old. Life would be a lot easier even with the existing release cycle if we weren't so incestuously tied to the latest GNOME release (and if the GNOME libraries didn't make compatibility so hard by deprecating things so quickly). Obviously we'll have to fix that anyway, and I wonder how much of the proposed benefit we could achieve by *only* fixing that, while sticking with 6-monthly releases on the GNOME schedule? For example, if users could use Evolution 3.8 on top of GNOME 3.6, and upgrading didn't mean they have to rebuild their *whole* world with it, the existing situation wouldn't be quite so bad anyway, would it? But more importantly, our users seem to be constantly playing catch-up in terms of supported releases. Because of the delay between upstream releases and distro releases, by the time users finally upgrade to a newer Evolution, more often than not they're upgrading to a version that's either nearing the tail end of its 6-month support window or is already unsupported. But we've never *prevented* any distro packager from continuing to do maintenance for older releases. I did it for 2.32 for a while, when MeeGo was using that. If distributions want to cherry-pick patches back into an unsupported release that they're using, we should encourage them to do so. That's frustrating, both for users and for me as a developer, but we just don't have the manpower to support multiple stable releases and still get any kind of significant development work done. I'd like us to consider moving to a 12-month release cycle, which would sync up with GNOME's release schedule annually instead of semi-annually. Here's my initial proposal, if you guys are open to this: Please take the above comments as just thinking aloud, rather than objections. I'm more than happy to attempt what you propose. On Tue, 2013-07-23 at 21:28 +0530, Srinivasa Ragavan wrote: The challenge will be to sync properly with the GNOME freezes during the second half of the cycle. It will be good to sync with that, so that when the product releases with GNOME release, there is doc / translation all ready. Agreed. I really wouldn't want EDS to be part of this, if we ever want it to be a proper platform/core material. Just Evolution would be better fit for this model IMHO. I don't think that makes sense. As Fabiano points out, Evo and EDS are *very* closely tied. Even in the *stable* branch in 3.8.4 there are fixes for EDS/EWS which require corresponding fixes in Evo. Breaking the close version ties with the rest of GNOME makes sense, but not between Evo and EDS. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Wed, 2013-07-24 at 02:54 +0200, Fabiano Fidêncio wrote: I also fully agree with your suggestion. As we have discussed, users are reporting bugs against 3.8.x now and they will need to wait at least 6 months before they get a fix in 3.10.x. I mean, from the stability point of view it would be great if we have a larger window to work, test and correct our mistakes.. Am I the only one who fixes bugs and implements features on the gnome-3-8 branch, then commits, cherry-picks that to master, and *then* cherry-picks it back to gnome-3-8 (with the -x option) to make it look like it happened in master first? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Wed, 2013-07-24 at 10:59 +0100, David Woodhouse wrote: On Wed, 2013-07-24 at 02:54 +0200, Fabiano Fidêncio wrote: I also fully agree with your suggestion. As we have discussed, users are reporting bugs against 3.8.x now and they will need to wait at least 6 months before they get a fix in 3.10.x. I mean, from the stability point of view it would be great if we have a larger window to work, test and correct our mistakes.. Am I the only one who fixes bugs and implements features on the gnome-3-8 branch, then commits, cherry-picks that to master, and *then* cherry-picks it back to gnome-3-8 (with the -x option) to make it look like it happened in master first? Hi, I'd say double yes: 1) yes, I do develop new things in master first, then backport to stable branch (it's sometimes only about applying, sometimes real backport) 2) yes, most likely because stable branches are feature-frozen (plus couple more freezes), thus you violate a policy by doing new features there. :) Of course, one may define what a new feature is in the first place. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Wed, 2013-07-24 at 10:58 +0100, David Woodhouse wrote: My concern is that it could also be longer before new features and fixes actually make it into a release. For example, if we were on an annual schedule and people were still using Evolution 3.6 today instead of Evolution 3.8 we'd still be having to kill evolution-source-registry after connecting to the VPN if we actually want to see our calendars. And if a distribution ships a few weeks before a release, that now means they can be shipping a version of Evolution which is a *year* old, instead of only six months old. I agree with David. My main frustration with Evo right now is that I'm always a release behind because my distribution appears to be chronically one Gnome release back (I understand this is due to my distribution and not the responsibility of the developers), for whatever reason. That means I was stuck on 3.4 until May (which was bad as there were numerous problems with 3.4), and will be using 3.6 for most of the rest of the year. If the distributors and the Evo release cycle don't line up nicely you could be working with an Evolution that's more than 18 months old (assuming a 6 month distro release cycle; some distros are longer than that) before you get to the next version. Not being familiar with Evo development I'm not sure how feasible it is, but ideally part of the change in release cycle would mean divorce from the Gnome version lockstep, and Evo being able to build against multiple versions of Gnome. If Evo were changed to be more of a stand-alone utility (at least optionally), rather than being bundled with Gnome, that would be (IMO) a good thing for users. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
Hi Fabiano, On Wed, Jul 24, 2013 at 6:29 AM, Fabiano Fidêncio fabi...@fidencio.org wrote: Srini, I really wouldn't want EDS to be part of this, if we ever want it to be a proper platform/core material. Just Evolution would be better fit for this model IMHO. Could I ask you why? If you check our git's activity you will see that the most part of bugs we are fixing are touching both in Evolution as in EDS. I really cannot imagine these two parts not walking together. I know how tight the development is. Infact, in my watch, we added a configure check that mandates same minor micro version. But IMHO this model should change for good. It kind of brought lot of flexibility for introducing breakages because we know Evolution would work with only the right version of EDS well but we kind get into a model of ignoring the apps that would depend on EDS. All along we (Evolution/EDS hackers) were blamed for breaking API/ABI. Im not support this following statement, but there was a time, when you can just build evolution and not use latest EDS/Gtk/other platform bits on atleast 2 older GNOME releases. I may not ask for this, but atleast we should have EDS decoupled from Evolution releases to let it survive/develop as a platform on its own. Some might argue that having a yearly releases will give longer API/ABI stability, but again coupling EDS Evolution will let us into more breakages. My point for this was not about the duration, but about decoupling the EDS Evolution releases to plan/avoid any API/ABI (re)designs for EDS. This is my thought, and some may support it but a lot might oppose it ;-). Thanks, -Srini. Best Regards, -- Fabiano Fidêncio ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Wed, Jul 24, 2013 at 3:28 PM, David Woodhouse dw...@infradead.org wrote: I don't think that makes sense. As Fabiano points out, Evo and EDS are *very* closely tied. Even in the *stable* branch in 3.8.4 there are fixes for EDS/EWS which require corresponding fixes in Evo. Breaking the close version ties with the rest of GNOME makes sense, but not between Evo and EDS. It is my wish, we could decouple EDS Evolution releases to start building API/ABI stability into EDS. I don't have strong objects to EDS having yearly releases. Im not saying that we wont/cant' to backporting fixes and re-releasing for minor/micro releases. We should be able to go back at least 2 GNOME releases. This is required kind of required if you want to avoid 'adapting to 3.6 EDS' like commits in EWS/LibreOffice/SyncEvolution/* -Srini ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Tue, 2013-07-23 at 10:10 -0400, Matthew Barnes wrote: Increasingly I'm feeling like the traditional 6-month release cycle is just too short for Evolution. Hi, I'm replying slightly later, I was thinking of this a bit. Generally I agree, I also feel like the 6-month release cycle is too short for any extensive work. 12-month might be better, even it brings more work to us. For a good reason, of course. * Bump Evolution's major version number to split away from GNOME's semi-annual release numbering. Call the upcoming March 2014 release Evolution 4.0 (or perhaps even Evolution 2014... I'm open to ideas). I would not bump the version, let's just slow down. One cannot do major rewrites all the time, the dust should settle one day, and then we might get back to sync with GNOME releases, and possibly also version. The GtkHTML version is the example for me, when we couldn't do that, when other evolution products were version-synced with GNOME version, for easier recognition which GNOME version this is supposed to work on. * We would continue releasing stable updates and development snapshots at a steady pace. Our release schedule could even be more predictable than it is now. We could do, for example, stable releases on the 1st Monday of each month and development snapshots on the 3rd Monday. I can imagine a simple .ics file on http://projects.gnome.org/evolution page with the release schedule, like the one for GNOME releases exists :) Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Thu, 2013-07-25 at 06:42 +0200, Milan Crha wrote: ... even it brings more work to us. For a good reason, of course. By the way, it also means that any so-called white-space cleanups, which I always understood as a one-time job, not a multiple-times-per-releases job, should either stop completely (we have our code under control, do we not? [1]) or be done only once, just before the major release. I was just beaten by this when applying a patch from master to gnome-3-8, it was quite painful and discouraging to apply the patch by hand. Bye, Milan [1] The script introduces coding style bugs too, which should be fixed. I noticed multiple times that it uses 8 spaces instead of tabs for function parameters indentation, but the evolution code uses tabs for indentation. It doesn't make me laugh when I see a white-space cleanup change being mostly about this nonsense in the code I just wrote and made sure I follow the coding style guide for evolution code. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
