Development process

[John Bailey]

On 04/08/2010 03:25 AM, Jorge Villaseñor wrote:
> 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.

That's what I was getting at with my example of Gadu-Gadu privacy.  Something
like this that is an important feature could potentially be delayed months if we
have other stuff pending that's not quite ready for release.  As much as you and
I are of the opinion that distributions can deal with our releases when we make
them, we do have to have *some* consideration for it, as it's not really a good
idea to release 2.7.0 because feature X is ready but a bunch of other stuff
isn't, then just six weeks later decide we need 2.8.0 because the other stuff is
now ready.  It makes our lives more difficult and it makes packagers' jobs more
difficult.

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

But it is the immediately obvious benefit.  I guess I'm showing some resistance
to change on the potentially false belief that the current process isn't broken,
so it doesn't need fixing.  Maybe I'm wrong and it'll magically solve a ton of
problems, but I'm just not sold on it.

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

As a point of discussion, on the whole you're probably right with this
statement.  That said, I did use next.minor for its entire life as 2.7.0devel.
I did this intentionally so I'd be forced to keep it updated with respect to
i.p.p, and I think I'm largely the one who pushed for the merge back to i.p.p
after 2.6.6 was released.  During much of that time, it did feel like I was the
only person using the branch, until Daniel came in and started working on the
win32 changes.

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

Yes, and the current 2.7.0devel is causing a number of bug fixes to be held up.
 It's certainly frustrating, both for me and for the Gadu-Gadu users who are
complaining because 2.6.6 is bundled with an ancient libgadu that doesn't
support the new GG numbers over 17,000,000.

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

A merge window *does* sound like a good idea.  I'm not sure how well it will
work for us in practice, though.

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

So basically you're saying we decide how wide the merge window is, then freeze
merges to i.p.p after that window's expired, right?  Then we test and fix bugs?
 (To paraphrase Mark, shouldn't the majority of testing and fixing happen when
writing the 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.

Non-painful is a pipe dream, I think.  Less painful may be possible, but there's
no such thing as a painless release process.

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

Have you *seen* the amount of complaining we get when we cut releases without
string freezes?  Invariably at least some translators complain because they
wanted to make small tweaks to their translations but couldn't get them into the
micro because we didn't freeze.

> What will this bring to us?
> Lot more testing to new code.

In theory.  I'm going to bet that a significant portion of developers are going
to just switch from i.p.p to i.p.p.next.release (or whatever we call it) because
of not wanting to change the way things are done.

> Cheap micro (bugfix) releases while all Developers are still working
> on new stuff.

Again, just in theory.  I guarantee we're going to have some forgetfulness and
eventual crossing from one branch to the other that shouldn't (an old bug fixed
on i.p.p or something added to next.release that shouldn't be).

> Potential contributors to know what's going on with the development.
> This is important because this way we can attract more patch writers.

I doubt these proposed changes are really going to help attract contributors.

> Packagers would love to have some kind of regular release schedule
> instead of the erratic one we have.

Yes, they would, but again I'm not sold on this being something that can
actually work for us, or at least something that won't fall flat on its face in
a few months (at most).

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

As a partial explanation, I'm going to quote my own blog
(http://theflamingbanker.blogspot.com/2010/01/on-subject-of-bugs-or-help-wanted-and.html)
here:

  * We all have families that we’d like to spend time with. Many of us have
spouses/significant others, and a few of us also have children. Family is a
demand on our time that should never be ignored.
  * All (or almost all) of us have jobs.
  * We’re human too--we get burned out, experience stress, need to unwind after
work, etc.

Also, I'm sure a few of us have just simply lost interest.

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/20100411/da457c67/attachment.sig>