Re: Lets get branches names right this time (was: Re: Proposed release process/plans)
- From: Chema Celorio <chema ximian com>
- To: Bill Haneman <bill haneman sun com>
- Cc: Gediminas Paulauskas <menesis delfi lt>, Havoc Pennington <hp redhat com>, desktop-devel-list gnome org, gnome-hackers gnome org
- Subject: Re: Lets get branches names right this time (was: Re: Proposed release process/plans)
- Date: 13 Jun 2002 15:02:48 -0500
On Thu, 2002-06-13 at 12:39, Bill Haneman wrote:
> On Thu, 2002-06-13 at 18:38, Chema Celorio wrote:
> > On Thu, 2002-06-13 at 12:27, Bill Haneman wrote:
> ...
> > > The problem with this scheme is that 2-0-0 is "two branches removed"
> > > from HEAD, which is a significant problem in that important patches
> > > (i.e. for stoppers) have to be committed to three places, and ordinary
> > > bugfixes to two places (i.e. 2-0 and HEAD). That's a bit burdensome...
> > > which is why I propose to hold new features until 2-0-1 branches, or
> > > else put them on their own branch.
> >
> > Yes, the problem here is that each module is different. It is hard to
> > say to hold new features for all modules, they are in different
> > development cycles and stability (I'm thinking libgnomeprint).
>
> OK;
>
> Does anyone have an issue with me using gnome-2-0-0 for
> 2.0.0-release-only code, and continuing to use HEAD for 2.0.1 until it
> enters a "deeper" freeze? That way at least the branch names for the
> actual release candidates match up.
I do.
See, i don't have a lot of libgnomeprint bugs right now that are fixable
in a 2.0.1 timeframe. We (1) disabled multiple printers, that takes care
of a lot of the current problems, the gpa stuff is a lot simpler with
one printer. (2) We only have a PS backend. And API additions are not
2.0.1 material for adding new features, even if the API additions are
small.
I am starting to think that gnome-print is different from the rest,
because it was very late for the gnome 2.0 cycle. So in summary: the low
number of fixable bugs is mainly because we used only a small subset of
features.
My short term plans for gnome-print are not 2.0.1 releasable material
given the general idea of stability and freezness that the rest of the
platform is aiming for.
Or, if you think libgnomeprint[ui] is buggy, please bugzilla it to prove
me wrong ;-). But nobody is arguing that it needs lots and lots of love,
it does.
On a different note, it seems to me that we are trying to enforce
stability by playing with the branching strategy. I.E. Don't allow
people to have a HEAD branch where they can do crazy stuff so that they
keep fixing bugs only and not new features.
regards,
Chema
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]