Development process

Thu Apr 8 03:25:10 EDT 2010

On Wed, Apr 7, 2010 at 12:02 AM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
> 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.

Yes, I know, but prpl features don't add API, sometimes they are added
at micro releases which causes to add new code => potential new bugs
on this releases as I stated on a previous email.

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

That's not 100% true, avoid having all that release branches would be
just a plus.

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

I have been thinking a little more about this and in addition of the
points I have explained on my last email. Being i.p.p the one from we
will get the next minor and every of us actively working on it allow
us to work a little more on new features (in my scheme) or API/modules
additions giving them a lot more testing without having bugfixes
sitting there until we feel like releasing the next minor (more on
this below).

The actual development uses i.p.n.m as a merge stuff + add API + test
new stuff but I feel like nobody actually uses this branch as his main
build (the one you use daily) so there is no much test done until we
feel like releasing a next minor and i.p.n.m is propagated to i.p.p.

Another problem with actual process is that when we propagate i.p.n.m
to i.p.p it's "hard" (as not as easy as before the propagation) to get
micro releases. So fixes for old code will sit on until the next minor
get released which actually takes a lot because we begin the testing
over new fatures/API at this point, not when they were added.

In the scheme I propose, we have three stages none of them constrained
by some schedule:

*After a minor release we start adding features from ready branches to
i.p.p, apply ready patches from trac. Do mayor code changes, cleanup.
And here I mean, changes on every module: libpurple, Pidgin, Finch,
bindings, plugins, and prpls Some projects call this stage "merge
window".

* After some time once that we feel like there is enough new code.
Start a testing stage when every developer can test, find and fix bugs
in new code.

* When we feel like releasing (hopefully not too far from the start of
the cycle) get a string freeze, translator do their work and then
release and start over.

At the same time this is done, bugs reported on trac over actual
released code can be fixed on i.p.next.release (or how you do want to
call that branch) and propagated regularly to i.p.p. If we manage to
find a non-painful way to make releases, this fixes over old code can
get out quickly, each 3 weeks or a month, the time you like.

As you can see, there is no need for string freeze on every micro
releases because major changes will be done on i.p.p, actually the
string freeze could be done in parallel with testing + bug hunt.

What will this bring to us?
Lot more testing to new code.
Cheap micro (bugfix) releases while all Developers are still working
on new stuff.
More reliable release process, being independent from actual development.
Potential contributors to know what's going on with the development.
This is important because this way we can attract more patch writers.
Packagers would love to have some kind of regular release schedule
instead of the erratic one we have.

Actually, this very scheme can be used without changes when the work
on 3.0.0 start.

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

Maybe we must find why the work just doesn't get done and if it's
because of how the project is managed change stuff to make it easy for
everyone.

What is the opinion of the rest of the developers?

Masca