On 13/10/15 00:10, Dmitry Smirnov wrote:
On Monday 12 October 2015 12:31:31 Ghislain Vaillant wrote:
And is actively developed upstream. AFAIK, the 0.2.x branch is
deprecated and won't receive any bugfix / feature.

This is true although I'm not happy with support of 3.x either...
As a matter of fact 0.2.x stopped receiving updates long before 3.x was
announced. Yet even now 0.2.x is more mature than 3.x...

Yet, the reality is that upstream has moved on and Debian is desperately holding onto to a deprecated, albeit still working, version.

I'll just point that very few of the GNOME-3 apps have reached
feature-parity with their corresponding GNOME-2 / MATE version, which
makes me question whether an upload to testing / unstable will *ever*
happen. At least, according to your standards.

As I've said, I think/hope that eventually Gitg-3 will be ready for
"unstable". Upload to "unstable" may happen sooner if something (e.g. library
upgrade) break Gitg-2 beyond repair...

So no precise timeline, judging by the usage of "think" "hope" and "may". Waiting for things to break does not sound like a healthy reason to upgrade, does it?

Though I do not expect Gitg-3 performance to improve so speed/slowness is not
a blocker...

I have seen a few upstream bugs investigating the startup-time problems.

We are also diverging from the official statement of Debian unstable
providing "the latest and greatest" [1].

[1] https://wiki.debian.org/DebianUnstable

I do not recognise a conflict here. IMHO it is more important to ensure
usability of packages in "unstable". Perhaps you are right and having both
(Gitg-2 and Gitg-3) at the same time could be a solution in a short term...

Gitg 3.17.x is "usable", just not by your standards.

Anyway, you made your position very clear and I believe further
discussion would be a wasted effort on my end.

Actually I'm almost with you. Upgrade to new Gitg-3 is inevitable. We are
merely disagree regarding when to do it. :)

Right now, and please correct me if I am mistaken, but *you* are making the decision for *all* Debian users to stick with old and no-longer maintained software.

Sure, there has been an updated version in experimental, and for quite a while now. But looking back to our discussion, this version *may or may not* transition to unstable, again based on *your* personal considerations of how "ready" the software is, not the package itself.

Since there is absolutely *no guarantee* that upstream will ever address all your concerns, this issue is a plain dead-end, isn't it?

Would a better course of action rather be to update the software and file bugs with appropriate severity regarding the missing features *you* believe are missing, like any regular Debian user would do? Let users' feedback do the talking instead of deciding for them?

Best regards,
Ghis

Reply via email to