Re: [foreman-dev] Propsing a move from Google Groups to Discourse
Greg, I absolutely understand the motivation, every two years amount of programmers doubles. That is a crazy amount of newcomers. But these new people are not idiots and some technical level is required even for soft roles in our community. And we can make lists approachable very much like forums. Do not put me into position of blind and angry dev who can't accept something different or new. I understand all contexts and I say Discourse is an overkill that will bother me and possibly others. God I wish Google Groups are gone, but not for this. > * do nothing Honestly, yeah. > * switch mailing list for minimal improvement s/minimal/reasonable/ > * switch to a forum, big upheaval but potential big payoff Sure, because there are no downsides. It's not about a list standard e-mail headers. The forum has different workflow and features and there will be new features as well while mailing list will stay the same. This will screw my inbox. This will but a wall between e-mail users and web forum users. This is what's this all about. And I think we don't need to go that direction. LZ On Fri, Nov 3, 2017 at 6:45 PM, Greg Sutcliffe wrote: > One more thought occurred to me while I was out on the nursery pickup, so > I'll drop here before I bow out for the weekend. > > Lukas, I think part of our disagreement is our different goals. As I > highlighted in the last mail, users behave differently to devs. These days I > consider myself more user than dev (when did I last contribute code), so I > have a different world view. > > You want to protect a tried and trusted workflow, likely used by many here - > that's fine. My job is to promote and develop the user community, so I see > room for improvement. > > Here's the catch though... Our future devs, as a community, *come from* the > user community. If we don't focus there, then we risk stagnating the dev > community too. > > I won't deny this change is a larger net benefit for the user group. The case > for the dev community is harder to argue. But there *is* benefit, and > compared to running a list (for dev) and a forum (for users) I think the > better argument is to use a forum for both. > > I don't expect to convince everyone, so this is going to come down to a group > decision - but not for a while yet. We need to do more tests. > > Have a great weekend all, > Greg > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Later, Lukas @lzap Zapletal -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Propsing a move from Google Groups to Discourse
I also think it's important to note that just because things like mailman have existed for years and will continue to exist for years does not mean they're always the best tool for the job. As open source developers it's also important to be _open_ to change, and always to evaluate what the best tool to get the job done is. A false dichotomy for sure, but: can I continue running CentOS 5 or Solaris 10? Sure, but it probably will stagnate me from doing what I want to do. It's like doing "DevOps" by using clusterssh to run commands on all your servers instead of a config management tool. Greg is right--many would-be new developers _are_ turned off from things like mailing lists. I know because I used to be turned off by them--and to a certain extent, still am. There's nothing worse than finding a `-dev` list on google for an issue you're having and not being able to find or indeed _know_ if there's a response to a thread: Forum-type solutions don't have that issue, and as long as they support email, even if it's not "first", then I think any distruption in workflow, if limited, is worth it to encourage new voices. I recently graduated from University, and know a lot of people that wouldn't step near a mailing list for development--and would be especially reluctant to contribute to them. To many "next gen" developers, email is not the workflow they will choose to adopt, and sticking with listservs because they have always been and will always be is not a good enough reason in my opinion. (Please note this is mostly random rambling on my behalf, and entirely opinion based to attempt to give insight from someone who's only recently joined the whole process) On Fri, Nov 3, 2017 at 1:45 PM Greg Sutcliffe wrote: > One more thought occurred to me while I was out on the nursery pickup, so > I'll drop here before I bow out for the weekend. > > Lukas, I think part of our disagreement is our different goals. As I > highlighted in the last mail, users behave differently to devs. These days > I consider myself more user than dev (when did I last contribute code), so > I have a different world view. > > You want to protect a tried and trusted workflow, likely used by many here > - that's fine. My job is to promote and develop the user community, so I > see room for improvement. > > Here's the catch though... Our future devs, as a community, *come from* > the user community. If we don't focus there, then we risk stagnating the > dev community too. > > I won't deny this change is a larger net benefit for the user group. The > case for the dev community is harder to argue. But there *is* benefit, and > compared to running a list (for dev) and a forum (for users) I think the > better argument is to use a forum for both. > > I don't expect to convince everyone, so this is going to come down to a > group decision - but not for a while yet. We need to do more tests. > > Have a great weekend all, > Greg > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Propsing a move from Google Groups to Discourse
One more thought occurred to me while I was out on the nursery pickup, so I'll drop here before I bow out for the weekend. Lukas, I think part of our disagreement is our different goals. As I highlighted in the last mail, users behave differently to devs. These days I consider myself more user than dev (when did I last contribute code), so I have a different world view. You want to protect a tried and trusted workflow, likely used by many here - that's fine. My job is to promote and develop the user community, so I see room for improvement. Here's the catch though... Our future devs, as a community, *come from* the user community. If we don't focus there, then we risk stagnating the dev community too. I won't deny this change is a larger net benefit for the user group. The case for the dev community is harder to argue. But there *is* benefit, and compared to running a list (for dev) and a forum (for users) I think the better argument is to use a forum for both. I don't expect to convince everyone, so this is going to come down to a group decision - but not for a while yet. We need to do more tests. Have a great weekend all, Greg -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Propsing a move from Google Groups to Discourse
Putting what I think is the more important part first ... On 03/11/17 13:30, Lukas Zapletal wrote: > What we are running is a mailing list here. We are running a mailing list *today*, and you're right, I want to change that. This may well be where we simply have to stop and let others join in the conversation, as I don't think either of us is going to back down ;) > It's a mailing list, we are open source developers and this is our > way of communication. It's *your* preferred way of communication, yes (and probably mine too, to be honest). Don't forecast that onto all 2500 users signed up to our lists, though - we may be in a minority. I'll quote from the Art of Community here: "Each type of contributor will have different preferences. Software developers generally prefer content to be delivered directly to them. They are typically most comfortable with mailing lists and RSS feeds (updated content from websites and online resources) and don’t like to have to refresh a browser to see if new content exists. This is part of why many (typically Western) developers don’t get on very well with forums." "Users are (typically) different. Users often love forums for their accessibility and simplicity. The conversation flow is clear, the interface is friendly, and the web browser is a familiar window to that world. Users are used to having to refresh their browser to see if updates exist. They are used to visiting many websites to find content, and they generally feel uncomfortable about technical barriers to these discussions and content. Users just don’t like to jump through hoops, particularly technical hoops that can easily trip them up." Now our users are more technical than most, but still, this has been my experince as well - users want shiny, developers do not. Honestly I'm surprised no one else has complained along with you yet :) > I understand how this is supposed to work technically, but will my > gmail.com handle this correctly? This is not how e-mail lists are > supposed to work. Will my MUA work correctly? Won't I see broken > threads because folks will introduce new shiny feature into Discourse > that does not play with plain emails anymore? I can't tell. Yeah you > set up a testing instance, but there is almost no real traffic and I > really don't know how it will look like with thousands of emails. My > MUA handles millions of them just fine. These are well documented standards. In my emails I'm seeing what I think are the right headers: List-ID: List-Archive: List-Unsubscribe: Auto-Submitted: auto-generated In-Reply-To: <90019b41-28a7-babc-65da-5843e2098...@emeraldreverie.org> References: <90019b41-28a7-babc-65da-5843e2098...@emeraldreverie.org> Precedence: list That, I believe, should be sufficient, and things are getting threaded here, at least with the volume I have. As you say, we need more volume to be sure, which is *exactly* why I've made a test category for people to mess with before we take any decisions. Please try it out! We won't know unless we try, and that means at least a few people making a thread in the testing area, with mailing list mode enabled (under personal prefs > email) (Note there's a 2 min delay in creating new topics, 30s delay betweem posts to the same topic, and a 5s delay for any new post - going faster than that will mean you'll get a bounce) Also, it seems Ohad didn't get around to enabling the mailforward I requested, which is why topic creation by email was failing (yay DNS). I've re-used the dev one for now, emails to community-...@theforeman.org seem to be working fine for creating topics in the test area (i've started one to test inline replies with too, which see to be persed nicely). > Ever been to XdaDevelopers searching for Android ROM? Oh god, XDA is awful, yes, we are not going there. But the fact is we have some issues with our users list (the dev list benefits less from this, again because of that quote above, but it *does* benefit, and I don't want to run a forum *and* a list). You may not like recommended topics, but it could be of significant benefit to the users group (and actually it can be restricted by category). Like any tool, if you use it wrong its a bad thing (like XDA). > My response is not about "look here is an alternative HyperKitty". I'd > be fine with any other mailing list And there's our impasse, I want to move away from a list. But it doesn't change the choice in front of us: * do nothing * switch mailing list for minimal improvement * switch to a forum, big upheaval but potential big payoff > Yeah, feels like I am the only one. Not a good feeling, really. Give it time. I doubt you are alone, and this debate is not done. Cheers, Greg -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d
Re: [foreman-dev] Moving katello puppet modules to the foreman github namespace
All repositories have been transfered to theforeman Github organization. A new team has been created named 'Katello Installer' that contains all puppet modules and users from the same team in the Katello github organization. On Fri, Nov 3, 2017 at 9:50 AM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: > On Fri, Nov 03, 2017 at 09:28:18AM -0400, Eric D Helms wrote: > >> On Fri, Nov 3, 2017 at 9:03 AM, Ewoud Kohl van Wijngaarden < >> ew...@kohlvanwijngaarden.nl> wrote: >> >> Not sure if I understand what you mean. Are you saying to create a katello >>> installer team in theforeman org to match it with the katello org one? >>> That >>> was similar to what I was thinking. It's the easiest in the short term >>> and >>> we can easily iterate from there. >>> >> >> >> Yes, thanks for clarifying. Essentially, just port the existing team over >> and we can then go from there towards future integrations between >> repositories and teams. All the modulesync PRs are merged. I'll create the >> team and then transfer each module if you are ready? >> > > I'm ready. > > > On Thu, Nov 02, 2017 at 01:42:31PM -0400, Eric D Helms wrote: >>> >>> I am ready to move them when you give the green light. My inclination for permissions and team setup would be to maintain all individual maintership on the modules to date. Further, to take the katello installer team and add them to a similar installer team on theforeman organization. On Thu, Nov 2, 2017 at 12:38 PM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: Hello all, > > Previously this has been discussed in various threads but now we're > ready > to make it a reality. All modules should be ready to use a single > modulesync repository and a pull request has been opened. > https://github.com/theforeman/foreman-installer-modulesync/pull/78 > lists all tasks that need to be completed. > > Some important things to note: > > * We invite users to submit redmine issues to the foreman installer > project. Previously we only pointed them to Redmine without specific > directions. > * We will continue to publish modules on the puppet forge under the > katello user. Moving modules there requires a bit more effort for > little > benefit. > * This does (not yet) include merging the installers. For now > foreman-installer won't ship the katello modules. > > -- >>> You received this message because you are subscribed to the Google Groups >>> "foreman-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to foreman-dev+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >> >> >> -- >> Eric D. Helms >> Red Hat Engineering >> >> -- >> You received this message because you are subscribed to the Google Groups >> "foreman-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-dev+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Eric D. Helms Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[foreman-dev] Rails log is now printed for failed tests
Hey, just to want to increase visiblity of this patch: https://github.com/theforeman/foreman/pull/4739 In short, when you have a test failure, there should be a relevant Rails log printed on standard output. You can opt-out this via ENV variable if you don't like this, but I find this very useful particularly on our Jenkins when debugging tests. -- Later, Lukas @lzap Zapletal -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Moving katello puppet modules to the foreman github namespace
On Fri, Nov 03, 2017 at 09:28:18AM -0400, Eric D Helms wrote: On Fri, Nov 3, 2017 at 9:03 AM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: Not sure if I understand what you mean. Are you saying to create a katello installer team in theforeman org to match it with the katello org one? That was similar to what I was thinking. It's the easiest in the short term and we can easily iterate from there. Yes, thanks for clarifying. Essentially, just port the existing team over and we can then go from there towards future integrations between repositories and teams. All the modulesync PRs are merged. I'll create the team and then transfer each module if you are ready? I'm ready. On Thu, Nov 02, 2017 at 01:42:31PM -0400, Eric D Helms wrote: I am ready to move them when you give the green light. My inclination for permissions and team setup would be to maintain all individual maintership on the modules to date. Further, to take the katello installer team and add them to a similar installer team on theforeman organization. On Thu, Nov 2, 2017 at 12:38 PM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: Hello all, Previously this has been discussed in various threads but now we're ready to make it a reality. All modules should be ready to use a single modulesync repository and a pull request has been opened. https://github.com/theforeman/foreman-installer-modulesync/pull/78 lists all tasks that need to be completed. Some important things to note: * We invite users to submit redmine issues to the foreman installer project. Previously we only pointed them to Redmine without specific directions. * We will continue to publish modules on the puppet forge under the katello user. Moving modules there requires a bit more effort for little benefit. * This does (not yet) include merging the installers. For now foreman-installer won't ship the katello modules. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Eric D. Helms Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Propsing a move from Google Groups to Discourse
> So if I understand, you're OK with a web interface for creating / > managing a conversation that you don't want in your inbox in Hyperkitty, > but not happy with exactly the same workflow in Discourse? I find that > hard to resolve, can you clarify? All I want is standard mailman-like list experience. This is a regression in behavior, a change from a list to forum. Let me explain down below. > I disagree with the word "hack" here, I think Discourse also works fine > over email. In all the testing I've done, the only thing I'm seeing is a > minor issue with format=flowed URLs (and tbh not all mail clients > support that either). You can set the mailing-list mode flag and it will > email you everything, you need never log into the UI again. I've had > that flag set for the last week, and can confirm that I was recieving > everything and could reply/start threads just fine. How is this > different to a mailing list? I understand how this is supposed to work technically, but will my gmail.com handle this correctly? This is not how e-mail lists are supposed to work. Will my MUA work correctly? Won't I see broken threads because folks will introduce new shiny feature into Discourse that does not play with plain emails anymore? I can't tell. Yeah you set up a testing instance, but there is almost no real traffic and I really don't know how it will look like with thousands of emails. My MUA handles millions of them just fine. Mailman will be here for another 20 years and more. It will work as long as e-mails are alive. And I do believe it's not going anywhere. > It has to be said, I do like Hyperkitty, and I agree it would be an > improvement over Google Groups. However, it doesn't address many of the > use cases in my original post (and followups): All of these are nice things, Greg. But these are irrelevant. What we are running is a mailing list here. It's a mailing list, we are open source developers and this is our way of communication. People do not need "powers". Powers to do what with? Lock topics? Create complicated sub-groups structures? Mute people or delete posts? This is what I hate about forums. Pins and banners? Totally hate these. Ever been to XdaDevelopers searching for Android ROM? God that's awful, this is how it all ends - complicated pinned neverending threads with things like "This post is reserved". And dozen of "recommended topics" which are always totally irrelevant. Let's just run a mailing list please. If you want to do your statistics or gamify this, take this offline. There are tools generating mail statistics. Fedora have concept of badges, it is all doable. > The summary seems to be that Discourse can do *everything* Hyperkitty > can, and from my testing, even the email support is first class. Both > are open, both can be hacked on if needed, both can be hosted or > self-hosted. But only Discourse brings more power and flexibility to the > table, both immediately, and for anything other needs we may have in > the future. You are comparing apple and orange here. A forum with a mailing list. I say let's stick with an orange, a mailing list. My response is not about "look here is an alternative HyperKitty". I'd be fine with any other mailing list (*) with nice user archive with easy entry for newcomers. It's about keeping our discussion where it belongs. (*) mailing list - a software that keeps emails in plain form not in some kind of a database > I'm *very* interested to hear others views though! Yeah, feels like I am the only one. Not a good feeling, really. -- Later, Lukas @lzap Zapletal -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Moving katello puppet modules to the foreman github namespace
On Fri, Nov 3, 2017 at 9:03 AM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: > Not sure if I understand what you mean. Are you saying to create a katello > installer team in theforeman org to match it with the katello org one? That > was similar to what I was thinking. It's the easiest in the short term and > we can easily iterate from there. Yes, thanks for clarifying. Essentially, just port the existing team over and we can then go from there towards future integrations between repositories and teams. All the modulesync PRs are merged. I'll create the team and then transfer each module if you are ready? > > > On Thu, Nov 02, 2017 at 01:42:31PM -0400, Eric D Helms wrote: > >> I am ready to move them when you give the green light. >> >> My inclination for permissions and team setup would be to maintain all >> individual maintership on the modules to date. Further, to take the >> katello >> installer team and add them to a similar installer team on theforeman >> organization. >> >> On Thu, Nov 2, 2017 at 12:38 PM, Ewoud Kohl van Wijngaarden < >> ew...@kohlvanwijngaarden.nl> wrote: >> >> Hello all, >>> >>> Previously this has been discussed in various threads but now we're ready >>> to make it a reality. All modules should be ready to use a single >>> modulesync repository and a pull request has been opened. >>> https://github.com/theforeman/foreman-installer-modulesync/pull/78 >>> lists all tasks that need to be completed. >>> >>> Some important things to note: >>> >>> * We invite users to submit redmine issues to the foreman installer >>> project. Previously we only pointed them to Redmine without specific >>> directions. >>> * We will continue to publish modules on the puppet forge under the >>> katello user. Moving modules there requires a bit more effort for little >>> benefit. >>> * This does (not yet) include merging the installers. For now >>> foreman-installer won't ship the katello modules. >>> >> > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Eric D. Helms Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Building a Rails 5.1 SCL
On Thu, Nov 2, 2017 at 6:24 AM, Daniel Lobato Garcia wrote: > I agree with all of that, definitely something to do in a different > repository. > > Just one question, my understanding is that you prefer to do this (SCL) > because we are uncertain of the time/effort required for vendoring the > gems/npm > packages. Given that long-term we would have to keep up building SCLs > (which if I’m not wrong are going to be less used from EL8 onward) and > maintaining > packages (which consumes a great deal of our time). > To be fair, I judged this based on what the community prefers not just my personal preference per the other thread. I do tend to still think NPM should be vendorized given how it does not provide runtime dependencies and only build time as well as the complex nature of how it handles packages and dependencies (and sheer scale of packages). Eric > > Parallel to this effort, do you think it’s worth moving forward with the > vendorization of npm so that gems can follow suit? > > -- > Daniel Lobato Garcia > > @dLobatog > blog.daniellobato.me > daniellobato.me > > GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30 > Keybase: https://keybase.io/elobato > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Eric D. Helms Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Building a Rails 5.1 SCL
On Thu, Nov 2, 2017 at 8:02 AM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: > On Wed, Nov 01, 2017 at 02:00:29PM -0400, Eric D Helms wrote: > >> In a previous thread [1], we discussed building an SCL vs. vendorizing >> gems >> and the general consensus was to build an SCL. This thread is to outline a >> starting plan for how to build and maintain a Rails 5.1 SCL. I invite and >> appreciate comments towards this design. >> >> I'll begin by laying out some overall goals for the effort, a general >> proposal of information and finally a breakdown of the why for each of the >> proposal items to better explain my thinking. >> >> >> Goals >> >> * Stand alone Rails 5.1 SCL and repository >> * Owned and maintained by the Foreman community >> * Easy to update and maintain >> * Strive for automation and package tooling to reduce maintenance cost >> >> >> Proposal >> >> Build location: Copr >> SCL Name: tfm-ror51 >> Git repository: theforeman/tfm-ror51-packaging >> Hosted: yum.theforeman.org/rails/tfm-ror51 >> RPM Signing: signed by unique Foreman owned GPG key >> Tooling Repo: create package tooling repository separate from >> tfm-ror51-packaging repo >> Tooling Technology: Ansible >> >> >> Breakdown >> >> Build Location >> >> There has been discussion around moving our RPM builds to Copr and off of >> Koji. This will require shifting our configuration and setup, testing and >> working out kinks in Copr workflow. Building this Rails SCL provides us an >> opportunity to use Copr from the start, get familiar with it and workout >> tooling to interact with and manage a repository there. Therefore, I am >> proposing to start with Copr from the get go and avoid Koji. >> > > +1 > > SCL Name >> >> Given the Foreman community will own the SCL, and our SCL namespace is >> 'tfm' I am suggesting we follow convention by naming it tfm-ror51. >> Previous >> Rails SCLs, were named similarly: rh-ror41, rh-ror42, sclo-ror42. >> > > +1 though we could look at creating a CentOS SIG to do it under the sclo > flag. IMHO this can be parallel to the development or even after the fact. > > Git Repository >> >> I am proposing we don't put this into foreman-packaging given the >> lifecycle >> of the SCL will not follow that of Foreman. Further, with the goal to >> create a stand-alone Rails SCL repository this should have its own >> lifecycle. >> > > +1 > > Hosted >> >> We could point at the direct Copr repository, and reduce our bandwidth. >> However, since we own this Rails SCL I believe we should host it as such >> officially. Further, this would allow us to do some pre-flight testing by >> building a repository in Copr, running a test of either the SCL itself >> and/or Foreman against the SCL updates before promoting. >> > > +1 > > This would be similar to how we now have koji: as a staging ground, we > test against this and promote if it's stable with the added benefit that > it's easier to consume. > > RPM Signing >> >> I am recommending here that we sign the SCL RPMs with a new GPG key >> generated just for signing the SCL packages. >> > > COPR signs repos by default with its own GPG key. Do you want a separate > GPG key when we host it on yum.theforeman.org? > > Tooling >> >> With an eye towards foreman-packaging changes, I am proposing we create a >> separate git repository for all package tooling. The goal here would to >> build out new tooling to allow easier maintenance of the packaging and >> repository. This will allow the tooling to evolve independently of either >> packaging repository. Further, when applying this tooling to >> foreman-packaging later, the tooling would not have to be duplicated >> across >> branches. >> > > +1 > > Tooling Technology >> >> I am proposing a centralization on Ansible as the tooling technology for a >> number of reasons. First, I feel that it has a low barrier to entry while >> providing a mix of high and low level interfaces. Secondly, Ansible allows >> orchestrating and building out more complex and directed tasks. Third, a >> team of us has some built out Ansible tooling that has been working well >> for us in another area that would be easy to port for packaging >> management. >> I personally think bash is complex to understand for complex actions and >> is >> too simple for building up a set of cohesive tooling. >> > > For me this depends. If an ansible playbook is just a list of commands > then IMHO it doesn't add much value over a shell script. If you use higher > level tools (modules?) then there's a great benefit in both readability and > maintainability. I could see us developing a copr module so we can use > copr_build and such. I might have to lay out more of what I am thinking, but based on some other work there is a chunk of neat and powerful stuff that be done by using Ansible + inventories with packages. Plus, as you said, modules give the ability to create some higher level abstractions. I also stand by that Ansible syntax is easier for new contributors
Re: [foreman-dev] Moving katello puppet modules to the foreman github namespace
Not sure if I understand what you mean. Are you saying to create a katello installer team in theforeman org to match it with the katello org one? That was similar to what I was thinking. It's the easiest in the short term and we can easily iterate from there. On Thu, Nov 02, 2017 at 01:42:31PM -0400, Eric D Helms wrote: I am ready to move them when you give the green light. My inclination for permissions and team setup would be to maintain all individual maintership on the modules to date. Further, to take the katello installer team and add them to a similar installer team on theforeman organization. On Thu, Nov 2, 2017 at 12:38 PM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: Hello all, Previously this has been discussed in various threads but now we're ready to make it a reality. All modules should be ready to use a single modulesync repository and a pull request has been opened. https://github.com/theforeman/foreman-installer-modulesync/pull/78 lists all tasks that need to be completed. Some important things to note: * We invite users to submit redmine issues to the foreman installer project. Previously we only pointed them to Redmine without specific directions. * We will continue to publish modules on the puppet forge under the katello user. Moving modules there requires a bit more effort for little benefit. * This does (not yet) include merging the installers. For now foreman-installer won't ship the katello modules. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Propsing a move from Google Groups to Discourse
Thanks Lukas - I wanted a healthy debate, and now I've got one :) This is indeed constructive - you've forced me to go back and examine my starting post more than a few times while writing this. That's a very good thing - we need to be sure of our goal here. There's a lot of good points here, and some not so good, so let me try to return the favour of some constructive criticism. I'll start with the points addressed to me, and then move on to comparing Hyperkitty with Discourse. On 03/11/17 10:52, Lukas Zapletal wrote: > I was planning not to reply, but I can't sorry. > I am sorry Greg, I know you invested a lot in this and you have some > positive experience in the past. Don't be sorry. This is a big change thats proposed, and we're not going to make everyone 100% happy. It well may be that I'm one of the people that's not happy with what we come to agree on :) Protyping things and working to improve the community is my job. It's not time wasted if the community decides to go another way. Again, no need to be sorry. We all want a good outcome. I don't like Discourse at all. <<< > Well my experience with Discourse is > rather bad, mostly from https://forum.turris.cz/ So I'll go into your arguments for Mailman / Hyperkitty further down, but you don't really say why you dislike Discourse - is it *solely* that it's not a mailing list, or is there more to it? > I also understand you might not be fully available for couple of next > months and it's just you if I understand correctly with experience > maintaining Discourse. I would rather preferred hosted solution on a > free as in freedom service (Fedora lists). You comment makes it sound like you're not aware of this (apologies if you are), but Discourse is also open source, and the hosting is on our own infra. As for myself, I will not be entirely gone, I'm just going to be a normal community member with a dayjob for a bit. I would expect to reply to urgent things within a few hours at most, there will be a decent selection of admins & moderators, and other people will have root access as per our base Puppet users module that goes on all our servers - I wouldn't be that irresponsible with something so critical to our operation. It's also true that we'd want to migrate in the early hours of the morning when all is quiet, and I'd be available for that for sure. OK, lets talk about software :) Rather that reply to each point individually, I want to try and gather your points and then compare them, so please do correct me if I miss anything. So I think you're saying: * Mailing lists are fine * email-centric * Open / data liberation etc * indexed by Google * Hyperkitty has * Social logins * Web-based message sending In addition, playing with the Fedora instance (admittedly briefly) I also see: * Some thread metrics (days inactive / old, tags, etc) * Participants in thread * some list metrics (active posters, list activity I can't see the list from a manager's point of view, so I'm not sure what level of metrics it can provide, but in general I'm sure that its better than Google Groups. Did I get everything? I hope so, I don't want to misrepresent you. Lets start by removing the things that Discourse also does. It's open source (https://github.com/discourse/), self-hosted on our own infra, and will be indexed by Google once I make it public. It also supports all the same social logins - I just kept it to GitHub to match Redmine. So that leaves us with: * Mailing lists are fine * email-centric * Hyperkitty has * Web-based message sending * Some post & thread metrics * Tag support (presumably UI only) There is, however, an interesting conflict in your mail - you say you're happy to start threads and manage a conversation entirely in the Hyperkity UI: > I sometimes use this for lists I don't want to get into my inbox on a > daily basis and it works just fine. To start a thread, it's just a > simple link and HyperKitty will just ask you to Sign-In with one of > your existing accounts. Super fast So if I understand, you're OK with a web interface for creating / managing a conversation that you don't want in your inbox in Hyperkitty, but not happy with exactly the same workflow in Discourse? I find that hard to resolve, can you clarify? > Benefits? Mailman works great over email, it's not just some hack I disagree with the word "hack" here, I think Discourse also works fine over email. In all the testing I've done, the only thing I'm seeing is a minor issue with format=flowed URLs (and tbh not all mail clients support that either). You can set the mailing-list mode flag and it will email you everything, you need never log into the UI again. I've had that flag set for the last week, and can confirm that I was recieving everything and could reply/start threads just fine. How is this different to a mailing list? It has to be said, I do like Hyperkitty, and I agree it would be an improvement over Google Groups. However, it doe
Re: Re: [foreman-dev] Building a Rails 5.1 SCL
On 11/02, Ewoud Kohl van Wijngaarden wrote: > On Thu, Nov 02, 2017 at 11:24:26AM +0100, Daniel Lobato Garcia wrote: > > Just one question, my understanding is that you prefer to do this (SCL) > > because we are uncertain of the time/effort required for vendoring the > > gems/npm > > packages. Given that long-term we would have to keep up building SCLs > > (which if I’m not wrong are going to be less used from EL8 onward) and > > maintaining > > packages (which consumes a great deal of our time). > > My expectation is that vendorizing RPMs would cost a similar time as > building the SCL. Given separate packaging has a lot of benefits over > bundling[1]. > > Thinking about this, we currently don't check the licenses of bundled npm > modules in our existing packaging. It's possible we currently ship something > we're not legally allowed to ship but we simply don't know.o Problem is - it's pretty much impossible to make npm work with the rpm model. Dependencies are different between libraries such that this is common: A depends on C > 1.5 B depends on C = 1.0 Foreman depends on A and B If we don't bundle, there's no way to tell RPM to install C >= 1.5 and C = 1.0 at the same time (as far as I know). About the legality problem - I think we should start creating some script that parses all the dependencies we have and their licenses and make a summary, then detect any possible conflicts... > > With regards to EL8 I think you're hinting at the modularization effort > that's currently in Fedora. For those unaware: it's aimed to be a much > better version of SCLs. Better integrated in the system but also allow > easily producing containers. At the moment there's still little > documentation and we'll likely support EL7 for a while so at this point I'm > not planning much. What we do want to do is move from our own Koji instance > to COPR. That should be prepared for modularization. Developing the SCL in > COPR can be seen as a first step in this process. > > [1]: > https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries#Why_Bundled_Libraries_are_a_problem > > > Parallel to this effort, do you think it’s worth moving forward with the > > vendorization of npm so that gems can follow suit? > > Personally I'd say gems shouldn't follow suit unless maintaining the SCL > proves too much work. In fact, the only reason I currently accept npm > vendorization is that we currently can't keep up with the changes. If we can > develop sufficient tooling I'd actually like to roll back npm vendorization > too when we can provide the same developer flexibility. As I said above - npm vendorization (at the level we do now with bundled-npm packages) isn't possible to roll back, at least to my knowledge > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30 Keybase: https://keybase.io/elobato -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
Re: [foreman-dev] Propsing a move from Google Groups to Discourse
Quick update... A few people have been posting to the users/dev categories on Discourse, so let me quickly clarify - there is no sync Discourse -> List. Anything you post there will not make back to the lists. To help prevent that, for now I've locked those 3 categories. Admins can still post, but everyone else just has See permissions. Obviously we'll unlock that if/when we move over. Greg -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [foreman-dev] Propsing a move from Google Groups to Discourse
I was planning not to reply, but I can't sorry. >>> I don't like Discourse at all. <<< I was hoping to get rid of Google Groups in favour of - wait for it - GNU Mailman! Yeah, you might think this would be step backwards, but let me explain. GNU Mailman is the core of open source. It's the heart, really. Similarly as git or other things. It helps to communicate millions of people for decades and it is nothing wrong with it. What is problematic and old is the entry barrier (it's a list) and the default mailman archival tool you may have already seen. This is how it looks like: https://lists.gnu.org/archive/html/weechat-dev/ Yeah, old, clunky interface and there is a need for new users to register into the list to be able to post. But hey, this has been already solved! It's called HyperKitty and Fedora already migrated to a year ago! Look, nice and clean interface with ability to send message right away from your browser: https://lists.fedoraproject.org/archives/ When you click on Sign In, there are about a dozen of account integrations including Google Plus, OpenID, GitLab, GitHub, Twitter, Facebook or StackExchange. That's plenty, way enough for our users to get started. Then click on an archive (not list) and click on Start New Thread. Yes, as easy as that. You can test on this testing mailing list: https://lists.fedoraproject.org/archives/list/test-mailman3%40lists.fedoraproject.org/ I sometimes use this for lists I don't want to get into my inbox on a daily basis and it works just fine. To start a thread, it's just a simple link and HyperKitty will just ask you to Sign-In with one of your existing accounts. Super fast: https://lists.fedoraproject.org/archives/list/test-mailm...@lists.fedoraproject.org/message/new Benefits? Mailman works great over email, it's not just some hack, it its main purpose. You also have a lot of options when you are receiving mail (daily, weekly, no copies etc), data is yours and not somewhere in cloud if you want to, archives are very fast and searchable via Google or anything pretty much. And your whole history is just bunch of emails, data liberation in practice. When I compare this to Google Groups or Discourse it also loads faster as there is less JavaScript I think. >>> My proposal is: Let's move to Fedora mailing lists with HyperKitty, it's a >>> reliable infrastructure. Problem solved. <<< I am sorry Greg, I know you invested a lot in this and you have some positive experience in the past. Well my experience with Discourse is rather bad, mostly from https://forum.turris.cz/ but if there is some chance to fix our terrible Google Groups, let's do it the "right way". I also understand you might not be fully available for couple of next months and it's just you if I understand correctly with experience maintaining Discourse. I would rather preferred hosted solution on a free as in freedom service (Fedora lists). On Wed, Nov 1, 2017 at 4:54 PM, Greg Sutcliffe wrote: > Hi all, > > As ever from me, this is long. Sorry about that, it's a habit. Here's > the TL;DR: > > * What: move Google Groups -> Discourse > * Why: https://blog.discourse.org/category/use-cases/ > * Can I try? - Scroll to the end for login details > > So, as some of you know, I'm a big fan of the Discourse[1] forum > software - I use it for another community, and it's just lovely. I've > been testing it out recently with a view to using it for Foreman, and > I think it's time to explain my reasoning and ask for your thoughts. > > # What? > > Firstly, the "what" - what do I want to do? Simply put, I want to > migrate from Google Groups to Discourse. That means locking the groups > from further emails and using Discourse for our "written" discussions. > Obviosuly there's data migration that needs to happen there, but we'll > get to that. > > Before all the die-hard mailing list fans stop reading here - please > keep reading. Discourse has options to interact entirely by email. > Your workflow may not be broken :) > > # Why? > > Why do I want this? The short version is "because anything is better > than Google Groups", but more seriously, I think Discourse is great. > The reasons are different for each of our mailing lists though, so let > me break it down: > > ## foreman-users > > When it comes to supporting our users, what matters is that they can > ask a question, get a reply, and feel confident in that reply. For > those who do the replying, they need to be highlight and in some way > rewarded for the work they do. > > The problem with a mailing list is that neither of these things is > really achievable. If a user (new to our list, who knows no-one) gets > 2 different replies, who is (s)he to trust? A forum can display user > levels, and badges, making the developer reply stand out from the > other new user's reply. A mailing list has nothing - and worse, the > Groups API is so bad that I barely know who our mailing list regulars > are (I have to webscrape it using a crawler ...) so I can re
Re: AW: [foreman-dev] Propsing a move from Google Groups to Discourse
On 02/11/17 17:46, Matthias Dellweg wrote: > Hi Greg, > so you tested the happy flow. But as a scientist i must ask you, did you check > the opposite, too? Does someone not being the author nor a member of the > mentioned > group not receive the notification? > cheers As it happens, I can answer your question after the fact. Discourse provides extensive logs on the emails it sends. We now have 10+ people activated and testing the site, and yest I can see that only myself and John were emailed. Here's a pic of the logs, email addresses redacted :) Greg -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [foreman-dev] Propsing a move from Google Groups to Discourse
On 03/11/17 10:32, Lukas Zapletal wrote: > Greg, I have not interest in moving to any kind of web UI. I want to > send another millions of emails, including those "+1". I think we all > agree that any kind of migration must not disrupt way we work today - > a plain mailing-list we all know and use for decades. And I have absoluetly no interest in breaking your workflow. We're on the same side here, mostly ;) > Thanks for decreasing it. I still have concerns about the non-standard > special per-thread address way of replies which I get. Embedding a token in the reply-to is pretty standard, I've seen other projects doing it. The alternative is a token in the *body* which I think is worse. I'm hoping to get a proper wildcard mailforward in place so the reply-to is community+@theforeman.org instead of the underlying Gmail account at some point. What concerns do you have with this approach? > How do I start a new thread via email? Can I do that, can't I? Of course. Email community+t...@theforeman.org for the Testing category. If/when we go live, there will also be community+dev and community+users set up to email to - for now these are disabled so that we don't get duplicates from the list imports. Greg -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Propsing a move from Google Groups to Discourse
Greg, I have not interest in moving to any kind of web UI. I want to send another millions of emails, including those "+1". I think we all agree that any kind of migration must not disrupt way we work today - a plain mailing-list we all know and use for decades. Thanks for decreasing it. I still have concerns about the non-standard special per-thread address way of replies which I get. How do I start a new thread via email? Can I do that, can't I? LZ On Fri, Nov 3, 2017 at 10:58 AM, Greg Sutcliffe wrote: > On 02/11/17 18:35, Lukas Zapletal wrote: >> Tried to reply with just few words and I am getting: >> >> We’re sorry, but your email message to >> [“theforeman.discourse+680bec16c469f36694d1ecef341e8...@gmail.com”] >> (titled Re: [TheForeman] [Testing Area] October newsletter) didn’t >> work. >> Reason: >> Body is too short (minimum is 20 characters) >> If you can correct the problem, please try again. >> >> I am gonna definitely hate this, can we turn this off? A reply of >> "yes" is still a valid one. > > True enough. Of course, that can be altered (seriously, there's a > setting for *everything*) but I'll give you the Discourse reason for > that being 20 by default: > > Since Discourse is intended as web-first, the idea is that instead of > "me too", "I like this", "+1" style replies, you should be encouraged to > click the "Like" button instead. From a discussion viewpoint, a simple > "yes", while valid, doesn't add to the *debate*, only to the weight of a > previous opinion, and instead of the topic author having to *manually* > count up the '+1' posts, (s)he can just look at what got the most likes. > > Of course, it's tricky to click a Like by email, so I've reduced it 1 > character minimum for now. Please do test it again. > > Longer term, I hope we do move to using the UI features such as likes, > polls, etc, but I accept that isn't going to happen overnight :D > > Greg > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Later, Lukas @lzap Zapletal -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Propsing a move from Google Groups to Discourse
On 02/11/17 18:35, Lukas Zapletal wrote: > Tried to reply with just few words and I am getting: > > We’re sorry, but your email message to > [“theforeman.discourse+680bec16c469f36694d1ecef341e8...@gmail.com”] > (titled Re: [TheForeman] [Testing Area] October newsletter) didn’t > work. > Reason: > Body is too short (minimum is 20 characters) > If you can correct the problem, please try again. > > I am gonna definitely hate this, can we turn this off? A reply of > "yes" is still a valid one. True enough. Of course, that can be altered (seriously, there's a setting for *everything*) but I'll give you the Discourse reason for that being 20 by default: Since Discourse is intended as web-first, the idea is that instead of "me too", "I like this", "+1" style replies, you should be encouraged to click the "Like" button instead. From a discussion viewpoint, a simple "yes", while valid, doesn't add to the *debate*, only to the weight of a previous opinion, and instead of the topic author having to *manually* count up the '+1' posts, (s)he can just look at what got the most likes. Of course, it's tricky to click a Like by email, so I've reduced it 1 character minimum for now. Please do test it again. Longer term, I hope we do move to using the UI features such as likes, polls, etc, but I accept that isn't going to happen overnight :D Greg -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Foreman instrumenting analysis
> I lean towards the push model here. The main reason is > the simpler way to publish the instrumentation data from whatever > process we want to track. Also, my understanding is, that we don't care > only if the service is up or down (readiness and liveness) but also > about trends during the processing. My ultimate goal with this thread is to find an agreement and then file a PR so Foreman Rails can send telemetry data in a way that anyone can integrate this into any kind of existing or future monitoring framework. I am currently NOT interested in any kind of system monitoring, services or performance at this point, although I already have some plans in this regard. Once we have Rails telemetry integration, I will likely show demo of how this works with PCP monitoring framework. -- Lukas @lzap Zapletal -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
