Development process

[Jorge Villaseñor]

2010/4/6 Sadrul Habib Chowdhury <imadil at gmail.com>:
> * 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>:
>> >> I'm not proposing to switch to this very process neither kernel like
>> >> process. But I guess we can adapt some of this ideas to pidgin's
>> >> actual development process to be less erratic at releasing.
>> >
>> >> 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)
>> >
>> > This mostly sounds good to me... I worry that strictly adhering to
>> > these guidelines could make development more cumbersome and thereby
>> > deter development.  But yeah, I totally agree with these ideas.
>> >
>> > --Mark
>> >
>>
>> 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.
>>
>> 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.

Why it is complicated? The mayor change here is that the main
development branch would be i.p.n.m instead of i.p.p.

> 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?

Maybe I didn't expresed well when I said "feature branches" I mean the
large ones, just like we have right now with the difference that the
merges get over i.p.n.m.

Yes it's solving some issues:

1) There are some old branches that no one is working on, most of them
were merge ready last time someone commited it but never merged, now
they need to be updated before merging. Some other are patches that
need a little improvement or they were just almost ready and only need
someone to give it a little love before being released. This was the
case with X-status, it was sitting there for months until malu
darkrain and rekkarnoyo took it, updated it and merged (in 10 days) it
in main development branch then every one helped a little to clean it
up and now it's ready. This process would be quicker if this features
doesn't need to wait until we decide release a minor.

2) New features => new bugs. Getting every feature waiting for a minor
release would help to make clear to (libpurple and pidgin/finch) users
and packagers when they can expect new features/bugs (minor) or just
bugfixes (micro). This also allow us to have more testing before
releasing new features and have any bug reported after the release, be
fixed in a micro. This can easily be done with this scheme.

3) When there is a vulnerability release it could be done right over
i.p.p even if we are planning a minor bump instead of the need to
branch from the last release tag and backport the bugfix. So emergency
releases would be really easy and straight forward.

4) There are some fixes that sit on i.p.p long time before the branch
is release ready (because of new features or stuff). This bugs can get
out quicker if we release more frequently.

>> 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.
>
> I think i.p.p has been relatively stable most of the time recently; at
> least, I am pretty sure the stability of i.p.p hasn't been an issue for
> delaying releases in a very long time. Lack of developer time (and
> coordination, and interest?) is a far greater issue for releasing
> frequently, in my view. (For example, right now, I believe i.p.p is
> relatively stable, but have we considered when to release 2.7.0?)

It's a interesting point, what is the main reason we are not releasing
frequently? I'm not sure *this* is the main reason, but sure I think
it is a way to make it easier.