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