Bug 692446

Well, it's obviously an upstream issue, fixed in upstream. I told you on IRC that this is there for years. I do not see any request you want to do with this bug report, it's just couple of statements. Is this a request to backport patch to Fedora 14? I would say no, basically because of my first two sentences.

We are using Fedora 14, the latest Fedora release.
It contains Evolution 2.32; the latest Evolution release.

We found this bug, which is affecting us. It's relatively easy to fix, and the fix is simple so it does not have much chance of introducing other problems.

What is the policy on fixing such bugs in Fedora?

Do we not bother to fix them at all, and just say "we'll fix it in the next release"? 

Or does it depend on the upstream project? If the upstream project says "we do not care about supporting our the latest release of our code, we consider it a dead end", does that mean Fedora doesn't bother to fix bugs in that package either? And *should* it mean that? Or if a package is a dead-end with no available upstream support for *any* release, should Fedora even be shipping it at all?

We/We/Fedora/Upstream. Four different things.

I do this based on my opinion, and all what you said is, from my point of view, up to each maintainer. I may do things wrong here, no doubt.

(In reply to comment #3)
>  I may do things wrong here, no doubt.

Perhaps. But I was trying to ssk what your policy *is*, with the Fedora maintainer hat on, before I suggested that you are doing things wrong.

Here we have a bug, in a Fedora release that is the latest available and is intended to be supported for another... 8? 9? months.

It's a calendar bug which can display meetings *wrongly*, causing you to miss the meeting or go to the wrong location, etc. It basically means that you can't always trust Evolution to tell you the truth about your appointments.

It has a fairly simple, *safe* patch to fix it.

Why would we *not* wnt to fix it?

I would very much like to know what the policy is, in the genaral case. It certainly seems confusing to me.

I don't think there really is a Fedora-wide or even desktop-wide policy.  If there is it certainly hasn't been communicated clearly down the ranks.

Generally Milan and I work upstream-only as much as possible and try to avoid patching the Fedora packages, preferring instead to pick up the fix in the next upstream release.  But if the upstream branch has reached EOL as 2.32 has, then it's kind of case-by-case.  It's kind of up to each maintainer to decide if the bug is severe enough to warrant a patch.

We usually say "no" by default because patching for individual bugs sets an unsustainable precedent given our limited manpower.  RHEL of course is a different story since people actually pay money for that.

Well, even if you think "turn up with a simple unintrusive patch that's already been accepted in HEAD, and we'll merge it" is a particularly onerous precedent to set, you don't *have* to be bound by precedent anyway.

With respect to manpower issues in distributions shipping Evolution, perhaps if we follow that thread we'd end up back at the separate discussion we've had elsewhere, about how it would be really useful if there was some central location that all the distributors shipping Evolution would continue to collect such simple fixes even after the official GNOME development has declared the latest stable release to be a 'dead end' and moved on.

That would mean that all the distributors aren't duplicating effort by all doing the same work, and it would reduce the manpower needed to keep track of (and test) such fixes. Think of it much like the -stable branches of the Linux kernel. Or, if you prefer, think of it as the equivalent of the "upstream-only" policy, for maintaining the stable release.

We could set up such a tree anywhere (like on github), starting as a clone of the gnome-2-32 branch from GNOME git.

Or — and this is a revolutionary idea, I know — instead of creating such a tree elsewhere for distributors to use as a "stable upstream", perhaps we could just keep committing occasional fixes like this to the gnome-2-32 branch in GNOME git, which would otherwise be unused now anyway. It can't do any *harm* to put them there to save time and effort for all the distributors, can it?

I don't want to make work for you; I want to make life *easier*. And I'm quite happy to take on the task of backporting fixes (when they don't apply as-is like this one does). I'm also happy to do the work of updating the Fedora package and doing test builds — or even go as far as releasing updates, although I quite understand if you'd prefer me not to.

I really don't think that leaving this bug unfixed in Fedora 14 for the remaining 8 months or so of its lifetime is the best solution, and I'm offering to do the work required to fix it.

I was commenting on your question about general policy, not this specific bug.

I think distributing the maintenance burden for older releases among "lieutenants" for those branches makes sense.  Perhaps you could then coordinate additional 2.32 releases for distros to pick up (including Fedora).  I'm happy to relinquish control of the gnome-2-32 branch for that.