Development process

[Jorge Villaseñor]

2010/4/13 Sadrul Habib Chowdhury <imadil at gmail.com>:
> * Jorge Villaseñor had this to say on [13 Apr 2010, 14:07:42 -0500]:
 [snip]
>> 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.
>
> Not necessarily. Pidgin is a fairly large project, large enough that
> it's not exactly trivial for Random Joe to pick up the code and start
> hacking on it. This I think is fairly normal. But we do have people who
> get through the initial learning curve and stick around for long-term
> contribution. We also regularly have patches from casual patch writers.
> For example, I see 11 additions in our COPYRIGHT file between 2.6.6 and
> 2.7.0

That's nice. I haven't noticed that much patches from contributors.
Maybe it could be a good practice to force commiters to always add a
"patch from foo". I know most of the time everyone does, but maybe
some times it's forgotten.

[snip]

>> 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?
>
> Sometimes it's necessary to rephrase some texts to make things clear. An
> existing string might itself be a bug, a new feature might require new
> strings etc. (I absolutely don't want a only-bug-fixes-in-micro-versions
> strategy), so we do need a 'string freeze' before release.

I said there is no *need* ;-) we can and it might be a good idea to
have a string freeze on micro releases, still I think the string
changes could be fewer on micro than macro releases.

>> 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).
>
> As I have said above, I think it is a good idea to have a merge window
> after a release. (We hardly ever change the gtk/glib version
> requirements, so that's really not an issue)

I listed gtk/glib changes because we are changing gtk/glib version
requirement on *this* release. As an actual example, no like a usual
thing to do.

> My understanding from 'not a rant' quoted above, and from what you have
> been saying is, and I agree with this wholeheartedly, what we do
> need for more frequent releases is better coordination among the
> developers regarding the releases, e.g. we can have a discussion about
> the next release soon after a release. This discussion could include
> what branches can be readily merged with i.p.p, which branches need more
> testing and could use more developer work, how long the merge window
> should be etc. From this discussion, we can also decide whether the next
> release should cause a bump in micro or minor (or major!)

Agree.

> I disagree on the point that we need to change how we are using branches
> etc. We need to have a stable release process, and whatever process we
> decide on I expect would be compatible with our current development
> process.

I proposed the branch change because is the way I found it would be
easy to manage stable/bugfix code and new development/next minor
releases. If you have any other easier idea I'm ok.

[snip]

I guess we all agreed on merge window and a stable releases. Now we
need to find a way (maybe a different one than the one I proposed) to
get this process working.