Hi,
I like to see "package branch name" of each modules to be aligned more.
Here is a list of the current module, the module stream name, the package branch name, another package name. There are some patterns on the list.
# module, the module stream name (module/foo's branch), the package branch name (rpms/foo's branch), another package name (rpms/bar's branch) mongodb 3.6 3.6 None nodejs 8 8 None perl 5.24 fXX fXX python3 3.6 None None python36 3.6 None master ruby 2.5 ruby-2.5 master scala 2.10 javapackages javapackages varnish 6 stream-6 stream-6
See more detail at https://pagure.io/jaruga-modules-branches I think "None" is same with "master" technically.
In case of modules/ruby, we ruby team decided "the package branch name" as "ruby-X.Y" with a module name prefix against "X.Y" documented in the naming guideline. Because a package of a module A (ex. modules/ruby) can be used also in a module B (ex. modules/rubygem-rails, modules/vagrant and etc. In this case, a package branch name needs to have "ruby-X.Y", "rubygem-rails-X.Y", "vargrant-X.Y".
Do you like to see some alignments for the naming? Hopefully after the discussion here in this thread, below page will be updated. https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidel...
Regards, Jun
Why?
What is the problem with packages having branch "latest", "1.x" and such?
On Tue, Apr 16, 2019 at 3:35 PM Jun Aruga jaruga@redhat.com wrote:
Hi,
I like to see "package branch name" of each modules to be aligned more.
Here is a list of the current module, the module stream name, the package branch name, another package name. There are some patterns on the list.
# module, the module stream name (module/foo's branch), the package branch name (rpms/foo's branch), another package name (rpms/bar's branch) mongodb 3.6 3.6 None nodejs 8 8 None perl 5.24 fXX fXX python3 3.6 None None python36 3.6 None master ruby 2.5 ruby-2.5 master scala 2.10 javapackages javapackages varnish 6 stream-6 stream-6
See more detail at https://pagure.io/jaruga-modules-branches I think "None" is same with "master" technically.
In case of modules/ruby, we ruby team decided "the package branch name" as "ruby-X.Y" with a module name prefix against "X.Y" documented in the naming guideline. Because a package of a module A (ex. modules/ruby) can be used also in a module B (ex. modules/rubygem-rails, modules/vagrant and etc. In this case, a package branch name needs to have "ruby-X.Y", "rubygem-rails-X.Y", "vargrant-X.Y".
Do you like to see some alignments for the naming? Hopefully after the discussion here in this thread, below page will be updated.
https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidel...
Regards, Jun _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Tue, Apr 16, 2019 at 3:38 PM Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
Why?
What is the problem with packages having branch "latest", "1.x" and such?
It's no problem. Rather it might be better in the point of view of "minimal necessary package branches for now". I thought it again.
I considered below case of that a package is included in 2 different modules. Then in the case, a module bar can not refer rpms/bar's 1.2 branch because of specific issue of module bar. But creating new branch "bar-1.2" on rpms/foo on that time might solve the situation.
On modules/foo branch: 1.2 foo.yml data: components: foo: ref: 1.2
On modules/bar branch: 3.4 bar.yml data: components: foo: ref: bar-1.2
rpms/foo branch: 1.2 branch: bar-1.2
-- Jun
Hi Mikolaj
I thought of using names in format "stream-${name}-${stream}" (eg.
stream-scala-2.10), but I can use "${name}-${stream}" (scala-2.10) format too - consistency between modules is more important than maintainer personal preferences.
I just checked current modules' situation in f29 module repository. Maybe this list shows all the module or most modules in it. The result is here. https://pagure.io/jaruga-modules-branches
So, current package branch name patterns are
* "stream-${name}-${stream}": 2 (postgresql, varnish) * "${name}-${stream}": 1 (ruby (but not created yet)) * Both "${name}-${stream}" and "${stream}": 1 (kubernetes) * "${stream}": 11
Remarkable case is kubernetes module. 2 types of module stream names: 1.10, openshift-3.10 2 types of package branch names: 1.10, openshift-3.10 1.10 is maybe used like a kubernetes-1.10 branch.
There is no "${name}-${stream}" except ruby I thought I would create it.
As the examples of package branch names are defined explicitly referring http://calver.org/ . https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidel... In the point of consistency of "current" modules, it might be better to align with a kubernetes module's style.
That is * As a first branch name: "${stream}" * As a 2nd branch name: foo-${stream}
Jun
On Tue, Apr 16, 2019 at 3:26 PM Jun Aruga jaruga@redhat.com wrote:
Hi,
I like to see "package branch name" of each modules to be aligned more.
Here is a list of the current module, the module stream name, the package branch name, another package name. There are some patterns on the list.
# module, the module stream name (module/foo's branch), the package branch name (rpms/foo's branch), another package name (rpms/bar's branch) mongodb 3.6 3.6 None nodejs 8 8 None perl 5.24 fXX fXX python3 3.6 None None python36 3.6 None master ruby 2.5 ruby-2.5 master scala 2.10 javapackages javapackages varnish 6 stream-6 stream-6
See more detail at https://pagure.io/jaruga-modules-branches I think "None" is same with "master" technically.
In case of modules/ruby, we ruby team decided "the package branch name" as "ruby-X.Y" with a module name prefix against "X.Y" documented in the naming guideline. Because a package of a module A (ex. modules/ruby) can be used also in a module B (ex. modules/rubygem-rails, modules/vagrant and etc. In this case, a package branch name needs to have "ruby-X.Y", "rubygem-rails-X.Y", "vargrant-X.Y".
Do you like to see some alignments for the naming?
For my modules I also want component branch names to correspond to module name/stream. If the same component is used across different modules/streams then there would simply be several branches pointing to the same commit.
I thought of using names in format "stream-${name}-${stream}" (eg. stream-scala-2.10), but I can use "${name}-${stream}" (scala-2.10) format too - consistency between modules is more important than maintainer personal preferences.
-- Mikolaj
I think the rules for module branches should be stricter. After several back and forth in discussions with Jun about stream branches for Ruby, I believe that the concept of "using upstream major versions as branches" [1] is not enough and can work just for the simplest cases.
We should use ${module}-${stream} branches everywhere (the "stream-" prefix would be useful as well, because it would explain the semantics use after the prefix).
For example, if we have "foo" module with "1.0" and "2.0" streams and it ships "bar" and "baz" components, the components should have appropriate "(stream-)foo-1.0" and "(stream-)foo-2.0" branches.
We could also utilize `git symbolic-ref` to link the branches if needed ....
Vít
Dne 16. 04. 19 v 15:25 Jun Aruga napsal(a):
Hi,
I like to see "package branch name" of each modules to be aligned more.
Here is a list of the current module, the module stream name, the package branch name, another package name. There are some patterns on the list.
# module, the module stream name (module/foo's branch), the package branch name (rpms/foo's branch), another package name (rpms/bar's branch) mongodb 3.6 3.6 None nodejs 8 8 None perl 5.24 fXX fXX python3 3.6 None None python36 3.6 None master ruby 2.5 ruby-2.5 master scala 2.10 javapackages javapackages varnish 6 stream-6 stream-6
See more detail at https://pagure.io/jaruga-modules-branches I think "None" is same with "master" technically.
In case of modules/ruby, we ruby team decided "the package branch name" as "ruby-X.Y" with a module name prefix against "X.Y" documented in the naming guideline. Because a package of a module A (ex. modules/ruby) can be used also in a module B (ex. modules/rubygem-rails, modules/vagrant and etc. In this case, a package branch name needs to have "ruby-X.Y", "rubygem-rails-X.Y", "vargrant-X.Y".
Do you like to see some alignments for the naming? Hopefully after the discussion here in this thread, below page will be updated. https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidel...
Regards, Jun _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Modularity team,
On below definition of the modularity document, there is a problem, as Vit said. https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidel...
The problem is If we use X.Y.Z as a package branch name with rpms/bar, for example the situation is like this.
modules/foo 2.5 rpms/foo 2.5 rpms/bar 2.5
In this case, seeing rpms/bar 2.5 branch, people tend to recognize it, "bar"'s 2.5 branch. But it's wrong. It can be actually bar 1.2.3 that is included in module foo 2.5.
rpms/bar's situation means "rpms/<another> package branch" in the list. You see several patterns in it.
Maybe I covered most modules situation. https://pagure.io/jaruga-modules-branches
postgresql module solves the situation like this.
modules/foo 11 rpms/foo stream-postgresql-11 rpms/bar stream-postgresql-11
reviewboard module solves the situation like this.
modules/foo 3.0 rpms/foo 3.0 rpms/bar 1.2 (it means bar 1.2 version's branch)
I wish at least recommended way is documented in the modularity section of the page.
-- Jun
-
Igor Gnatenko -
Jun Aruga -
Mikolaj Izdebski -
Vít Ondruch