kicad-developers team mailing list archive

[Miguel Angel <miguelangel@xxxxxx>]

    I really understand both points, git is wonderful, git is faster (C
written), and has much
better interfaces for collaboration (github.com specially).

    In the few months that I've spent maintaining the KicadOSX builder, I
was surprised
on how much collaboration did I get via github (pull requests.. or patches
on bug comments).
https://github.com/kicad/kicadosxbuilder/pulls?direction=desc&page=1&sort=created&state=closed


   On the other side, does it worth to change system over and over again?.

   (I know I should have no vote at all here, since my collaboration to
Kicad lately it's almost 0...)

   I strongly believe it's worth, because it's the better tools what makes
software advance
at faster paces that they did years ago. I can't foresee any decline in git
usage, development or
maintenance, as it's heavily used for the Linux source code itself (which I
suppose it's one
of the most active opensource communities).  At the same time, I know that
time will prove me wrong,
something better will be invented, and people will eventually adopt it.

   As far as I understand, bzr and git, are almost the same thing, one
written in python, one written
in C, one with an smaller community, one with a bigger one..., one seems to
have stopped development
(point that I didn't realize until now...), and the other one is actively
developed (http://www.ohloh.net/p/git )
-for now-.

  All the similarities make me think, that probably the gains are bigger
than the migration pain, but
pff, everything always look to me easier than it actually is, so don't
listen me ;-).


   Cheers,
Miguel Ángel.

PS: more notes about git:

*) gerrit + git-review, it's something awesome..., it let's you commit
every new patch as a review,
  everybody can comment at your patch, propose improvements, and people can
vote, then it's core-developers
who give the final vote. (It can actually be configured).

   example :
https://review.openstack.org/#/c/53609/4/neutron/tests/unit/mlnx/test_mlnx_neutron_agent.py
                  https://review.openstack.org/#/c/53609/

   Jenkins can be plugged to it, and if any proposed patch breaks the
build, or the tests, it get's a -1 vote,and
it cannot be merged (unless forced)

*) I work daily in projects where the combination of launchpad + git is
used (instead of launchpad+bzr), and
it works well.


---
irc: ajo / mangelajo
Miguel Angel Ajo Pelayo
+34 636 52 25 69
skype: ajoajoajo


2014-02-04 Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>:

