I'd like to chime in if I may. I've found "VERIFIED" to be needless.
Especially in cases where I have logs or whatnot, having to prove the bug
is there is tedious.
Shouldn't the existence of the report be evidence enough?
On Fri, Jun 17, 2016 at 10:39 AM, Rich Freeman wrote:
> On Fri, Jun 17,
On Fri, Jun 17, 2016 at 1:26 PM, Kristian Fiskerstrand wrote:
> On 06/17/2016 07:05 PM, Brian Dolbec wrote:
>>
>> Then everyone PLEASE stop referring to the Gentoo ebuild tree as
>> portage. Reserve portage for the upstream PACKAGE MANAGER.
>
> indeed
>
Agree, though this wasn't the sense I mean
On 06/17/2016 07:05 PM, Brian Dolbec wrote:
> On Fri, 17 Jun 2016 18:46:16 +0200
> Kristian Fiskerstrand wrote:
>
>> On 06/17/2016 06:41 PM, Rich Freeman wrote:
>>> On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand
>>> wrote:
On 06/17/2016 03:58 PM, Rich Freeman wrote:
>
>
On Fri, 17 Jun 2016 18:46:16 +0200
Kristian Fiskerstrand wrote:
> On 06/17/2016 06:41 PM, Rich Freeman wrote:
> > On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand
> > wrote:
> >> On 06/17/2016 03:58 PM, Rich Freeman wrote:
> >>>
> >>> That could actually be generalized. I could see m
On 06/17/2016 06:41 PM, Rich Freeman wrote:
> On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand
> wrote:
>> On 06/17/2016 03:58 PM, Rich Freeman wrote:
>>>
>>> That could actually be generalized. I could see many types of bugs
>>> where the issue is with upstream, and we might want to trac
On Fri, Jun 17, 2016 at 11:33 AM, Kristian Fiskerstrand wrote:
> On 06/17/2016 03:48 PM, Rich Freeman wrote:
>>
>> Also, in the case of STABLEREQs would we treat them more like security
>> bugs - the last arch would just post a comment that all archs are
>> stable and un-CC themselves, but leave t
On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand wrote:
> On 06/17/2016 03:58 PM, Rich Freeman wrote:
>>
>> That could actually be generalized. I could see many types of bugs
>> where the issue is with upstream, and we might want to track the
>> progress as upstream implements a fix, relea
On 06/17/2016 03:58 PM, Rich Freeman wrote:
> On Fri, Jun 17, 2016 at 9:52 AM, Michał Górny wrote:
>> On Thu, 16 Jun 2016 15:14:44 +0200
>> Kristian Fiskerstrand wrote:
>>
>>> On 06/16/2016 03:02 PM, Michał Górny wrote:
Hello, everyone.
>>>
>>>
>>>
What I'd like to introduce i
On 06/17/2016 03:48 PM, Rich Freeman wrote:
> On Fri, Jun 17, 2016 at 9:02 AM, Kristian Fiskerstrand
> wrote:
>> On 06/17/2016 02:18 PM, Rich Freeman wrote:
>>
>>> If I'm a maintainer and I resolve a bug, how do I know if I should
>>> mark it resolved or not before it is stable?
>>
>> If package
On Fri, 17 Jun 2016 09:58:52 -0400
Rich Freeman wrote:
> On Fri, Jun 17, 2016 at 9:52 AM, Michał Górny wrote:
> > On Thu, 16 Jun 2016 15:14:44 +0200
> > Kristian Fiskerstrand wrote:
> >
> >> On 06/16/2016 03:02 PM, Michał Górny wrote:
> >> > Hello, everyone.
> >> >
> >>
> >>
> >>
> >> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 17/06/16 15:58, Rich Freeman wrote:
> That could actually be generalized. I could see many types of
> bugs where the issue is with upstream, and we might want to track
> the progress as upstream implements a fix, releases it, and then it
> is sta
On Fri, Jun 17, 2016 at 9:52 AM, Michał Górny wrote:
> On Thu, 16 Jun 2016 15:14:44 +0200
> Kristian Fiskerstrand wrote:
>
>> On 06/16/2016 03:02 PM, Michał Górny wrote:
>> > Hello, everyone.
>> >
>>
>>
>>
>> >
>> > What I'd like to introduce instead is a new STABILIZED state. It would
>> > -- li
On Thu, 16 Jun 2016 15:14:44 +0200
Kristian Fiskerstrand wrote:
> On 06/16/2016 03:02 PM, Michał Górny wrote:
> > Hello, everyone.
> >
>
>
>
> >
> > What I'd like to introduce instead is a new STABILIZED state. It would
> > -- like VERIFIED now -- be only available for bugs already RESOLVE
On Fri, Jun 17, 2016 at 9:02 AM, Kristian Fiskerstrand wrote:
> On 06/17/2016 02:18 PM, Rich Freeman wrote:
>
>> If I'm a maintainer and I resolve a bug, how do I know if I should
>> mark it resolved or not before it is stable?
>
> If package is in stable to begin with, I would certainly prefer it
On 06/17/2016 03:02 PM, Kristian Fiskerstrand wrote:
>> Can you clarify what you mean by that?
>>
>> If I have a tracker with 47 resolved blockers, how do I know which of
>> those made it to stable?
>>
>
> The once that are RESOLVED FIXED, before they are in stable they should
> be open with InVC
On 06/17/2016 02:18 PM, Rich Freeman wrote:
> On Fri, Jun 17, 2016 at 7:58 AM, Kristian Fiskerstrand
> wrote:
>> On 06/17/2016 01:50 PM, Rich Freeman wrote:
>>> It might be better to just close the original bug, and then open a new
>>> STABLEREQ bug on the tracker whenever we're interested in tra
On Fri, Jun 17, 2016 at 7:58 AM, Kristian Fiskerstrand wrote:
> On 06/17/2016 01:50 PM, Rich Freeman wrote:
>> It might be better to just close the original bug, and then open a new
>> STABLEREQ bug on the tracker whenever we're interested in tracking
>> stabilization. That also serves as a remin
On 06/17/2016 01:50 PM, Rich Freeman wrote:
> It might be better to just close the original bug, and then open a new
> STABLEREQ bug on the tracker whenever we're interested in tracking
> stabilization. That also serves as a reminder to the maintainer that
> somebody actually wants it stabilized.
On Fri, Jun 17, 2016 at 3:37 AM, Alexander Berntsen wrote:
>
> I would not want to tie our choosing RESOLVED to be tied to whether
> there is a stabilised package in the tree or not, because there are
> other Portage users than Gentoo. But I would not oppose such an
> enforcement too strongly at t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I *seriously* object to a RFC that affects so many people lasting
*less than 24h*.
- --
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCgAGBQJXY77iAAoJENQqWdRUGk8BCKIP/3ZG
On Thu, 16 Jun 2016 15:02:13 +0200
Michał Górny wrote:
> Hello, everyone.
>
> Here's the third bugs.g.o redesign RFC.
>
> This time it's about closed bugs. Right now we have two states for
> them: RESOLVED and VERIFIED.
>
> RESOLVED is the usual state that the developers use when they close
>
[No OpenPGP signature atm, smartcard not cooperating, this is really bad
form :|]
On 06/17/2016 09:50 AM, Michał Górny wrote:
>
> Bugzilla supports adding any number of extra fields. However, isn't
> the URL field sufficient for this? I'd rather not increase the size of
> the form if there's not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 17/06/16 09:50, Michał Górny wrote:
> However, isn't the URL field sufficient for this?
This is useful in many cases for describing the bug and similar things
when the bug is being reported. Is it possible to have multiple URLs
sensibly in this fi
On Fri, 17 Jun 2016 09:37:22 +0200
Alexander Berntsen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> What we have been doing in Portage so far is that when we fix it in
> git, we put IN_PROGRESS + InVCS, and write a comment that links to the
> commit on gitweb. Then when we actua
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
What we have been doing in Portage so far is that when we fix it in
git, we put IN_PROGRESS + InVCS, and write a comment that links to the
commit on gitweb. Then when we actually release Portage, we consider
it to be fixed, and make it RESOLVED.
I w
On 06/16/2016 11:57 PM, Andreas K. Huettel wrote:
> How about introducing a state that explicitly means "resolved but needs
> stabilization"?
We already have InVCS keyword for this
--
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5
>
> To be honest, I don't really see the need for VERIFIED state. Since
> it's used scarcely, it can't be really relied upon. Some users use it
> completely incorrectly (e.g. when the bug should be reopened instead).
>
Indeed. Kill VERIFIED with fire.
--
Andreas K. Huettel
Gentoo Linux devel
>
> What I'd like to introduce instead is a new STABILIZED state. It would
> -- like VERIFIED now -- be only available for bugs already RESOLVED,
> and it could be used to signify that the fix has made it into stable.
>
Right now I dont think we agree what "RESOLVED" means.
* Some people close
On 17 June 2016 at 01:02, Michał Górny wrote:
> VERIFIED is used scarcely, and not really consistently. It can only be
> used on RESOLVED bugs, and sometimes users use it to confirm that
> the bug is resolved.
Its also worth pointing out VERIFIED status annoyingly restricts a
package, and so any
On 16/06/16 14:19, James Le Cuirot wrote:
> On Thu, 16 Jun 2016 15:14:44 +0200
> Kristian Fiskerstrand wrote:
>
>>> What I'd like to introduce instead is a new STABILIZED state. It
>>> would -- like VERIFIED now -- be only available for bugs already
>>> RESOLVED, and it could be used to signify th
On Thu, 16 Jun 2016 15:02:13 +0200 Michał Górny wrote:
> Hello, everyone.
>
> Here's the third bugs.g.o redesign RFC.
>
> This time it's about closed bugs. Right now we have two states for
> them: RESOLVED and VERIFIED.
>
> RESOLVED is the usual state that the developers use when they close
> a
On 06/16/2016 03:19 PM, James Le Cuirot wrote:
> I currently set InVCS for pending-stable fixes in conjunction with the
> IN_PROGRESS state. I would like to keep InVCS at least.
Exactly
--
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 510
On Thu, 16 Jun 2016 15:14:44 +0200
Kristian Fiskerstrand wrote:
> > What I'd like to introduce instead is a new STABILIZED state. It
> > would -- like VERIFIED now -- be only available for bugs already
> > RESOLVED, and it could be used to signify that the fix has made it
> > into stable.
> >
>
On Thu, Jun 16, 2016 at 3:02 PM, Michał Górny wrote:
> Hello, everyone.
>
> Here's the third bugs.g.o redesign RFC.
>
> This time it's about closed bugs. Right now we have two states for
> them: RESOLVED and VERIFIED.
>
> RESOLVED is the usual state that the developers use when they close
> a bug.
On 06/16/2016 03:02 PM, Michał Górny wrote:
> Hello, everyone.
>
>
> What I'd like to introduce instead is a new STABILIZED state. It would
> -- like VERIFIED now -- be only available for bugs already RESOLVED,
> and it could be used to signify that the fix has made it into stable.
>
> While
Hello, everyone.
Here's the third bugs.g.o redesign RFC.
This time it's about closed bugs. Right now we have two states for
them: RESOLVED and VERIFIED.
RESOLVED is the usual state that the developers use when they close
a bug. It's also the only state that could be directly transferred from
oth
36 matches
Mail list logo