Re: Anyone recognise this fixed bug (subtext: where is the bug DB?)

[email protected] (Richard Foley) Tue, 18 Jul 2000 13:44:33 +0200
Newsgroups perl.bugmongers,perl.perl5.porters
Organization RFI
Message-ID <[email protected]>
Alan Burlison wrote:
> 
> > email addresses (the cc list?) of the people who are also 
The cc list is being maintained for all bugs.  
When the status of a bug changes, do all on the cc list want to be notified 
(plus admins), (not p5p), or only when the bug is closed?

> As far as who can change the state of bugs - I think the person who
> raised it should be able to close it as 'not a bug' in case they raised
> a bug in error, 
The originator can now (hopefully) admin the bug.

> register initially to get access to the system.  In fact you might be
I hope the autoregistration feature will work :-) -> [email protected]
If it fails for any reason it should mail all active admins, who can then take
appropriate action.

> I also think a bugfix should have to be logged and given some sort of
> patch id before a bug will be marked as closed.  That way the pumpking
> stands some vague chance of figuring out what was fixed by whom and
> when.  I've always thought that the current mechanism of just firing a
> patch at p5p and hoping it sticks is a bit hit and miss.  I am in awe of
> the pumpkings who manage to wrest some order from the apparent chaos.
We need to discuss this patchID a bit:  
Should it be a relation between ticketid and fixed_in_version
(5.6.0.2_p01_20000321.001)
Or should it be an unique (non-incrementing) ID?  (p_235354532)
Or version_unique_patchid (5.6.0.3_45151)
Or is there currently a standard patchID we can use that I don't know about?

> below.  Lots of this happens already informally, but if p5p are serious
> about lowering the barrier to contributing to perl and getting more
> people involved I think a bit more structure is required.
Lots more people :-)

> 4.  Eventually a bugfix is produced, and is mailed to the bug system.
> This assigns a patch id, notifies the bugfixer of the patch ID and then
> cc's the patch to p5p.  The patch is associated inside the database with
> the appropriate bug, and the bug is marked as 'fixed'.
> 
> 5.  Multiple patches can be associated with a single bug.  
5.6.0.2_p01_20000321.001
5.6.0.2_p02_20000321.001
5.6.0.2_p99_20000321.001
?

Or is this just too long?

> 7.  When the pumpking has finished producing a new release, he sends a
> mail back to the bug DB with a list of the integrated patch IDs.  This
> updates the status of all the revevant bugs in the database from 'fixed'
> to 'integrated' and marks the bug with the release that the fix was
> integrated into.
Something along the lines of?:

	To: patch_<version>_<ticketid>_<ticketid>_<ticketid>[email protected]

or 
	
	To: patch_<version>[email protected]
	Subject: <ticketid> <ticketid> <ticketid> ...

or both or something else?

> 
> This is obviously only an outline - for example it is going to be
> necessary to allow backing out of patches that seem OK but that in fact

	To: patch_<patchid>[email protected]

:-)

> aren't.  However I think the key thing is the association between a bug
> report and a patch.  This is something that doesn't happen at the
> moment, and I think if more people start patching it will be very
True: it's never been a requirement, happy to help integrate it though :-)

Ciao
Richard Foley
---
[email protected] | [email protected] | [email protected]
'Ciao' - shorter than 'Aufwiedersehen'