From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5809 invoked by alias); 16 Oct 2009 23:37:18 -0000 Received: (qmail 5799 invoked by uid 22791); 16 Oct 2009 23:37:16 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS,URI_BLOGSPOT X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Oct 2009 23:37:11 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 398302F78004; Sat, 17 Oct 2009 00:37:09 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwrJpTo8y6v9; Sat, 17 Oct 2009 00:37:01 +0100 (BST) Message-ID: <4AD903A4.7000800@ecoscentric.com> Date: Fri, 16 Oct 2009 23:37:00 -0000 From: Alex Schuilenburg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jonathan Larmour CC: ecos-maintainers@ecos.sourceware.org Subject: Re: hg conversion notes and summary References: <4AD32231.5060506@ecoscentric.com> <4AD5E3C1.10700@ecoscentric.com> <4AD7F4D3.6010008@jifvik.org> <4AD8405D.1010205@ecoscentric.com> <4AD87EBA.5000603@jifvik.org> In-Reply-To: <4AD87EBA.5000603@jifvik.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-maintainers-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@ecos.sourceware.org X-SW-Source: 2009-10/txt/msg00005.txt.bz2 Jonathan Larmour wrote: > Alex Schuilenburg wrote: >> Jonathan Larmour wrote on 2009-10-16 05:21: >> >>> Alex Schuilenburg wrote: >>> I also see an hgext dir with the same date, including bugzilla.py, >>> notify.py. >>> >>> If we do make a decision to move to hg, we'll need to know if there >>> would be any problems using that version, and so whether I'd need to >>> agitate towards moving sourceware to something more recent (which >>> isn't straightforward as other projects use hg too). >> >> It would be worthwhile upgrading IMHO to pick up the current features >> and fixes - the only requirement is python 2.4 or above. > > Given it's used by other projects, I'd have to give a good reason for > potential disruption. If there is something concrete I could mention > (bug X will make it hard, or it is missing important feature Y) that > would be useful. Based on what you said below about shell access, I would not bother with the upgrade now. I was only thinking about those maintainers who did not want to run hg on their local machine. If sourceware were to only be used to serve the repository (push/pull), I dont see a need to upgrade. I'll take a look through the changes anyway, just in case.. > >> There are no problems I know of upgrading - I upgraded from 1.0.2 to >> 1.3.1 midway through our internal CVS to hg conversion and in fact >> benefited from one of the bugfixes (hg reports a file as modified when >> it is not - simple to recover, but annoying when you do a major merge), >> but it does not matter really what sourceware is running if it is only >> handling push/pull since I would assume any merge work would be done >> offsite on sombody's own machine and their own updated version of hg. > > Shell accounts on sourceware are usually highly restricted, so yes. OK, that could simplify things. > > >> That after all is what DRCS is all about ;-) The only local sourceware >> issues may be bugzilla, notify or the hgwebdir.cgi which have seen >> fairly useful improvements since 1.0 (including git plugin and git views >> so those got fans still get the same look and feel, should you be so >> inclined). > > Would the bugzilla plugin need to live on sourceware or on the > bugzilla machine? Not on the bugzilla machine, and given restricted shell access, not on sourceware either. First, let me clarify things. 1) The bugzilla hg plugin is great for allowing you to track changesets and bugfixes/contributions. What it does is add a comment into a bugzilla bug if that bug has been referenced in the changeset comment (according to some predefined criteria). So, for example, if you are committing a fix for a bug or a contribution submitted as a bug and have something like "Fix for bugzilla 1000123", or "Integration of contribution in bugzilla 1000123" within the changeset comment (CVS log equivalent for newbies), it will add a comment to bug 1000123 according to whatever template you specify. For example: http://hg.mozilla.org/mozilla-central/ shows bug references, and https://bugzilla.mozilla.org/show_bug.cgi?id=481775#c17 shows a minimal comment while http://developerbugs.linuxfoundation.org/show_bug.cgi?id=1443#c1 shows a more descriptive comment Notes on implementation: The hg-bugzilla plugin does this using email, sending email to the bugzilla email interface email_in.pl (which allows you to add comments, etc). The changeset will obviously not be visible though until pushed into the main repository (unless of course the commit is made on sourceware). Similarly you can set up your hg web interface to point to the bugs on bugzilla (as per 1st url example), but that will most likely require somebody to set this up on sourceware. 2) The hg email command (patchbomb extension) is a way changesets can be packaged and sent in a standard form. This can be to individuals for review, mailing lists, a single file attachment to a bugzilla bug or even the email_in.pl interface. For an example on how one project is does this, see http://libvirt.org/CIM/patches.html. It gives a formal specification to contributors on how to submit patches to the project using the hg patchbomb extension. If you choose bugzilla for submission of patches or contributions, you would simply use the -m option of "hg email" to create a single mbox file that would be added as an attachment to a bug report. That would be the contribution. If accepted, a simple "hg import" of that file will apply the contribution. How simple is all that? 3) The direct submission from a contributor into bugzilla I mentioned setting up is simply a morphing of (1) and (2). It is not a standard feeature and would need to be written (hence my offer), but is very simple IMHO. It will probably be the most useful to regular contributors, but equally could be set as the standard way to contribute. It would simply require a modified email_in.pl interface (I have contributed to this interface in the past, specifically addiing attachments to bugzilla bugs, so I have a clue) to suck up hg patchbombs and convert them into patch attachments within a single bugzilla bug report. The 0'th email (the description) becomes the description, and the [PATCH M of N] emails become the attachments. Or it could collate the all changesets into a single "hg email -m" style attachment. Not sure which is best, probably the latter for simplicity of application, but equally the former makes it easier to comment on individual changesets. The morphing is simply the use of the bugzilla login info needed for the bugzilla plugin to provide site and bugzilla security (otherwise we end up opening bugzilla to spam). For a description of the patchbomb extention, just run "hg help email" on a system with it installed (it is distrubuted as standard and enabled on our two main servers). > > You can defer answering till after a decision's been made :-) I preferred now while it is all still fresh ;-) BTW, I would like to point out a couple of high profile projects using hg: Open Office: http://blogs.sun.com/GullFOSS/entry/openoffice_org_development_switches_to FireFox: http://hg.mozilla.org/mozilla-central/ Google Code: http://googlecode.blogspot.com/2009/04/mercurial-support-for-project-hosting.html Python: http://mail.python.org/pipermail/python-dev/2009-March/087931.html Linux-HA: http://hg.linux-ha.org/ NetBeans: http://wiki.netbeans.org/HgHowTos OpenSolaris: http://opensolaris.org/ XEmacs: http://www.xemacs.org/ XEN: http://xenbits.xensource.com/ to name but a small few. A bigger list can be found at: http://mercurial.selenic.com/wiki/ProjectsUsingMercurial -- Alex Schuilenburg Managing Director/CEO eCosCentric Limited www.ecoscentric.com