On Sun, Jul 20, 2014, at 04:35 PM, Jay S. Bryant wrote:
> Thanks Duncan and also Dolph, I should have made the question
> broader. :-)
>
> On Wed, 2014-07-16 at 13:22 +0100, Duncan Thomas wrote:
> > On 16 July 2014 03:57, Jay S. Bryant wrote:
> > > John,
> > >
> > > So you have said a few time
Thanks Duncan and also Dolph, I should have made the question
broader. :-)
On Wed, 2014-07-16 at 13:22 +0100, Duncan Thomas wrote:
> On 16 July 2014 03:57, Jay S. Bryant wrote:
> > John,
> >
> > So you have said a few times that the specs are a learning process.
> > What do you feel with have le
On 16 July 2014 03:57, Jay S. Bryant wrote:
> John,
>
> So you have said a few times that the specs are a learning process.
> What do you feel with have learned thus far using specs?
I'm not John, but I'm going to answer as if you'd addressed the question wider:
- Specs can definitely help flesh
t; > Don Dugger
> >
> > "Censeo Toto nos in Kansa esse decisse." - D.
> > Gale
> >
> > Ph: 303/443-3786
> >
> >
> >
> > From: Dolph
>
> From: Dolph Mathews
> [mailto:dolph.math...@gmail.com]
> Sent: Tuesday, July 1, 2014 11:02 AM
> To: OpenStack Development Mailing List (not
>
> Leave the option about when to submit a design vs. when to submit code to
the
> contributor.
That's is what is being done so far right? Hard to know (mainly if you are
a first contributor) when a change is big or not. I can see lots
of patches being submitted without the spec getting rejected
On 15 July 2014 15:01, Erlon Cruz wrote:
>> Leave the option about when to submit a design vs. when to submit code to
>> the contributor.
>
> That's is what is being done so far right? Hard to know (mainly if you are a
> first contributor) when a change is big or not. I can see lots of patches
> b
On Mon, Jul 14, 2014 at 7:38 AM, Duncan Thomas
wrote:
> On 14 July 2014 07:11, Flavio Percoco wrote:
> > I almost fully agree with this last point. The bit I don't agree with is
> > that there are some small refactor changes that aim to change a core
> > piece of the project without any impact o
On 14 July 2014 07:11, Flavio Percoco wrote:
> I almost fully agree with this last point. The bit I don't agree with is
> that there are some small refactor changes that aim to change a core
> piece of the project without any impact on the final user that are
> spec/blueprint worthy to explaining
On Mon, Jul 14, 2014 at 8:38 AM, Duncan Thomas
wrote:
> On 14 July 2014 07:11, Flavio Percoco wrote:
> > I almost fully agree with this last point. The bit I don't agree with is
> > that there are some small refactor changes that aim to change a core
> > piece of the project without any impact o
On 07/13/2014 04:01 PM, Dolph Mathews wrote:
>
> On Wed, Jul 9, 2014 at 1:54 PM, Jay Bryant
> mailto:jsbry...@electronicjungle.net>>
> wrote:
>
> I had been under the impression that all BPs we going to require a
> spec. I, however, was made are in today's cinder meeting that we
> a
;
>>>
>>> --
>>>
>>> Don Dugger
>>>
>>> "Censeo Toto nos in Kansa esse decisse." - D. Gale
>>>
>>> Ph: 303/443-3786
>>>
>>>
>>>
>>> *From:* Dolph Mathews [mailto:dolph.math...
wn justification seems like the wrong way to
>> go.
>>
>>
>>
>> --
>>
>> Don Dugger
>>
>> "Censeo Toto nos in Kansa esse decisse." - D. Gale
>>
>> Ph: 303/443-3786
>>
>>
>>
>> *From:* Dolph Mathews [mailto:dolp
way to go.
>
>
>
> --
>
> Don Dugger
>
> "Censeo Toto nos in Kansa esse decisse." - D. Gale
>
> Ph: 303/443-3786
>
>
>
> *From:* Dolph Mathews [mailto:dolph.math...@gmail.com]
> *Sent:* Tuesday, July 1, 2014 11:02 AM
> *To:* OpenStack Development
Excerpts from Dolph Mathews's message of 2014-07-01 10:02:13 -0700:
> The argument has been made in the past that small features will require
> correspondingly small specs. If there's a counter-argument to this example
> (a "small" feature requiring a relatively large amount of spec effort), I'd
>
On Wed, Jul 2, 2014 at 7:08 AM, Lingxian Kong wrote:
> IMO, 'spec' is indeed a good idea and indeed useful for tracking
> features, although it's a little tough for us not using English as
> native language. But we still need to identify these 'small features',
> and core reviewers do some review
IMO, 'spec' is indeed a good idea and indeed useful for tracking
features, although it's a little tough for us not using English as
native language. But we still need to identify these 'small features',
and core reviewers do some review, then approve them ASAP, so that we
can avoid to waste a lot o
On Tue, Jul 1, 2014 at 10:02 AM, Dolph Mathews wrote:
> The argument has been made in the past that small features will require
> correspondingly small specs. If there's a counter-argument to this example
> (a "small" feature requiring a relatively large amount of spec effort), I'd
> love to have
for usage questions)
Subject: Re: [openstack-dev] [all][specs] Please stop doing specs for any
changes in projects
The argument has been made in the past that small features will require
correspondingly small specs. If there's a counter-argument to this example (a
"small" feature req
I meant the administrative overhead of the contributor having to submit
a spec to Gerrit and then everyone having to deal with yet another
review, not the overhead of writing/reviewing the spec itself.
On Tue, Jul 01 2014, Dolph Mathews wrote:
> The argument has been made in the past that small f
The argument has been made in the past that small features will require
correspondingly small specs. If there's a counter-argument to this example
(a "small" feature requiring a relatively large amount of spec effort), I'd
love to have links to both the spec and the resulting implementation so we
c
On Mon, Jun 30 2014, Joshua Harlow wrote:
> There is a balance here that needs to be worked out and I've seen
> specs start to turn into requirements for every single patch (even if
> the patch is pretty small). I hope we can rework the 'balance in the
> force' to avoid being so strict that every
Excerpts from Boris Pavlovic's message of 2014-06-30 14:11:08 -0700:
> Hi all,
>
> Specs are interesting idea, that may be really useful, when you need to
> discuss large topics:
> 1) work on API
> 2) Large refactoring
> 3) Large features
> 4) Performance, scale, ha, security issues that requires
ent Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, June 30, 2014 at 2:11 PM
To: OpenStack Development Mailing List
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [all][specs] Please stop doing specs for any
Hi all,
Specs are interesting idea, that may be really useful, when you need to
discuss large topics:
1) work on API
2) Large refactoring
3) Large features
4) Performance, scale, ha, security issues that requires big changes
And I really dislike idea of adding spec for every patch. Especially whe
25 matches
Mail list logo
