Development process

[John Bailey]

On 04/06/2010 03:25 PM, Sadrul Habib Chowdhury wrote:
> * Jorge Villaseñor had this to say on [06 Apr 2010, 13:22:21 -0500]:
>> 2010/4/6 Mark Doliner <mark at kingant.net>:
>>> 2010/4/6 Jorge Villaseñor <salinasv at gmail.com>:
>>>> mayor: API/ABI breakage, remove deprecated stuff, remove public
>>>> modules,etc  (done once in a while)
>>>> minor: API aditions, libpurple/pidgin feature aditions, prpl feature
>>>> aditions (done each time we have some new features ready)
>>>> micro: pidgin/libpurple/prpl bug fixes, security releases. (done when
>>>> there are bug fixes to be released)

For the record, *most* of our current development follows this model already, as
most of our feature additions require API of some sort to be added.

>> Talking with elb, sadrul and kmstage in c at d.p.i I guess I need to
>> clarify that I don't propose to release minor once a feature is added,
>> but to delay features to minor releases.

Delaying all features to a minor point release can (and almost certainly will)
be a painful policy.  Obviously some features *should* wait for a minor release
even if they don't require API--for example, enabling VV on a new protocol
should wait to allow more testing, cleanup, and debugging.  But if, for example,
someone comes along with a patch to do something like make the gadu-gadu prpl
use libpurple's privacy facilities, I'm not going to want to make that wait
potentially months for a minor version.

>> A way to avoid detering development I suggest to have i.p.n.m as a
>> main development branch, in this branch we merge every merge-ready
>> feature branch so all developers can help to finish the cleanup and
>> prevent regresions. Bugfixes get applied to i.p.p which must be
>> propagated to i.p.n.m at least every week so our development branch
>> have every fix done.
> 
> This sounds unnecessarily complicated to me.
> 
> Currently, for large-ish features (code-wise), we use separate branches
> (e.g. for the X-status stuff), and merge with i.p.p (or i.p.p.n.m) when
> they are considered reasonably complete. We use the i.p.p.n.m branch
> for changes that add API, but aren't quite release-ready. I believe this
> is working fairly well for us.
> 
> I guess what I am asking is, is there an actual problem that your
> proposed scheme solves?

After talking with Jorge this evening, I believe what he proposed isn't actually
what he means.  More appropriate for what he actually wants to accomplish would
be for us to have an always-present i.p.p.next.release (or similar), abandon
i.p.p.n.m, and use i.p.p for what next.minor is currently used for.  In this
model, i.p.p would be propagated to next.release when it's ready for string
freeze and release.  i.p.p should still be the main development branch, with
bugfixes going into next.release and the divergence of the two branches
eventually being resolved both on a regular schedule and at each point where a
minor release would happen.

The problem he's trying to solve is having a bunch of release branches.  I'm not
entirely convinced it's a major enough problem to worry about, though.

>> As kmstage said in c at d.p.i we can manage to get a 3 weeks release
>> cycle if we have a stable branch, in this case it would be i.p.p so it
>> would be easy to make stable releases.

We did 3-week cycles for the infancy of the 2.x series.  It worked well, but
with our current lack of time and interest, we're going to end up with 3-week
periods where there are no changes at all, which will inevitably throw off our
entire schedule.

Perhaps what would be more useful would be if I would act like a project manager
and nag people until stuff gets done.  I've been reluctant to do this because 1)
I'm already a nagging, whining pain in the rear so no one would notice; 2) I
don't feel that I have the authority; and 3) it feels futile given how few
active people we have right now.

John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20100407/d5b1d73f/attachment.sig>