Bug#801549: gitg: new upstream release available (3.18.0)

2015-12-28 Thread Jérémy Lal 
2015-11-07 1:12 GMT+01:00 Jérémy Lal :

>
>
> 2015-10-26 9:39 GMT+01:00 Dmitry Smirnov :
>
>> On Sunday 25 October 2015 14:25:28 Jérémy Lal wrote:
>> > I'm trying to find how to fix it.
>>
>> Thanks. I hope you have some ideas about it or we will just have to open
>> upstream bug...
>>
>
> I haven't found why it's not building right in a sid chroot, while it
> builds fine
> in my user environment.
>

Hello,
with version 3.19.3 it builds fine using sbuild, and it also seems to be
smoother
at dealing with large diffing / branches merges.
I just gave a try - it doesn't require big (if any) packaging change.

Jérémy

Bug#801549: gitg: new upstream release available (3.18.0)

2015-11-06 Thread Jérémy Lal 
2015-10-26 9:39 GMT+01:00 Dmitry Smirnov :

> On Sunday 25 October 2015 14:25:28 Jérémy Lal wrote:
> > I'm trying to find how to fix it.
>
> Thanks. I hope you have some ideas about it or we will just have to open
> upstream bug...
>

I haven't found why it's not building right in a sid chroot, while it
builds fine
in my user environment.

On the other hand, i'm opening quite big diffs (12000 lines) in something
like
4 seconds, and it's not crashing at all. Something else has changed - maybe
the webkit2gtk-4.0 2.11 i built and installed the other day.

Jérémy

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-26 Thread Dmitry Smirnov 
On Sunday 25 October 2015 14:25:28 Jérémy Lal wrote:
> I'm trying to find how to fix it.

Thanks. I hope you have some ideas about it or we will just have to open 
upstream bug...


> Please also accept my apologies for the non-friendly tone i had before.

No worries. :)

By the way thank you for your work on Redmine which I use fairly often. ;)

-- 
Cheers,
 Dmitry Smirnov.


signature.asc
Description: This is a digitally signed message part.

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-25 Thread Dmitry Smirnov 
On Saturday 24 October 2015 15:49:52 Jérémy Lal wrote:
> About the FTBFS: the package is missing a build dependency on python-gi-dev

Adding "python-gi-dev" to Build-Depends have no effect on the following FTBFS:


Merging translations into data/gitg.desktop. 
/usr/bin/g-ir-compiler  --includedir=. -o GitgExt-1.0.typelib GitgExt-1.0.gir 
Could not find GIR file 'Gitg-1.0.gir'; check XDG_DATA_DIRS or use --includedir 
error parsing file GitgExt-1.0.gir: Failed to parse included gir Gitg-1.0 


I'm getting the above in clean "unstable" on amd64.

-- 
Regards,
 Dmitry Smirnov.

---

The persistence of erroneous beliefs exacerbates the widespread
anachronistic failure to recognize the urgent problems that face
humanity on this planet.
-- Murray Gell-Mann, "Quark and the Jaguar"


signature.asc
Description: This is a digitally signed message part.

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-25 Thread Jérémy Lal 
2015-10-25 9:26 GMT+01:00 Dmitry Smirnov :

> On Saturday 24 October 2015 15:49:52 Jérémy Lal wrote:
> > About the FTBFS: the package is missing a build dependency on
> python-gi-dev
>
> Adding "python-gi-dev" to Build-Depends have no effect on the following
> FTBFS:
>
> 
> Merging translations into data/gitg.desktop.
> /usr/bin/g-ir-compiler  --includedir=. -o GitgExt-1.0.typelib
> GitgExt-1.0.gir
> Could not find GIR file 'Gitg-1.0.gir'; check XDG_DATA_DIRS or use
> --includedir
> error parsing file GitgExt-1.0.gir: Failed to parse included gir Gitg-1.0
> 
>
> I'm getting the above in clean "unstable" on amd64.
>
>
Yes, i'm getting it too now.
Also i'm not getting it on "unclean" environment. I'm trying to find
how to fix it.

Please also accept my apologies for the non-friendly tone i had before.

Jérémy

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-24 Thread Jérémy Lal 
2015-10-24 13:34 GMT+02:00 Dmitry Smirnov :