> >________________________________
> > From: Henner Zeller <h.zeller@xxxxxxx>
> >To: Joel Holdsworth <joel@xxxxxxxxxxxxxxxxxxx>
> >Cc: kicad-developers@xxxxxxxxxxxxxxxxxxx
> >Sent: Tuesday, February 4, 2014 3:43 PM
> >Subject: Re: [Kicad-developers] Revisiting the Git decision (I come in
> peace! - with a patch)
> >
> >
> >
> >Thank you for this mail. I fullheartedly agree.
> >
> >
> >I myself am usually very active with contributing to projects I am using
> - many projects from KDE to LyX, gimp, kphotoalbum, OpenScad ... (many more
> to name) have patches from me. Mostly because whenever I use a program, and
> I see things to change/fix/improve I just do it, because as a software
> engineer that is the matter I do all day :). If things are simple git pull,
> branch and send a pull request for review and iterate, I am happy.
> >
> >
> >I have used many VCS systems - from sccs, RCS in the early days over CVS,
> SVN, now Perforce (yeah, for work) and git. I contributed to SVN, was the
> maintainer for CVSweb for a while. I even wrote a VCS system my diploma
> thesis. And for one one patch to KiCad I even used bazaar. The only project
> I ever had to use bazaar. So yeah, I had some exposure to VCS system.
> >
> >
> >Bazaar is powerful and it looks like it has similar features to git.
> However, it is an oddball VCS that never took off and is mostly dead now.
> It is rarely used while git is one of the hot VCS systems that a very high
> percentage of open source projects use, virtually every open source
> developer is familiar with it. I suspect even the main KiCad developers are
> familiar with git.
> >
> >
> >
> >When I contributed one patch to KiCad, I perceived the use of bazaar an
> inconvenient hurdle. And the mental fatigue you feel when you have to learn
> about some rare and obsolete technology that is only used in very few
> projects (only _one_ project I care about), just to get the work done.
> >
> >
> >
> >I believe that many developers and potential contributors feel the same
> and the occasional thread like this popping up on this mailing list shows
> that there are many potential developers that would like to contribute,
> have an easy-to-use git-pull request and review process such as on github
> and just spend the time getting some patches done, not battle with a VCS
> hindrance.
> >
> >
> >Right now, I do have a list of like 5 things I want to work on on KiCad
> and contribute patches, but the prospect of having to figuring out again
> how to properly do local branches, do the equivalent of pull requests and
> code review for a rare VCS that is not relevant for anything else I do is
> keeping me from doing it.
> >
> >
> >Of course you could just say that I am lazy and should just get over it
> and learn bazaar. Fair point. But fact is, that this is preventing _me_
> from getting into the contribution right now (and working on KiCad) and
> many others as well.
> >
> >
> >So while I respect the decision to stick with bazaar right now, just be
> aware that this definitely is a hindrance and hurdle for people to
> contribute.
> >
> >
> >We keep the kicad library in git. But we keep the KiCad source in bazaar.
> Just that double use alone would qualify for switching to git now.
> >It is forseeable, that the need to switch away from bazaar is at the
> horizon in a year or so anyway. Why not do it now and have a more inviting
> development environment for hundreds of possible contributors - to
> unfortunately the expense of a dozen or so regular contributors who have to
> adapt to a different workflow.
> >
> >
> >-henner
> >
> >
>
> Like git, there are very few bzr commands that people use on a daily
> basis. I may not be creating branches in the best way possible, but what I
> do is something like this:
>
> 1. bzr checkout lp:kicad kicad_head
> 2. Create my (very heavy) branches:
>    a. bzr branch kicad_head mybranch
>    b. cd mybranch && bzr bind ../kicad_head
> 3. Hack at code, with the occasional 'bzr up' in kicad_head and mybranch
> 4. Create a patch: bzr diff > mypatch
>
> If it's a small patch I post it to the list, if it's an enormous patch I
> push it to my patch repository on github and make an announcement on the
> list. Updating a patch to the latest revision is trivial and as easily done
> as in git.
>
> The only other commands I commonly use are revert, add, commit, log, and
> revno.
>
> Whenever I get stuck (which is rare) I just spend a few minutes looking at
> the bzr documentation.
>
> If I need to make a change to a project source to suit my needs I don't
> let the VCS stop me. I've even been known to work with that
> second-most-awful-vcs-ever (svn -- I completely agree with Linus Torvalds'
> comments on svn).
>
> Personally I find it takes much more effort for me to make sure I comply
> with the source formatting rules than it takes to learn to use bzr.
>
> - Cirilo
>
> >
> >
> >
> >On 1 February 2014 03:40, Joel Holdsworth <joel@xxxxxxxxxxxxxxxxxxx>
> wrote:
> >
> >Hi Guys,
> >>
> >>I'm new to this project - though not to open source in general. I'm the
> >>author of PulseView - a GUI for logic analyzers and oscilloscopes; part
> >>of the sigrok project.
> >>
> >>I've been trying to get started making contributions to your project,
> >>building from source, fixing problems etc. and I feel like I've
> >>encountered an unusually large number of hurdles to me a would-be casual
> >>contributor.
> >>
> >>I'll just mention one of them in this message, and that is the project's
> >>usage of Bazaar. I understand some discussion has already taken place
> >>about this, and the project authors wish to stay with Bazaar - and I
> >>respect that decision. As a project author myself, I agree with the
> >>principle that the authors can do whatever they damn well like.
> >>
> >>But...
> >>
> >>Here's the thing: I really think it's the wrong call.
> >>
> >>Though I'm not at all happy to say it, Bazaar is dead. You can see that
> >>clearly here: www.ohloh.net/p/bazaar - bazaar has not had a single
> >>commit in 3 months. In that time Git has had literally hundreds. Or try
> >>reading this blog post from a former developer:
> >>http://stationary-traveller.eu/pages/bzr-a-retrospective.html
> >>
> >>But Bazaar is still usable - it still works - right? Of course this is
> >>true, one can still get work done with it, and will be able to for some
> >>time to come. But at this point - in my opinion - it's a dead horse.
> >>
> >>Rightly or wrongly, Bazaar has lost the mindshare battle, and now very
> >>few developers have any familiarity with it at all. Whereas with a Git
> >>project, I can grab the code, make a local branch, start hacking, make
> >>some commits, tidy them up with rebase, shove them up on a github
> >>account (that I already have ready to go), and notify the maintainer -
> >>all without learning anything new. And I think this is true for many
> >>other developers. But in kicad using bazaar there is significant
> >>friction involved in every single one of the above steps for the
> newcomer.
> >>
> >>Of course someone sufficiently motivated can overcome these things. But
> >>I think there is a significant constituency of good contributors who
> >>just have very little time to spare, but who have good things to offer,
> >>and who you never hear from because they were discouraged by the
> friction.
> >>
> >>For myself, overcoming this friction has definitely kept me away from
> >>hacking on Kicad for some time.
> >>
> >>So I'm asking what you think?
> >>
> >>Of course I totally respect the project author's right to decide, and I
> >>really respect this project - it is an amazing piece of work. Which is
> >>why I really want to see it continue to grow and prosper.
> >>
> >>I consider myself somewhat knowledgeable about Git, usage, migration
> >>etc., so if I can help with some transition work, or clarify anything I
> >>would be happy to help.
> >>
> >>On the subject of Launchpad - it seems to me like a fine project system,
> >>so if everyone is happing using it, I see no need to migrate away from
> >>it - unless you want to. And there are several high quality Git hosting
> >>platforms available, some have wikis and bug trackers etc. - if you ever
> >>want to do an import to them at some point in the future.
> >>
> >>Also, I've been doing a little work on scripts/libary-repos-install.sh,
> >>see the attached patch, would someone be willing to review it/commit it?
> >>
> >>Best Regards
> >>Joel Holdsworth
> >>
> >>_______________________________________________
> >>Mailing list: https://launchpad.net/~kicad-developers
> >>Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >>Unsubscribe : https://launchpad.net/~kicad-developers
> >>More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >
> >
> >_______________________________________________
> >Mailing list: https://launchpad.net/~kicad-developers
> >Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >Unsubscribe : https://launchpad.net/~kicad-developers
> >More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>