Defining the field's behaivor a bit more could help us with the name. Will
it actually be shown to the user in viewsets and filter results?
I think the answer should be no, not until it's fully finished. I can't
think of a reason why a user would want to see inconsistent content during
a sync or
Thanks for answering my questions. I agree on not using an “is_” prefix and
avoiding “visible.”
Your suggestion of “valid” sounds fine. Maybe some other options: finished,
complete[d], ready.
David
On Wed, Dec 13, 2017 at 2:15 PM, Jeff Ortel wrote:
>
>
> On 12/13/2017
I read through the story and it looks good to me. I marked it as groomed.
On Fri, Dec 8, 2017 at 3:50 PM, Brian Bouterse wrote:
> Recently @ttereshc brought up a tasking system improvement while
> investigating a user reported issue. I think it's something we want to get
>
On 12/13/2017 12:46 PM, David Davis wrote:
A few questions. First, what is meant by incomplete? I’m assuming it
refers to a version in the process of being created or one that was
not successfully created?
Both.
Also, what’s the motivation behind storing this information? Is there
There has been discussion on IRC about a matter related to versioned
repositories that needs to be broadened. It dealt with situations
whereby a new repository version exists in the DB in an incomplete
state. The incomplete state exists because conceptually a repository
version includes both
+1
David
On Wed, Dec 13, 2017 at 11:36 AM, Brian Bouterse
wrote:
> +1 to this
>
>
> On Wed, Dec 13, 2017 at 10:03 AM, Daniel Alley wrote:
>
>> - close issues 3163 and 3164
>>> - move JWT auth use cases from the MVP document[2] to the 3.1+
>>>
+1
On Wed, Dec 13, 2017 at 11:24 AM, Ina Panova wrote:
> +1
>
>
>
>
> Regards,
>
> Ina Panova
> Software Engineer| Pulp| Red Hat Inc.
>
> "Do not go where the path may lead,
> go instead where there is no path and leave a trail."
>
> On Tue, Dec 12, 2017 at 8:32
+1 to this
On Wed, Dec 13, 2017 at 10:03 AM, Daniel Alley wrote:
> - close issues 3163 and 3164
>> - move JWT auth use cases from the MVP document[2] to the 3.1+
>> document[3].
>> - add a story for removing "djangorestframework-jwt" from pulp 3.0
>
>
> s/story/task, and
>
Hi,
In our current setup, we have a purely internal pulp deployment, that
publishes to an NFS share.
HTTP frontend machines handle the cert-based authn/authz and serve the
content from the NFS share.
We have an internal set of HTTP frontend machines, and an internal customer
has access to
+1
On Wed, Dec 13, 2017 at 10:02 AM, Bihan Zhang wrote:
> +1
>
> On Wed, Dec 13, 2017 at 10:01 AM, Jeff Ortel wrote:
>
>> +1
>>
>> On 12/12/2017 10:47 AM, Brian Bouterse wrote:
>>
>> As we get to the end of the MVP planning for Pulp3, I want to check-in
+1
On Wed, Dec 13, 2017 at 10:01 AM, Jeff Ortel wrote:
> +1
>
> On 12/12/2017 10:47 AM, Brian Bouterse wrote:
>
> As we get to the end of the MVP planning for Pulp3, I want to check-in
> about deferring 3 areas of Pulp functionality to the 3.1+ page [0]. I'm
> looking for
+1
On 12/12/2017 10:47 AM, Brian Bouterse wrote:
As we get to the end of the MVP planning for Pulp3, I want to check-in
about deferring 3 areas of Pulp functionality to the 3.1+ page [0].
I'm looking for feedback, especially -1s, about deferring the
following 3 things from the Pulp 3.0
+1 here too
On Wed, Dec 13, 2017 at 8:28 AM, David Davis wrote:
> I think this makes sense. +1 from me.
>
>
> David
>
> On Tue, Dec 12, 2017 at 11:47 AM, Brian Bouterse
> wrote:
>
>> As we get to the end of the MVP planning for Pulp3, I want to
I think this makes sense. +1 from me.
David
On Tue, Dec 12, 2017 at 11:47 AM, Brian Bouterse
wrote:
> As we get to the end of the MVP planning for Pulp3, I want to check-in
> about deferring 3 areas of Pulp functionality to the 3.1+ page [0]. I'm
> looking for feedback,
14 matches
Mail list logo