QA-agree.
--
nurla
On Thu, Sep 11, 2014 at 6:28 PM, Mike Scherbakov
wrote:
> > Mike, i've just want to say, if feature isn't ready for production use
> and we have no other choice, we should provide detailed limitations and
> examples of proper use.
> Fully agree, such features should become ex
> Mike, i've just want to say, if feature isn't ready for production use
and we have no other choice, we should provide detailed limitations and
examples of proper use.
Fully agree, such features should become experimental. We should have this
information in release notes.
Basically, Patching of O
Mike, i've just want to say, if feature isn't ready for production use and
we have no other choice, we should provide detailed limitations and
examples of proper use.
On Thu, Sep 11, 2014 at 5:58 PM, Tomasz Napierala
wrote:
>
> On 11 Sep 2014, at 09:19, Mike Scherbakov
> wrote:
>
> > Hi all,
>
On 11 Sep 2014, at 09:19, Mike Scherbakov wrote:
> Hi all,
> what about using "experimental" tag for experimental features?
>
> After we implemented feature groups [1], we can divide our features and for
> complex features, or those which don't get enough QA resources in the dev
> cycle, we c
> +1, absolutely agree, but we should determine count of allowed bugs for
experimental features against severity.
Anastasia, can you please give an example? I think we should not count them
at all. Experimental features, if they are isolated, they can be in any
stated. May be just very beginning of
+1
On Thu, Sep 11, 2014 at 5:05 PM, Anastasia Urlapova
wrote:
> > I think we should not count bugs for HCF criteria if they affect only
> > experimental feature(s).
>
> +1, absolutely agree, but we should determine count of allowed bugs for
> experimental features against severity.
>
> On Thu, S
> I think we should not count bugs for HCF criteria if they affect only
> experimental feature(s).
+1, absolutely agree, but we should determine count of allowed bugs for
experimental features against severity.
On Thu, Sep 11, 2014 at 2:13 PM, Nikolay Markov
wrote:
> Probably, even "experimenta
Probably, even "experimental feature" should at least pretend to be
working, anyway, or it shouldn't be publically announced. But I think
it's important to describe limitation of this features (or mark some
of them as "untested") and I think list of known issues with links to
most important bugs is
> May be we can use tag per feature, for example "zabbix"
Tags are ok, but I still think that we can mention at least some
significant bugs. For example, if some feature doesn't work in some
deployment mode (e.g. simple, with ceilometer, etc) we can at least
notify users so they even don't try.
A
> if we point somewhere about knowing issues in those experimental features
there are might be dozens of bugs.
May be we can use tag per feature, for example "zabbix", so it will be easy
to search in LP all open bugs regarding Zabbix feature?
On Thu, Sep 11, 2014 at 12:11 PM, Igor Kalnitsky
wrote
> I think we should not count bugs for HCF criteria if they affect only
> experimental feature(s).
+1, I'm totally agree with you - it makes no sense to count
experimental bugs as HCF criteria.
> Any objections / other ideas?
I think it would be great for customers if we point somewhere about
kn
Hi all,
what about using "experimental" tag for experimental features?
After we implemented feature groups [1], we can divide our features and for
complex features, or those which don't get enough QA resources in the dev
cycle, we can declare as experimental. It would mean that those are not
produ
12 matches
Mail list logo