Re: [Usability] Moving the HIG



On Tue, 2007-03-20 at 15:08 +0000, Calum Benson wrote:
> On Fri, 2007-03-16 at 13:25 -0500, Shaun McCance wrote:
> 
> > I would like to propose that we move the HIG from its
> > current very buried location into gnome-devel-docs.
> > The Usability Team will still have complete control
> > over the content of the HIG.
> 
> Sounds good to me.

Excellent.  Apparently, we can't do a copy/move with
full revision history across modules in SVN (ugh), so
I'm going to talk to our admins about what it would
take to do that.

Another thing I'm trying to figure out is what to do
about bugzilla.  It kind of sucks not having bugzilla
match the SVN modules and released tarballs.  But you
guys are making good use of components under the HIG,
and you'd lose that if the HIG were just a component
of gnome-devel-docs.  I wish bugzilla's categorization
were more flexible than a strict two-level thing.

> > Since I would like to make actual releases of this
> > module, the content should be in a releasable state
> > at release time.  Of course, the Usability Team can
> > always make branches for more long-term changes.
> 
> Hmm... wouldn't the stable version be on a branch, and development on
> trunk, as with the bulk of the source code?  I'm bound to get confused
> otherwise :)

Generally, we make stable branches after the first
stable release.  Sometimes we make them much later,
depending on development plans and such.  So trunk
may be stable at times, unstable at others.  We'll
do stable branches in gnome-devel-docs, mostly for
the benefit of translators.

Sometimes, though, we make branches for long-term
unstable development work.  See, for instance, the
yelp-document branch of Yelp.  It's a retooling of
the internal API in Yelp, and it's taken a while
to come to fruition.  If we had done that work on
trunk, we would have effectively blocked releases.

So what I meant was, if you've got some massive
ongoing changes to the HIG that won't be completed
by the 2.20.0 release date (tentatively September 5),
then you should feel free to make a branch for that
work, so that trunk is releasable on time.

--
Shaun





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]