Thank you for the detailed response:) I do agree with you about all points
except the issues confirmation policy. The confirmation policy which you
have just described seems to be used at this time (people submit new tickets
and wait until these will be confirmed by the team members). I suggest to
try a slightly different approach:
1. One who have created the ticket can only mark it 'Invaild', but cannot
confirm the issue (to avoid the single-person-visible-only issues).
2. Anyone can confirm tickets from other people in case he or she has
reproduced the same issue (and yes, we believe the people to be fair, this
3. Only committers can mark the tickets from other people 'invalid'.
I do not think that there will be more fixed bugs per month with this
approach, but it makes the tickets management to be more flexible.
2010/8/17 Nikodemus Siivola <nikodemus@...>
> On 29 May 2010 23:45, Roman Marynchak <roman.marynchak@...> wrote:
> > This is a question to SBCL maintainers. I probably had to ask it before
> > nominating my patches for release in Launchpad, but anyway it is better
> > ask later than to ask never:)
> ...and better to answer late than never... :)
> > The question is: what should I do after I have provided the patch and
> > counted all notes about the problems with the patch? Should I mark the
> > 'In progress', assign it to me and nominate it for release? Or I should
> > after the final patch is provided, and do not touch the ticket anymore?
> > we have any rules about this?
> I think I would prefer:
> 1. Mark the issue In progress, and assign it to yourself.
> 2. Once it's done, tag it for review. We don't currently use the
> release nomination stuff, and even if we did, it would be for "this
> bug should be fixed for release X", not "this specific fix was
> > Also, what is the issues confirmation policy? Should they be confirmed by
> > maintainers only, or other registered in Launchpad people also may
> > an issue?
> I think my general preference is that only committers should mark
> stuff confirmed -- that way people whose issues have been confirmed
> can know that at least someone on the team has seen the bug.
> That said, comments from non-committers about bugs ("I can replicate
> this bug on FooBSD 13 SPARC, SBCL from today's CVS.") are _extremely_
> > I am asking this to avoid confusions during Launchpad usage. It would be
> > good to have the 'official' rules about SBCL Launchpad site stated
> > and to obey them.
> Very true. For the first 6 month or year of our Launchpad usage almost
> everyone who used it was a committer, or sufficiently telepathic that
> things worked reasonably well without thinking about it too much --
> but writing a nice set of guidelines is probably in order now.
> -- Nikodemus