Re: bugzilla practices

[Roland McGrath <roland at hack dot frob dot com>]

> Those would be overlapping classes.

Sure.  But it's the cases of a person in one and not the other that's
relevant to the rationale I gave.

> Yes.  Or encourage people to get involved, anyway, even if not explicitly 
> recruiting to a specific role.

Of course.  I meant to suggest that this is as perhaps the most common
appropriate first role for a new person.

> Depending on what the triagers do it's also open to people who aren't able 
> to complete copyright assignments for whatever reason.

That's a good point.

> Reasonable, though we need an understanding of what's meant by 
> user-visible.  (Various of my sys/*.h -> bits/*.h changes fixed problems 
> of some SPARC headers not having been updated for API changes in the main 
> header - that could have affected any users trying to build with the 
> particular API that hadn't been added to the SPARC versions.  Does that 
> count as user-visible?)
> 
> >    If someone just sends a patch cold to the mailing list, we should get it
> 
> A patch for a bug, that is, as opposed to a cleanup or new feature.

Yes, for "patch" I could have said "fix".  But I think it's not a bad idea
to have bugzilla items for new features too, though certainly less necessary.

> I only found when adding to the procedures that some suggestions of mine 
> from 2009 had got on the page.  I marked them as possibly not current.  I 
> think Carlos has sorted out how to handle Bugzilla use after branching - 
> but how to use Bugzilla to work out whether we are ready to branch and tag 
> is less clear, and that's what my suggestions from 2009 were more about.

Those are two separate issues, both worthy of coherent policies that people
understand.  I think the former is more pressing, and I still don't know
the story there (though I haven't scoured the wiki thoroughly).


Thanks,
Roland