Re: [Bug-apl] Improved contribution workflow

[enztec]

mysql?? wth is that ... i think you meant mariaDB ? right?

here is a google cache of projects using bazaar web page - the original site 
didn't come up form me



On Thu, 28 Sep 2017 08:41:57 -0400
Louis Chrétien <address@hidden> wrote:

> In this discussion, I would respectfully suggest a look at Bazaar:
> 
> http://bazaar.canonical.com/en/ <http://bazaar.canonical.com/en/>
> 
> Part of the GNU Project, it is a very comprehensive tool that allows many 
> workflows, including centralized (a la CVS/Subversion), gatekeeper, or 
> distributed (like GIT).
> 
> It is used by, among others, The Linux Foundation, Ubuntu, Debian, MySQL
> 
> Integrates with LaunchPad, for creating a community with forums, bug 
> tracking, etc…
> 
> Here’s a nice overview: Ten reasons to switch to Bazaar
> http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html 
> <http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html>
> 
> 
> > On Sep 28, 2017, at 05:29, Alexey Veretennikov <address@hidden> wrote:
> > 
> > Hi,
> > 
> > I'm really having trouble to understand how did you find it difficult to 
> > find information or concept guides.
> > 
> > There is just an _awesome_ book available online: 
> > https://git-scm.com/book/en/v2 <https://git-scm.com/book/en/v2>
> > which contains 99% of the stuff you need to know, including details on how 
> > the internally git works, all concepts and explaining workflows.
> > There is an awesome speech by Linus as well which describes main concepts 
> > on how it indented to be used: https://www.youtube.com/watch?v=4XpnKHJAok8 
> > <https://www.youtube.com/watch?v=4XpnKHJAok8>
> > 
> > The github itself has a great tutorial and emphasize own workflow 
> > (pull-requests).
> > 
> > Also about working on your own, since the ability for git to work from 
> > scratch without any servers etc just make it much easier for personal use 
> > than svn and other vcs - i.e. you just archive whole directory and copy to 
> > another pc etc and continue to work.
> > 
> > Having say that, the usage of github or whatever other system is just a 
> > maintainer preference: if he wants to make the contributions easier and 
> > reach wider audience of contributors. So far github is the easiest and most 
> > widely used repository storage and social network around open source 
> > projects (not necessarily free software!).
> > 
> > Dyalog for instance is already moving their auxulary libraries and tools to 
> > github: https://github.com/dyalog/ <https://github.com/dyalog/> , in the 
> > move to reach larger and younger audience of contributors and APL 
> > developers.
> > For example their new IDE, RIDE, is already there.
> > 
> > P.S. On a humor note, about git: 
> > https://www.youtube.com/watch?v=CDeG4S-mJts 
> > <https://www.youtube.com/watch?v=CDeG4S-mJts>
> > 
> > Br,
> > /Alexey
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 2017-09-28 5:10 GMT+02:00 David B. Lamkins <address@hidden 
> > <mailto:address@hidden>>:
> > On Wed, Sep 27, 2017 at 12:00:08PM -0400, address@hidden 
> > <mailto:address@hidden> wrote:
> > > From: Juergen Sauermann <address@hidden <mailto:address@hidden>>
> > > To: Elias Mårtenson <address@hidden <mailto:address@hidden>>, 
> > > "address@hidden <mailto:address@hidden>"
> > >  <address@hidden <mailto:address@hidden>>
> > > Subject: Re: [Bug-apl] Improved contribution workflow
> > 
> > [... snip ...]
> > > As to Mercurial and git, I am really not a fan of them. Mercurial is kind 
> > > of
> > > bearable because you can use it from SVN.
> > > But the way in which people work on github is, IMHO, horrible, even 
> > > though they
> > > seem to be successful. This is probably
> > > due to my own lack of knowledge about git, but what I have seen so far is 
> > > not
> > > motivating me to increase that knowledge.
> > 
> > I can certainly appreciate the sentiment. I'd like to share my own 
> > experience as a git user, FWIW.
> > 
> > Until three years ago I had been a strong proponent of SVN. I understood as 
> > much of the workflow as I needed. Really the only downside of SVN, for me, 
> > was having to occasionally ping someone who had locked a needed file for 
> > too long.
> > 
> > Then I joined an R&D outfit that uses git on the engineering side. (The 
> > business folks use SVN.) I have to say that my early experiences with git 
> > were unpleasant, mainly due to the *huge* "surface area" of the toolkit and 
> > the lack of a (IMO, at least) well-written concept guide. Mind you, there's 
> > *tons* of "how to" posts and articles, some of which have been useful. But 
> > the general approach is "here's how I did this" with little explanation 
> > beyond the commands and arguments necessary to solve the problem...
> > 
> > AIUI, one of the reasons for the depth of git is that it supports a 
> > plethora of workflows. There are other factors, of course: the fact that 
> > git is a distributed system and offers a bunch of "plumbing" for custom 
> > system integration probably contributes to the bloat. The question you need 
> > to answer -- and I don't think there's a one-size-fits-all perspective -- 
> > is how you feel about the tradeoff between git's complexity and its 
> > capabilities.
> > 
> > Again, AIUI: It's quite likely that if you're working on a project having 
> > many contributors, then the project will have an established git workflow 
> > with guidelines (or even requirements) as tohow to do common tasks. The 
> > most difficult situation, I think, is to learn git on your own as a sole 
> > (or principal) contributor, with only the man pages and the afforementioned 
> > resources for deciphering git.
> > 
> > GitHub takes away some of the complexity at the expense of hiding a lot of 
> > the more clever bits of git. (I personally am not a fan of web UIs for 
> > technical tasks.) The downside is that folks who learn only the GitHub (or 
> > GitLab, or ...) interface tend to invent Rube Goldberg-like workflows or to 
> > completely ignore, say, the notion of "upstream". Take a peek at 
> > Arduino-related repos for a great example of this: I once had to (attempt 
> > to) track down the source of some GPS code that originated for an Arduino 
> > shield; there were multiple upstreams, each of which had tens or hundreds 
> > of forks. The code that I was trying to identify, though, no longer 
> > existed. But these are all git repos, no matter how many there are, right? 
> > Yeah, right. Unfortunately, none of the "ease of use" of the web UI does 
> > much (if anything) to inform its users regarding useful workflows. It 
> > turned out that the owner of the "ancestral" upstream wiped and rewrote the 
> > repo for every release; the early release that I needed to consult didn't 
> > exist anywhere...
> > 
> > Personally, I'd advise taking at least a peek at git if the opportunity 
> > presents itself. Regardless of whether you want to adopt git, you will 
> > encounter useful projects that do present their assets as a git repo; you'd 
> > be well-served to know some basic commands such as switching branches and 
> > viewing the commit log. But I wouln't suggest jumping ship from a system 
> > with which you're already comfortable.
> > 
> > (That said, I *do* have a recommendation for a GNU Autotools replacement: 
> > Meson and Ninja. I've begun to adopt that build toolchain for my personal 
> > and work projects, and am quite pleased with what I've seen so far. For an 
> > example of a small project built using Meson and Ninja, see the xs shell 
> > that I maintain: <https://github.com/TieDyedDevil/XS 
> > <https://github.com/TieDyedDevil/XS>>.)
> > 
> > --
> > "The chain which can be yanked is not the eternal chain."
> > -- G. Fitch
> > 
> > 
> 
> 
> ---
> Louis Chrétien
> address@hidden
> 
> 
> 
>