Bugzilla maintenance

Matthew Burgess matthew at linuxfromscratch.org
Tue Jul 13 12:43:03 PDT 2004

On Tue, 13 Jul 2004 14:21:55 -0500
James Robertson <jwrober at linuxfromscratch.org> wrote:

> Matthew Burgess wrote:
> > On Tue, 13 Jul 2004 11:48:54 -0500
> > James Robertson <jwrober at linuxfromscratch.org> wrote:
> > 
> >>I changed and removed the CVS version to SVN for all bugs for all
> >>products except LFS.
> > 
> > James, would you mind adding a 'testing' version to the LFS product
> > too, so we can track bugs that are reported against that branch?  By
> > and large such bugs will affect SVN too, but when fixed in 'testing'
> > they can be merged upstream.  Admittedly, when we start using the
> > 3-tier setup properly I'd imagine we should be doing the reverse
> > (fixing on trunk and then backporting to the testing branch).
> > 
> Sure, before I do so, let me make sure I am on the same page as you.
> Stable releases get a number (e.g. 5.1.1)
> Testing (BRANCH) never gets a number and is "known" in BZ as TESTING
> Unstable (TRUNK) never gets a number and is "known" in BZ as SVN

That's how I envisaged it, yes.
> We then "track" bugs for all three tiers this way. Bugs in TESTING can
> be closed and patches uploaded to TESTING and SVN for the commit.  if
> a bug is for a named STABLE version number, we can then upload the
> patch to all three if necessary.
> Is that right, or did I get my directions reversed?  Still learning
> this whole 3-tier deal.

I think that's about it.  Essentially, we can never guarantee that a bug
will be reported against the "correct" version of the book.  What I'd
like to see is people reporting bugs against the fastest moving target -
i.e. unstable.  A bugzilla maintainer/overseer then looks at the bug and
determines how far down the cycle it affects us.

It may be that the page containing the typo or whatever hasn't been
involved in a branch to 'testing' yet, in which case it obviously only
affects the'unstable branch'.  A fix is committed as and when it's made

In the event that the area of the book that contains the bug has already
been branched into the 'testing' tree, then the fix is first applied to
'unstable', then backported to 'testing'.  It may be that the same fix
applies cleanly to both tiers, in which case fixing both tiers at the
same time would probably be the most sensible approach.  In fact this
should be the most common situation.  I believe this is the way that at
least some open-source projects work, in particular GCC.

Now, it's also possible of course that your average Joe User just got
pointed to LFS from /. & found a typo in the last stable release. 
Telling him to check out the unstable/testing tiers aint going to go
down too well, and we run the risk of losing valuable bug reports that
way.  So, we have to be prepared to be able to merge changes back
upstream from a stable branch too.

I don't see this as a particular problem for bugzilla though - as long
as it "knows" about the different branches and stable release versions
so anyone is able to report a bug against any of the 3 development lines
at any time then I think thats sufficient.

Hopefully this ramble hasn't confused you any more than you already
might have been :)



More information about the website mailing list