Development process

Jorge Villaseñor salinasv at gmail.com
Tue Apr 13 15:07:42 EDT 2010


On Sun, Apr 11, 2010 at 3:25 PM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
> 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.

I guess this point get clarified below. I don't mean release when get
a new feature added. If some feature doesn't get into 2.7.0 it can
wait until 2.8.0 "merge-window" to get into i.p.p so this other
feature doesn't change anything on the process.

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

(this is not a rant)
The current process is very erratic and disrupted, there are no
focused efforts. There is no actual planning or organization at all.
As you said at the end of your email, most of you have lost interest,
there are some branches just sitting there without no one caring about
them, there is no answer when someone ask this list about some design
concerns. We must find a way to get people interested, get more and
more stable contributors. All this tell me that actually there is
something broke.

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

Freeze merges to i.p.p and adding too much code to it. Yes, the
majority of testing and fixing must happen when writing code, then I
guess it make sense to have this "testing/bug fix" stage small. I
think this still is a good idea to get the less bugs released (so
eventually the work on i.p.next.release would tend to zero, I'm
hopping).

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

There is no *need* for string freeze because translators work can be
done on the "string freeze" stage. Actually we can say that
i.p.next.release can be string freezed always because it's just a
bugfix branch so it's not likely to have string changes, or am I wrong
here?

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

I'm ok with that, they can keep fixing released bugs on
i.p.next.release. while the other developers (and new feature testers)
can use i.p.p.

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

Old bugs fixed on i.p.p is not a big issue, they can wait until next
minor, it's just a good idea to get that fixes on i.p.n.r. We just
must care about not adding new stuff to i.p.n.r to avoid the need of
plucking it to i.p.p and revert it.

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

That's why I'm trying to find a way to get things done the easiest way
so people have to use the less time to maintain pidgin. I'm not saying
my approach is the better one, I'm just trying to get some discussion
here so we all can find a better way to do stuff.

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

I have been thinking a little about this and I guess this process
allow us to get a little more focused effort on some stuff. As a
example, let's say we release 2.7.0 then we get some consensus on what
needs to be done to 2.8.0: merge X, Y ready branches, migrate every
deprecated gtk/glib functions to the now supported versions, Add patch
A, B, C, fix tickets I, J, K (this may be done with trac milestones).
Maybe this is enough for a release, then we all can focus on this few
priority topics and get it done for 2.8.0. The same way, when SoC ends
merge all work done that is ready in a new minor.

I would like to ask every developer what they think about moving the
process or keep the one we have now.

Regards




More information about the Devel mailing list