> On Saturday 24 October 2015 10:47:11 Jérémy Lal wrote:
> > In less than five minutes i was able to workaround the FTBFS and have
> > a gitg 3.18 debian package built.
>
> It is nice that you see the obvious way to fix it. Maybe you could share
> your
> workaround? Unfortunately solution to FTBFS is not that obvious to me. Or
> maybe I would have more time to fix the issue if I wouldn't be involved to
> endless arguments about uploading immature Gitg to unstable... :(
>
>
> > Isn't your role as a maintainer to fix the FTBFS issue ?
>
> It is an upstream issue. Anyway even with little time on my hands I do my
> best supporting new Gitg in "experimental" for over the year despite that I
> consider it unusable as well as packaging and maintaining its dependency
> library...
>
>
About the FTBFS: the package is missing a build dependency on python-gi-dev

Cheers,
Jérémy.

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-24 Thread Jérémy Lal 
2015-10-24 10:32 GMT+02:00 Dmitry Smirnov :

> On Saturday 24 October 2015 09:49:15 Jérémy Lal wrote:
> > i'm now a happy daily user of gitg 3.18 on debian/sid - and couldn't work
> > without it.
>
> I'm glad for you but as a daily user of older Gitg-2 I can't use new one
> (3.x) due to
>
>   * broken/unusable diff view making it impossible to review large diffs
> involving many files.
>
>   * lack of "blame" view.
>
>   * FTBFS of 3.18.0.
>
>
> > Note the slow loading of large diffs seems to be fixed (2 seconds for a
> > very large one).
>
> I'm glad to read that but I'm unable to confirm it because 3.18.0 FTBFS.
>

In less than five minutes i was able to workaround the FTBFS and have
a gitg 3.18 debian package built.
Isn't your role as a maintainer to fix the FTBFS issue ?
If you're not considering fixing it yourself, than you might better hand
over
the maintainer role to someone else.


3.17.1 is unfortunately up to 15 times slower than Gitg-2 -- when the latter
> takes 1.5 seconds to start, Gitg-3 may initialise for bloody 15(!) seconds.
> I just can't stand it but as I've said earlier this is not a blocker as I
> don't expect new Gitg-3 (with all its new dependencies) to work any faster
> (or even at the same speed) as the Gitg-2.
>

gitg 3.17.1 or 3.18 starts instantly. On my computer the only slowdown
i noticed was with big diffs (but honestly i don't remember if early gitg
was
as good or as bad). There has been improvement in the latest version.

Please test gitg in a clean environment, or on another machine.
Maybe you have something else slowing down gitg. Maybe you need to
git gc the repository you use. Maybe you have a bazillion repositories
and you don't open gitg from one of them ?

> Please accept help for packaging,
>
> Could you help to fix FTBFS or maybe follow-up with upstream please?
>

Sure ! But i don't see the relation with upstream (yet, i'll forward any
upstream
bug i will find).

> as i really don't understand why not
> > uploading gitg 3.18 to unstable is wrong.
>
> Because it will remove old Gitg-2 which is still more usable than Gitg-3.
> I'm nor replacing bad with worse -- not just yet.
>
> You are welcome to work in experimental branch but please do not upload to
> "unstable" yet.


