Re: [Pulp-dev] Github Required Checks

[Daniel Alley]

Jeremy, I don't think David was continuing our line of discussion on
policy, but rather rebutting the original idea that Github's "required
checks" be enforced for all plugins.  That goes back to the whole
difference between having a policy that requires green tests and making it
physically impossible to merge PRs without them.  Maybe some plugins want a
policy and some plugins are fine with hard required checks on Github, but
the latter shouldn't be enforced on everyone - is what I think David was
saying.

Also, my understanding is that pulp_deb is not strictly under our control,
but that we're hosting it specifically to let misa use our QA
infrastructure, and because we might want to productise it at some point in
the future.

On Mon, Feb 5, 2018 at 12:55 PM, Jeremy Audet  wrote:

> > Regarding the plugin repos, last year we talked about plugins being
> completely autonomous (aside from abiding by our Code of Conduct). Wouldn’t
> setting the required checks for projects like pulp_file, pulp_python,
> pulp_deb, etc violate this autonomy? In other words, shouldn’t we let
> plugin teams decide their own policy and what checks to enable?
>
> Are pulp_file, pulp_python, pulp_deb, and so on autonomous projects? The
> fact that they're hosted on GitHub under the pulp organization [1]
> indicates that they're under our control. Since they're under our control,
> we get to set the rules. If any of these projects really are autonomous,
> then somebody please kick them out of the pulp organization.
>
> If I was writing paychecks to a team of devs, and they refused to adopt
> basic QA processes for their projects, I'd happily fire the entire dev
> team. I can't be the only one who's had this thought.
>
> [1] https://github.com/pulp
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Github Required Checks

[Jeremy Audet]

> Regarding the plugin repos, last year we talked about plugins being
completely autonomous (aside from abiding by our Code of Conduct). Wouldn’t
setting the required checks for projects like pulp_file, pulp_python,
pulp_deb, etc violate this autonomy? In other words, shouldn’t we let
plugin teams decide their own policy and what checks to enable?

Are pulp_file, pulp_python, pulp_deb, and so on autonomous projects? The
fact that they're hosted on GitHub under the pulp organization [1]
indicates that they're under our control. Since they're under our control,
we get to set the rules. If any of these projects really are autonomous,
then somebody please kick them out of the pulp organization.

If I was writing paychecks to a team of devs, and they refused to adopt
basic QA processes for their projects, I'd happily fire the entire dev
team. I can't be the only one who's had this thought.

[1] https://github.com/pulp
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Github Required Checks

[David Davis]

Regarding the plugin repos, last year we talked about plugins being
completely autonomous (aside from abiding by our Code of Conduct). Wouldn’t
setting the required checks for projects like pulp_file, pulp_python,
pulp_deb, etc violate this autonomy? In other words, shouldn’t we let
plugin teams decide their own policy and what checks to enable?


David

On Mon, Feb 5, 2018 at 11:37 AM, Jeremy Audet  wrote:

> > I _do_ think we need to formalize a set of rules about merging, though,
> and decide how strict we want to be about it.  There are a few
> possibilities:
>
> I'm only indirectly affected by this decision, so take my opinion with a
> grain of salt.
>
>1. I dislike option 1, because it unnecessarily ties us to a
>particular policy implementation. Yes, it's *nice* to always have green
>Travis reports. But Travis and other service providers break, and their
>screw-ups shouldn't stop us from doing productive work.
>2. I like option 2, because it lets us assert that QA process failures
>must be fixed, without tying oursevles too closely to an unreliable third
>party.
>3. I dislike option 3, because it trains devs to think that QA process
>failures is OK and normal. It's not. Technical debt that affects QA
>processes should always be paid off.
>
> Distinguishing between policy and implementation is tricky. Ask ICANN
> about that. But I still think it's a valuable goal to aim for. Here's a
> sample policy statement that might apply to this team:
>
> Every PR must pass the checks defined by the `all` make target, for all of
>> the interpreters listed in `setup.py`.
>>
>
> This policy statement doesn't include implementation details such as:
>
>- Are these checks automatically executed or manually executed?
>- If automatically executed, which service provider is used? Travis?
>CircleCI? Or perhaps a custom Jenkins or Buildbot application that rents
>VMs from an IaaS provider?
>- Are builds performed on RHEL 7, or in Docker containers based on
>Ubuntu 16.04, or in systemd-nspawn containers based on Arch, or something
>else?
>
> Notably, these implementation details can change, while the policy stays
> the same.
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Github Required Checks

