Re: [Evolution-hackers] Maintenance fork for Evolution / EDS 2.32
On Mon, 2011-04-04 at 08:53 +0200, Milan Crha wrote: > On Fri, 2011-04-01 at 20:07 +0100, David Woodhouse wrote: > > That's great; thanks. I'll do a little more testing on the patches > > I've cherry-picked into my trees, and then unless someone else has > > objected in the meantime I'll push them. > > Hi, > I objected against this many times, directly to you, on IRC, with no > effect, obviously. If I recall correctly, the reason why release-team > decreased releases is that distributions were *not* using .2 release. > Which is just the opposite you are trying to convince us. If they are > not using official releases, why should they use unofficial branch? Fedora does. As Yves-Alexis said, Debian (and thus Ubuntu?) does. And MeeGo does. Even before we start looking at other distributions, that is *enough* duplication of effort that it seems worthwhile to collaborate on a single code base rather than each having their own 'fork' and backporting fixes from HEAD for themselves. > By the way, how would you look for a fix user reported to your > distribution, as a distribution maintainer? > ... > Note that I do not expect anyone looking into git branch for a > particular fix, ... That's all very true, for a *specific* fix for a bug that a user has managed to report. Having said that, if the distro *were* currently running 2.32.1, I'd hope the 'workflow' you outline would *also* include checking in the gnome-2-32 branch to see if the fix has *already* been backported and tested there? By collecting the backported patches into a central tree, we don't break the workflow you describe — it stills works just as before, with an extra 'shortcut' to a fully-backported-and-tested patch in some cases. But I'm not thinking *just* about specific fixes for bugs that get reported. Part of the benefit of a central tree is that if a bug gets reported in *one* distribution and fixed there, the backported fix can benefit users of *all* distributions. Take the issue with ordering of modified recurrences, for example. How many users would manage to actually track that down and make a coherent bug report, and how many would just be inconvenienced by the fact that changes sometimes don't show up right in Evolution, and put it down to gremlins? I feel sure that the reason that bug went unreported for so long was *not* because nobody actually *saw* it. By putting that fix into a 2.32.3 release, we potentially get that fix out to a large number of users of distributions who are stil on 2.32 (which includes Fedora, for the next 8 months or so). I appreciate that you think I'm wasting my time. Perhaps I am; time will tell. But my time is my own to waste. My main concern is to ensure that I'm not wasting *your* time. And since you can choose to completely ignore what we're doing in the gnome-2-32 branch, I think we're safe on that front. -- dwmw2 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Maintenance fork for Evolution / EDS 2.32
On lun., 2011-04-04 at 08:53 +0200, Milan Crha wrote: > I objected against this many times, directly to you, on IRC, with no > effect, obviously. If I recall correctly, the reason why release-team > decreased releases is that distributions were *not* using .2 release. > Which is just the opposite you are trying to convince us. If they are > not using official releases, why should they use unofficial branch? In my (Debian) case, I usually upload .2 releases (and even .3). See http://packages.qa.debian.org/e/evolution.html Regards, -- Yves-Alexis ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Maintenance fork for Evolution / EDS 2.32
On Tue, 2011-04-05 at 16:31 +0530, Chenthill Palanisamy wrote: > This would certainly help distributions which want to stay with > Evolution 2.32 for a while.. My only concern here is, while > cherry-picking patches how would we take care of the translations and > documentation ? Are we adhering to the freezes in the gnome-2-32 > branch (am not calling this a latest stable branch) ? > > If the documentation and translations are taken care of, should the > freezes matter ? In my opinion, freezes in effect on stable branches are indefinite, whether the branches are still maintained by upstream or not. Perhaps a good rule of thumb to follow here is to only backport patches from newer *stable* branches like gnome-3-0, never directly from master. Extended maintenance of older branches was discussed recently at GNOME.Asia [1]. If you don't think there's consensus on the freeze issue, it might be worth bringing this up on desktop-devel-list or distributor-list, as I'm sure the topic is still fresh in people's minds. [1] http://np237.livejournal.com/31693.html ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Maintenance fork for Evolution / EDS 2.32
On Mon, Apr 4, 2011 at 12:23 PM, Milan Crha wrote: > On Fri, 2011-04-01 at 20:07 +0100, David Woodhouse wrote: >> That's great; thanks. I'll do a little more testing on the patches >> I've cherry-picked into my trees, and then unless someone else has >> objected in the meantime I'll push them. > > Hi, > I objected against this many times, directly to you, on IRC, with no > effect, obviously. If I recall correctly, the reason why release-team > decreased releases is that distributions were *not* using .2 release. > Which is just the opposite you are trying to convince us. If they are > not using official releases, why should they use unofficial branch? > > By the way, how would you look for a fix user reported to your > distribution, as a distribution maintainer? The work-flow, as I > understand it, is like this: > a) user enters a bug report in your distro bugzilla > b) maintainer gathers enough information to identify the issue > c) check upstream bugzilla for a "duplicate" or possible fix > d) decide on the change whether backport or indicate "will be fixed > in the next stable/unstable release" > > Note that I do not expect anyone looking into git branch for a > particular fix, with a very good reason, they would rather check in > bugzilla, which offers much better searching ability and contains enough > information for possible bug matching, with compare of git commit. And > the bugzilla should have enough information about the fix, like either a > patch or a link to particular commit. The evolution-related products use > to it that way. This would certainly help distributions which want to stay with Evolution 2.32 for a while.. My only concern here is, while cherry-picking patches how would we take care of the translations and documentation ? Are we adhering to the freezes in the gnome-2-32 branch (am not calling this a latest stable branch) ? If the documentation and translations are taken care of, should the freezes matter ? - Chenthill. > > That's my opinion. > Bye, > Milan > > P.S.: as of today (or tomorrow, if you wish), the official stable > release is 3.0.0. > > ___ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers > ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Maintenance fork for Evolution / EDS 2.32
On Fri, 2011-04-01 at 20:07 +0100, David Woodhouse wrote: > That's great; thanks. I'll do a little more testing on the patches > I've cherry-picked into my trees, and then unless someone else has > objected in the meantime I'll push them. Hi, I objected against this many times, directly to you, on IRC, with no effect, obviously. If I recall correctly, the reason why release-team decreased releases is that distributions were *not* using .2 release. Which is just the opposite you are trying to convince us. If they are not using official releases, why should they use unofficial branch? By the way, how would you look for a fix user reported to your distribution, as a distribution maintainer? The work-flow, as I understand it, is like this: a) user enters a bug report in your distro bugzilla b) maintainer gathers enough information to identify the issue c) check upstream bugzilla for a "duplicate" or possible fix d) decide on the change whether backport or indicate "will be fixed in the next stable/unstable release" Note that I do not expect anyone looking into git branch for a particular fix, with a very good reason, they would rather check in bugzilla, which offers much better searching ability and contains enough information for possible bug matching, with compare of git commit. And the bugzilla should have enough information about the fix, like either a patch or a link to particular commit. The evolution-related products use to it that way. That's my opinion. Bye, Milan P.S.: as of today (or tomorrow, if you wish), the official stable release is 3.0.0. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Maintenance fork for Evolution / EDS 2.32
On Fri, 2011-04-01 at 20:07 +0100, David Woodhouse wrote: > Although presumably there will be 3.01 and 3.02 releases so those > branches aren't *quite* as orphaned as 2.32 yet :) Yeah, 3.0.1 at least per the GNOME schedule, although we've been doing at least one additional stable update ever since GNOME went from three down to just a single update per six-month cycle. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Maintenance fork for Evolution / EDS 2.32
On Fri, 2011-04-01 at 13:28 -0400, Matthew Barnes wrote: > On Fri, 2011-04-01 at 18:00 +0100, David Woodhouse wrote: > > I hope that eventually, we might be permitted to use the "real" > > gnome-2-32 branch in GNOME git for this, rather than having to do it > > elsewhere. If that branch is a "dead end" and would otherwise be unused, > > then there's no harm in letting us use it as a more central location for > > our collaboration, surely? > > I'm fine with you using the "real" gnome-2-32 branch. Would even be > nice to see another formal 2.32 release if enough patches accumulate. That's great; thanks. I'll do a little more testing on the patches I've cherry-picked into my trees, and then unless someone else has objected in the meantime I'll push them. > Per GNOME's six-month release cycle, upstream maintainers have pretty > much wrapped up 3.0 and are now focused on 3.1. Although presumably there will be 3.01 and 3.02 releases so those branches aren't *quite* as orphaned as 2.32 yet :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Maintenance fork for Evolution / EDS 2.32
On Fri, 2011-04-01 at 18:00 +0100, David Woodhouse wrote: > I hope that eventually, we might be permitted to use the "real" > gnome-2-32 branch in GNOME git for this, rather than having to do it > elsewhere. If that branch is a "dead end" and would otherwise be unused, > then there's no harm in letting us use it as a more central location for > our collaboration, surely? I'm fine with you using the "real" gnome-2-32 branch. Would even be nice to see another formal 2.32 release if enough patches accumulate. Per GNOME's six-month release cycle, upstream maintainers have pretty much wrapped up 3.0 and are now focused on 3.1. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Maintenance fork for Evolution / EDS 2.32
Although the Evolution developers have moved on to better things and consider Evolution 2.32 to be a dead end, there are distributions still trying to ship this "dead end". It is the latest stable release of Evolution, after all. Rather than all the distributors working separately to keep track of patches and backport bug fixes from Evo HEAD, it would be useful if we could make a git tree somewhere which collects such patches and reduces our duplication of effort. Kind of like the -stable tree for the Linux kernel. To that end, I have created trees at: http://git.infradead.org/evolution-data-server-2.32.git git://git.infradead.org/evolution-data-server-2.32.git http://git.infradead.org/evolution-2.32.git git://git.infradead.org/evolution-2.32.git We can define our operating policy as we go, but I'd be happy if we could stick to *only* cherry-picking patches which have already been applied to the master branch (with massaging to make them apply as necessary). I've been using 'git cherry-pick -x' so that we can refer back to the original commit easily. I've backported a small number of fixes from HEAD that I think are appropriate, or which are already being shipped in some distributions. I'm more than happy to give accounts on git.infradead.org to distribution maintainers, and look at other patches which distributions are shipping. I hope that eventually, we might be permitted to use the "real" gnome-2-32 branch in GNOME git for this, rather than having to do it elsewhere. If that branch is a "dead end" and would otherwise be unused, then there's no harm in letting us use it as a more central location for our collaboration, surely? Presumably we'll do the same thing for Evolution 3.0 during the time period when it is orphaned by upstream, but still being shipped by distributions. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
