Patches
Ethan Blanton
elb at psg.com
Sat Apr 14 10:34:34 EDT 2007
Eric Polino spake unto us the following wisdom:
> I'm Eric, and I'll be working on Finch this summer under Sadrul.
Welcome. :-)
> I'm new to the idea of open source culture and have heard of several
> ways the projects like to have their patches submitted. I'm wondering
> what the acceptable way to do it here with Pidgin has been and/or is.
As a Summer of Code student, you will be given access to the monotone
repository, so you will be able to commit your changes (with
supervision from your mentor, at least at first) directly to the Pidin
monotone codebase. Depending on your project's impact, you may be
working on a branch while this happens, rather than on trunk; Sadrul
and the other developers will help you decide which is most
appropriate. (It looks like your functionality is core enough that
you will probably want to use a branch, and merge your changes over to
trunk as they become stable.)
> I read the UsingPidginMonotone page on the wiki and it seems odd that
> you would allow commits from developers just like that. Who can
> commit? Who can merge branches? I've used mercurial a bit in the
> past, so the idea of DVCSes isn't new to me. In fact, on my local box
> I've copied my monotone repo to another folder where i've put it under
> Hg for both familiarity and the built in quilt features, called MQ in
> Hg.
Perhaps UsingPidginMonotone should be clarified, if I understand your
question. With monotone, anyone can commit to their local repository,
and there is nothing we can do to change that. In fact, we *like*
that! However, in order to be able to push those changes to the
monotone repository on pidgin.im, you must have an approved key.
Changes committed by non-developers can be shared with whomever those
developers like, but they cannot be uploaded to pidgin.im to be
part of the official Pidgin tree without the assistance of a core
developer with write access to that repository.
> Which brings me to another question. I've been told that the
> submission of a patch that does more than one fix is a big nono. So
> the advent of quilt and patch stacks has helped in working out those
> issues. Hg has that built into it's VCS so that MQ is aware of the
> versioning and works very nicely with merges. I had a friend of mine
> explain it well to me,and it seems really slick. Anyhow, the point
> is, how does monotone deal with that? Or more importantly how do you
> deal with that in Pidgin? What has been your method of dealing with
> this issue?
Quilt is overkill for the sort of patch splitting that one *normally*
needs to do on a project like Gaim. There are certainly cases where
it may be beneficial, but we actually believe that a DVCS like
Monotone will reduce those cases, due to the fact that branches and
"private" commits become so much cheaper and easier, or even possible.
The monotone crowd has discussed quilt functionality in the past, and
I'm not sure what the results were -- you can check the mailing list
archives and wiki at monotone.ca for more information.
(Patch stacks become a much bigger deal for, say, the kernel, where
you have external developers making large changes, or internal
developers making large changes which go through a long review before
release, requiring continual integration with various versions for
compatability and bug testing. With Gaim, these things are not a real
problem -- external developers very rarely submit large patches with
divisible requirements, and more earth-shaking changes are free to be
integrated into the main tree.)
Ethan
--
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20070414/ce254d5a/attachment.sig>
More information about the Devel
mailing list