On Fri, 10 Sep 2010 18:32:38 +0200
Jeroen Roovers wrote:
> On Tue, 7 Sep 2010 21:30:34 +
> "Robin H. Johnson" wrote:
>
> > On Tue, Sep 07, 2010 at 10:47:27PM +0200, Róbert Čerňanský wrote:
> > > 2.3. Upstream issues
> > >Do not close a bug (as RESOLVED/UPSTREAM) until it is fixed by
> >
On Tue, 7 Sep 2010 21:30:34 +
"Robin H. Johnson" wrote:
> On Tue, Sep 07, 2010 at 10:47:27PM +0200, Róbert Čerňanský wrote:
> > 2.3. Upstream issues
> >Do not close a bug (as RESOLVED/UPSTREAM) until it is fixed by
> >upstream.
If the reason you propose this is visibility, then maybe
El mié, 08-09-2010 a las 01:44 +0400, dev-ran...@mail.ru escribió:
> On Tue, Sep 07, 2010 at 09:30:34PM +, Robin H. Johnson wrote:
> > This implies that the upstream is alive enough to fix it.
> >
> > I feel it should mean that the bug has been reported to upstream, and
> > that state is docum
On Tue, Sep 07, 2010 at 09:30:34PM +, Robin H. Johnson wrote:
> This implies that the upstream is alive enough to fix it.
>
> I feel it should mean that the bug has been reported to upstream, and
> that state is documented in the bug.
>
> If we keep every upstream bug open instead of closed,
> > 2.3. Upstream issues
> >
> >Do not close a bug (as RESOLVED/UPSTREAM) until it is fixed by
> >upstream.
>
> This implies that the upstream is alive enough to fix it.
>
> I feel it should mean that the bug has been reported to upstream, and
> that state is documented in the bug.
>
>
On Tue, Sep 07, 2010 at 10:47:27PM +0200, Róbert Čerňanský wrote:
> 2.3. Upstream issues
>Do not close a bug (as RESOLVED/UPSTREAM) until it is fixed by
>upstream.
This implies that the upstream is alive enough to fix it.
I feel it should mean that the bug has been reported to upstream, an
On Mon, 6 Sep 2010 08:32:16 +
"Robin H. Johnson" wrote:
[...]
> 2. Special cases
As a user I'd like to see following:
2.3. Upstream issues
Do not close a bug (as RESOLVED/UPSTREAM) until it is fixed by
upstream.
Robert
--
Robert Cernansky
E-mail: hslis...@zoznam.sk
Jabber: h...@ja
On 09/06/2010 10:39 AM, Dirkjan Ochtman wrote:
> On Mon, Sep 6, 2010 at 10:32, Robin H. Johnson wrote:
>> After a discussion on IRC, a few of us were considering the value of
>> adding suggestions on handling of bugs in Bugzilla from a developer (and
>> editbugs user) perspective.
>
> Good idea,
On Mon, 6 Sep 2010 10:39:59 +0200, Dirkjan Ochtman
wrote:
> [...]
> >
> > 2.2. Security bugs
> > The developer should comment, but ONLY members of the security team
> > should:
> > - change whiteboard
> > - add/remove arches
> > - change bug status/reso
>
> The arches can still remove thems
On Mon, Sep 6, 2010 at 10:32, Robin H. Johnson wrote:
> After a discussion on IRC, a few of us were considering the value of
> adding suggestions on handling of bugs in Bugzilla from a developer (and
> editbugs user) perspective.
Good idea, I've been confused about the interaction models here.
>
Hi,
After a discussion on IRC, a few of us were considering the value of
adding suggestions on handling of bugs in Bugzilla from a developer (and
editbugs user) perspective.
These is the simplest set I have to start, but I'd really like other
comments and ideas.
1. General case
- You should on
11 matches
Mail list logo
