[foreman-dev] Form inputs and accessibility
Hey everyone, I would like to propose that we establish a requirement that all new form inputs include both a unique ID attribute and a like so: Name: For form fields where the is no label we should use bootstrap's .sr-only class on the label to hide it like so: Name: This allows screen readers to relate a label field to an input in a meaningful way making it easier for the visually impaired to use our application (as an added bonus unique input IDs also allow for easier to write and maintain QA automation). It is important that the ID be unique to the page so as not to confuse screen readers and also in order to produce valid HTML. Please help this effort by keeping an eye out for new input fields that on't have IDs and labels and if you happen to notice an input without an ID and label please fix it. See also [1]. Thanks, Walden [1] https://webaim.org/techniques/forms/controls#input -- 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] Release process & permissions
+1 on not doing a release just for the sake of it. Sometimes it's needed but most of the time it's not. See the differences between 1.15.0 and 1.15.4: https://github.com/theforeman/foreman-installer/compare/1.15.0...1.15.4 On Thu, Sep 28, 2017 at 07:57:34PM -0400, Eric D Helms wrote: Related to Dmitri's point, and I've thrown this question out with Katello releases at least every other release, do all the components that are currently released "together" need to be so these days? That is to say, can any of the "versioned together components" be released more independently but within the version stream? For example, say we are approaching 1.17 release, that is a good time to cut puppet releases, installer and potentially smart proxy but do they need to be released together? Does Foreman 1.17.1 necessitate a 1.17.1 installer? Or reverse it, does an installer update have to wait on a Foreman 1.17.1 release? Katello used to do this practice with a lot of repositories (e.g. katello-agent, katello-selinux) and were at times releasing projects "just because" without any real changes. After moving away from that, to let katello-agent, katello-selinux and hammer-cli-katello more independently release the process got a lot simpler. Further, I'd argue that each project got a bit more focused and more thought put into maintenance and release. Food for thought and discussion. E On Thu, Sep 28, 2017 at 2:29 PM, Dmitri Dolguikh wrote: Why not distribute the release process? Each component can have (probably already does) multiple maintainers who are capable of doing most of the leg-work. The role of the release nanny then becomes coordinating the effort, making public announcements and such. Such an approach would help avoid overly broad permissions too. -d On Thu, Sep 28, 2017 at 3:23 AM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: To release a gem to rubygems I'd recommend looking at how voxpupuli implemented this using Travis[1]. The same can be done for puppet[2]. That means you can push a tag to git and the release is there. There are also tools that help you bump. For puppet there is puppet-blacksmith[3]. How to do annotated tags is in my notes[3]. A more generic script is bump2version[5] and I'm sure there are similar tools in the ruby world. IMHO these tools should be suggested in the plugin templates. [1]: https://github.com/voxpupuli/modulesync/blob/e53079030501756 fc4111511fb9b6a239ffcb2a3/.travis.yml#L18-L27 [2]: https://github.com/voxpupuli/puppet-nginx/blob/fc363114e509f 439b51ea22723a996ffca8a107d/.travis.yml#L48-L58 [3]: https://github.com/voxpupuli/puppet-blacksmith [4]: http://pad-katello.rhcloud.com/p/releasing-modules [5]: https://github.com/c4urself/bump2version On Wed, Sep 27, 2017 at 08:08:46AM -0700, Daniel Lobato wrote: For foreman-docker I had a process: https://github.com/theforeman/foreman-docker/blob/master/rel ease/RELEASE.md https://github.com/theforeman/foreman-docker/blob/master/rel ease/rollout-release which I planned to implement in all theforeman org plugins ideally. It didn't happen but it's a similar thing. On Wednesday, September 27, 2017 at 4:56:51 PM UTC+2, Timo Goebel wrote: ... isn‘t continuous delivery old these days? Why aren‘t we doing it? I vote in favor of automating this. This ensures predictable results and hopefully makes this process easier. To be honest: The current process scares me. Same for plugin releases. They also are way too manual right now. Timo > On 27. Sep 2017, at 16:46, Daniel Lobato Garcia > wrote: > > Hi devs, > > After a few releases, and now that I'm trying to help someone else to > take over in case it's needed, I found a roadblock. > > Whoever is doing the release, needs to have **many** permissions. > > Otherwise, it doesn't make much sense for a person to take over release > responsibilities. For example, if Ondrej has to do 1.15.5, he would need > the following permissions (see at the end of the email). > > Of course there are alternatives: > > 1 is to have the release nanny be supervised by people who have 'earned' > these permissions. This is a bad idea because some of the tasks just > cannot be 'supervised'. The nanny would have to ask someone to tag > repositories, modify jenkins jobs, upload GPG signatures, post to the > mailing list, tag new builds in Koji... > > 2 is to extend http://ci.theforeman.org/view/Release%20pipeline/ and > make it a real pipeline from 0 to release completed. At this moment, > releases that are not the first RC1 are mostly automated by > https://github.com/dlobatog/foreman_release and > https://github.com/theforeman/tool_belt. > > My proposal is to go forward with 2. Give Jenkins permissions to do all > of the actions needed, and whoever is the release nanny, ideally only > has to make sure all of the steps are moving forward. If something > breaks, figure out how to fix it for the next release. > > This would mean making a few extra jobs before and after the curr
Re: [foreman-dev] Release process & permissions
IMHO that's another (better?) way of phrasing the point I made about relasing being about communication in another email. On Thu, Sep 28, 2017 at 11:29:36AM -0700, Dmitri Dolguikh wrote: Why not distribute the release process? Each component can have (probably already does) multiple maintainers who are capable of doing most of the leg-work. The role of the release nanny then becomes coordinating the effort, making public announcements and such. Such an approach would help avoid overly broad permissions too. -d On Thu, Sep 28, 2017 at 3:23 AM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: To release a gem to rubygems I'd recommend looking at how voxpupuli implemented this using Travis[1]. The same can be done for puppet[2]. That means you can push a tag to git and the release is there. There are also tools that help you bump. For puppet there is puppet-blacksmith[3]. How to do annotated tags is in my notes[3]. A more generic script is bump2version[5] and I'm sure there are similar tools in the ruby world. IMHO these tools should be suggested in the plugin templates. [1]: https://github.com/voxpupuli/modulesync/blob/e53079030501756 fc4111511fb9b6a239ffcb2a3/.travis.yml#L18-L27 [2]: https://github.com/voxpupuli/puppet-nginx/blob/fc363114e509f 439b51ea22723a996ffca8a107d/.travis.yml#L48-L58 [3]: https://github.com/voxpupuli/puppet-blacksmith [4]: http://pad-katello.rhcloud.com/p/releasing-modules [5]: https://github.com/c4urself/bump2version On Wed, Sep 27, 2017 at 08:08:46AM -0700, Daniel Lobato wrote: For foreman-docker I had a process: https://github.com/theforeman/foreman-docker/blob/master/rel ease/RELEASE.md https://github.com/theforeman/foreman-docker/blob/master/rel ease/rollout-release which I planned to implement in all theforeman org plugins ideally. It didn't happen but it's a similar thing. On Wednesday, September 27, 2017 at 4:56:51 PM UTC+2, Timo Goebel wrote: ... isn‘t continuous delivery old these days? Why aren‘t we doing it? I vote in favor of automating this. This ensures predictable results and hopefully makes this process easier. To be honest: The current process scares me. Same for plugin releases. They also are way too manual right now. Timo > On 27. Sep 2017, at 16:46, Daniel Lobato Garcia > wrote: > > Hi devs, > > After a few releases, and now that I'm trying to help someone else to > take over in case it's needed, I found a roadblock. > > Whoever is doing the release, needs to have **many** permissions. > > Otherwise, it doesn't make much sense for a person to take over release > responsibilities. For example, if Ondrej has to do 1.15.5, he would need > the following permissions (see at the end of the email). > > Of course there are alternatives: > > 1 is to have the release nanny be supervised by people who have 'earned' > these permissions. This is a bad idea because some of the tasks just > cannot be 'supervised'. The nanny would have to ask someone to tag > repositories, modify jenkins jobs, upload GPG signatures, post to the > mailing list, tag new builds in Koji... > > 2 is to extend http://ci.theforeman.org/view/Release%20pipeline/ and > make it a real pipeline from 0 to release completed. At this moment, > releases that are not the first RC1 are mostly automated by > https://github.com/dlobatog/foreman_release and > https://github.com/theforeman/tool_belt. > > My proposal is to go forward with 2. Give Jenkins permissions to do all > of the actions needed, and whoever is the release nanny, ideally only > has to make sure all of the steps are moving forward. If something > breaks, figure out how to fix it for the next release. > > This would mean making a few extra jobs before and after the current > release pipeline. In my opinion, it's the way to go to ensure anyone can > take over this responsibility. > > At this moment, we are in a situation where only people who > mostly have permissions everywhere can successfully do a release without > asking many people for favors. > > Personally if we complete this, I see it as a big win as it would dwarf > our bus factor for release managers & allow us to release at any pace we > desire (right now it's slow because we can't truly release things from > one day to the next due to the work involved). > > Thoughts? > > Here's the list of permissions: > > > > Github: > - Push in foreman, foreman-selinux, foreman-installer, >smart-proxy, foreman-infra, foreman-packaging > > Transifex - > - Allow to change the auto-update URL to point to latest -stable >branch > > Redmine - > - Create new "Found in Release" version > > Jenkins - > - Modify jobs > - Run jobs > > Koji - > - Create tags > - SSH access to update the mash scripts > - Create packages > - Tag builds > > Repository servers > - ssh in deb.theforeman.org > - ssh in yum.theforeman.org > > Announcements - > - Post to foreman-announce > - Merge access in theforeman.org > - Change IRC message > - Publish in T