On 13/10/15 11:26, Dmitry Smirnov wrote:
On Tuesday 13 October 2015 10:03:49 Ghislain Vaillant wrote:
Gitg 3.17.x is "usable", just not by your standards.
It is not usable to me. I can't review diffs affecting many files and
(although I won't hold Gitg just for this reason) I can't wait for 10 seconds
every time I start it before it opens. (I'm glad you've never seen this
problem but it exists).
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.
Yes, right now I'm making this decision in favour of unmaintained but working
software comparing to maintained but severely impaired alpha/beta quality
software. This is not a vote and I stand for my decision. I will eventually
reconsider but for now I'll stay on this position for some time.
Do you realise that you are asking me to take away the tool (gitg-2) that I'm
using maybe 100 times a day without suitable replacement? I'm not ready to do
such disservice to myself and to Debian users.
Ack.
Gitg-2 still _works_ better than Gitg-3. Your argument is already won -- new
UI or not Gitg-3 will eventually replace Gitg-2 but not just yet.
If you are so desperate to switch Debian to Gitg-3 then I'd suggest to
convince upstream to work on proper implementations of diff view and blame
view.
Let's keep the ball rolling. Can you provide a comprehensive list of
features / bugfixes that should be included for a future release to be
worthy of an upload to unstable?
Have all these been passed along to upstream? Which bugs are you
referring to for diff and blame views in this list [1]?
[1]
https://bugzilla.gnome.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=gitg
Alternatively if you are prepared to maintain Gitg-3 and libgit2-glib then
you can prepare source upload for "gitg3" package and convince FTP-masters to
accept once you find a sponsor for it.
Also please remember to fix FTBFS in 3.18.0 because in it's curernt state it
can't be uploaded at all.
As you previously mentioned, adding a new source package is not optimal.
Working on the full listing of blockers seem more constructive. That
being said, should upstream disregard them, then a separate source
package may be reconsidered in the future.
What do you think?
Ghis
