Merging XMPP SoC branch

[Ethan Blanton]

Chris Forsythe spake unto us the following wisdom:
> Ethan Blanton wrote:
> >This isn't a "should have been followed" thing, really, and it's not
> >at all about tricky version control checkin-fu.  It's simply a benefit
> >of having a capable DVCS.  (The propagate discussion, elsewhere in
> >this thread, *is* sort of about checkin-fu, but it is likewise simply
> >a benefit of having a capable *VCS*, no D required.  Subversion really
> >is That Bad, which is, I suspect, why no propagates were performed --
> >anyone who's been scarred by trying to actually merge with subversion
> >(or CVS) would certainly avoid it like the plague.)  The point of a
> >DVCS is that any developer can sync with any other developer, at any
> >time.  This means that Andreas and Augie could set up a rendezvous
> >server on one of their boxes (or simply pass a database with the new
> >revisions, or whatever) and work between themselves, without involving
> >pidgin.im, or that Andreas could proxy revisions into the pidgin.im
> >database on behalf of Augie.
> 
> Yes, but none of this says how you guys want to do things in a 
> documented way of some kind.

I think there's a conceptual gap here -- this part of the process
isn't something which needs to be documented as "this is how Pidgin
development works", at all.  Andreas pushing revisions which were
created by Augie (for example) is exactly the same as Andreas
accepting a patch from Augie and committing it, only with better
change history.  Obviously Andreas is free to accept patches from
anyone he chooses, and by extension he's free to push revisions from
arbitrary individuals, as well.

> >Ideally, as time goes by, many of our contributions would be taken
> >directly from third-party developers by way of monotone, and simply
> >pushed to the public repository (probably with an approval, which is
> >just a certificate binding a revision to a branch, in this case by a
> >known developer).
>
> For Adium we wrote up how we want patch contributors to submit patches, 
> that might be useful for you guys to do the same thing.

We have a TipsForPatchSubmissions wiki page; it currently recommends
'mtn diff', which is roughly equivalent to pulling revisions from a
contributor in terms of change history, but somewhat simpler for the
casual contributor (no need to set up a server), at the cost of losing
the key history (note that monotone allows the author history to be
otherwise preserved).

> >If there is anything out of this discussion which could be usefully
> >added to UsingPidginMonotone[1], someone should certainly add it -- I
> >created that document with enough help to get people started, and the
> >intent that, as people found tricky things or useful things, they
> >would share them with other developers.  (Which is why it's on the
> >wiki, and not a static web page.)
> 
> It'd be nice if the documentation sent in the previous email could be 
> added to the documentation (of course, reworded and all that) so that 
> others don't fall into the potential pitfall here.

I'm not sure, really, what you're asking for here.  The documentation
would say "use Monotone in a reasonable way".  Unless I'm missing
something, everything in this thread is covered in the monotone
tutorial on monotone.ca or in 'info monotone'.  That said, if *you*
see something useful, please add it to the wiki, or specify more
concisely what it is, and I will do so.  (Because it all seems like
trivial DVCS operation to me, I'm obviously not a good judge of what
to change.)

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/20070714/84fa7808/attachment.sig>