Hi,
at the CSM Workshop at SUSE we discussed how to update the current SUSE
Ruby style guide [1] to reflect the experience we gained since its
introduction and also real-world Ruby usage. We agreed on the following:
1. The style guide should have a maintainer, who will be responsible
for its text and for processing and incorporating changes proposed
by others. Maintainer's decisions should generally reflect the
prevailing opinions of SUSE/openSUSE Ruby developers as they will
express them.
I volunteered to be such maintainer, which was accepted by
everyone present.
2. There should be a clear process to introduce changes, which would
allow everyone interested to participate, but which would also be
light-weight and which would not cause additional delays. The
process proposal we agreed on is outlined below.
3. SUSE Ruby developers will meet at future CSM Workshops whenever
they feel the need to discuss changes in the style guide in
person. Proposed changes resulting from such discussions will then
still go through the formal process like all other changes.
Please have a look at the process proposal and let me know if you have
any comments. After the discussion I'd like to put the final process
description into the style-guides repository. Then I'd like to use the
process to propose some specific changes to the specification, which we
also discussed at the CSM Workshop.
Thank you.
Style Guide Update Process
--------------------------
Anyone interested can propose a change to the Ruby style guide. Such
person is called an *initiator*. The process is as follows:
1. The initiator creates a pull request against the style guide on
GitHub with the proposed change.
2. The initiator announces the proposed change at:
- ruby-devel(a)suse.de
- opensuse-ruby(a)opensuse.org.
3. SUSE/openSUSE Ruby developers will discuss the proposed change
(either at the pull request on GitHub, or in the mailing lists),
possibly expressing their agreement, disagreement and requests for
modifications. This discussion will be overseen by the maintainer,
who will work with the initiator to adapt the proposed change as
necessary.
4. Based on the discussion, the maintainer will decide either to
merge the pull request or reject it. He will announce his decision
as a reply to the original e-mail announcement of the proposed
change.
[1] https://github.com/SUSE/style-guides/blob/master/Ruby.md
--
David Majda
SUSE developer
--
To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org
We have several Rails based applications in our openSUSE infrastructure
(OBS, Hermes, TSP, OSEM...) but all of them deal with our iChain login
proxy in a different way, so I implemented a Devise backend that should
be flexible and generic enough to allow the usage of Devise to sign
in/out/up in our infrastructure in a quite straightforward way:
https://github.com/openSUSE/devise_ichain_authenticatable
Contributions are welcome.
Cheers.
--
Ancor González Sosa
openSUSE Team at Suse Linux GmbH
--
To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org