>
> > I'm offering co-maintenance of the package here.
>
> Thank you. I'm entertaining idea of uploading new source package "gitg2"
> and
> orphan Gitg-3 and its dependencies (or hand 'em over to you). I'll let you
> know when I'll arrive at my decision -- I'm too busy to think about it
> right
> now so I need to take some time... :(
>
>
> > If it is so buggy as to not go to testing, migration-blocking bugs can be
> > added easily.
>
> This is not the point. We need to preserve Gitg-2 for a time being until
> Gitg-3 is ready


As someone already told you, i also think your position is a bit
"chicken-and-egg"
problem. Anyway, uploading to experimental is fine for me. Hopefully you'll
test it
some more until you're convinced gitg 3.18 is a great piece of software !


Jérémy

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-24 Thread Dmitry Smirnov 
On Saturday 24 October 2015 09:49:15 Jérémy Lal wrote:
> i'm now a happy daily user of gitg 3.18 on debian/sid - and couldn't work
> without it.

I'm glad for you but as a daily user of older Gitg-2 I can't use new one 
(3.x) due to 

  * broken/unusable diff view making it impossible to review large diffs 
involving many files.

  * lack of "blame" view.

  * FTBFS of 3.18.0.


> Note the slow loading of large diffs seems to be fixed (2 seconds for a
> very large one).

I'm glad to read that but I'm unable to confirm it because 3.18.0 FTBFS.

3.17.1 is unfortunately up to 15 times slower than Gitg-2 -- when the latter 
takes 1.5 seconds to start, Gitg-3 may initialise for bloody 15(!) seconds.
I just can't stand it but as I've said earlier this is not a blocker as I 
don't expect new Gitg-3 (with all its new dependencies) to work any faster 
(or even at the same speed) as the Gitg-2.


> Please accept help for packaging,

Could you help to fix FTBFS or maybe follow-up with upstream please?


> as i really don't understand why not
> uploading gitg 3.18 to unstable is wrong.

Because it will remove old Gitg-2 which is still more usable than Gitg-3.
I'm nor replacing bad with worse -- not just yet.

You are welcome to work in experimental branch but please do not upload to 
"unstable" yet.


> I'm offering co-maintenance of the package here.

Thank you. I'm entertaining idea of uploading new source package "gitg2" and 
orphan Gitg-3 and its dependencies (or hand 'em over to you). I'll let you 
know when I'll arrive at my decision -- I'm too busy to think about it right 
now so I need to take some time... :(


> If it is so buggy as to not go to testing, migration-blocking bugs can be
> added easily.

This is not the point. We need to preserve Gitg-2 for a time being until 
Gitg-3 is ready.

-- 
Cheers,
 Dmitry Smirnov.

---

Odious ideas are not entitled to hide from criticism behind the human
shield of their believers' feelings.
-- Richard Stallman


signature.asc
Description: This is a digitally signed message part.

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-24 Thread Dmitry Smirnov 
On Saturday 24 October 2015 10:47:11 Jérémy Lal wrote:
> In less than five minutes i was able to workaround the FTBFS and have
> a gitg 3.18 debian package built.

It is nice that you see the obvious way to fix it. Maybe you could share your 
workaround? Unfortunately solution to FTBFS is not that obvious to me. Or 
maybe I would have more time to fix the issue if I wouldn't be involved to 
endless arguments about uploading immature Gitg to unstable... :(


> Isn't your role as a maintainer to fix the FTBFS issue ?

It is an upstream issue. Anyway even with little time on my hands I do my 
best supporting new Gitg in "experimental" for over the year despite that I 
consider it unusable as well as packaging and maintaining its dependency 
library...


> If you're not considering fixing it yourself, than you might better hand
> over the maintainer role to someone else.

Considering. :(


> Please test gitg in a clean environment, or on another machine.
> Maybe you have something else slowing down gitg. Maybe you need to
> git gc the repository you use. Maybe you have a bazillion repositories
> and you don't open gitg from one of them ?

Tried that. You are not listening. It is not "git gc" thing because effect is 
consistent and reproducible over multiple runs on the same repository.

Once again, I do not consider poor speed a blocker.


> As someone already told you, i also think your position is a bit
> "chicken-and-egg"

How is broken multi-file diff in new Gitg is "chicken-and-egg"?


> problem. Anyway, uploading to experimental is fine for me.

Thanks.


> Hopefully you'll test it
> some more until you're convinced gitg 3.18 is a great piece of software !

It's been already a year since I've been testing every new release of Gitg 
only to feel sad about what it became. It was indeed a great piece of 
software and maybe hopefully one day it will be OK again...

-- 
Best wishes,
 Dmitry Smirnov.


signature.asc
Description: This is a digitally signed message part.

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-24 Thread Jérémy Lal 
Package: gitg
Followup-For: Bug #801549

Dear Maintainer,

i'm now a happy daily user of gitg 3.18 on debian/sid - and couldn't work
without it.
Note the slow loading of large diffs seems to be fixed (2 seconds for a very
large one).
Please accept help for packaging, as i really don't understand why not
uploading gitg 3.18 to unstable is wrong. I'm offering co-maintenance
of the package here.
If it is so buggy as to not go to testing, migration-blocking bugs can be added
easily.

Jérémy


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (670, 'unstable'), (650, 'testing'), (590, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.1.6 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gitg depends on:
ii  dbus-x11 1.10.0-3
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gir1.2-peas-1.0  1.16.0-1
ii  git  1:2.6.2-1
ii  gsettings-desktop-schemas3.18.1-1
ii  libatk1.0-0  2.18.0-1
ii  libc62.19-22
ii  libcairo-gobject21.14.2-2
ii  libcairo21.14.2-2
ii  libenchant1c2a   1.6.0-10.1
ii  libgdk-pixbuf2.0-0   2.32.1-1
ii  libgee-0.8-2 0.18.0-1
ii  libgirepository-1.0-11.46.0-1
ii  libgit2-23   0.23.1-1
ii  libgit2-glib-1.0-0   0.23.6-1
ii  libglib2.0-0 2.46.1-1
ii  libgtk-3-0   3.18.2-1
ii  libgtksourceview-3.0-1   3.18.1-1
ii  libgtkspell3-3-0 3.0.7-2
ii  libjavascriptcoregtk-4.0-18  2.10.2+dfsg1-1
ii  libjson-glib-1.0-0   1.0.4-2
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpeas-1.0-01.16.0-1
ii  libsecret-1-00.18.3-1
ii  libsoup2.4-1 2.52.1-1
ii  libwebkit2gtk-4.0-37 2.10.2+dfsg1-1

gitg recommends no packages.

gitg suggests no packages.

-- no debconf information

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-13 Thread Ghislain Vaillant 

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

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-13 Thread Dmitry Smirnov 
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.

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.
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.

And please don't play arguments by suggesting that I'm waiting for Gitg-2 to 
break. That's not what I meant. :(

-- 
Regards,
 Dmitry Smirnov.

---

In questions of science, the authority of a thousand is not worth the
humble reasoning of a single individual.
-- Galileo Galilei


signature.asc
Description: This is a digitally signed message part.

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-13 Thread Ghislain Vaillant 

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_status=NEW_status=ASSIGNED_status=REOPENED=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

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-13 Thread Dmitry Smirnov 
On Tuesday 13 October 2015 12:28:22 Ghislain Vaillant wrote:
> 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]?

I already mentioned the following URL where I listed my concerns:

https://bugzilla.gnome.org/show_bug.cgi?id=746923#c3


> Working on the full listing of blockers seem more constructive.

True. At least it can be helpful to avoid replacing bad with worse...


> That
> being said, should upstream disregard them, then a separate source
> package may be reconsidered in the future.

Everything is possible... :)


> What do you think?

I really hope we can cease wasting time on this discussion... I have too 
little time for this due to other priorities...

It would be very nice and helpful if you could follow-up with upstream.

-- 
Best wishes,
 Dmitry Smirnov.

---

It is no use saying, 'We are doing our best.' You have got to succeed
in doing what is necessary.
-- Winston Churchill


signature.asc
Description: This is a digitally signed message part.

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-12 Thread Dmitry Smirnov 
On Monday 12 October 2015 07:35:38 Ghislain Vaillant wrote:
>* start-up times: *slow* is subjective and quite variable from one
> user to another.

Subjectiveness is not the point here. Maybe it depends on size of repository 
but in my testing on same machine and on same repositories, when started 
multiple times (to make sure it uses caching) Gitg-3 starts 5 to 15 times 
slower than Gitg-2.

> For instance, gitg-3 starts in no-time for me.

Apparently you compare "no-time" to nothing...


>* functionality regressions:
>  - given upstream GNOME track record, this is unlikely to change?

I don't know about GNOME and I don't see how it is relevant. Gitg upstream 
seems to be slowly moving in the right direction so it looks like there is 
hope for Gitg...


>  - following the same mindset, we would still be stuck with GNOME
> 2.x in Debian then?

I don't know. I never use GNOME (I'm not sure if it is worth using) otherwise 
probably I would have known. Anyway to some extent Cinnamon and MATE are 
GNOME-2 derivatives so in a way we are stuck with GNOME-2.


> Perhaps a separate source package for gitg-3 would please us all.

Yeah, I thought about that too. But most likely I will not be maintaining it 
since I can't even use it myself. I'm prepared to orphan its dependency 
library "libgit2-glib" as soon as somebody will be willing to maintain both.


> On a different note, since when sharing different views than someone
> else make them *irrational*. Was the judging really necessary here?

Sorry I had no intention to be judgemental. In your own words you've 
expressed that you want new Gitg-3 for its nice UI but the price of new looks 
are features that someone somewhere is using right now (myself included). I 
hope you'd agree that trading features for new looks does not make much 
sense.

-- 
Cheers,
 Dmitry Smirnov.

---

Do your duty as you see it, and damn the consequences.
-- George S. Patton


signature.asc
Description: This is a digitally signed message part.

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-12 Thread Ghislain Vaillant 

On 12/10/15 01:21, Dmitry Smirnov wrote:

On Monday 12 October 2015 00:39:06 Ghislain Antony Vaillant wrote:

A new upstream version is available (3.18.0) which brings some more
improvement and bugfixes [1]. Please consider submitting an update
to the current package in experimental at least,


I can't upload 3.18.0 because it FTBFS as follows:


/usr/bin/g-ir-compiler  --includedir=. -o GitgExt-1.0.typelib GitgExt-1.0.gir
Could not find GIR file 'Gitg-1.0.gir'; check XDG_DATA_DIRS or use --
includedir
error parsing file GitgExt-1.0.gir: Failed to parse included gir Gitg-1.0
Makefile:6431: recipe for target 'GitgExt-1.0.typelib' failed



That's unfortunate, but I am happy to hear that you are on it.




or even unstable,
if your opinion regarding feature parity between v0.2.x and v3.18.x
has changed.


No, my _assessment_ of 3.x hasn't change. Gitg-3 starts very slow and still
suffers from UI and functionality regressions:

 https://bugzilla.gnome.org/show_bug.cgi?id=746923#c3

I tested 3.17.1 for a little while and I just could not use it.


Not my attention to start an argument here, but a few comments on the 
points you mentioned:


  * start-up times: *slow* is subjective and quite variable from one 
user to another. For instance, gitg-3 starts in no-time for me.


  * functionality regressions:
- given upstream GNOME track record, this is unlikely to change?
- following the same mindset, we would still be stuck with GNOME 
2.x in Debian then?



I personally prefer the more modern interface of the latest versions.


Sorry but I do not share your irrational fancy for modern interface that
limit your ability to do certain things that can be done with old version of
Gitg.


Perhaps a separate source package for gitg-3 would please us all.

On a different note, since when sharing different views than someone 
else make them *irrational*. Was the judging really necessary here?


Regards,
Ghis

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-12 Thread Dmitry Smirnov 
On Monday 12 October 2015 18:20:21 Dmitry Smirnov wrote:
> Maybe it depends on size of
> repository but in my testing on same machine and on same repositories,
> when started multiple times (to make sure it uses caching) Gitg-3 starts 5
> to 15 times slower than Gitg-2.

I've forgotten to mention that with Gitg-3 it comes down to up to 10 seconds 
delay after start before UI appears. In the other words I'd say that Gitg-3 
did not pass my QA testing yet...

-- 
All the best,
 Dmitry Smirnov.

---

Continuous effort - not strength or intelligence - is the key to unlocking
our potential.
-- Winston Churchill



signature.asc
Description: This is a digitally signed message part.

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-12 Thread Dmitry Smirnov 
On Monday 12 October 2015 09:53:00 Ghislain Vaillant wrote:
> I won't open that can of worms again, much has been said on that subject
> already on the GNOME-2 / MATE / GNOME-3 debate a few years back.
> 
> Moving the discussion forward, I won't try to convince you to go a
> different path.

Please keep in mind that Gitg is an effective development tool. I can't 
understand why you are so impatient to sacrifice important and useful 
features merely for UI consistency. My guess is that you probably use only 
very basic features of Gitg and never stumbled upon deficiencies and pitfalls 
of new release.

On one hand I shall be happy to hand over maintenance of Gitg-3 (and its 
dependencies) but on the other hand I do not want to introduce yet another 
package that does mostly the same but with new interface. New package is a 
burden and justification for its introduction (pleasing GNOME fans?) is weak 
especially considering that the package is already in "experimental".
Couldn't you just be little more patient and use package from "experimental" 
in the mean time?

-- 
Best wishes,
 Dmitry Smirnov.

---

Without doubt you are not sane.
-- Tage Danielsson


signature.asc
Description: This is a digitally signed message part.

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-12 Thread Ghislain Vaillant 

On 12/10/15 08:23, Dmitry Smirnov wrote:

On Monday 12 October 2015 18:20:21 Dmitry Smirnov wrote:

Maybe it depends on size of
repository but in my testing on same machine and on same repositories,
when started multiple times (to make sure it uses caching) Gitg-3 starts 5
to 15 times slower than Gitg-2.


I've forgotten to mention that with Gitg-3 it comes down to up to 10 seconds
delay after start before UI appears. In the other words I'd say that Gitg-3
did not pass my QA testing yet...



It is instantaneous on my machine (Haswell laptop). I cannot tell the 
difference between gitg 0.2.x and gitg 3.17.x startup speed.


Ghis

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-12 Thread Ghislain Vaillant 

On 12/10/15 08:20, Dmitry Smirnov wrote:

On Monday 12 October 2015 07:35:38 Ghislain Vaillant wrote:

* start-up times: *slow* is subjective and quite variable from one
user to another.


Subjectiveness is not the point here. Maybe it depends on size of repository
but in my testing on same machine and on same repositories, when started
multiple times (to make sure it uses caching) Gitg-3 starts 5 to 15 times
slower than Gitg-2.


For instance, gitg-3 starts in no-time for me.


Apparently you compare "no-time" to nothing...


s/no-time/unnoticeable




* functionality regressions:
  - given upstream GNOME track record, this is unlikely to change?


I don't know about GNOME and I don't see how it is relevant. Gitg upstream
seems to be slowly moving in the right direction so it looks like there is
hope for Gitg...


Gitg is part of the GNOME application suite [1] and as such, it aims at 
following the UI guidelines set by upstream GNOME [2]. The new UI is 
consistent with other GNOME apps such as Baobab (Disk Usage Analyzer).


[1] https://wiki.gnome.org/action/show/Apps/Gitg?action=show=Gitg
[2] https://developer.gnome.org/hig/stable/

Currently, gitg 0.2.x is not consistent with the rest of the GNOME-3 
ecosystem packaged in Debian.



  - following the same mindset, we would still be stuck with GNOME
2.x in Debian then?


I don't know. I never use GNOME (I'm not sure if it is worth using) otherwise
probably I would have known. Anyway to some extent Cinnamon and MATE are
GNOME-2 derivatives so in a way we are stuck with GNOME-2.


Cinnamon is based on GNOME-3, MATE is a fork of GNOME-2.


Perhaps a separate source package for gitg-3 would please us all.


Yeah, I thought about that too. But most likely I will not be maintaining it
since I can't even use it myself. I'm prepared to orphan its dependency
library "libgit2-glib" as soon as somebody will be willing to maintain both.


I am happy to check with the pkg-gnome-team whether they are happy to 
take over both gitg-3 and libgit2-glib (with my help).



On a different note, since when sharing different views than someone
else make them *irrational*. Was the judging really necessary here?


Sorry I had no intention to be judgemental.


No worries.


In your own words you've
expressed that you want new Gitg-3 for its nice UI but the price of new looks
are features that someone somewhere is using right now (myself included).


Which was part of the rationales behind the existence of MATE. 
Unfortunately MATE only forked a few selected core apps of GNOME-2, and 
gitg was not part of it. Perhaps a feature request for a future release 
of MATE?



I hope you'd agree that trading features for new looks does not make much
sense.


I won't open that can of worms again, much has been said on that subject 
already on the GNOME-2 / MATE / GNOME-3 debate a few years back.



Moving the discussion forward, I won't try to convince you to go a 
different path. I am happy to explore the solution of launching a new 
source package for gitg 3.x.


Ghis

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-12 Thread Ghislain Vaillant 

On 12/10/15 11:39, Dmitry Smirnov wrote:

On Monday 12 October 2015 09:53:00 Ghislain Vaillant wrote:

I won't open that can of worms again, much has been said on that subject
already on the GNOME-2 / MATE / GNOME-3 debate a few years back.

Moving the discussion forward, I won't try to convince you to go a
different path.


Please keep in mind that Gitg is an effective development tool. I can't
understand why you are so impatient to sacrifice important and useful
features merely for UI consistency.


See my comment on the GNOME-2 / MATE / GNOME-3. Same can be said 
regarding gedit, nautilus...



My guess is that you probably use only
very basic features of Gitg and never stumbled upon deficiencies and pitfalls
of new release.


Which is consistent with GNOME-3's switch of priorities to put design 
and basic features first, to the detriment of more advanced ones.



On one hand I shall be happy to hand over maintenance of Gitg-3 (and its
dependencies) but on the other hand I do not want to introduce yet another
package that does mostly the same but with new interface.


And is actively developed upstream. AFAIK, the 0.2.x branch is 
deprecated and won't receive any bugfix / feature.



New package is a
burden and justification for its introduction (pleasing GNOME fans?) is weak
especially considering that the package is already in "experimental".
Couldn't you just be little more patient and use package from "experimental"
in the mean time?


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.


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


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

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


Despite our disagreement on the subject of this bug report, I take this 
opportunity to thank you for maintaining gitg in Debian.


Ghis

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-12 Thread Dmitry Smirnov 
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...


> 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...
Though I do not expect Gitg-3 performance to improve so speed/slowness is not 
a blocker...


> 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...

 
> 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. :)


> Despite our disagreement on the subject of this bug report, I take this
> opportunity to thank you for maintaining gitg in Debian.

Thank you very much for your kind words.

-- 
Best wishes,
 Dmitry Smirnov.

---

The most fatal blow to progress is slavery of the intellect. The most
sacred right of humanity is the right to think, and next to the right to
think is the right to express that thought without fear.
-- Helen H. Gardner, "Men, Women and Gods"


signature.asc
Description: This is a digitally signed message part.

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-11 Thread Ghislain Antony Vaillant 
Package: gitg
Version: 3.17.1-1
Severity: wishlist

Dear Maintainer,

A new upstream version is available (3.18.0) which brings some more 
improvement and bugfixes [1]. Please consider submitting an update 
to the current package in experimental at least, or even unstable, 
if your opinion regarding feature parity between v0.2.x and v3.18.x 
has changed.

I personally prefer the more modern interface of the latest versions.

[1] http://ftp.gnome.org/pub/gnome/sources/gitg/3.18/gitg-3.18.0.news

Best regards,
Ghislain

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (2, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gitg depends on:
ii  dbus-x11 1.10.0-3
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gir1.2-peas-1.0  1.16.0-1
ii  git  1:2.6.1-1
ii  gsettings-desktop-schemas3.18.0-1
ii  libc62.19-22
ii  libcairo21.14.2-2
ii  libgdk-pixbuf2.0-0   2.32.1-1
ii  libgee-0.8-2 0.18.0-1
ii  libgirepository-1.0-11.44.0-1+b2
ii  libgit2-glib-1.0-0   0.23.6-1
ii  libglib2.0-0 2.46.0-2
ii  libgtk-3-0   3.16.6-1
ii  libgtksourceview-3.0-1   3.18.0-1
ii  libgtkspell3-3-0 3.0.7-2
ii  libjavascriptcoregtk-4.0-18  2.10.0+dfsg1-1
ii  libjson-glib-1.0-0   1.0.4-2
ii  libpango-1.0-0   1.38.0-3
ii  libpeas-1.0-01.16.0-1
ii  libsecret-1-00.18.3-1
ii  libsoup2.4-1 2.52.0-1
ii  libwebkit2gtk-4.0-37 2.10.0+dfsg1-1

gitg recommends no packages.

gitg suggests no packages.

-- no debconf information

Bug#801549: gitg: new upstream release available (3.18.0)

2015-10-11 Thread Dmitry Smirnov 
On Monday 12 October 2015 00:39:06 Ghislain Antony Vaillant wrote:
> A new upstream version is available (3.18.0) which brings some more
> improvement and bugfixes [1]. Please consider submitting an update
> to the current package in experimental at least,

I can't upload 3.18.0 because it FTBFS as follows:


/usr/bin/g-ir-compiler  --includedir=. -o GitgExt-1.0.typelib GitgExt-1.0.gir 
Could not find GIR file 'Gitg-1.0.gir'; check XDG_DATA_DIRS or use --
includedir 
error parsing file GitgExt-1.0.gir: Failed to parse included gir Gitg-1.0 
Makefile:6431: recipe for target 'GitgExt-1.0.typelib' failed 



> or even unstable,
> if your opinion regarding feature parity between v0.2.x and v3.18.x
> has changed.

No, my _assessment_ of 3.x hasn't change. Gitg-3 starts very slow and still 
suffers from UI and functionality regressions:

https://bugzilla.gnome.org/show_bug.cgi?id=746923#c3

I tested 3.17.1 for a little while and I just could not use it.

 
> I personally prefer the more modern interface of the latest versions.

Sorry but I do not share your irrational fancy for modern interface that 
limit your ability to do certain things that can be done with old version of 
Gitg.

-- 
Best wishes,
 Dmitry Smirnov.

---

A man is his own easiest dupe, for what he wishes to be true he
generally believes to be true.
-- Demosthenes, Third Olynthiac, sct. 19 (349 BCE)


signature.asc
Description: This is a digitally signed message part.