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 is obvious).
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.

Best Regards,
Roman

2010/8/17 Nikodemus Siivola <nikodemus@random-state.net>
On 29 May 2010 23:45, Roman Marynchak <roman.marynchak@gmail.com> 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 to
> 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 issue
> 'In progress', assign it to me and nominate it for release? Or I should stop
> after the final patch is provided, and do not touch the ticket anymore? Do
> 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
approved".

> Also, what is the issues confirmation policy? Should they be confirmed by
> maintainers only, or other registered in Launchpad people also may confirm
> 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_
welcome.

> I am asking this to avoid confusions during Launchpad usage. It would be
> good to have the 'official' rules about SBCL Launchpad site stated somewhere
> 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.

Cheers,

 -- Nikodemus