On 08-12-2017 09:44, Ben Bucksch wrote: >> Conversely, why should we make it harder for people working on >> Mozilla (and used to hg) to contribute the off patches to Thunderbird? > > > Do we have Mozilla employees contributing patches for us? A > significant amount? Dunno about employment status, but there certainly are a bunch of overflow contributions from people working mostly (I think) on m-c code, fairly important ones. For instance our Japanese friends come to mind.  -Magnus

On 08/12/2017 08:44, Ben Bucksch wrote: > Do we have Mozilla employees contributing patches for us? A > significant amount? Yes and yes. Quite frequently, when they do major refactoring, they do a patch for C-C as well. My life would be quite miserable without those patches. Jörg.

On Thu, Dec 7, 2017 at 10:55 PM Magnus Melin <mkmelin+mozilla@iki.fi> wrote: > On 07-12-2017 23:50, Tom Prince wrote: > > This is definitely false. I know several prominent, skilled open-source > developers who have not bothered to make contributions (even easy ones) > because they can't be bothered to figure out or install a new version > control system. We want to make it easy for new people to start > contributing to Thunderbird; any hurdle we put in front of people means we > will lose some people before they actually start contributing. Certainly > once somebody has started contributing regularly, we can push them to start > using hg, but that shouldn't be the first hurdle they face. > > > On linux, installing mercurial is maybe 30s and even on Windows, you'll > set it up in a few minutes. I'm sorry, but if 30s of your time is a major > hurdle to contribute, your contributions are not going to be considerable. > If we only people we want to contribute are people that make "considerable" contributions, we won't ever get more contributors. Most people who contribute will start with small fixes. There is some discussion of this in https://medium.freecodecamp.org/the-bad-practice-in-foss-projects-management-32f66c3515f9#da06. I think this dismissive response to small contributions is not good for the health of the project. In any case, I think you significantly underestimate the effort required to install and learn a new version control tool enough to contribute using it. Certainly the actual time to download and install mercurial (from selecting the program to install to it being installed) may only be 30s (on a good internet connection, but as you point out the size of the mozilla and thunderbird repository will be a larger issue in this case). But, there is also - figuring out which program to install (is it `mercurial` or `hg` or something else) - figuring out how to clone the thunderbird repos - figuring out how to get something out of the repo to submit as a change - dealing with the possibility that there exists commands with identical names in git and hg that have opposite behavior, which could easily lead to losing changes Perhaps you don't consider this much to take in, but anybody who is going to be contributing is going to be doing in their spare time. Any hurdle is going to push people some other activity, or contributing to a project that doesn't require as much initial investment to start contributing to. Given that approaching the codebase is a challenge in and of itself, if we want to grow the contributor base, we should do whatever is practical to make contributing easier; which I think includes having a well-supported and monitored github mirror. > For comparison, setting up the build environment on Windows is a > multi-hour effort even on a fast machine and fast connection. Downloading > the initial repos is almost 3GB. I would think on the list of things > blocking contribution, these are more important hurdles, but of course not > easily addressable. > All of these are addressable and should be addressed in addition to other things. - A build environment is (in theory) only needed if you are making changes to C++ files. I hope (once the migration to taskcluster is done) to enable artifact builds <https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Artifact_builds> that don't require installing a build environment. - Git supports shallow clones that don't require donwloading the entire history, which is much smaller. Hg is also going to get shallow clone support in the medium-future. - If we have a github mirror, people can make small fixes directly in the browser, without needing to download anything. > In any case, even some Mozilla employees working on large firefox projects > use git for them, so why should we make it harder for a casual contributor > to work on thunderbird? > > > Conversely, why should we make it harder for people working on Mozilla > (and used to hg) to contribute the off patches to Thunderbird? > As I've said elsewhere I don't think we should change the source of truth, just add more options for people to contribute. Everything the currently works will continue to work. -- Tom

On 11-12-2017 02:17, Tom Prince wrote: > If we only people we want to contribute are people that make > "considerable" contributions, we won't ever get more contributors. > Most people who contribute will start with small fixes. There is some > discussion of this > inhttps://medium.freecodecamp.org/the-bad-practice-in-foss-projects-management-32f66c3515f9#da06. > I think this dismissive response to small contributions is not good > for the health of the project. I certainly didn't mean to imply small contributions aren't welcome, they sure are. > > In any case, I think you significantly underestimate the effort > required to install and learn a new version control tool enough to > contribute using it. Certainly the actual time to download and install > mercurial (from selecting the program to install to it being > installed) may only be 30s (on a good internet connection, but as you > point out the size of the mozilla and thunderbird repository will be a > larger issue in this case). But, there is also > > *  figuring out which program to install (is it `mercurial` or `hg` > or something else) > * figuring out how to clone the thunderbird repos > * figuring out how to get something out of the repo to submit as a > change > * dealing with the possibility that there exists commands with > identical names in git and hg that have opposite behavior, which > could easily lead to losing changes > There is for sure things that can be improved in our documentation for the process above. For people starting out, the few commands you need to clone create a patch are not that many. I don't have a strong preference for git or hg myself, I just think having unnecessary options is usually more confusing than it's worth, even if the intentions are good.  -Magnus

On 11.12.2017 22:42, Magnus Melin wrote: <snip> > I don't have a strong preference for git or hg myself, I just think > having unnecessary options is usually more confusing than it's worth, > even if the intentions are good. Didn't follow the whole thread, but just my 2cent: Considering the problems I had w/ when cloning the codebase (had put it aside for quite a while, no idea if it's better now), my vote clearly goes to git. IMHO, it's much easier to use, and there're also good hosting sites. Maybe we should consider cutting the history and some automatic mirror/importer for the moz-central part. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287