version control (again...)
MentalGuy forwarded me this: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00005.html
and I wonder whether this has any messages for inkscape's use of bzr.
njh
On Sat, Jan 4, 2014 at 5:49 PM, Nathan Hurst wrote:
MentalGuy forwarded me this: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00005.html
and I wonder whether this has any messages for inkscape's use of bzr.
Nathan,
We already had a discussion about bzr, git etc. just a few months ago. The general consensus was that we are not all that much interested to move away from bzr (and, therefore, Launchpad) at the moment, while people who don't really like bzr can use a git-bzr bridge.
Alexandre
On Sun, 2014-01-05 at 00:49 +1100, Nathan Hurst wrote:
and I wonder whether this has any messages for inkscape's use of bzr.
Actually, the most interesting part for me was about managing project direction:
We lost sight of what mattered for our users, focusing on features that were nice but perhaps not as necessary as we thought. We overengineered. We didn't get rid of the crufty unnecessary features. It's harder to comprehend, contribute to or fix performance issues in a large layered codebase. And the larger a codebase becomes, the larger the surface for bugs, the harder it is to refactor.
I think Inkscape is on the winning side of cruft management overall. But it's something I'm aware of as exciting features are always going to have the most energy.
As for focusing on users... that's a hard problem for Inkscape since there's no nice big juicy connection there between the two.
kinda makes me happy we do have really smart people who have a good sense of direction in Inkscape.
Martin,
On Sun, 2014-01-05 at 00:49 +1100, Nathan Hurst wrote:
MentalGuy forwarded me this: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00005.html
and I wonder whether this has any messages for inkscape's use of bzr.
While I think there's an independent discussion for Inkscape I just wanted to confirm that all the internal projects at Canonical that I work on are using Bazaar and Launchpad. There isn't any major feature work going on for those projects, but they are both maintained by Canonical and not bitrotting.
Long term, I do think that Inkscape will have to move to Git. While Bazaar is a better VCS in my opinion, the reality is that today it's becoming another obstacle for new developers to learn who are likely already familiar with Git. I think it's important to the project to make it as easy as possible for new developers to get involved. I'd like to see better OSS Git hosting before that move happens (Github is awesome, but it goes downhill quick) but I think it'll eventually be the right thing for Inkscape.
Ted
On Sat, Jan 04, 2014 at 12:48:44PM -0600, Ted Gould wrote:
On Sun, 2014-01-05 at 00:49 +1100, Nathan Hurst wrote:
MentalGuy forwarded me this: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00005.html
and I wonder whether this has any messages for inkscape's use of bzr.
While I think there's an independent discussion for Inkscape I just wanted to confirm that all the internal projects at Canonical that I work on are using Bazaar and Launchpad. There isn't any major feature work going on for those projects, but they are both maintained by Canonical and not bitrotting.
Long term, I do think that Inkscape will have to move to Git. While Bazaar is a better VCS in my opinion, the reality is that today it's becoming another obstacle for new developers to learn who are likely already familiar with Git. I think it's important to the project to make it as easy as possible for new developers to get involved. I'd like to see better OSS Git hosting before that move happens (Github is awesome, but it goes downhill quick) but I think it'll eventually be the right thing for Inkscape.
These are all good points, and especially after reading the linked article it looks pretty clear that Inkscape should eventually migrate to git.
Alexandre's right that the consensus from the prior discussion was to hold off on this for now, but maybe we should add it on the roadmap.
Bryce
2014/1/5 Bryce Harrington <bryce@...961...>:
These are all good points, and especially after reading the linked article it looks pretty clear that Inkscape should eventually migrate to git.
If we really must migrate to something else, then I'd rather we move to Mercurial. Despite several tries I find Git unusable, its default command actions downright malicious and its manpages useless. Mercurial still has some of the limitations of Git but at least its manpages and integrated help are actually helpful.
Regards, Krzysztof
On Sat, 2014-01-04 at 19:14 -0800, Josh Andler wrote:
Can you elaborate?
A very simple command, maybe `bzt` which detects .bzr or .git and shuttles a command to the right place so I don't have to keep mixing up which one I'm using right now. Re-route some features like `bzr uncommit` and change things like -a default when committing using git.
I'd end up re-reading Krzysztof's excellent post about which UI pieces are "borderline malicious". But I'd probably ignore corner cases and keep things simple to a core set of functions.
bzt commit -m "I don't care what kind of VCS you are, just commit it!"
Martin,
* Something I won't get to do but would love to in an infinite universe is map `git branch [name]` to `bzr branch --hardlink . .bzr/branches/[name]`
Martin,
Personally I'd rather see your time and energy actually being used on inkscape rather than creating fixes to problems we're creating by changing vcs again. I'd also like to avoid custom tools like the plague, as their one more thing to maintain across our multiple platforms or we have different systems in different places.
on the wider discussion:
What do we actually benefit from changing? Half the arguments every time this comes up seem to be little more than 'but thats what everyone else is using now (or switching to)' which makes sod all difference if we arent getting devs who are already well established devs on those other systems. If Git has a horrible learning curve, why would we change to it? Do we honestly believe that the VCS we use is stopping new devs coming to the project? My only real experience of Git was when the svn change history got completely screwed over by svn-git. Personally unless someone can give some clear concise pros and cons of the change, (including what we do for a bug tracker, as I assume we'd have to move from launch pad) with some fairly compelling arguments then I dont really think we should be wasting time or energy having the discussion let alone making a change.
just my 2c (somewhat irrelevant since about all i get time for is reading the list these days!)
Cheers
John
On Sun, Jan 5, 2014 at 8:00 AM, Martin Owens <doctormo@...400...> wrote:
On Sat, 2014-01-04 at 19:14 -0800, Josh Andler wrote:
Can you elaborate?
A very simple command, maybe `bzt` which detects .bzr or .git and shuttles a command to the right place so I don't have to keep mixing up which one I'm using right now. Re-route some features like `bzr uncommit` and change things like -a default when committing using git.
I'd end up re-reading Krzysztof's excellent post about which UI pieces are "borderline malicious". But I'd probably ignore corner cases and keep things simple to a core set of functions.
bzt commit -m "I don't care what kind of VCS you are, just commit it!"
Martin,
- Something I won't get to do but would love to in an infinite universe
is map `git branch [name]` to `bzr branch --hardlink . .bzr/branches/[name]`
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I'll get to the point. I think it's a waste of time and energy right now to talk about this. I think the release needs to be our priority and almost everything else is a waste of time and energy.
If we have time to discuss this, we wasted time that could fix bugs.
Let's focus on the release and get it out the door before even discussing changing the working environment again.
Respectfully, Josh On Jan 5, 2014 11:56 AM, "John Cliff" <john.cliff@...400...> wrote:
Martin,
Personally I'd rather see your time and energy actually being used on inkscape rather than creating fixes to problems we're creating by changing vcs again. I'd also like to avoid custom tools like the plague, as their one more thing to maintain across our multiple platforms or we have different systems in different places.
on the wider discussion:
What do we actually benefit from changing? Half the arguments every time this comes up seem to be little more than 'but thats what everyone else is using now (or switching to)' which makes sod all difference if we arent getting devs who are already well established devs on those other systems. If Git has a horrible learning curve, why would we change to it? Do we honestly believe that the VCS we use is stopping new devs coming to the project? My only real experience of Git was when the svn change history got completely screwed over by svn-git. Personally unless someone can give some clear concise pros and cons of the change, (including what we do for a bug tracker, as I assume we'd have to move from launch pad) with some fairly compelling arguments then I dont really think we should be wasting time or energy having the discussion let alone making a change.
just my 2c (somewhat irrelevant since about all i get time for is reading the list these days!)
Cheers
John
On Sun, Jan 5, 2014 at 8:00 AM, Martin Owens <doctormo@...400...> wrote:
On Sat, 2014-01-04 at 19:14 -0800, Josh Andler wrote:
Can you elaborate?
A very simple command, maybe `bzt` which detects .bzr or .git and shuttles a command to the right place so I don't have to keep mixing up which one I'm using right now. Re-route some features like `bzr uncommit` and change things like -a default when committing using git.
I'd end up re-reading Krzysztof's excellent post about which UI pieces are "borderline malicious". But I'd probably ignore corner cases and keep things simple to a core set of functions.
bzt commit -m "I don't care what kind of VCS you are, just commit it!"
Martin,
- Something I won't get to do but would love to in an infinite universe
is map `git branch [name]` to `bzr branch --hardlink . .bzr/branches/[name]`
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, Jan 05, 2014 at 01:32:38AM +0100, Krzysztof Kosiński wrote:
2014/1/5 Bryce Harrington <bryce@...961...>:
These are all good points, and especially after reading the linked article it looks pretty clear that Inkscape should eventually migrate to git.
Despite several tries I find Git unusable, its default command actions downright malicious and its manpages useless.
Yeah, I found it a royale pain in the ass to learn myself, and certainly had it chop my fingers off more than once. So I totally know what you're talking about.
But it's a learnable skill, and if a dunce like me can pick it up, anyone can. It's true git's man pages are as inscrutiable as its user-hostile error messages, but git's popular enough that there's tons and tons of actually helpful blog posts and tutorials.
And actually, I've found that git has quite a few nifty advanced features. It's definitely a skill worth having.
Bryce
participants (8)
-
Alexandre Prokoudine -
Bryce Harrington -
John Cliff -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
Nathan Hurst -
Ted Gould