bzr

[Reuben Thomas]

Anyone mind if I move hello to bzr? I'd rather not have to put up with
CVS. (Others may prefer git; I would myself, but it's been
contraindicated from on high.)

--
http://rrt.sc3d.org

[Karl Berry]

    Anyone mind if I move hello to bzr?

I should mention to (the few) people here that I invited Reuben to
become the new maintainer of hello, since he's been working on GNU
standards/infrastructure stuff for a while, and I'm always happy to
offload anything :).

    contraindicated from on high.)

As I wrote to you, Reuben, it's not a matter of fiat, but of the purpose
of the hello package ...

karl

[Reuben Thomas]

On 27 April 2011 00:36, Karl Berry <karl@...> wrote:

>    Anyone mind if I move hello to bzr?
>
> I should mention to (the few) people here that I invited Reuben to
> become the new maintainer of hello, since he's been working on GNU
> standards/infrastructure stuff for a while, and I'm always happy to
> offload anything :).
>
>    contraindicated from on high.)
>
> As I wrote to you, Reuben, it's not a matter of fiat, but of the purpose
> of the hello package ...

Sorry, I didn't mean to suggest the contrary, and hello is indeed
precisely the sort of package in which standards (which are what it's
about) override personal preference (which was what I expressed).

--
http://rrt.sc3d.org

[Jim Meyering]

Reuben Thomas wrote:
> Anyone mind if I move hello to bzr?

Considering the usability/efficiency/maturity gap between bzr and git,
I would prefer to see hello use git.  I think it makes more sense for
hello to use the dVCS that appears to be preferred by GNU developers,
not just for ease of use, but also for the size of the Git community,
and to better prepare people new to GNU for the tools they're most
likely to see in projects using modern tools.

[Karl Berry]

I don't see it as political.  I see it as a function of the purpose of
the package, rather than blindly saying "git is always better".

The purpose of hello is to be an example package of the GNU system.
Bazaar is the GNU VC.
QED.

I could say more, but I really don't want to spend more time on this
discussion.  It's not that important, seems to me.  Let Reuben decide,
as the new maintainer.

k

[Reuben Thomas]

On 27 April 2011 23:29, Karl Berry <karl@...> wrote:
>
> The purpose of hello is to be an example package of the GNU system.
> Bazaar is the GNU VC.
> QED.

Thanks. So it appears to be a tension between two different functions
of hello: as an example of the GNU system, and as a template for how
GNU packages are written. Does that sound like a fair summary?

--
http://rrt.sc3d.org

[Karl Berry]

    as an example of the GNU system, and as a template for how
    GNU packages are written. Does that sound like a fair summary?

I'm afraid I don't really understand the distinction you're drawing.

At any rate, GNU packages are (and always have been) developed in more
than one way.  This is a good thing.  In the case at hand, the added
complications of dVC are not worth the benefits for all projects.  One
technical benefit of bzr (as far as I know) is that it can be used as a
*non*-distributed VC.  Or maybe you guys consider that a drawback, I
don't know ... :).

k

[Reuben Thomas]

On 28 April 2011 00:24, Karl Berry <karl@...> wrote:
>    as an example of the GNU system, and as a template for how
>    GNU packages are written. Does that sound like a fair summary?

As an example of the GNU system, one wants to use only parts of the
GNU system to build it. As a template for how GNU packages are built,
one wants to use the best, most widely-used tools.

> In the case at hand, the added
> complications of dVC are not worth the benefits for all projects.

The more I use dVCSs, the more I'm convinced they're better in all
ways, because they add basic tools useful for both version control
(which is as useful to the individual as to the group) and for
collaboration that the file system and coreutils simply don't provide
conveniently. The increased power for the individual is the best
thing: you can't as an individual really use a centralized VCS, at
least, only in the smallest, lowest-contention projects, and you can't
use them offline at all. The anarchic feel of instant forking
encouraged and enabled by github in particular epitomizes the way in
which the user is liberated and empowered by dVCSs; several years
after first using them and a few after finally being converted, I'm
still just starting to get my head round that.

I am however convinced that a dVCS (whichever it is) is much more
appropriate for GNU: centralized VCSs give power to the administrator,
and as such should if anything be discouraged.

I think the apparent extra complexity is just that: what's really
happened is that rather than having a crude tool for accessing files
with history on a single server, we now have a rich tool for sharing
file histories. Along the way we have added lots of amazing
functionality (git bisect!) that non-dVCSs simply didn't have; that
doesn't count as part of the extra complexity of distribution. Much
complexity has actually vanished, because complicated (and tedious)
manual operations have been automated. But it's only once
functionality has been crystallised into commands that it tends to be
counted as complexity...

None of this helps me choose between bzr & git, though; I'll have a
poke about in GNU and elsewhere and a think and see if anything
reverses my current leaning towards git.

--
http://rrt.sc3d.org

[Reuben Thomas]

After consideration, I've moved hello to bzr. In the end I was swayed
by its greater accessibility to beginners (as hello should be
beginner-friendly), flexibility of usage (centralized or
decentralized) and licensing. Weighing against that was the more
widespread use of git, and in some nifty git-only functionality in
gnulib. I noted that bzr plays nicely with git in all the usual ways:
it can import/export and use a git repo directly as a foreign plugin,
thus allowing users to move from one to the other in their own way and
at their own pace.

--
http://rrt.sc3d.org