This is the mail archive of the ecos-maintainers@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: hg conversion notes and summary


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]