Merging XMPP SoC branch

Evan Schoenberg evan.s at dreskin.net
Wed Jul 11 12:27:40 EDT 2007


On Jul 10, 2007, at 9:19 AM, Richard Laager wrote:

> See below, plus the fact that Andreas is duplicating code that's in
> trunk because he's not aware of propagate (or I'm seriously mistaken).

Richard, could you clarify how Andy is 'duplicating code'?  Although  
I am not an SoC mentor (because I didn't have nearly enough time this  
summer to commit to that) I have been following his commits to  
im.pidgin.soc.2007.xmpp via the viewmtn RSS feed since Day 1, and I'm  
not aware of this duplication and would have spoken up if I were.  I  
don't believe he's been using propagate to keep his branch 'current'  
with im.pidgin.pidgin, but I fail to see how that is a problem.

If this *is* a problem, perhaps documenting whatever monotone  
practice regarding propagate you (or, more generally, we) are  
expecting would be good? Neither Andy nor his mentor Augie have ever  
used monotone before this summer, and I have never used it outside  
the context of Pidgin and libpurple.  I've read UsingPidginMonotone  
in detail, but know little of mtn beyond that; UsingPidginMonotone  
only discusses propagate as being useful for merging of two branches.

>> Note that I probably won't get any feedback from anybody as long as
>> this is hidden away in a branch.
>
> I was under the impression that SoC projects had mentors.
>
> (In case anyone is missing the sarcasm, I'm an SoC mentor.)

First off, Andy did many people a disservice with his strongly  
negative statement that he won't get any feedback, but I think many  
involved already know that he's is prone to writing like that sometimes.

He has gotten feedback from #pidgin, from this mailing list, from the  
XEP standards list, and surely from Augie (I'd be disappointed if he  
hasn't, but unless I hear otherwise explicitly I'm confident this is  
the case).  'anybody' in this case refers to people using his new  
code extensively - as can't really be done by just one or two people.

>
> Then again, I was also under the impression that SoC projects couldn't
> depend on each other to avoid situations like this.

I'd like to clarify about the statement of dependencies: None of the  
Adium SoC projects were set up in their original proposals to have  
interdependencies.  Students on various projects have just found that  
new specific components of their plans could best be implemented with  
the help of other students -- for example, Erik Beerepoot is working  
on improving group chat in Adium, and one of the aspects of XMPP in  
which Andy wants to work is XMPP conferences. There's clearly  
overlap... I think that coordinating development efforts like this  
for a limited slice of a project is a really good bonus learning  
experience about OSS development, and discouraging it would be  
counterproductive.

> I don't see why we have to take any action on this anyway... have  
> Adium
> track the branch until it's merge-ready. If it's merge ready now, then
> why wasn't it merged rather than having a discussion about merging it
> "early"?

We don't have to take action on this for Adium, no.  Adium could  
certainly propagate im.pidgin.pidgin to im.pidgin.soc.2007.xmpp and  
use that.  However, -if- the work so far is ready for prime time,  
merging now has the benefit of getting much of it into 2.1.0 for both  
use and further development efforts (by a larger community than just  
a single SoC student).

'early', as Andy mentions in his reply, is simply because the  
original plan was to merge SoC branches at some point after SoC is  
complete or just before that time.  It definitely could have been  
just merged immediately without any discussion... it's very odd to me  
to offer "If it were ready we wouldn't be having this discussion!" as  
an objection given the broadness of Sean's original question ("Is  
there objection to merging his code in early and letting him continue  
to work in HEAD?").

Cheers,
Evan
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20070711/126ad432/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://pidgin.im/pipermail/devel/attachments/20070711/126ad432/attachment.sig>


More information about the Devel mailing list