This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC Release Status (2003-08-03)


On Monday, August 4, 2003, at 11:28 PM, Mark Mitchell wrote:
> > Anyhow, we certainly shouldn't change old, closed bugs.  I just want 
> > to keep
> > people from marking new bugs as targeted for 3.3.1.

On Mon, Aug 04, 2003 at 11:41:00PM -0400, Daniel Berlin wrote:
> I can add this feature if you guys really want it, I just see it as a 
> "don't do that" type thing that we're all smart enough not to do.  Why 
> would a developer target a new bug at an old release?
> Remember, users can't target bugs to milestones.

I've already spent time changing incorrectly set target milestones, and
I can change them again if need be.  We don't have to make the tools force
us to behave; we can use peer pressure (after all, all of us with CVS
write access could do whatever we want, and we don't).

I don't think we need to ask Daniel to do anything here.  All we need is
for the folks with Bugzilla write access to understand the rule.

In any case, for every rule there's an exception: what if we discover,
after the release, that some open bug was actually fixed in 3.3.1?  Why
*not* set the target milestone to 3.3.1 and add it to the list of fixed
bugs?

My goal here is to get to the point where I can do the release notes with
one Bugzilla query.  Dream on, of course; I still have to distinguish bugs
that arose during development and never appeared in any release, as well
as do a sanity check, but if I can at least get a superset, that will save
a lot of work.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]