Development process

[Sadrul Habib Chowdhury]

* Jorge Villaseñor had this to say on [13 Apr 2010, 14:07:42 -0500]:
[snip]
> >
> > 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,

It could be 'some', I doubt it's 'most'.

> there are some branches just sitting there without no one caring about
> them,

Did you have any specific branch in mind? For the current branches, for
example, I think some are waiting for 3.x, and some are prpl-specific
that are actively being worked on (and some I think can now be
suspended).

> 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

[snip]
> > 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).

A 'merge window' sounds like a good idea to me too.

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

[snip]
> 
> 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)

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

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.

Cheers.
Sadrul

> 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