2015-10-24 10:32 GMT+02:00 Dmitry Smirnov <[email protected]>: > 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
