bzr-gtk vs. QBzr

[Russel Winder]

Mark,

On Wed, 2009-03-11 at 08:20 +1100, Mark Hammond wrote:
> On 6/03/2009 11:03 PM, Russel Winder wrote:
> 
> > Is this an indicator that Olive-GTK and bzr-gtk are going to be left to
> > decay leaving QBzr and TortoiseBzr as the GUIs?  If so then the pressure
> > would be on QBzr to develop a GUI similar to Olive-GTK.
> 
> Surely you mean the "pressure" would be on the volunteers who felt 
> strongly enough about this to make it happen, rather than implying the 
> existing qbzr volunteers would have any kind of obligation?

This is an interesting, and not entirely straightforward, issue.

The vast majority of people using Subversion do so via TortoiseSVN, but
this aligns with being Windows users.  Linux, Solaris, Mac OS X, etc.
users have RapidSvn and the like but as far as I can tell command line
is what gets used by these people.  However this is a minority usage (by
a very long way).   Accessing Subversion via Subclipse or Subversive
with Eclipse, and the equivalent with NetBeans and IntelliJ IDEA
probably swamps actual command line usage by programmers, etc.

Reasoning by analogy, the vast majority of Bazaar users are going to be
TortoiseBzr users -- unless Bazaar is a niche product that fails to
begin to replace Subversion.  Likewise Eclipse, NetBeans and IntelliJ
IDEA plugins will likely be the standard way programmers access any VCS.
This leaves GUI access on Linux, Solaris, Mac OS X as a tiny minority
activity because these people use the command line and the history of
Subversion GUI clients on these platforms is not strong, i.e. there is a
lot of inertia against their use.

As I understand it, QBzr is the toolkit used by the majority of Bazaar
GUI things, TortoiseBzr, Eclipse plugin -- I don't know about NetBeans
or IntelliJ IDEA but given the reasons for using Qt rather than GTK in
TortoiseBzr and the Eclipse plugin then it seems likely that QBzr is the
prime toolkit.

As a marketing tool a QBzr equivalent or Olive-GTK, whilst a minority
tool potentially almost unused, would be a strong stick to beat
Subversion.  RapidSvn is really not good.  So if Canonical want extra
ammunition in the campaign to make Bazaar the main DVCS of choice, they
could decide to properly fund development of this GUI -- which I think
would be a good thing overall.

Your point is though that Bazaar is FOSS and so the regime of "people
volunteer to develop what they think is missing" applies.  If this was
just a programmer thing, then that would be an excellent "survival of
the fittest" selection mechanism.  If no-one is pained enough to develop
the code then the code isn't needed and so the fact that it is missing
is not a problem.  However, the vast majority of VCS users are not now
programmers, VCS are not programmer tools, they are corporate tools.
The majority of users of VCS are not programmers and not in a position
to volunteer.  So if Bazaar has pretensions of being a VCS and notjust a
programmer tool, there has to be acceptance that the "FOSS
pain/volunteer" approach is not the sole driver.

Which brings us back to the Bazaar core team, the QBzr team, and
Canonical.  What is the strategy, what is the resource, leading to what
is the decision.

As I understand it the QBzr team of lowered the priority of an Olive-GTK
equivalent, which is fine, it is their right to make that decision.   So
it is really up to someone with a pain to volunteer in classic mold or
for Canonical to resource the work.

Personally I am a command line user with a need for remote branch
tracking a la gitk.  I cannot volunteer to do development at the moment
-- all my programming time is taken up, but I do undertake testing and
bug reporting.  I contribute where I can, and this includes adding ideas
into the pot.
   
   
-- 
Russel.
============================================================
Dr Russel Winder                 Partner

Concertant LLP          t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,     f: +44 8700 516 084    voip:  sip:russel.winder at ekiga.net
London SW11 1EN, UK.    m: +44 7770 465 077    xmpp: russel at russel.org.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090311/2f00dbd4/attachment.pgp