Good Morning Everyone,
We have been informed thst week at the upstream devs working on the product-definition-center (PDC) are moving away from the project and are going to leave it without a maintainer. Since we adopted PDC for a variety of data flows, this puts us in an awkward position. :(
Ralph and I met up on Tuesday to brainstorm the list of things we actively use PDC for today and to come up with a contingency plan for how to handle them. One overarching option is for us (fedora-infra) to take ownership of the PDC codebase as a whole. We didn't fully explore this option, figuring that the codebase is large and contains lots of tables, endpoints, and codepaths that we didn't use nor which we plan to use.
Instead, below we've got the four things we use PDC for and some options for what to do with each.
With the exception of /modules/, one common pattern that we like is to investigate splitting out the "django apps" that make up PDC into their own projects. We're calling these "pdc-lite", for fun. See more below.
* Modules The data in the /modules/ PDC endpoint is *also* in the MBS db. Ralph's team is going to just use that and stop using pdc anything for modules. We're going to need to patch pungi, mbs for local builds, and a few other places. This should be a relatively low-pain transition.
* Stream branches, branch ownership, retirement dates? - SLA/EOL are currently stored in PDC. - Queried by releng scripts for retirement, fedrepo-req for new branches, etc.. option #1 git repo full of yaml file similar to the override repo compiled into a single JSON blob Single place for all retired packages This feels like the lowest tech option. git gives us change control for free... but people easily get lost in the "UX" of navigating a gigantic git repo full of plaintext files. option #2 pagure's DB/API pagure knows nothing about branches currently, so that would be bigger lift option #3 PDC internally is composed of ~20 "django apps" https://github.com/product-definition-center/product-definition-center/tree/... We could pick the 2 or 3 that comprise the branches feature, copy them out, and turn them into their own service: the "branch definition center": BDC. That would be the "pdc-lite" approach mentionned above, ie: PDC with only the "app" of interest
* release/life-circle tracking? option #1: PDC lite with just that app of interest option #2: JSON/yaml file on the proxies option #3: pkgdb-lite option #4: ??? compose tracking? impacted: fedfind option #1: PDC-lite with just that app of interest option #2: Drop this entirely? Adam probably really wants to keep the record of composes. option #3: ???
The "pdc-lite" options are attractive, across the board. One thing we get from this is greater clarity when discussing things formerly in PDC. If something is in the branch-definition-center, the compose-definition-center, or the release-definition-center.. you know what you're talking about. Today, when talking about whether or not something should be or is in "PDC", it is easy to get confused.
I propose we start the discussion on the list and plan for a meeting sometime late next week to discuss it further with the interested parties (please signal yourself)
What do you think?
Pierre and Ralph
* Stream branches, branch ownership, retirement dates? - SLA/EOL are currently stored in PDC. - Queried by releng scripts for retirement, fedrepo-req for new branches, etc.. option #1 git repo full of yaml file similar to the override repo compiled into a single JSON blob Single place for all retired packages This feels like the lowest tech option. git gives us change control for free... but people easily get lost in the "UX" of navigating a gigantic git repo full of plaintext files.
I am all for this option because it makes everything public and it is consistent with the /tests/ and modules/ namespace approach that has been more recently introduced. I think that option is actually even attractive.
Just noting...I am not a core developer in this subject but this comes to mind as a good way to implement the "branch meta-data storage app".
clime
On Fri, Apr 20, 2018 at 7:34 PM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
Good Morning Everyone,
We have been informed thst week at the upstream devs working on the product-definition-center (PDC) are moving away from the project and are going to leave it without a maintainer. Since we adopted PDC for a variety of data flows, this puts us in an awkward position. :(
Ralph and I met up on Tuesday to brainstorm the list of things we actively use PDC for today and to come up with a contingency plan for how to handle them. One overarching option is for us (fedora-infra) to take ownership of the PDC codebase as a whole. We didn't fully explore this option, figuring that the codebase is large and contains lots of tables, endpoints, and codepaths that we didn't use nor which we plan to use.
Instead, below we've got the four things we use PDC for and some options for what to do with each.
With the exception of /modules/, one common pattern that we like is to investigate splitting out the "django apps" that make up PDC into their own projects. We're calling these "pdc-lite", for fun. See more below.
- Modules The data in the /modules/ PDC endpoint is *also* in the MBS db.
Ralph's team is going to just use that and stop using pdc anything for modules. We're going to need to patch pungi, mbs for local builds, and a few other places. This should be a relatively low-pain transition.
- Stream branches, branch ownership, retirement dates?
- SLA/EOL are currently stored in PDC.
- Queried by releng scripts for retirement, fedrepo-req for new
branches, etc.. option #1 git repo full of yaml file similar to the override repo compiled into a single JSON blob Single place for all retired packages This feels like the lowest tech option. git gives us change control for free... but people easily get lost in the "UX" of navigating a gigantic git repo full of plaintext files. option #2 pagure's DB/API pagure knows nothing about branches currently, so that would be bigger lift option #3 PDC internally is composed of ~20 "django apps" https://github.com/product-definition-center/product- definition-center/tree/master/pdc/apps We could pick the 2 or 3 that comprise the branches feature, copy them out, and turn them into their own service: the "branch definition center": BDC. That would be the "pdc-lite" approach mentionned above, ie: PDC with only the "app" of interest
- release/life-circle tracking? option #1: PDC lite with just that app of interest option #2: JSON/yaml file on the proxies option #3: pkgdb-lite option #4: ??? compose tracking? impacted: fedfind option #1: PDC-lite with just that app of interest option #2: Drop this entirely? Adam probably really wants to keep the record of composes. option #3: ???
The "pdc-lite" options are attractive, across the board. One thing we get from this is greater clarity when discussing things formerly in PDC. If something is in the branch-definition-center, the compose-definition-center, or the release-definition-center.. you know what you're talking about. Today, when talking about whether or not something should be or is in "PDC", it is easy to get confused.
I propose we start the discussion on the list and plan for a meeting sometime late next week to discuss it further with the interested parties (please signal yourself)
What do you think?
Pierre and Ralph
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists. fedoraproject.org
Bodhi also uses PDC to determine which packages are critpath per release.
I'm interested in this topic, so please do invite me to discuss next week!
On 20 April 2018 at 20:15, Randy Barlow bowlofeggs@fedoraproject.org wrote:
Bodhi also uses PDC to determine which packages are critpath per release.
I'm interested in this topic, so please do invite me to discuss next week!
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org
fedora-packages get the list of packages from PDC during the indexing of the xapian database. You can add me in the discussion too.
I am not very familiar with django but could we keep the current PDC setup and just disable the django apps we are not using ? That way we would not have to touch the other apps depending on PDC.
On 04/20/2018 10:34 AM, Pierre-Yves Chibon wrote:
Good Morning Everyone,
We have been informed thst week at the upstream devs working on the product-definition-center (PDC) are moving away from the project and are going to leave it without a maintainer. Since we adopted PDC for a variety of data flows, this puts us in an awkward position. :(
...snip..
I propose we start the discussion on the list and plan for a meeting sometime late next week to discuss it further with the interested parties (please signal yourself)
What do you think?
So, some generic thoughts:
* I kinda don't like the tree of files in git. It would work, but it seems poor, like we don't know how to use a database. Along with just strange to work with.
* Right now we have (I think) 3 Django apps... mailman3, pdc and ask. Of course the people doing the work should choose, but it seems like with Django there's always a treadmill of keeping it on the new version thats supported, etc. We ran into this with pdc recently where the version upstream was using wouldn't work with rhel or fedora django without work.
* If we are going to split out just the things we need, perhaps this would be a good time to try our hand at microservices? ie, small as we can make them, run in openshift, deploy quickly/all the time, etc If we do that we should make sure to gather requirements and only make those things we need to.
Definitely include me in on the planning... thanks.
kevin
On Fri, Apr 20, 2018 at 11:34 AM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
I propose we start the discussion on the list and plan for a meeting sometime late next week to discuss it further with the interested parties (please signal yourself)
I am reimplementing a small piece of PDC as well, because the RH Ceph Storage product uses/used PDC's v1/releases/{release_id}/rpm-mapping/{package}/ endpoint. I'd be interested in hearing where Fedora may be heading with their replacement ideas. Please let me know the time of the meeting :)
Prior to PDC, we had/have another internal solution that used a PostgreSQL database for what PDC calls rpm-mappings. We thought PDC would eventually replace this database. With this sytem, it was impossible to submit changes to the data store unless you were one of the few people who had rights to submit changes in postgres. Even reading the data out into something a mere mortal can understand was a chore.
Obviously there are many orthogonal problems there, and we could solve them with better APIs, docs, etc and still keep the Postgres backend. However it does strike me that flat YAML files in Git are an attractive backing store. It would make make it easier to submit and approve data changes, because anyone can submit pull requests to the flat files, and a CI system could test the changes before merging (or even auto-merge), etc.
- Ken
On Sat 21 Apr 2018 05:06:32 PM CEST Ken Dreyer wrote:
On Fri, Apr 20, 2018 at 11:34 AM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
I propose we start the discussion on the list and plan for a meeting sometime late next week to discuss it further with the interested parties (please signal yourself)
I am reimplementing a small piece of PDC as well, because the RH Ceph Storage product uses/used PDC's v1/releases/{release_id}/rpm-mapping/{package}/ endpoint. I'd be interested in hearing where Fedora may be heading with their replacement ideas. Please let me know the time of the meeting :)
Prior to PDC, we had/have another internal solution that used a PostgreSQL database for what PDC calls rpm-mappings. We thought PDC would eventually replace this database. With this sytem, it was impossible to submit changes to the data store unless you were one of the few people who had rights to submit changes in postgres. Even reading the data out into something a mere mortal can understand was a chore.
Obviously there are many orthogonal problems there, and we could solve them with better APIs, docs, etc and still keep the Postgres backend. However it does strike me that flat YAML files in Git are an attractive backing store. It would make make it easier to submit and approve data changes, because anyone can submit pull requests to the flat files, and a CI system could test the changes before merging (or even auto-merge), etc.
The difference is that PDC rpm-mappings API endpoint was result of two sources: * Manual per-rpm mappings (overrides) - this is sort of suitable if you have a product with just a couple source packages so it's manageable this way (i.e Ceph case) * Results of compose metadata import - this is what Fedora/RHEL uses because several thousands of source packages are not manageable one-by-one by humans manually.
You could still make a system that would create "PRs" for the generated files for second case, but then querying the current state will still be a bit tricky. I guess...
On Sun, Apr 22, 2018 at 2:23 AM, Stanislav Ochotnicky sochotnicky@redhat.com wrote:
The difference is that PDC rpm-mappings API endpoint was result of two sources:
- Manual per-rpm mappings (overrides) - this is sort of suitable if you have a product with just a couple source packages so it's manageable this way (i.e Ceph case)
- Results of compose metadata import - this is what Fedora/RHEL uses because several thousands of source packages are not manageable one-by-one by humans manually.
You could still make a system that would create "PRs" for the generated files for second case, but then querying the current state will still be a bit tricky. I guess...
Yeah, the fact that we have (at least) two different input and storage methods there is a lot of complexity. I'm not sure that's a good design in 2018.
Regardless, you're right, I'm envisioning that we'd have a tool to generate the data commits and PRs (or just commit + push directly). PDC had included its own rudimentary form of version control for auditing and message bus integration. Git's experience is much richer.
- Ken
- I kinda don't like the tree of files in git. It would work, but it
seems poor, like we don't know how to use a database. Along with just strange to work with.
We could use Git repo of yaml files as the basis but import data upon each commit for each branch into a locally mounted sqlite DB. Commits would be rejected if the import could not be completed. Then setup just a tiny API upon that sqlite DB served by some micro webapp.
Access control, versioning and write access would be handled by Git, but user-friendly, fast, read-only data access would be handled by the sqlite + http API pair.
The Git backend can also probably also added later.
I am writing this because I think it's an interesting option from the technical perspective, not because I would be actually involved with PDC at the moment. I just wanted to share the idea in case somebody finds it applicable.
clime
On Mon, Apr 23, 2018 at 7:34 PM, Ken Dreyer ktdreyer@ktdreyer.com wrote:
On Sun, Apr 22, 2018 at 2:23 AM, Stanislav Ochotnicky sochotnicky@redhat.com wrote:
The difference is that PDC rpm-mappings API endpoint was result of two sources:
- Manual per-rpm mappings (overrides) - this is sort of suitable if you have a product with just a couple source packages so it's manageable this way (i.e Ceph case)
- Results of compose metadata import - this is what Fedora/RHEL uses because several thousands of source packages are not manageable one-by-one by humans manually.
You could still make a system that would create "PRs" for the generated files for second case, but then querying the current state will still be a bit tricky. I guess...
Yeah, the fact that we have (at least) two different input and storage methods there is a lot of complexity. I'm not sure that's a good design in 2018.
Regardless, you're right, I'm envisioning that we'd have a tool to generate the data commits and PRs (or just commit + push directly). PDC had included its own rudimentary form of version control for auditing and message bus integration. Git's experience is much richer.
- Ken
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists. fedoraproject.org
On Sat, Apr 21, 2018 at 5:06 PM, Ken Dreyer ktdreyer@ktdreyer.com wrote:
On Fri, Apr 20, 2018 at 11:34 AM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
I propose we start the discussion on the list and plan for a meeting sometime late next week to discuss it further with the interested parties (please signal yourself)
I am reimplementing a small piece of PDC as well, because the RH Ceph Storage product uses/used PDC's v1/releases/{release_id}/rpm-mapping/{package}/ endpoint.
For reference, this project to replace PDC's rpm-mappings endpoint is now open-source at https://github.com/ktdreyer/product-listings-manager
I'm not sure if Fedora's currently using the rpm-mappings part of PDC, but I figured I'd mention that this is where we're heading with RH product variant rpm mappings.
- Ken
Hello, please include me in the planning too. I happen to know Django and PDC a bit, and want to help.
Lubomír
Pierre-Yves Chibon píše v Pá 20. 04. 2018 v 19:34 +0200:
Good Morning Everyone,
We have been informed thst week at the upstream devs working on the product-definition-center (PDC) are moving away from the project and are going to leave it without a maintainer. Since we adopted PDC for a variety of data flows, this puts us in an awkward position. :(
Ralph and I met up on Tuesday to brainstorm the list of things we actively use PDC for today and to come up with a contingency plan for how to handle them. One overarching option is for us (fedora-infra) to take ownership of the PDC codebase as a whole. We didn't fully explore this option, figuring that the codebase is large and contains lots of tables, endpoints, and codepaths that we didn't use nor which we plan to use.
Instead, below we've got the four things we use PDC for and some options for what to do with each.
With the exception of /modules/, one common pattern that we like is to investigate splitting out the "django apps" that make up PDC into their own projects. We're calling these "pdc-lite", for fun. See more below.
- Modules The data in the /modules/ PDC endpoint is *also* in the MBS
db. Ralph's team is going to just use that and stop using pdc anything for modules. We're going to need to patch pungi, mbs for local builds, and a few other places. This should be a relatively low-pain transition.
- Stream branches, branch ownership, retirement dates?
- SLA/EOL are currently stored in PDC.
- Queried by releng scripts for retirement, fedrepo-req for new
branches, etc.. option #1 git repo full of yaml file similar to the override repo compiled into a single JSON blob Single place for all retired packages This feels like the lowest tech option. git gives us change control for free... but people easily get lost in the "UX" of navigating a gigantic git repo full of plaintext files. option #2 pagure's DB/API pagure knows nothing about branches currently, so that would be bigger lift option #3 PDC internally is composed of ~20 "django apps" https://github.com/product-definition-center/product-definition -center/tree/master/pdc/apps We could pick the 2 or 3 that comprise the branches feature, copy them out, and turn them into their own service: the "branch definition center": BDC. That would be the "pdc-lite" approach mentionned above, ie: PDC with only the "app" of interest
- release/life-circle tracking? option #1: PDC lite with just that app of interest option #2: JSON/yaml file on the proxies option #3: pkgdb-lite option #4: ??? compose tracking? impacted: fedfind option #1: PDC-lite with just that app of interest option #2: Drop this entirely? Adam probably really wants to keep the record of composes. option #3: ???
The "pdc-lite" options are attractive, across the board. One thing we get from this is greater clarity when discussing things formerly in PDC. If something is in the branch-definition-center, the compose-definition-center, or the release-definition-center.. you know what you're talking about. Today, when talking about whether or not something should be or is in "PDC", it is easy to get confused.
I propose we start the discussion on the list and plan for a meeting sometime late next week to discuss it further with the interested parties (please signal yourself)
What do you think?
Pierre and Ralph
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproj ect.org
Hi, is it too late? I want to help as well.
On Fri, 2018-04-20 at 19:34 +0200, Pierre-Yves Chibon wrote:
Good Morning Everyone,
We have been informed thst week at the upstream devs working on the product-definition-center (PDC) are moving away from the project and are going to leave it without a maintainer. Since we adopted PDC for a variety of data flows, this puts us in an awkward position. :(
Ralph and I met up on Tuesday to brainstorm the list of things we actively use PDC for today and to come up with a contingency plan for how to handle them. One overarching option is for us (fedora-infra) to take ownership of the PDC codebase as a whole. We didn't fully explore this option, figuring that the codebase is large and contains lots of tables, endpoints, and codepaths that we didn't use nor which we plan to use.
Instead, below we've got the four things we use PDC for and some options for what to do with each.
With the exception of /modules/, one common pattern that we like is to investigate splitting out the "django apps" that make up PDC into their own projects. We're calling these "pdc-lite", for fun. See more below.
- Modules The data in the /modules/ PDC endpoint is *also* in the MBS
db. Ralph's team is going to just use that and stop using pdc anything for modules. We're going to need to patch pungi, mbs for local builds, and a few other places. This should be a relatively low-pain transition.
- Stream branches, branch ownership, retirement dates?
- SLA/EOL are currently stored in PDC.
- Queried by releng scripts for retirement, fedrepo-req for new
branches, etc.. option #1 git repo full of yaml file similar to the override repo compiled into a single JSON blob Single place for all retired packages This feels like the lowest tech option. git gives us change control for free... but people easily get lost in the "UX" of navigating a gigantic git repo full of plaintext files. option #2 pagure's DB/API pagure knows nothing about branches currently, so that would be bigger lift option #3 PDC internally is composed of ~20 "django apps" https://github.com/product-definition-center/product-definition -center/tree/master/pdc/apps We could pick the 2 or 3 that comprise the branches feature, copy them out, and turn them into their own service: the "branch definition center": BDC. That would be the "pdc-lite" approach mentionned above, ie: PDC with only the "app" of interest
- release/life-circle tracking? option #1: PDC lite with just that app of interest option #2: JSON/yaml file on the proxies option #3: pkgdb-lite option #4: ??? compose tracking? impacted: fedfind option #1: PDC-lite with just that app of interest option #2: Drop this entirely? Adam probably really wants to keep the record of composes. option #3: ???
The "pdc-lite" options are attractive, across the board. One thing we get from this is greater clarity when discussing things formerly in PDC. If something is in the branch-definition-center, the compose-definition-center, or the release-definition-center.. you know what you're talking about. Today, when talking about whether or not something should be or is in "PDC", it is easy to get confused.
I propose we start the discussion on the list and plan for a meeting sometime late next week to discuss it further with the interested parties (please signal yourself)
What do you think?
Pierre and Ralph
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproj ect.org
On Thu, 2018-05-17 at 10:09 +0800, Chenxiong Qi wrote:
Hi, is it too late? I want to help as well.
Hello, I just realized the part "is it too late?" could be ambiguous and confuse people. Sorry for my poor English. I just meant I want to help. :)
Regards, Chenxiong Qi
On Fri, 2018-04-20 at 19:34 +0200, Pierre-Yves Chibon wrote:
Good Morning Everyone,
We have been informed thst week at the upstream devs working on the product-definition-center (PDC) are moving away from the project and are going to leave it without a maintainer. Since we adopted PDC for a variety of data flows, this puts us in an awkward position. :(
Ralph and I met up on Tuesday to brainstorm the list of things we actively use PDC for today and to come up with a contingency plan for how to handle them. One overarching option is for us (fedora-infra) to take ownership of the PDC codebase as a whole. We didn't fully explore this option, figuring that the codebase is large and contains lots of tables, endpoints, and codepaths that we didn't use nor which we plan to use.
Instead, below we've got the four things we use PDC for and some options for what to do with each.
With the exception of /modules/, one common pattern that we like is to investigate splitting out the "django apps" that make up PDC into their own projects. We're calling these "pdc-lite", for fun. See more below.
- Modules The data in the /modules/ PDC endpoint is *also* in the MBS
db. Ralph's team is going to just use that and stop using pdc anything for modules. We're going to need to patch pungi, mbs for local builds, and a few other places. This should be a relatively low-pain transition.
- Stream branches, branch ownership, retirement dates?
- SLA/EOL are currently stored in PDC.
- Queried by releng scripts for retirement, fedrepo-req for new
branches, etc.. option #1 git repo full of yaml file similar to the override repo compiled into a single JSON blob Single place for all retired packages This feels like the lowest tech option. git gives us change control for free... but people easily get lost in the "UX" of navigating a gigantic git repo full of plaintext files. option #2 pagure's DB/API pagure knows nothing about branches currently, so that would be bigger lift option #3 PDC internally is composed of ~20 "django apps" https://github.com/product-definition-center/product-definiti on -center/tree/master/pdc/apps We could pick the 2 or 3 that comprise the branches feature, copy them out, and turn them into their own service: the "branch definition center": BDC. That would be the "pdc-lite" approach mentionned above, ie: PDC with only the "app" of interest
- release/life-circle tracking? option #1: PDC lite with just that app of interest option #2: JSON/yaml file on the proxies option #3: pkgdb-lite option #4: ??? compose tracking? impacted: fedfind option #1: PDC-lite with just that app of interest option #2: Drop this entirely? Adam probably really wants to keep the record of composes. option #3: ???
The "pdc-lite" options are attractive, across the board. One thing we get from this is greater clarity when discussing things formerly in PDC. If something is in the branch-definition-center, the compose-definition-center, or the release-definition-center.. you know what you're talking about. Today, when talking about whether or not something should be or is in "PDC", it is easy to get confused.
I propose we start the discussion on the list and plan for a meeting sometime late next week to discuss it further with the interested parties (please signal yourself)
What do you think?
Pierre and Ralph
infrastructure mailing list -- infrastructure@lists.fedoraproject.o rg To unsubscribe send an email to infrastructure-leave@lists.fedorapr oj ect.org
On Thu, May 17, 2018 at 10:09:21AM +0800, Chenxiong Qi wrote:
Hi, is it too late? I want to help as well.
No it's not too late, PDC is currently a little bit on the back fire due to other priorities but we'll need to get back to it (I expect around early June).
I will gather all parties who expressed interest in this thread in a meeting so we can move this forward then :)
Thanks for your interest!
Pierre
Good Morning Everyone,
So there has been a number of person who expressed in this topic. The list I have so far is: - Clime - bowlofeggs - cverna - nirik - lsedlar - abompard - cqi - Ken Dreyer - ralphbean - mboddu
I propose that we meet up next week on Monday at 14:00 UTC.
What do you prefer, IRC or video (bluejeans)?
What do you all think?
Pierre
On Thu, 7 Jun 2018 at 20:34, Randy Barlow bowlofeggs@fedoraproject.org wrote:
On 06/07/2018 12:20 PM, Pierre-Yves Chibon wrote:
I propose that we meet up next week on Monday at 14:00 UTC.
Works for me.
That works for me too
What do you prefer, IRC or video (bluejeans)?
I have a slight preference for IRC.
No preference
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro...
On 06/07/2018 09:20 AM, Pierre-Yves Chibon wrote:
Good Morning Everyone,
So there has been a number of person who expressed in this topic. The list I have so far is:
- Clime
- bowlofeggs
- cverna
- nirik
- lsedlar
- abompard
- cqi
- Ken Dreyer
- ralphbean
- mboddu
I propose that we meet up next week on Monday at 14:00 UTC.
A bit early for me, but if others can all make it I can read the logs/notes and chime in after that if I have any questions...
What do you prefer, IRC or video (bluejeans)?
IRC would be nice as I can read the discussion later... but again if everyone is doing bluejeans thats fine.
kevin
On Thu, Jun 7, 2018 at 10:20 AM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
I propose that we meet up next week on Monday at 14:00 UTC.
Thanks. That works for me.
- Ken
On 06/08/2018 12:20 AM, Pierre-Yves Chibon wrote:
Good Morning Everyone,
So there has been a number of person who expressed in this topic. The list I have so far is:
- Clime
- bowlofeggs
- cverna
- nirik
- lsedlar
- abompard
- cqi
- Ken Dreyer
- ralphbean
- mboddu
I propose that we meet up next week on Monday at 14:00 UTC.
What do you prefer, IRC or video (bluejeans)?
It's a bit late for me. I prefer IRC that I can read the discussion later.
What do you all think?
Pierre
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro...
Pierre-Yves Chibon píše v Čt 07. 06. 2018 v 18:20 +0200:
Good Morning Everyone,
So there has been a number of person who expressed in this topic. The list I have so far is:
- Clime
- bowlofeggs
- cverna
- nirik
- lsedlar
- abompard
- cqi
- Ken Dreyer
- ralphbean
- mboddu
I propose that we meet up next week on Monday at 14:00 UTC.
What do you prefer, IRC or video (bluejeans)?
What do you all think?
The time works for me, and I have no preference over irc or bluejeans.
Lubomír
On Fri, Jun 8, 2018 at 8:58 AM, Lubomír Sedlář lubomir.sedlar@gmail.com wrote:
Pierre-Yves Chibon píše v Čt 07. 06. 2018 v 18:20 +0200:
Good Morning Everyone,
So there has been a number of person who expressed in this topic. The list I have so far is:
- Clime
- bowlofeggs
- cverna
- nirik
- lsedlar
- abompard
- cqi
- Ken Dreyer
- ralphbean
- mboddu
I propose that we meet up next week on Monday at 14:00 UTC.
What do you prefer, IRC or video (bluejeans)?
What do you all think?
Time is ok. I very slightly prefer irc.
clime
The time works for me, and I have no preference over irc or bluejeans.
Lubomír _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists. fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ infrastructure@lists.fedoraproject.org/message/ OP33GEBX2NQPZTREYSPOHPWSJHSEOKA2/
On Thu, Jun 07, 2018 at 06:20:43PM +0200, Pierre-Yves Chibon wrote:
Good Morning Everyone,
So there has been a number of person who expressed in this topic. The list I have so far is:
- Clime
- bowlofeggs
- cverna
- nirik
- lsedlar
- abompard
- cqi
- Ken Dreyer
- ralphbean
- mboddu
I propose that we meet up next week on Monday at 14:00 UTC.
It seems we all prefer IRC, I propose we use the #fedora-apps room on freenode. We can always fall back to one of the #fedora-meeting room is -apps is too chatty (in other words: don't do PRs in the middle of the meeting :)).
Pierre
infrastructure@lists.fedoraproject.org
-
Aurelien Bompard -
Chenxiong Qi -
Clement Verna -
Ken Dreyer -
Kevin Fenzi -
Lubomír Sedlář -
Michal Novotny -
Pierre-Yves Chibon -
Randy Barlow -
Stanislav Ochotnicky