Re: Proposal: Graphics2D rewrite branch

[Mark Wielaard]

Hi,

On Wed, 2005-12-07 at 12:05 -0700, Tom Tromey wrote:
> >>>>> "Tom" == Thomas Fitzsimmons <address@hidden> writes:
> 
> Tom> I'd like to propose a new branch in the GNU Classpath CVS repository:
> Tom> graphics2d-rewrite.  Patches to this branch should be sent to
> Tom> address@hidden with a subject line prefix of [g2d rewrite].
> Tom> Commit policy is the same as GNU Classpath trunk.
> 
> I say go for it.

Yes, if you think you need a branch for this rewrite please do (call it
something descriptive like cairo-graphics2d). I can see that if you want
to just phase out GdkGraphics and always use a new setup around
CairoGraphics2D that it might be nice to have a branch to not disturb
the work of others. But as said by some others if at all possible do the
work on the trunk. That does make it easier for others to follow/help
out.

> Furthermore I think we should adopt gcc-ish branch rules.  These are
> pretty reasonable and have proven to work well in practice.  Namely:
> 
> * Any Classpath developer can make a branch for any purpose.
>   All branches ought to be documented somewhere, so we can know which
>   are live, who owns them, and when they die.  I don't know where we
>   would put this though (suggestions?)

I'll create a page in the wiki
http://developer.classpath.org/mediation/ClasspathBranches

> * Some rules can be changed on a branch.  In particular the branch
>   maintainer can change the review requirements, and the requirement
>   of keeping things building, testing, etc, can also be lifted.
>   (These should be documented along with the branch name and owner if
>   they differ from the trunk.)
>
>   Requirements for patch email to classpath-patches and for paperwork
>   *cannot* be lifted.

And you should not see it as "private" or "may be broken at random
times". It should be as much as possible something that you work with a
team on (and if there is no team - yet - then there is nothing as bad as
having a completely broken build to get others to help out).

> * Merges from the trunk to a branch are at the discretion of the
>   branch maintainer.
> 
> * A merge from a branch to the trunk is treated like any other patch.
>   In particular, it has to go through review, it must satisfy all the
>   trunk requirements (build, regression test, documentation).
> 
>   This rule prevents folks from working around trunk rules by making
>   a branch :-)

These rules sound very good. I will add them to the Hacking Guide.

>   There may be additional timing requirements on merging a branch to
>   the trunk depending on the release schedule, etc.  For instance we
>   may not want to do a branch merge just before a release.

Good point. I believe we do communicate very well on the mailing-lists.
So I don't think this will ever be a problem. But the "release
master" (which seems to be me atm, although we never officially created
that role) should have a veto in the last few weeks before a stable
release for any branch -> trunk merges.

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part