[Jeremy Audet]

> I _do_ think we need to formalize a set of rules about merging, though,
and decide how strict we want to be about it.  There are a few
possibilities:

I'm only indirectly affected by this decision, so take my opinion with a
grain of salt.

   1. I dislike option 1, because it unnecessarily ties us to a particular
   policy implementation. Yes, it's *nice* to always have green Travis
   reports. But Travis and other service providers break, and their screw-ups
   shouldn't stop us from doing productive work.
   2. I like option 2, because it lets us assert that QA process failures
   must be fixed, without tying oursevles too closely to an unreliable third
   party.
   3. I dislike option 3, because it trains devs to think that QA process
   failures is OK and normal. It's not. Technical debt that affects QA
   processes should always be paid off.

Distinguishing between policy and implementation is tricky. Ask ICANN about
that. But I still think it's a valuable goal to aim for. Here's a sample
policy statement that might apply to this team:

Every PR must pass the checks defined by the `all` make target, for all of
> the interpreters listed in `setup.py`.
>

This policy statement doesn't include implementation details such as:

   - Are these checks automatically executed or manually executed?
   - If automatically executed, which service provider is used? Travis?
   CircleCI? Or perhaps a custom Jenkins or Buildbot application that rents
   VMs from an IaaS provider?
   - Are builds performed on RHEL 7, or in Docker containers based on
   Ubuntu 16.04, or in systemd-nspawn containers based on Arch, or something
   else?

Notably, these implementation details can change, while the policy stays
the same.
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] pulp 3 distributor use cases

[Eric Helms]

Thanks for the clarity. That explanation definitely helped me wrap my head
around it.

On Mon, Feb 5, 2018 at 5:47 AM, Dennis Kliban  wrote:

> I update issue 2894[0] with the new name, Exporter. Can someone please
> groom this ticket?
>
> [0]https://pulp.plan.io/issues/2894
>
>
> Thanks,
> Dennis
>
> On Fri, Feb 2, 2018 at 5:28 PM, Daniel Alley  wrote:
>
>> +1 rename
>>
>> On Fri, Feb 2, 2018 at 10:51 AM, Austin Macdonald 
>> wrote:
>>
>>> +1 rename to Exporter.
>>>
>>> On Fri, Feb 2, 2018 at 10:13 AM, Brian Bouterse 
>>> wrote:
>>>
 +1 to renaming a Pulp3 'Distributor' to be 'Exporter'. The name of a
 'Distribution' (when Pulp serves bits using its webserver) would stay the
 same. Currently the names Distributor and Distribution sound so similar
 that its very confusing. A Distribution and an Exporter would be clearer
 names I think.

 On Thu, Feb 1, 2018 at 10:30 AM, Dennis Kliban 
 wrote:

> Distributors are only used for exporting Publications out of Pulp.
>
> Distributions make Publications available to consume via http(s) at
> /content/relative/path/of/distribution/. Each Publication can be
> associated with any number of Distributions.
>
> The names are very similar, but perform different function. Perhaps
> Distributors should be called Exporters instead.
>
> On Thu, Feb 1, 2018 at 2:35 PM, Eric Helms  wrote:
>
>> Will Pulp 3 support multiple distributors on a single repository?
>> Could I, for example, attach the yum distributor multiple times but with 
>> a
>> different output path to publish the same repository at different 
>> locations?
>>
>>
>> Thanks,
>> Eric
>>
>> On Thu, Feb 1, 2018 at 6:54 AM, Dennis Kliban 
>> wrote:
>>
>>> I've updated the MVP use cases for the Distributors. The diff is
>>> here[0]. I removed the use case of a distributor exporting a Repository
>>> Version. The idea is to give users a single way to export repository
>>> versions. Users will first create a publication and then use a 
>>> distributor
>>> to export that publication.
>>>
>>> Please reply to this thread with any suggestions for the use cases
>>> related to Distributors.
>>>
>>> I'd like to write up stories for these use cases early next week, so
>>> the work can be merged by Feb 15th.
>>>
>>> [0] https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viabl
>>> e_Product/diff?utf8=%E2%9C%93=143_from=142
>>> ommit=View+differences
>>>
>>> Thanks,
>>> Dennis
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>

 ___
 Pulp-dev mailing list
 Pulp-dev@redhat.com
 https://www.redhat.com/mailman/listinfo/pulp-dev


>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev