Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main

== Summary ==

This Change will move Fedora git repositories to use "main" as the
default git branch instead of "master". Specific repositories will be
manually moved and default git branch for new projects will be set to
use "main".

The Fedora Community strives to be open and welcoming. Some language
around our git repositories is dated and could be more inclusive. Many
git repositories currently use "master" as the default branch. This
Change will move many repositories (see below) to use a "main" branch
as default. This small bit of naming adjustment is in-line with
Fedora's vision for free and open source software built by inclusive,
welcoming, and open-minded communities.


== Owner ==

* Name: [[User:Kevin| Kevin Fenzi]], [[User:bcotton| Ben Cotton]],
[[User:pingou| pingou]], [[User:mohanboddu| Mohan Boddu]],
[[User:till| Till Maas]]
* Email: kevin(a)scrye.com, bcotton(a)redhat.com, pingou(a)pingoured.fr,
mboddu(a)bhujji.com, opensource(a)till.name


== Detailed Description ==

The Fedora Project controls a number of git repositories. This change
will move the default branch (that is, the git branch used when
nothing is specified) from 'master' to 'main'. Existing git clones
will need to pull to get the changed default branch. Existing Pull
Requests against the 'master' branch will need to be rebased against
the 'main' branch. Documentation will be updated.



== Benefit to Fedora ==

The Fedora Project will be a more welcoming place for new contributors.


== Scope ==

This change will take place in a number of phases:

=== Phase0 - 2020-12-14 ===

   A guide will be published to explain how maintainers/project
managers can change the default
   branch on pagure.io, which they can then do based in their projects desires.

=== Phase1 - 2020-12-15 ===

The following repos will be switched:

  src.fedoraproject.org/flatpacks/*
  pagure.io:
    releng
    releng/*
    fedora-comps
    fedora-kickstarts
    fedora-infrastructure
    fedora-lorax-templates
    fedora-mediawikitheme
    fedora-packager
    fedora-infra/*
    infra-docs
    koji-fedmsg-plugin
    workstation-ostree-config
    pungi-fedora
  github.com
    fedora-infra/*

=== Phase2 - 2021-01-13 ===

   src.fedoraproject.org/*
   pagure.io default for new projects will be changed to 'main'

* Proposal owners:

   Switching all above listed projects git repos to use 'main'
   Deleting the 'master' branch
   Announcing when changes have been made on devel-announce / other lists.

* Other developers:

   Other developers are encouraged to change their upstream projects
on pagure.io, github or gitlab.

* Release engineering:

   Releng will adjust any scripts that assume 'master' branch to use
'main' instead. The list includes and maybe few more
   [https://pagure.io/releng/blob/master/f/scripts/update-critpath.py
update-critpath.py]
   [https://pagure.io/releng/blob/master/f/scripts/block_retired.py
block_retired.py]
   [https://pagure.io/releng/blob/master/f/scripts/update-docs.sh
update-docs.sh]
   [https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py
find_unblocked_orphans.py]
   [https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-second-run.py
mass-rebuild-second-run.py]
   [https://pagure.io/releng/blob/master/f/scripts/adjust-eol-modules.py
adjust-eol-modules.py]
   [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py
adjust-eol-modules.py]
   [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py
adjust-eol-modules.py]
   [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol.py
adjust-eol.py]
   [https://pagure.io/releng/blob/master/f/scripts/pdc/create-new-release-bra...
create-new-release-branches.py]
   [https://pagure.io/releng/blob/master/f/scripts/pdc/create-branch.py
create-branch.py]
   [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-all.py
adjust-eol-all.py]
   [https://pagure.io/releng/blob/master/f/scripts/check-unretirement.py
check-unretirement.py]
   [https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-special.py
mass-rebuild-special.py]
   [https://pagure.io/releng/blob/master/f/scripts/need-rebuild.py
need-rebuild.py]
   [https://pagure.io/releng/blob/master/f/scripts/distgit-branch-unused.py
distgit-branch-unused.py]
   [https://pagure.io/releng/blob/master/f/scripts/create-new-release-branche...
create-new-release-branches.py]

* Policies and guidelines: N/A

* Trademark approval: N/A

* Alignment with Objectives:


== Upgrade/compatibility impact ==

Users with old checkouts will need to update their git configuration
or re-clone repositories that have changed before they can see any new
changes.

Repos used to build content for docs.fedoraproject.org can change the
default git branch, but the Antora module version (in `antora.yml`)
should remain `master` pending support for alternate "unversioned"
versions upstream.


== How To Test ==

# git clone <one of the listed repositories>
# cd <repositoryname>
# git branch

should return: `* main`


== User Experience ==

Users and developers will see more welcoming language and that the
fedora project expended effort to be more welcoming to them.


== Dependencies ==

none


== Contingency Plan ==

* Contingency mechanism: Revert repositories, scripts, and docs back
to the unwelcoming 'master'
* Contingency date: 2020-01-13


== Documentation ==

A short guide on how to change this for pagure.io will be produced.


== Release Notes ==

Many git repositories used to create Fedora releases were moved to use
a 'main' branch instead of a 'master' branch. The Fedora Project
envisions a world where everyone benefits from free and open source
software built by inclusive, welcoming, and open-minded communities.


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Fabio Valentini]

On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>
>  == Summary ==
>
>  This Change will move Fedora git repositories to use "main" as the
>  default git branch instead of "master". Specific repositories will be
>  manually moved and default git branch for new projects will be set to
>  use "main". 
Is there a reason why "main" is proposed instead of "rawhide" on
src.fp.o?
For all non-dist-git repositories I am fine with "main", but if we are
changing this anyway, "rawhide" would actually make more sense for
dist-git repos.
This would make the branch name actually match the "releasever".

Fabio

[Pierre-Yves Chibon]

On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
>  On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
>  >
>  > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  >
>  > == Summary ==
>  >
>  > This Change will move Fedora git repositories to use "main" as the
>  > default git branch instead of "master". Specific repositories will be
>  > manually moved and default git branch for new projects will be set to
>  > use "main".
>  
>  Is there a reason why "main" is proposed instead of "rawhide" on
> src.fp.o?
>  For all non-dist-git repositories I am fine with "main", but if we are
>  changing this anyway, "rawhide" would actually make more sense for
>  dist-git repos. 
One of the argument was that not every namespace on dist-git has a rawhide
version, for example containers do not have/use rawhide.
And having different default branches on different namespaces is not very
appealing.


Pierre

[Zbigniew Jędrzejewski-Szmek]

On Thu, Dec 03, 2020 at 04:15:24PM +0100, Pierre-Yves Chibon wrote:
>  On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
>  > On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  > >
>  > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  > >
>  > > == Summary ==
>  > >
>  > > This Change will move Fedora git repositories to use "main" as the
>  > > default git branch instead of "master". Specific repositories will
> be
>  > > manually moved and default git branch for new projects will be set to
>  > > use "main".
>  > 
>  > Is there a reason why "main" is proposed instead of "rawhide" on
> src.fp.o?
>  > For all non-dist-git repositories I am fine with "main", but if we are
>  > changing this anyway, "rawhide" would actually make more sense for
>  > dist-git repos.
>  
>  One of the argument was that not every namespace on dist-git has a rawhide
>  version, for example containers do not have/use rawhide.
>  And having different default branches on different namespaces is not very
>  appealing. 
I second the request to use "rawhide" for rawhide branches.

The way that branches in dist-git are used is very different from how
branches are used in the usual git repo, so I find the argument that
the same rules as in other repos should be used convincing. If we rename
it to rawhide, we have the simple rule that "branch of a given name is
used to build for that Fedora release", without any further explanation
about one exception necessary.

Zbyszek

[Kevin Fenzi]

On Thu, Dec 03, 2020 at 03:25:20PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  On Thu, Dec 03, 2020 at 04:15:24PM +0100, Pierre-Yves Chibon wrote:
>  > On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
>  > > On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  > > >
>  > > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  > > >
>  > > > == Summary ==
>  > > >
>  > > > This Change will move Fedora git repositories to use "main" as
> the
>  > > > default git branch instead of "master". Specific repositories
> will be
>  > > > manually moved and default git branch for new projects will be set to
>  > > > use "main".
>  > > 
>  > > Is there a reason why "main" is proposed instead of
> "rawhide" on src.fp.o?
>  > > For all non-dist-git repositories I am fine with "main", but if we
> are
>  > > changing this anyway, "rawhide" would actually make more sense for
>  > > dist-git repos.
>  > 
>  > One of the argument was that not every namespace on dist-git has a rawhide
>  > version, for example containers do not have/use rawhide.
>  > And having different default branches on different namespaces is not very
>  > appealing.
>  
>  I second the request to use "rawhide" for rawhide branches.
>  
>  The way that branches in dist-git are used is very different from how
>  branches are used in the usual git repo, so I find the argument that
>  the same rules as in other repos should be used convincing. If we rename 
Not convincing? :) 

>  it to rawhide, we have the simple rule that "branch of a given
> name is
>  used to build for that Fedora release", without any further explanation
>  about one exception necessary. 
Thats nice I guess, but it's still going to be more confusing for new
users that would expect a main branch (after more things move to that
around the world). 

I suppose we could split the difference and make main a ref to rawhide
or vice versa?

kevin

[Zbigniew Jędrzejewski-Szmek]

On Thu, Dec 03, 2020 at 12:24:32PM -0800, Kevin Fenzi wrote:
>  On Thu, Dec 03, 2020 at 03:25:20PM +0000, Zbigniew Jędrzejewski-Szmek
> wrote:
>  > On Thu, Dec 03, 2020 at 04:15:24PM +0100, Pierre-Yves Chibon wrote:
>  > > On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
>  > > > On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
>  > > > >
>  > > > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  > > > >
>  > > > > == Summary ==
>  > > > >
>  > > > > This Change will move Fedora git repositories to use "main"
> as the
>  > > > > default git branch instead of "master". Specific
> repositories will be
>  > > > > manually moved and default git branch for new projects will be set
> to
>  > > > > use "main".
>  > > > 
>  > > > Is there a reason why "main" is proposed instead of
> "rawhide" on src.fp.o?
>  > > > For all non-dist-git repositories I am fine with "main", but if
> we are
>  > > > changing this anyway, "rawhide" would actually make more sense
> for
>  > > > dist-git repos.
>  > > 
>  > > One of the argument was that not every namespace on dist-git has a rawhide
>  > > version, for example containers do not have/use rawhide.
>  > > And having different default branches on different namespaces is not very
>  > > appealing.
>  > 
>  > I second the request to use "rawhide" for rawhide branches.
>  > 
>  > The way that branches in dist-git are used is very different from how
>  > branches are used in the usual git repo, so I find the argument that
>  > the same rules as in other repos should be used convincing. If we rename
>  
>  Not convincing? :)  
Yeah, sorry. That sentence was clearly too long.

>  > it to rawhide, we have the simple rule that "branch of a
> given name is
>  > used to build for that Fedora release", without any further explanation
>  > about one exception necessary.
>  
>  Thats nice I guess, but it's still going to be more confusing for new
>  users that would expect a main branch (after more things move to that
>  around the world). 
>  
>  I suppose we could split the difference and make main a ref to rawhide
>  or vice versa? 
That'd work for me.

Zbyszek

[Neal Gompa]

On Fri, Dec 4, 2020 at 9:03 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Thu, Dec 03, 2020 at 12:24:32PM -0800, Kevin Fenzi wrote:
>  > On Thu, Dec 03, 2020 at 03:25:20PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  > > On Thu, Dec 03, 2020 at 04:15:24PM +0100, Pierre-Yves Chibon wrote:
>  > > > On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
>  > > > > On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
>  > > > > >
>  > > > > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  > > > > >
>  > > > > > == Summary ==
>  > > > > >
>  > > > > > This Change will move Fedora git repositories to use
> "main" as the
>  > > > > > default git branch instead of "master". Specific
> repositories will be
>  > > > > > manually moved and default git branch for new projects will be
> set to
>  > > > > > use "main".
>  > > > >
>  > > > > Is there a reason why "main" is proposed instead of
> "rawhide" on src.fp.o?
>  > > > > For all non-dist-git repositories I am fine with "main",
> but if we are
>  > > > > changing this anyway, "rawhide" would actually make more
> sense for
>  > > > > dist-git repos.
>  > > >
>  > > > One of the argument was that not every namespace on dist-git has a
> rawhide
>  > > > version, for example containers do not have/use rawhide.
>  > > > And having different default branches on different namespaces is not very
>  > > > appealing.
>  > >
>  > > I second the request to use "rawhide" for rawhide branches.
>  > >
>  > > The way that branches in dist-git are used is very different from how
>  > > branches are used in the usual git repo, so I find the argument that
>  > > the same rules as in other repos should be used convincing. If we rename
>  >
>  > Not convincing? :)
>
>  Yeah, sorry. That sentence was clearly too long.
>
>  > > it to rawhide, we have the simple rule that "branch of a given name is
>  > > used to build for that Fedora release", without any further explanation
>  > > about one exception necessary.
>  >
>  > Thats nice I guess, but it's still going to be more confusing for new
>  > users that would expect a main branch (after more things move to that
>  > around the world).
>  >
>  > I suppose we could split the difference and make main a ref to rawhide
>  > or vice versa?
>
>  That'd work for me.
>  
I've filed an RFE for supporting this use-case:
https://pagure.io/pagure/issue/5061



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Clement Verna]

On Thu, 3 Dec 2020 at 16:21, Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:

>  On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
>  > On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  > >
>  > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  > >
>  > > == Summary ==
>  > >
>  > > This Change will move Fedora git repositories to use "main" as the
>  > > default git branch instead of "master". Specific repositories will
> be
>  > > manually moved and default git branch for new projects will be set to
>  > > use "main".
>  >
>  > Is there a reason why "main" is proposed instead of "rawhide"
> on
>  src.fp.o?
>  > For all non-dist-git repositories I am fine with "main", but if we are
>  > changing this anyway, "rawhide" would actually make more sense for
>  > dist-git repos.
>
>  One of the argument was that not every namespace on dist-git has a rawhide
>  version, for example containers do not have/use rawhide.
>  
There is a fedora:rawhide base image container and I think most dockerfile
from the master branch are using this image for their base. So calling the
master branch rawhide would be ok for containers :-)


>  And having different default branches on different namespaces is not
> very
>  appealing.
>
>
>  Pierre
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Pierre-Yves Chibon]

On Thu, Dec 03, 2020 at 04:56:09PM +0100, Clement Verna wrote:
>     On Thu, 3 Dec 2020 at 16:21, Pierre-Yves Chibon
> <[1]pingou(a)pingoured.fr&gt;
>     wrote:
>  
>       On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
>       > On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton <[2]bcotton(a)redhat.com&gt;
>       wrote:
>       > >
>       > > [3]https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>       > >
>       > > == Summary ==
>       > >
>       > > This Change will move Fedora git repositories to use "main" as
> the
>       > > default git branch instead of "master". Specific repositories
> will
>       be
>       > > manually moved and default git branch for new projects will be set
>       to
>       > > use "main".
>       >
>       > Is there a reason why "main" is proposed instead of
> "rawhide" on
>       src.fp.o?
>       > For all non-dist-git repositories I am fine with "main", but if we
> are
>       > changing this anyway, "rawhide" would actually make more sense for
>       > dist-git repos.
>  
>       One of the argument was that not every namespace on dist-git has a
>       rawhide
>       version, for example containers do not have/use rawhide.
>  
>     There is a fedora:rawhide base image container and I think most dockerfile
>     from the master branch are using this image for their base. So calling the
>     master branch rawhide would be ok for containers :-) 
After looking at the infra and releng issue trackers Kevin managed to found back
the ticket I was thinking about.
You have my apologies, the namespace that was asking to a different default
branch and for that branch to not be named "rawhide" was flatpaks.
They wanted the default branch to be "stable", which would not apply to most
other namespaces. Thus the proposal to go with "main" which works for all
namespaces and seems to be on its way to become the industry standard.


Pierre

[Clement Verna]

On Thu, 3 Dec 2020 at 21:01, Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:

>  On Thu, Dec 03, 2020 at 04:56:09PM +0100, Clement Verna wrote:
>  >    On Thu, 3 Dec 2020 at 16:21, Pierre-Yves Chibon <[1]
>  pingou(a)pingoured.fr&gt;
>  >    wrote:
>  >
>  >      On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
>  >      > On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton <[2]bcotton(a)redhat.com&gt;
>  >      wrote:
>  >      > >
>  >      > > [3]
>  https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  >      > >
>  >      > > == Summary ==
>  >      > >
>  >      > > This Change will move Fedora git repositories to use "main"
> as
>  the
>  >      > > default git branch instead of "master". Specific
> repositories
>  will
>  >      be
>  >      > > manually moved and default git branch for new projects will be
>  set
>  >      to
>  >      > > use "main".
>  >      >
>  >      > Is there a reason why "main" is proposed instead of
> "rawhide" on
>  >      src.fp.o?
>  >      > For all non-dist-git repositories I am fine with "main", but if
>  we are
>  >      > changing this anyway, "rawhide" would actually make more sense
> for
>  >      > dist-git repos.
>  >
>  >      One of the argument was that not every namespace on dist-git has a
>  >      rawhide
>  >      version, for example containers do not have/use rawhide.
>  >
>  >    There is a fedora:rawhide base image container and I think most
>  dockerfile
>  >    from the master branch are using this image for their base. So
>  calling the
>  >    master branch rawhide would be ok for containers :-)
>
>  After looking at the infra and releng issue trackers Kevin managed to
>  found back
>  the ticket I was thinking about.
>  You have my apologies, the namespace that was asking to a different default
>  branch and for that branch to not be named "rawhide" was flatpaks.
>  They wanted the default branch to be "stable", which would not apply to
>  most
>  other namespaces. Thus the proposal to go with "main" which works for all
>  namespaces and seems to be on its way to become the industry standard.
>  
Ah no problem, just wanted to make sure that we did not avoid using rawhide
because of the container namespace :-)


>  Pierre
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Till Maas]

On Thu, Dec 03, 2020 at 08:52:13PM +0100, Pierre-Yves Chibon wrote:

>  After looking at the infra and releng issue trackers Kevin managed to
> found back
>  the ticket I was thinking about.
>  You have my apologies, the namespace that was asking to a different default
>  branch and for that branch to not be named "rawhide" was flatpaks.
>  They wanted the default branch to be "stable", which would not apply to most
>  other namespaces. Thus the proposal to go with "main" which works for all
>  namespaces and seems to be on its way to become the industry standard. 
The flatpak namespace considering "main" to be the stable branch but
rpms considering "main" to be the development branch, is IMHO an
argument why we flatpack should use "stable" and rpms "rawhide". This
will make it more clear for everyone what the branch is actually about.

Using a ref to introduce "main" for muscle memory also sounds like a
good idea.

Thanks
Till

[Pavel Valena]

----- Original Message -----
>  From: "Till Maas" <opensource(a)till.name&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Friday, December 4, 2020 11:09:27 AM
>  Subject: Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
>  
>  On Thu, Dec 03, 2020 at 08:52:13PM +0100, Pierre-Yves Chibon wrote:
>  
>  > After looking at the infra and releng issue trackers Kevin managed to found
>  > back
>  > the ticket I was thinking about.
>  > You have my apologies, the namespace that was asking to a different default
>  > branch and for that branch to not be named "rawhide" was flatpaks.
>  > They wanted the default branch to be "stable", which would not apply to
>  > most
>  > other namespaces. Thus the proposal to go with "main" which works for all
>  > namespaces and seems to be on its way to become the industry standard.
>  
>  The flatpak namespace considering "main" to be the stable branch but
>  rpms considering "main" to be the development branch, is IMHO an
>  argument why we flatpack should use "stable" and rpms "rawhide".
> This
>  will make it more clear for everyone what the branch is actually about. 
I agree. "main" is still quite ambiguous - is it stable? is it devel?

And "rawhide" would correspond with the repo... Is there any show-stopper that
I've missed?

Pavel

>  
>  Using a ref to introduce "main" for muscle memory also sounds like a
>  good idea.
>  
>  Thanks
>  Till

[Kevin Fenzi]

On Fri, Dec 04, 2020 at 06:11:40AM -0500, Pavel Valena wrote:
>  ----- Original Message -----
>  > From: "Till Maas" <opensource(a)till.name&gt;
>  > To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  > Sent: Friday, December 4, 2020 11:09:27 AM
>  > Subject: Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
>  > 
>  > On Thu, Dec 03, 2020 at 08:52:13PM +0100, Pierre-Yves Chibon wrote:
>  > 
>  > > After looking at the infra and releng issue trackers Kevin managed to found
>  > > back
>  > > the ticket I was thinking about.
>  > > You have my apologies, the namespace that was asking to a different default
>  > > branch and for that branch to not be named "rawhide" was flatpaks.
>  > > They wanted the default branch to be "stable", which would not apply
> to
>  > > most
>  > > other namespaces. Thus the proposal to go with "main" which works for
> all
>  > > namespaces and seems to be on its way to become the industry standard.
>  > 
>  > The flatpak namespace considering "main" to be the stable branch but
>  > rpms considering "main" to be the development branch, is IMHO an
>  > argument why we flatpack should use "stable" and rpms "rawhide".
> This
>  > will make it more clear for everyone what the branch is actually about.
>  
>  I agree. "main" is still quite ambiguous - is it stable? is it devel? 
It's the main branch where things take place. ;) 

>  And "rawhide" would correspond with the repo... Is there
> any show-stopper that I've missed? 
I don't think you can make branches completely descripive by themselves,
unless possibly you make them really long. 

flatpak_branch_where_stable_flatpaks_are_made_from

rawhide_its_the_branch_for_the_development_version_of_fedora_called_rawhide

So, IMHO, we are overcomplicating it, and we should just use main. 

I suppose it's ok to make 'rawhide' a symref to main, or 'stable' in
the
flatpak case... 

kevin

[Till Maas]

Hi,

On Fri, Dec 04, 2020 at 11:13:19AM -0800, Kevin Fenzi wrote:

>  I don't think you can make branches completely descripive by
> themselves,
>  unless possibly you make them really long. 
>  
>  flatpak_branch_where_stable_flatpaks_are_made_from 
That it is about flatpaks is already described in the namespace, that it
is a branch is clear from git. This only leaves "stable" as the one
information in the long name that would be missing.

> rawhide_its_the_branch_for_the_development_version_of_fedora_called_rawhide 
It is fair to assume that someone who needs to use this already knows
what rawhide is. Otherwise they did not have any use for the branch,
even if it is called "main", so this long explanation does not make
sense, there.

>  I suppose it's ok to make 'rawhide' a symref to main, or
> 'stable' in the
>  flatpak case...  
"main" as a symref might help people that are used to using main.
Assuming that the symrefs are not visible, it makes more sense to use
the descriptive names for the branches such as rawhide/stable. Then they

Thanks
Till

[Kevin Fenzi]

On Fri, Dec 11, 2020 at 12:03:17PM +0100, Till Maas wrote:
>  Hi,
>  
>  On Fri, Dec 04, 2020 at 11:13:19AM -0800, Kevin Fenzi wrote:
>  
>  > I don't think you can make branches completely descripive by themselves,
>  > unless possibly you make them really long. 
>  > 
>  > flatpak_branch_where_stable_flatpaks_are_made_from
>  
>  That it is about flatpaks is already described in the namespace, that it
>  is a branch is clear from git. This only leaves "stable" as the one
>  information in the long name that would be missing. 
Sure, but 'stable' doesn't convey: These are flatpacks built against the
platform we deem as stable and distributed to all the stable fedora
releases. :) You just can't contain all the information about a branch
in it's name. (IMHO).
>  
>  > rawhide_its_the_branch_for_the_development_version_of_fedora_called_rawhide
>  
>  It is fair to assume that someone who needs to use this already knows
>  what rawhide is. Otherwise they did not have any use for the branch,
>  even if it is called "main", so this long explanation does not make
>  sense, there. 
Well, a new packager may well assume rawhide is main if they are used to
main being the main development branch... 

>  > I suppose it's ok to make 'rawhide' a symref to
> main, or 'stable' in the
>  > flatpak case... 
>  
>  "main" as a symref might help people that are used to using main.
>  Assuming that the symrefs are not visible, it makes more sense to use
>  the descriptive names for the branches such as rawhide/stable. Then they 
Your message seems to have gotten cut off here? :( 

symrefs appear just like any other ref... so adding one does mean that
there's now more choices, just 2 of them are exactly the same.

kevin

[Till Maas]

Hi,

On Sat, Dec 12, 2020 at 12:41:44PM -0800, Kevin Fenzi wrote:
>  On Fri, Dec 11, 2020 at 12:03:17PM +0100, Till Maas wrote:
>  > Hi,
>  > 
>  > On Fri, Dec 04, 2020 at 11:13:19AM -0800, Kevin Fenzi wrote:
>  > 
>  > > I don't think you can make branches completely descripive by themselves,
>  > > unless possibly you make them really long. 
>  > > 
>  > > flatpak_branch_where_stable_flatpaks_are_made_from
>  > 
>  > That it is about flatpaks is already described in the namespace, that it
>  > is a branch is clear from git. This only leaves "stable" as the one
>  > information in the long name that would be missing.
>  
>  Sure, but 'stable' doesn't convey: These are flatpacks built against the
>  platform we deem as stable and distributed to all the stable fedora
>  releases. :) You just can't contain all the information about a branch
>  in it's name. (IMHO). 
Yes, it cannot encode everything but it can at least help. Is there any
documentation about the flatpak work in Fedora? The wiki as all the
other information that I find on Google with "flatpak Fedora" only focus
on how to use them, for example https://fedoraproject.org/wiki/Flatpak
I think it is safe to assume that anyone getting involved to this will
at some point learn what is "stable" in the "stable" branch. Then it
will be easier to remember than "main" if "main" means something else
in
Fedora RPM packaging.

>  > >
> rawhide_its_the_branch_for_the_development_version_of_fedora_called_rawhide
>  > 
>  > It is fair to assume that someone who needs to use this already knows
>  > what rawhide is. Otherwise they did not have any use for the branch,
>  > even if it is called "main", so this long explanation does not make
>  > sense, there.
>  
>  Well, a new packager may well assume rawhide is main if they are used to
>  main being the main development branch...  
Might be. But if they checkout the repo and get a "rawhide" branch, they
should quickly realize that "rawhide" is the branch for "rawhide"
instead of looking for a main branch for rawhide.

>  > > I suppose it's ok to make 'rawhide' a symref to
> main, or 'stable' in the
>  > > flatpak case... 
>  > 
>  > "main" as a symref might help people that are used to using main.
>  > Assuming that the symrefs are not visible, it makes more sense to use
>  > the descriptive names for the branches such as rawhide/stable. Then they
>  
>  Your message seems to have gotten cut off here? :( 
>  
>  symrefs appear just like any other ref... so adding one does mean that
>  there's now more choices, just 2 of them are exactly the same. 
Uh, I guess undo killed this... I mean to also write that then the
"rawhide" branch would also appear as such in the shell prompt.

Thanks
Till

[Kevin Fenzi]

On Mon, Dec 14, 2020 at 05:52:16PM +0100, Till Maas wrote:
>  Yes, it cannot encode everything but it can at least help. Is there
> any
>  documentation about the flatpak work in Fedora? The wiki as all the
>  other information that I find on Google with "flatpak Fedora" only focus
>  on how to use them, for example https://fedoraproject.org/wiki/Flatpak
>  I think it is safe to assume that anyone getting involved to this will
>  at some point learn what is "stable" in the "stable" branch. Then it
>  will be easier to remember than "main" if "main" means something else
> in
>  Fedora RPM packaging. 
I'm not sure where docs are. I think only a few people build flatpaks. 

>  > > >
> rawhide_its_the_branch_for_the_development_version_of_fedora_called_rawhide
>  > > 
>  > > It is fair to assume that someone who needs to use this already knows
>  > > what rawhide is. Otherwise they did not have any use for the branch,
>  > > even if it is called "main", so this long explanation does not make
>  > > sense, there.
>  > 
>  > Well, a new packager may well assume rawhide is main if they are used to
>  > main being the main development branch... 
>  
>  Might be. But if they checkout the repo and get a "rawhide" branch, they
>  should quickly realize that "rawhide" is the branch for "rawhide"
>  instead of looking for a main branch for rawhide. 
Sure, unless it's a new empty repo. ;( 
 
>  > > > I suppose it's ok to make 'rawhide' a
> symref to main, or 'stable' in the
>  > > > flatpak case... 
>  > > 
>  > > "main" as a symref might help people that are used to using main.
>  > > Assuming that the symrefs are not visible, it makes more sense to use
>  > > the descriptive names for the branches such as rawhide/stable. Then they
>  > 
>  > Your message seems to have gotten cut off here? :( 
>  > 
>  > symrefs appear just like any other ref... so adding one does mean that
>  > there's now more choices, just 2 of them are exactly the same.
>  
>  Uh, I guess undo killed this... I mean to also write that then the
>  "rawhide" branch would also appear as such in the shell prompt. 
Yeah. 

kevin

[Gary Buhrmaster]

On Thu, Dec 3, 2020 at 3:08 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:

>  Is there a reason why "main" is proposed instead of
> "rawhide" on src.fp.o? 
Aligning as much as possible with what appears
to be the industry consensus ("main") makes sense
to me, as I will be able to (re)train my finger muscle
memory in the fedora name space to type "main".

While there is no technical reason every domain
cannot select different primary branch names,
and sometimes that does make sense, "main" is
sufficiently generic that to me it makes it a rational
default to avoid needing domain specific knowledge.

[Matthew Miller]

On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
>  Is there a reason why "main" is proposed instead of
> "rawhide" on src.fp.o?
>  For all non-dist-git repositories I am fine with "main", but if we are
>  changing this anyway, "rawhide" would actually make more sense for
>  dist-git repos.
>  This would make the branch name actually match the "releasever". 
I'm definitely in favor of this. I still have dreams of having Fedora and
CentOS Stream branches sharing space in the repository, and having
everything explicity named with what branch it is rather than fighting over
who owns "main" would be nice.

As an alternate proposal, what is currently "master" could be moved to
"rawhide" and a _new_ "main" branch created explicity to hold just a
readme
about that package's packaging details (like which branches are what
when there are module branches or other things, whether there are particular
things to be aware of that makes this package special, etc.). I'm not in
love with this as a git pattern, but it's A Thing People Do Sometimes and
maybe it's appropriate here.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Miro Hrončok]

On 12/3/20 7:50 PM, Matthew Miller wrote:
>  As an alternate proposal, what is currently "master" could
> be moved to
>  "rawhide" and a_new_  "main" branch created explicity to hold just a
> readme
>  about that package's packaging details (like which branches are what
>  when there are module branches or other things, whether there are particular
>  things to be aware of that makes this package special, etc.). 
Who maintains this README?

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Matthew Miller]

On Fri, Dec 04, 2020 at 12:43:43AM +0100, Miro Hrončok wrote:
>  Who maintains this README? 
We'd drop in a default one and it'd be the responsibility of the maintainers
of the various branches.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Miro Hrončok]

On 12/4/20 1:01 AM, Matthew Miller wrote:
>  On Fri, Dec 04, 2020 at 12:43:43AM +0100, Miro Hrončok wrote:
> > Who maintains this README?
>  
>  We'd drop in a default one and it'd be the responsibility of the maintainers
>  of the various branches. 
So except of maintain the branches, I need to maintain a README for my ~200 
packages and keep it up to date? That's a big showstopper for me.

The information can be requested by machines, why would a human maintain it?

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Matthew Miller]

On Fri, Dec 04, 2020 at 01:17:29AM +0100, Miro Hrončok wrote:
>  >We'd drop in a default one and it'd be the responsibility
> of the maintainers
>  >of the various branches.
>  So except of maintain the branches, I need to maintain a README for
>  my ~200 packages and keep it up to date? That's a big showstopper
>  for me. 
If you don't have anything interesting to say, it could just be the
description of the package. Or other auto-generated information.

>  The information can be requested by machines, why would a human
> maintain it? 
It's useful for humans who look a the gitforge.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Matthew Miller]

On Thu, Dec 03, 2020 at 07:21:17PM -0500, Matthew Miller wrote:
>  If you don't have anything interesting to say, it could just be
> the
>  description of the package. Or other auto-generated information.
>  > The information can be requested by machines, why would a human maintain it?
>  It's useful for humans who look a the gitforge. 
Mind you, I'm not strongly attached to this idea. Kevin's idea of just
aliasing main to rawhide seems fine with me too.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Miro Hrončok]

On 12/4/20 1:21 AM, Matthew Miller wrote:
>  On Thu, Dec 03, 2020 at 07:21:17PM -0500, Matthew Miller wrote:
> > If you don't have anything interesting to say, it could just be the
> > description of the package. Or other auto-generated information.
> >> The information can be requested by machines, why would a human maintain it?
> > It's useful for humans who look a the gitforge.
>  
>  Mind you, I'm not strongly attached to this idea. Kevin's idea of just
>  aliasing main to rawhide seems fine with me too. 
The kind of information presented in such README can be generated and displayed 
by the gitfogre instead. So whatever we end up with, having a README-only branch 
  doesn't sound appealing to me. (I'd say I support Kevin's idea, but there
are 
other factors I don't have an opinion on yet.)

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Vít Ondruch]

Dne 04. 12. 20 v 0:43 Miro Hrončok napsal(a):
>  On 12/3/20 7:50 PM, Matthew Miller wrote:
> > As an alternate proposal, what is currently "master" could be moved to
> > "rawhide" and a_new_  "main" branch created explicity to hold
> just a 
> > readme
> > about that package's packaging details (like which branches are what
> > when there are module branches or other things, whether there are 
> > particular
> > things to be aware of that makes this package special, etc.).
>
>  Who maintains this README?
>  
Please don't! We are using this setup internally and I am fighting 
against this for ages. There is nothing worse then cloning some 
repository which is essentially empty.


Vít

[Miro Hrončok]

On 12/4/20 10:04 AM, Vít Ondruch wrote:
>  
>  Dne 04. 12. 20 v 0:43 Miro Hrončok napsal(a):
> > On 12/3/20 7:50 PM, Matthew Miller wrote:
> >> As an alternate proposal, what is currently "master" could be moved to
> >> "rawhide" and a_new_  "main" branch created explicity to hold
> just a readme
> >> about that package's packaging details (like which branches are what
> >> when there are module branches or other things, whether there are particular
> >> things to be aware of that makes this package special, etc.).
> >
> > Who maintains this README?
> >
>  
>  Please don't! We are using this setup internally and I am fighting against this 
>  for ages. There is nothing worse then cloning some repository which is 
>  essentially empty. 
Yes, the internal setup with an useles default branch with an useless README is 
bad. Let's not do this in Fedora.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Daniel P. Berrangé]

On Thu, Dec 03, 2020 at 01:50:24PM -0500, Matthew Miller wrote:
>  On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
>  > Is there a reason why "main" is proposed instead of "rawhide" on
> src.fp.o?
>  > For all non-dist-git repositories I am fine with "main", but if we are
>  > changing this anyway, "rawhide" would actually make more sense for
>  > dist-git repos.
>  > This would make the branch name actually match the "releasever".
>  
>  I'm definitely in favor of this. I still have dreams of having Fedora and
>  CentOS Stream branches sharing space in the repository, and having
>  everything explicity named with what branch it is rather than fighting over
>  who owns "main" would be nice. 
Perhaps this is heresy, but we could stop calling our main development
stream "rawhide", and instead call it "main", then it will be
trivially
aligned with the "main" git branch name :-)

I've never felt "rawhide" was a particularly good name. Unless you're
already familiar with Fedora, it is something whose meaning in the context
of Fedora has to be explained each time. The common meaning of the word
rawhide doesn't have especially positive associations either IMHO.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Fabio Valentini]

On Fri, Dec 4, 2020 at 11:01 AM Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote:
>  Perhaps this is heresy, but we could stop calling our main development
>  stream "rawhide", and instead call it "main", then it will be
> trivially
>  aligned with the "main" git branch name :-)
>
>  I've never felt "rawhide" was a particularly good name. Unless you're
>  already familiar with Fedora, it is something whose meaning in the context
>  of Fedora has to be explained each time. The common meaning of the word
>  rawhide doesn't have especially positive associations either IMHO. 
Using "Rawhide" as the release name of the development branch has been
around for so long that renaming it would cause all sorts of
additional problems.
It's even listed on the disambiguation page for "Rawhide" on wikipedia
... so since this is probably a branding / trademark issue, I'd rather
not conflate it with the discussion about renaming the default branch
in git.

Fabio

[Kevin Fenzi]

On Fri, Dec 04, 2020 at 10:01:04AM +0000, Daniel P. Berrangé wrote:
>  On Thu, Dec 03, 2020 at 01:50:24PM -0500, Matthew Miller wrote:
>  > On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
>  > > Is there a reason why "main" is proposed instead of
> "rawhide" on src.fp.o?
>  > > For all non-dist-git repositories I am fine with "main", but if we
> are
>  > > changing this anyway, "rawhide" would actually make more sense for
>  > > dist-git repos.
>  > > This would make the branch name actually match the "releasever".
>  > 
>  > I'm definitely in favor of this. I still have dreams of having Fedora and
>  > CentOS Stream branches sharing space in the repository, and having
>  > everything explicity named with what branch it is rather than fighting over
>  > who owns "main" would be nice.
>  
>  Perhaps this is heresy, but we could stop calling our main development
>  stream "rawhide", and instead call it "main", then it will be
> trivially
>  aligned with the "main" git branch name :-)
>  
>  I've never felt "rawhide" was a particularly good name. Unless you're
>  already familiar with Fedora, it is something whose meaning in the context
>  of Fedora has to be explained each time. The common meaning of the word
>  rawhide doesn't have especially positive associations either IMHO. 
Yeah, I am not a super fan of the name rawhide (Although I am a super
fan of the thing we make called rawhide). :) 

I always thought it could be something better like 'headwaters' or
something. But that gets us into a big long bikeshed. :( 

kevin

[Matthew Miller]

On Fri, Dec 04, 2020 at 11:09:01AM -0800, Kevin Fenzi wrote:
>  I always thought it could be something better like
> 'headwaters' or
>  something. But that gets us into a big long bikeshed. :(  
I thought we'd all already settled on Primordial Soup. :)

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[DJ Delorie]

Daniel P. Berrangé <berrange(a)redhat.com&gt; writes:
>  Perhaps this is heresy, but we could stop calling our main
> development
>  stream "rawhide", and instead call it "main", then it will be
> trivially
>  aligned with the "main" git branch name :-) 
But fedoras aren't made of sheets of main, they're made from sheets of
rawhide...

[Gary Buhrmaster]

On Fri, Dec 4, 2020 at 9:24 PM DJ Delorie <dj(a)redhat.com&gt; wrote:

>  But fedoras aren't made of sheets of main, they're made from
> sheets of
>  rawhide... 
Actually, fedoras can be made from many different
source materials (straw, cotton, hemp, etc.) in
addition to rawhide.

There are some workflows such that I have
occasionally wished rawhide was just another
branch off of the primary (main/master) repo
just like the F33 branch.  But we can all adapt.

[Neal Gompa]

On Fri, Dec 4, 2020 at 4:39 PM Gary Buhrmaster
<gary.buhrmaster(a)gmail.com&gt; wrote:
>  On Fri, Dec 4, 2020 at 9:24 PM DJ Delorie <dj(a)redhat.com&gt; wrote:
>
>  > But fedoras aren't made of sheets of main, they're made from sheets of
>  > rawhide...
>
>  Actually, fedoras can be made from many different
>  source materials (straw, cotton, hemp, etc.) in
>  addition to rawhide.
>  
I'm pretty sure ours is made from Cotton. :)



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Peter Hutterer]

On Fri, Dec 04, 2020 at 04:24:26PM -0500, DJ Delorie wrote:
>  Daniel P. Berrangé <berrange(a)redhat.com&gt; writes:
>  > Perhaps this is heresy, but we could stop calling our main development
>  > stream "rawhide", and instead call it "main", then it will be
> trivially
>  > aligned with the "main" git branch name :-)
>  
>  But fedoras aren't made of sheets of main, they're made from sheets of
>  rawhide... 
I'd venture there's a significant percentage of users and developers that
aren't aware that a Fedora is hat. Not everyone is a native English speaker.

I certainly knew about Fedora-the-distro for years before some off-hand
comment made me realise that it's a type of hat. And the only reference to
rawhide I've ever known before working on Fedora was the Blues Brothers
song.

On a global scale, a lot of these puns are meaningless since they're too
tied to the local culture (well, almost always the US one).

Cheers,
   Peter

[Kevin Kofler]

Fabio Valentini wrote:
>  Is there a reason why "main" is proposed instead of
> "rawhide" on src.fp.o?
>  For all non-dist-git repositories I am fine with "main", but if we are
>  changing this anyway, "rawhide" would actually make more sense for
>  dist-git repos.
>  This would make the branch name actually match the "releasever". 
+1 for "rawhide" as the branch name.

I have always seen the inconsistency between "rawhide" and "master" as
a 
result of "master" being a default name in git. If we are going to change it 
anyway, we should change it to the real name ("rawhide"), and not to a third 
(!) name for the same thing ("main").

I also agree that for the non-dist-git repositories, "main" is fine. I 
initially (when this discussion started a few months ago) found it pretty 
surprising that "master" is seen as an issue in this context considering 
that there is no "slave" branch, but since the consensus in the community 
appears to be that it is indeed an issue, using a name like "main" that 
hopefully does not offend anyone makes sense. But dist-git should change to 
"rawhide" rather than "main".

        Kevin Kofler

[Miroslav Suchý]

Dne 04. 12. 20 v 15:25 Kevin Kofler via devel napsal(a):
>  +1 for "rawhide" as the branch name.
>  
>  I have always seen the inconsistency between "rawhide" and "master"
> as a 
>  result of "master" being a default name in git. If we are going to change it 
>  anyway, we should change it to the real name ("rawhide"), and not to a third 
>  (!) name for the same thing ("main"). 
+1

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

[Petr Šabata]

Since I don't see those on the list, does this impact

* rpkg (fedpkg)?
* koji (if no git commit is provided)?
* COPR?
* Koschei or other such services?

P

[Pierre-Yves Chibon]

On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
>  Since I don't see those on the list, does this impact
>  
>  * rpkg (fedpkg)? 
Wrapper to git, should not be impacted. The only thing I could think of was:
when we fedpkg clone an empty git repo, have fedpkg do the "git branch -M main"
directly. That being said, I'm not 100% sure when we creating a project on
dist-git today we create them empty.

>  * koji (if no git commit is provided)? 
koji builds from a git reference be that a commit, branch name or git tag.
There will be no consequences for koji there (instead of building from
url#master you'll be build from url#main).

>  * COPR? 
I'll let the COPR folks answer.

>  * Koschei or other such services? 
I don't know enough koschei to answer for it.
For the other services, we've tried to be exhaustive. If you can think of some
we missed/may have missed feel free to raise them.


Pierre

[Petr Šabata]

On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:
>  On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
>  > Since I don't see those on the list, does this impact
>  >
>  > * rpkg (fedpkg)?
>
>  Wrapper to git, should not be impacted. The only thing I could think of was:
>  when we fedpkg clone an empty git repo, have fedpkg do the "git branch -M
> main"
>  directly. That being said, I'm not 100% sure when we creating a project on
>  dist-git today we create them empty. 
Also fedpkg anything that tries to figure out what the release string
and build target are based on the branch name. E.g. fedpkg build.

>  > * koji (if no git commit is provided)?
>
>  koji builds from a git reference be that a commit, branch name or git tag.
>  There will be no consequences for koji there (instead of building from
>  url#master you'll be build from url#main). 
Yes, but I think, and correct me if I'm wrong, that if the SCMURL is
simply a repo name, it uses master HEAD. You could say it's an edge
case but if it does that, is should now attempt to use main, with
master as a fallback.

>  > * COPR?
>
>  I'll let the COPR folks answer.
>
>  > * Koschei or other such services?
>
>  I don't know enough koschei to answer for it.
>  For the other services, we've tried to be exhaustive. If you can think of some
>  we missed/may have missed feel free to raise them. 
I can only think of not-strictly-Fedora stuff, like people's bots that
autoupdate packages or do various things based on bus messages.

P

[Pierre-Yves Chibon]

On Thu, Dec 03, 2020 at 04:39:35PM +0100, Petr Šabata wrote:
>  On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves Chibon
> <pingou(a)pingoured.fr&gt; wrote:
>  >
>  > On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
>  > > Since I don't see those on the list, does this impact
>  > >
>  > > * rpkg (fedpkg)?
>  >
>  > Wrapper to git, should not be impacted. The only thing I could think of was:
>  > when we fedpkg clone an empty git repo, have fedpkg do the "git branch -M
> main"
>  > directly. That being said, I'm not 100% sure when we creating a project on
>  > dist-git today we create them empty.
>  
>  Also fedpkg anything that tries to figure out what the release string
>  and build target are based on the branch name. E.g. fedpkg build. 
Good point

>  > > * koji (if no git commit is provided)?
>  >
>  > koji builds from a git reference be that a commit, branch name or git tag.
>  > There will be no consequences for koji there (instead of building from
>  > url#master you'll be build from url#main).
>  
>  Yes, but I think, and correct me if I'm wrong, that if the SCMURL is
>  simply a repo name, it uses master HEAD. You could say it's an edge
>  case but if it does that, is should now attempt to use main, with
>  master as a fallback. 
It then uses HEAD which would be the same thing as what you get when you git
clone a repo and with this change it'll point to main.

Something to test/confirm, but I'm really pretty sure that it'll be fine.


Pierre

[Miro Hrončok]

On 12/3/20 4:39 PM, Petr Šabata wrote:
>  On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves
> Chibon<pingou(a)pingoured.fr>  wrote:
> > On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
> >> Since I don't see those on the list, does this impact
> >>
> >> * rpkg (fedpkg)?
> > Wrapper to git, should not be impacted. The only thing I could think of was:
> > when we fedpkg clone an empty git repo, have fedpkg do the "git branch -M
> main"
> > directly. That being said, I'm not 100% sure when we creating a project on
> > dist-git today we create them empty. 
Optionally, they can be empty.

   $ fedpkg request-repo ... --no-initial-commit

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Kevin Fenzi]

On Fri, Dec 04, 2020 at 12:45:03AM +0100, Miro Hrončok wrote:
>  On 12/3/20 4:39 PM, Petr Šabata wrote:
>  > On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves Chibon<pingou(a)pingoured.fr> 
> wrote:
>  > > On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
>  > > > Since I don't see those on the list, does this impact
>  > > > 
>  > > > * rpkg (fedpkg)?
>  > > Wrapper to git, should not be impacted. The only thing I could think of was:
>  > > when we fedpkg clone an empty git repo, have fedpkg do the "git branch -M
> main"
>  > > directly. That being said, I'm not 100% sure when we creating a project on
>  > > dist-git today we create them empty.
>  
>  Optionally, they can be empty.
>  
>    $ fedpkg request-repo ... --no-initial-commit 
This could be anoying if someone then pushes as master branch back up,
but I guess we can take those on a case by case basis. 

kevin

[Julen Landa Alustiza]

20/12/4 20:42(e)an, Kevin Fenzi igorleak idatzi zuen:
>  On Fri, Dec 04, 2020 at 12:45:03AM +0100, Miro Hrončok wrote:
> > On 12/3/20 4:39 PM, Petr Šabata wrote:
> >> On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves Chibon<pingou(a)pingoured.fr> 
> wrote:
> >>> On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
> >>>> Since I don't see those on the list, does this impact
> >>>>
> >>>> * rpkg (fedpkg)?
> >>> Wrapper to git, should not be impacted. The only thing I could think of was:
> >>> when we fedpkg clone an empty git repo, have fedpkg do the "git branch
> -M main"
> >>> directly. That being said, I'm not 100% sure when we creating a project
> on
> >>> dist-git today we create them empty.
> >
> > Optionally, they can be empty.
> >
> >    $ fedpkg request-repo ... --no-initial-commit
>  
>  This could be anoying if someone then pushes as master branch back up,
>  but I guess we can take those on a case by case basis. 
This change proposal should
cover changing pagure-dist-git's rules so 
that should be impossible.

Indeed we'll need to be able to opt-in to the new naming on some repos 
while the rest keeps the old one, so we could temporary need to disable 
the hardcoded rules and rely on upstream protected branches feature or 
something similar at least during the transition.

src.fp.o has strict rules to avoid to push some tags, this transition 
must keep those stricts rules in place while transitioning imo

Regards,
> 
> kevin
> 
> 
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Kevin Fenzi]

On Wed, Dec 09, 2020 at 08:02:45AM +0100, Julen Landa Alustiza wrote:
>  
>  
>  20/12/4 20:42(e)an, Kevin Fenzi igorleak idatzi zuen:
>  > On Fri, Dec 04, 2020 at 12:45:03AM +0100, Miro Hrončok wrote:
>  > > On 12/3/20 4:39 PM, Petr Šabata wrote:
>  > > > On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves
> Chibon<pingou(a)pingoured.fr>  wrote:
>  > > > > On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
>  > > > > > Since I don't see those on the list, does this impact
>  > > > > > 
>  > > > > > * rpkg (fedpkg)?
>  > > > > Wrapper to git, should not be impacted. The only thing I could think
> of was:
>  > > > > when we fedpkg clone an empty git repo, have fedpkg do the "git
> branch -M main"
>  > > > > directly. That being said, I'm not 100% sure when we creating a
> project on
>  > > > > dist-git today we create them empty.
>  > > 
>  > > Optionally, they can be empty.
>  > > 
>  > >    $ fedpkg request-repo ... --no-initial-commit
>  > 
>  > This could be anoying if someone then pushes as master branch back up,
>  > but I guess we can take those on a case by case basis.
>  This change proposal should cover changing pagure-dist-git's rules so that
>  should be impossible. 
Indeed, we can add that. 

>  Indeed we'll need to be able to opt-in to the new naming on some
> repos while
>  the rest keeps the old one, so we could temporary need to disable the
>  hardcoded rules and rely on upstream protected branches feature or something
>  similar at least during the transition. 
I'm not sure what you mean here. Someone pushing while we are changing
the repos?
>  
>  src.fp.o has strict rules to avoid to push some tags, this transition must
>  keep those stricts rules in place while transitioning imo 
Yep. And add master. Will update the change. 

kevin

[Julen Landa Alustiza]

Good morning,

20/12/9 23:24(e)an, Kevin Fenzi igorleak idatzi zuen:
>  On Wed, Dec 09, 2020 at 08:02:45AM +0100, Julen Landa Alustiza
> wrote:
> >
> >
> > 20/12/4 20:42(e)an, Kevin Fenzi igorleak idatzi zuen:
> >> On Fri, Dec 04, 2020 at 12:45:03AM +0100, Miro Hrončok wrote:
> >>> On 12/3/20 4:39 PM, Petr Šabata wrote:
> >>>> On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves
> Chibon<pingou(a)pingoured.fr>  wrote:
> >>>>> On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
> >>>>>> Since I don't see those on the list, does this impact
> >>>>>>
> >>>>>> * rpkg (fedpkg)?
> >>>>> Wrapper to git, should not be impacted. The only thing I could think
> of was:
> >>>>> when we fedpkg clone an empty git repo, have fedpkg do the "git
> branch -M main"
> >>>>> directly. That being said, I'm not 100% sure when we creating a
> project on
> >>>>> dist-git today we create them empty.
> >>>
> >>> Optionally, they can be empty.
> >>>
> >>>     $ fedpkg request-repo ... --no-initial-commit
> >>
> >> This could be anoying if someone then pushes as master branch back up,
> >> but I guess we can take those on a case by case basis.
> > This change proposal should cover changing pagure-dist-git's rules so that
> > should be impossible.
>  
>  Indeed, we can add that.
>  
> > Indeed we'll need to be able to opt-in to the new naming on some repos while
> > the rest keeps the old one, so we could temporary need to disable the
> > hardcoded rules and rely on upstream protected branches feature or something
> > similar at least during the transition.
>  
>  I'm not sure what you mean here. Someone pushing while we are changing
>  the repos? 
I thought there were some rpms namespace repos on phase 0, but that's 
not true, so nevermind. We can just modify dist-git for full rpms 
namespace :)

>>
>> src.fp.o has strict rules to avoid to push some tags, this transition must
>> keep those stricts rules in place while transitioning imo
> 
> Yep. And add master. Will update the change.
> 
> kevin
> 
> 
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Miroslav Suchý]

Dne 03. 12. 20 v 16:31 Pierre-Yves Chibon napsal(a):
> >
> > * rpkg (fedpkg)?
>
> Wrapper to git, should not be impacted. 
but is impacted.
There is bunch of

      if rel == 'master':
        return ['master']

which needs to be updated.
Also request_repo have hard-coded "master" name.


> > * COPR?
>  I'll let the COPR folks answer.
>   
Copr does not expose dist-git to users. I.e. you cannot directly upload to dist-git. Only
via WebUI or copr-cli. So
users don't even know the branch names.
We use master branch internally, but that is just because it is the default in git and
dist-git.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

[Pavel Raiskup]

On Thursday, December 3, 2020 5:50:46 PM CET Miroslav Suchý wrote:
>  >> * COPR?
>  > I'll let the COPR folks answer.
>  
>  Copr does not expose dist-git to users. I.e. you cannot directly upload to
>  dist-git. Only via WebUI or copr-cli. So users don't even know the branch
>  names.  We use master branch internally, but that is just because it is the
>  default in git and dist-git. 
We also support building from Fedora DistGit now, and if the committish isn't
specified explicitly, we pick the master branch now.  So we'll have to adapt and
change the default (once it is decided, I'm +1 to 'rawhide' will be picked
eventually).

Pavel

[Daniel P. Berrangé]

On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  
>  == Summary ==
>  
>  This Change will move Fedora git repositories to use "main" as the
>  default git branch instead of "master". Specific repositories will be
>  manually moved and default git branch for new projects will be set to
>  use "main".
>  
>  The Fedora Community strives to be open and welcoming. Some language
>  around our git repositories is dated and could be more inclusive. Many
>  git repositories currently use "master" as the default branch. This
>  Change will move many repositories (see below) to use a "main" branch
>  as default. This small bit of naming adjustment is in-line with
>  Fedora's vision for free and open source software built by inclusive,
>  welcoming, and open-minded communities. 
snip

>  == Upgrade/compatibility impact ==
>  
>  Users with old checkouts will need to update their git configuration
>  or re-clone repositories that have changed before they can see any new
>  changes. 
Is it possible to enhance pagure to support configuring branch
symbolic refs when branches are renamed, so clients don't need
to update their checkout ? IIUC, it involves running something
approximately like this on the server git repo:

   git symbolic-ref refs/heads/master refs/heads/main



Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Neal Gompa]

On Thu, Dec 3, 2020 at 10:53 AM Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote:
>  On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote:
>  > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  >
>  > == Summary ==
>  >
>  > This Change will move Fedora git repositories to use "main" as the
>  > default git branch instead of "master". Specific repositories will be
>  > manually moved and default git branch for new projects will be set to
>  > use "main".
>  >
>  > The Fedora Community strives to be open and welcoming. Some language
>  > around our git repositories is dated and could be more inclusive. Many
>  > git repositories currently use "master" as the default branch. This
>  > Change will move many repositories (see below) to use a "main" branch
>  > as default. This small bit of naming adjustment is in-line with
>  > Fedora's vision for free and open source software built by inclusive,
>  > welcoming, and open-minded communities.
>
>  snip
>
>  > == Upgrade/compatibility impact ==
>  >
>  > Users with old checkouts will need to update their git configuration
>  > or re-clone repositories that have changed before they can see any new
>  > changes.
>
>  Is it possible to enhance pagure to support configuring branch
>  symbolic refs when branches are renamed, so clients don't need
>  to update their checkout ? IIUC, it involves running something
>  approximately like this on the server git repo:
>
>     git symbolic-ref refs/heads/master refs/heads/main
>  
Probably, but I suspect that's more of a migration task. Do we need to
establish a persistent reference of master == main?



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Kevin Fenzi]

On Thu, Dec 03, 2020 at 03:53:00PM +0000, Daniel P. Berrangé wrote:
>  On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote:
>  > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  > 
>  > == Summary ==
>  > 
>  > This Change will move Fedora git repositories to use "main" as the
>  > default git branch instead of "master". Specific repositories will be
>  > manually moved and default git branch for new projects will be set to
>  > use "main".
>  > 
>  > The Fedora Community strives to be open and welcoming. Some language
>  > around our git repositories is dated and could be more inclusive. Many
>  > git repositories currently use "master" as the default branch. This
>  > Change will move many repositories (see below) to use a "main" branch
>  > as default. This small bit of naming adjustment is in-line with
>  > Fedora's vision for free and open source software built by inclusive,
>  > welcoming, and open-minded communities.
>  
>  snip
>  
>  > == Upgrade/compatibility impact ==
>  > 
>  > Users with old checkouts will need to update their git configuration
>  > or re-clone repositories that have changed before they can see any new
>  > changes.
>  
>  Is it possible to enhance pagure to support configuring branch
>  symbolic refs when branches are renamed, so clients don't need
>  to update their checkout ? IIUC, it involves running something
>  approximately like this on the server git repo:
>  
>     git symbolic-ref refs/heads/master refs/heads/main 
Yeah, it might be, but if we want to get rid of master we should just do
it, not leave all the existing checkouts around using it, IMHO. 

kevin

[Julen Landa Alustiza]

Would be great if we add a deprecation notice (wich could include an EOL 
for the symbolic-ref) to git's output while operating on master branch :D



20/12/3 16:53(e)an, Daniel P. Berrangé igorleak idatzi zuen:
> On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>>
>> == Summary ==
>>
>> This Change will move Fedora git repositories to use "main" as the
>> default git branch instead of "master". Specific repositories will be
>> manually moved and default git branch for new projects will be set to
>> use "main".
>>
>> The Fedora Community strives to be open and welcoming. Some language
>> around our git repositories is dated and could be more inclusive. Many
>> git repositories currently use "master" as the default branch. This
>> Change will move many repositories (see below) to use a "main" branch
>> as default. This small bit of naming adjustment is in-line with
>> Fedora's vision for free and open source software built by inclusive,
>> welcoming, and open-minded communities.
> 
> snip
> 
>> == Upgrade/compatibility impact ==
>>
>> Users with old checkouts will need to update their git configuration
>> or re-clone repositories that have changed before they can see any new
>> changes.
> 
> Is it possible to enhance pagure to support configuring branch
> symbolic refs when branches are renamed, so clients don't need
> to update their checkout ? IIUC, it involves running something
> approximately like this on the server git repo:
> 
>     git symbolic-ref refs/heads/master refs/heads/main
> 
> 
> 
> Regards,
> Daniel
>

[Kevin Fenzi]

On Wed, Dec 09, 2020 at 08:09:44AM +0100, Julen Landa Alustiza wrote:
>  Would be great if we add a deprecation notice (wich could include an
> EOL for
>  the symbolic-ref) to git's output while operating on master branch :D 
I think that would require changes on the git client end?

kevin
--
>  
>  
>  
>  20/12/3 16:53(e)an, Daniel P. Berrangé igorleak idatzi zuen:
>  > On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote:
>  > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  > > 
>  > > == Summary ==
>  > > 
>  > > This Change will move Fedora git repositories to use "main" as the
>  > > default git branch instead of "master". Specific repositories will
> be
>  > > manually moved and default git branch for new projects will be set to
>  > > use "main".
>  > > 
>  > > The Fedora Community strives to be open and welcoming. Some language
>  > > around our git repositories is dated and could be more inclusive. Many
>  > > git repositories currently use "master" as the default branch. This
>  > > Change will move many repositories (see below) to use a "main"
> branch
>  > > as default. This small bit of naming adjustment is in-line with
>  > > Fedora's vision for free and open source software built by inclusive,
>  > > welcoming, and open-minded communities.
>  > 
>  > snip
>  > 
>  > > == Upgrade/compatibility impact ==
>  > > 
>  > > Users with old checkouts will need to update their git configuration
>  > > or re-clone repositories that have changed before they can see any new
>  > > changes.
>  > 
>  > Is it possible to enhance pagure to support configuring branch
>  > symbolic refs when branches are renamed, so clients don't need
>  > to update their checkout ? IIUC, it involves running something
>  > approximately like this on the server git repo:
>  > 
>  >     git symbolic-ref refs/heads/master refs/heads/main
>  > 
>  > 
>  > 
>  > Regards,
>  > Daniel
>  > 
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Vitaly Zaitsev]

On 03.12.2020 16:02, Ben Cotton wrote:
>  This Change will move Fedora git repositories to use "main"
> as the
>  default git branch instead of "master". Specific repositories will be
>  manually moved and default git branch for new projects will be set to
>  use "main". 
1. Why "main" and not "rawhide"?
2. Who will fix the different maintainer scripts? So please add a 
symbolic link from main/rawhide to master.

>  Many git repositories currently use "master" as the default
> branch.  
I generally don't find the word "master" applied to repositories 
offensive at all.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Miroslav Suchý]

Dne 03. 12. 20 v 16:02 Ben Cotton napsal(a):
>  * Release engineering:
>  
>     Releng will adjust any scripts that assume 'master' branch to use
>  'main' instead. The list includes and maybe few more 
I do not see in the list upstream of dist-git.
I proceeded with:
  https://github.com/release-engineering/dist-git/pull/44

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

[Petr Šabata]

Also a couple of notes on modularity here:

# By default, module stream name is derived from the branch name
If we have any "master" modules, those will get unexpectedly renamed
as soon as they get rebuilt. This might impact tagging or updates and
cause confusion in general. We should check if there are any like that
and decide on further steps.

# Modules might be pulling components from their master branches to
build Rawhide artifacts
There are various use cases for this, too long to list. If the master
ref is no longer available, these will not build. Modulemd files that
pull components from master need to be updated after Phase 2.

# The modulemd component ref is optional and defaults to master
Unless this got changed later, if the ref field is omitted, the value
defaults to "master". This is part of the specification and is handled
by libmodulemd. Not sure how to proceed here.

And besides modularity:

There are people and teams who use bots to autobuild their upstream
projects in Rawhide. If they have a bot account (and I hope they do),
they should be notified to update their tooling.

P

[Vít Ondruch]

Dne 03. 12. 20 v 23:26 Petr Šabata napsal(a):
>  Also a couple of notes on modularity here:
>
>  # By default, module stream name is derived from the branch name
>  If we have any "master" modules, those will get unexpectedly renamed
>  as soon as they get rebuilt. This might impact tagging or updates and
>  cause confusion in general. We should check if there are any like that
>  and decide on further steps.
>
>  # Modules might be pulling components from their master branches to
>  build Rawhide artifacts
>  There are various use cases for this, too long to list. If the master
>  ref is no longer available, these will not build. Modulemd files that
>  pull components from master need to be updated after Phase 2.
>
>  # The modulemd component ref is optional and defaults to master
>  Unless this got changed later, if the ref field is omitted, the value
>  defaults to "master". This is part of the specification and is handled
>  by libmodulemd. Not sure how to proceed here. 

Not sure how hardwired this stuff is in libmodulemd and MBS, but the 
`ref` definition was reworded recently:

https://github.com/fedora-modularity/libmodulemd/pull/501/files

So if MBS relied on repository defaults, this could keep working.


Vít


P.S. since this was never good default for `ref`, I see an opportunity 
here ;)


>  And besides modularity:
>
>  There are people and teams who use bots to autobuild their upstream
>  projects in Rawhide. If they have a bot account (and I hope they do),
>  they should be notified to update their tooling.
>
>  P
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Kevin Fenzi]

On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote:
>  Also a couple of notes on modularity here:
>  
>  # By default, module stream name is derived from the branch name
>  If we have any "master" modules, those will get unexpectedly renamed
>  as soon as they get rebuilt. This might impact tagging or updates and
>  cause confusion in general. We should check if there are any like that
>  and decide on further steps. 
Good thing to check yes. I can try and do so. 

>  # Modules might be pulling components from their master branches to
>  build Rawhide artifacts
>  There are various use cases for this, too long to list. If the master
>  ref is no longer available, these will not build. Modulemd files that
>  pull components from master need to be updated after Phase 2. 
Yep. +1

>  # The modulemd component ref is optional and defaults to master
>  Unless this got changed later, if the ref field is omitted, the value
>  defaults to "master". This is part of the specification and is handled
>  by libmodulemd. Not sure how to proceed here. 
Can we change the default? 

>  And besides modularity:
>  
>  There are people and teams who use bots to autobuild their upstream
>  projects in Rawhide. If they have a bot account (and I hope they do),
>  they should be notified to update their tooling. 
We don't have much tracking on bot accounts. People make them and sign
up for fas for them, etc. 

We can try and find things that are obvious, but we are likely to miss
some. We can definitely help people who notice breakage tho. 

kevin

[Petr Šabata]

On Fri, Dec 4, 2020 at 8:48 PM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote:
>  > Also a couple of notes on modularity here:
>  >
>  > # By default, module stream name is derived from the branch name
>  > If we have any "master" modules, those will get unexpectedly renamed
>  > as soon as they get rebuilt. This might impact tagging or updates and
>  > cause confusion in general. We should check if there are any like that
>  > and decide on further steps.
>
>  Good thing to check yes. I can try and do so. 
Thanks.

>  > # Modules might be pulling components from their master branches
> to
>  > build Rawhide artifacts
>  > There are various use cases for this, too long to list. If the master
>  > ref is no longer available, these will not build. Modulemd files that
>  > pull components from master need to be updated after Phase 2.
>
>  Yep. +1 
Great, will you do that, too?

>  > # The modulemd component ref is optional and defaults to master
>  > Unless this got changed later, if the ref field is omitted, the value
>  > defaults to "master". This is part of the specification and is handled
>  > by libmodulemd. Not sure how to proceed here.
>
>  Can we change the default? 
According to Vít that's already happened (for completely unrelated
reasons), so we're good here.

>  > And besides modularity:
>  >
>  > There are people and teams who use bots to autobuild their upstream
>  > projects in Rawhide. If they have a bot account (and I hope they do),
>  > they should be notified to update their tooling.
>
>  We don't have much tracking on bot accounts. People make them and sign
>  up for fas for them, etc.
>
>  We can try and find things that are obvious, but we are likely to miss
>  some. We can definitely help people who notice breakage tho. 
Ah, I kinda expected these accounts to be clearly marked as being
non-human. Oh well.

Anyway, besides the magical module stream renames, all of this should
continue to work fine if we get the symbolic refs, I think?

P

[Kevin Fenzi]

On Fri, Dec 04, 2020 at 10:23:08PM +0100, Petr Šabata wrote:
>  On Fri, Dec 4, 2020 at 8:48 PM Kevin Fenzi <kevin(a)scrye.com&gt;
> wrote:
>  >
>  > On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote:
>  > > Also a couple of notes on modularity here:
>  > >
>  > > # By default, module stream name is derived from the branch name
>  > > If we have any "master" modules, those will get unexpectedly renamed
>  > > as soon as they get rebuilt. This might impact tagging or updates and
>  > > cause confusion in general. We should check if there are any like that
>  > > and decide on further steps.
>  >
>  > Good thing to check yes. I can try and do so.
>  
>  Thanks. 
hum, but I am not 100% sure what I am looking for.
modules with a master branch and no name defined? 
What does the name being defined look like in the yaml file?
>  
>  > > # Modules might be pulling components from their master branches to
>  > > build Rawhide artifacts
>  > > There are various use cases for this, too long to list. If the master
>  > > ref is no longer available, these will not build. Modulemd files that
>  > > pull components from master need to be updated after Phase 2.
>  >
>  > Yep. +1
>  
>  Great, will you do that, too? 
There seems to be a bunch of them. ;( 

atomic/atomic.yaml:            bootstrap: master
atomic/atomic.yaml:                ref: master
atomic/atomic.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
eclipse/eclipse.yaml:                ref: master
fonts/fonts.yaml:            bootstrap: master
fonts/fonts.yaml:            platform: master
freeipa/freeipa.yaml:            bootstrap: master
freeipa/freeipa.yaml:            389-ds: master
freeipa/freeipa.yaml:            bind: master
freeipa/freeipa.yaml:            sssd: master
freeipa/freeipa.yaml:            python2: master
freeipa/freeipa.yaml:            # python2-ecosystem: master
freeipa/freeipa.yaml:            python3: master
freeipa/freeipa.yaml:            python3-ecosystem: master
freeipa/freeipa.yaml:            platform: master
freeipa/freeipa.yaml:            java: master
freeipa/freeipa.yaml:            perl: master
freeipa/freeipa.yaml:            389-ds: master
freeipa/freeipa.yaml:            bind: master
freeipa/freeipa.yaml:            sssd: master
freeipa/freeipa.yaml:            samba: master
freeipa/freeipa.yaml:            pki: master
freeipa/freeipa.yaml:            tomcat: master
freeipa/freeipa.yaml:            resteasy: master
freeipa/freeipa.yaml:            httpd: master
freeipa/freeipa.yaml:            python2: master
freeipa/freeipa.yaml:            python2-ecosystem: master
freeipa/freeipa.yaml:            python3: master
freeipa/freeipa.yaml:            python3-ecosystem: master
freeipa/freeipa.yaml:            libtom: master
freeipa/freeipa.yaml:            fonts: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
freeipa/freeipa.yaml:                ref: master
hardware-support/hardware-support.yaml:            bootstrap: master
hardware-support/hardware-support.yaml:            platform: master
hardware-support/hardware-support.yaml:            host: master
hardware-support/hardware-support.yaml:            perl: master
help2man/help2man.yaml:            perl: master
help2man/help2man.yaml:            platform: master
help2man/help2man.yaml:            perl: master
help2man/help2man.yaml:            platform: master
help2man/help2man.yaml:                ref: master
host/host.yaml:            bootstrap: master
host/host.yaml:            platform: master
installer-bootstrap/installer-bootstrap.yaml:      bootstrap: master
installer-bootstrap/installer-bootstrap.yaml:      base-runtime: master
installer-bootstrap/installer-bootstrap.yaml:      bootstrap: master
installer/installer.yaml:            python3: master
installer/installer.yaml:            python3-ecosystem: master
installer/installer.yaml:            perl: master
installer/installer.yaml:                ref: master
java/java.yaml:            bootstrap: master
java/java.yaml:            platform: master
java/java.yaml:            fonts: master
java/java.yaml:            X11-base: master
javapackages-tools/javapackages-tools.yaml:            glassfish-master-pom:
javapackages-tools/javapackages-tools.yaml:                         glassfish-master-pom,
glassfish-servlet-api,
javapackages-tools/javapackages-tools.yaml:                         glassfish-master-pom,
glassfish-servlet-api,
javapackages-tools/javapackages-tools.yaml:                         geronimo-parent-poms,
glassfish-master-pom,
jdk-11/jdk-11.yaml:            jdk-10: [master]
krb5/krb5.yaml:            bootstrap: master
krb5/krb5.yaml:            platform: master
libtom/libtom.yaml:      bootstrap: master
libtom/libtom.yaml:      #platform: master
libtom/libtom.yaml:      #autotools: master
libtom/libtom.yaml:      #texlive: master
libtom/libtom.yaml:      platform: master
mariadb/mariadb.yaml:            bootstrap: master
mariadb/mariadb.yaml:            platform: master
mariadb/mariadb.yaml:            host: master
mariadb/mariadb.yaml:            networking-base: master
memcached/memcached.yaml:                ref: master
mongodb/mongodb.yaml:            bootstrap: master
mongodb/mongodb.yaml:            boost: master
mongodb/mongodb.yaml:            platform: master
mongodb/mongodb.yaml:            perl: master
mongodb/mongodb.yaml:            boost: master
mysql/mysql.yaml:            bootstrap: master
mysql/mysql.yaml:            platform: master
mysql/mysql.yaml:            host: master
mysql/mysql.yaml:            hardware-support: master
networking-base/networking-base.yaml:            bootstrap: master
networking-base/networking-base.yaml:            platform: master
networking-base/networking-base.yaml:            perl: master
networking-base/networking-base.yaml:            python3: master
networking-base/networking-base.yaml:            python3-ecosystem: master
nginx/nginx.yaml:            base-runtime: master
nginx/nginx.yaml:            base-runtime: master
ntp/ntp.yaml:            base-runtime: master
ntp/ntp.yaml:            base-runtime: master
perl-libintl-perl/perl-libintl-perl.yaml:            perl: master
perl-libintl-perl/perl-libintl-perl.yaml:            platform: master
perl-libintl-perl/perl-libintl-perl.yaml:            host: master
perl-libintl-perl/perl-libintl-perl.yaml:            perl: master
perl-libintl-perl/perl-libintl-perl.yaml:                ref: master
perl-libintl-perl/perl-libintl-perl.yaml:                ref: master
perl-libintl-perl/perl-libintl-perl.yaml:                ref: master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:            platform:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:            perl: master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:            host: master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:            perl: master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install-bootstrap/perl-Module-Install-bootstrap.yaml:                ref:
master
perl-Module-Install/perl-Module-Install.yaml:            platform: master
perl-Module-Install/perl-Module-Install.yaml:            perl: master
perl-Module-Install/perl-Module-Install.yaml:            perl-Module-Install-bootstrap:
master
perl-Module-Install/perl-Module-Install.yaml:            host: master
perl-Module-Install/perl-Module-Install.yaml:            perl: master
perl-Module-Install/perl-Module-Install.yaml:                ref: master
perl-Module-Install/perl-Module-Install.yaml:                ref: master
perl-Module-Install/perl-Module-Install.yaml:                ref: master
perl-Module-Install/perl-Module-Install.yaml:                ref: master
perl-Module-Install/perl-Module-Install.yaml:                ref: master
perl-Module-Install/perl-Module-Install.yaml:                ref: master
perl-Module-Package/perl-Module-Package.yaml:            perl: master
perl-Module-Package/perl-Module-Package.yaml:            perl-Module-Install: master
perl-Module-Package/perl-Module-Package.yaml:            perl-Moo: master
perl-Module-Package/perl-Module-Package.yaml:            platform: master
perl-Module-Package/perl-Module-Package.yaml:            host: master
perl-Module-Package/perl-Module-Package.yaml:            perl: master
perl-Module-Package/perl-Module-Package.yaml:            perl-Module-Install: master
perl-Module-Package/perl-Module-Package.yaml:            perl-Moo: master
perl-Module-Package/perl-Module-Package.yaml:                ref: master
perl-Module-Package/perl-Module-Package.yaml:                ref: master
perl-Module-Package/perl-Module-Package.yaml:                ref: master
perl-Module-Package/perl-Module-Package.yaml:                ref: master
perl-Module-Package/perl-Module-Package.yaml:                ref: master
perl-Module-Package/perl-Module-Package.yaml:                ref: master
perl-Module-Package/perl-Module-Package.yaml:                ref: master
perl-Module-Package/perl-Module-Package.yaml:                ref: master
perl-Module-Package/perl-Module-Package.yaml:                ref: master
perl-Module-Package/perl-Module-Package.yaml:                ref: master
perl-Module-Package/perl-Module-Package.yaml:                ref: master
perl-Module-Package/perl-Module-Package.yaml:                ref: master
perl-Module-Package/perl-Module-Package.yaml:                ref: master
perl-Module-Package/perl-Module-Package.yaml:                ref: master
perl-Module-Package/perl-Module-Package.yaml:                ref: master
perl-Moo/perl-Moo.yaml:            platform: master
perl-Moo/perl-Moo.yaml:            perl: master
perl-Moo/perl-Moo.yaml:            host: master
perl-Moo/perl-Moo.yaml:            perl: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Moo/perl-Moo.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:            perl: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:           
perl-Module-Install: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:           
perl-Module-Package: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:            platform: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:            host: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:            perl-Moo: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:            perl: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
perl-Unicode-EastAsianWidth/perl-Unicode-EastAsianWidth.yaml:                ref: master
postgresql/postgresql.yaml:      bootstrap: master
postgresql/postgresql.yaml:      platform: master
proftpd/proftpd.yaml:            base-runtime: master
proftpd/proftpd.yaml:            base-runtime: master
resteasy/resteasy.yaml:            bootstrap: master
resteasy/resteasy.yaml:            platform: master
resteasy/resteasy.yaml:            java: master
resteasy/resteasy.yaml:            apache-commons: master
resteasy/resteasy.yaml:            maven: master
resteasy/resteasy.yaml:                ref: master
resteasy/resteasy.yaml:                ref: master
resteasy/resteasy.yaml:                ref: master
resteasy/resteasy.yaml:                ref: master
resteasy/resteasy.yaml:                ref: master
resteasy/resteasy.yaml:                ref: master
resteasy/resteasy.yaml:                ref: master
resteasy/resteasy.yaml:                ref: master
resteasy/resteasy.yaml:                ref: master
resteasy/resteasy.yaml:                ref: master
resteasy/resteasy.yaml:                ref: master
resteasy/resteasy.yaml:                ref: master
resteasy/resteasy.yaml:                ref: master
resteasy/resteasy.yaml:                ref: master
rsyslog/rsyslog.yaml:            #perl: master
rsyslog/rsyslog.yaml:            #python2: master
rsyslog/rsyslog.yaml:            #python3: master
rsyslog/rsyslog.yaml:            #!!TEMPORARY!! - switch to master/upstream/etc. branch
once varnish module gets updated !!
rsyslog/rsyslog.yaml:        documentation: http://www.rsyslog.com/doc/master/index.html
ruby/ruby.yaml:                ref: master
ruby/ruby.yaml:                ref: master
ruby/ruby.yaml:                ref: master
ruby/ruby.yaml:                ref: master
ruby/ruby.yaml:                ref: master
ruby/ruby.yaml:                ref: master
samba/samba.yaml:            bootstrap: master
samba/samba.yaml:            platform: master
samba/samba.yaml:            python2: master
samba/samba.yaml:            python2-ecosystem: master
samba/samba.yaml:            libtom: master
shim/shim.yaml:            bootstrap: master
sssd/sssd.yaml:            bootstrap: master
sssd/sssd.yaml:            platform: master
sssd/sssd.yaml:            samba: master
sssd/sssd.yaml:            python3: master
sssd/sssd.yaml:            python3-ecosystem: master
swig/swig.yaml:            platform: master
swig/swig.yaml:            autotools: master
swig/swig.yaml:            boost: master
swig/swig.yaml:            help2man: master
swig/swig.yaml:            perl: master
swig/swig.yaml:            python2: master
swig/swig.yaml:            python3: master
swig/swig.yaml:            platform: master
swig/swig.yaml:            perl: master
swig/swig.yaml:                ref: master
swig/swig.yaml:                ref: master
swig/swig.yaml:                ref: master
system-tools/system-tools.yaml:      bootstrap: master
system-tools/system-tools.yaml:      platform: master
system-tools/system-tools.yaml:        ref: master
system-tools/system-tools.yaml:        ref: master
system-tools/system-tools.yaml:        ref: master
system-tools/system-tools.yaml:        ref: master
system-tools/system-tools.yaml:        ref: master
testmodule2/testmodule2.yaml:              testmodule: [master, 2.0]
testmodule2/testmodule2.yaml:              testmodule: [master, 2.0]
testmodule2/testmodule2.yaml:                ref: master
testmodule/testmodule.yaml:                ref: master
texlive/texlive.yaml:            bootstrap: master
texlive/texlive.yaml:            platform: master
texlive/texlive.yaml:            perl: master
texlive/texlive.yaml:            X11-base: master
texlive/texlive.yaml:            fonts: master
texlive/texlive.yaml:                ref: master
texlive/texlive.yaml:            #    ref: master
texlive/texlive.yaml:            #    ref: master
texlive/texlive.yaml:                ref: master
texlive/texlive.yaml:                ref: master
texlive/texlive.yaml:                ref: master
texlive/texlive.yaml:                ref: master
texlive/texlive.yaml:                ref: master
texlive/texlive.yaml:                ref: master
texlive/texlive.yaml:                ref: master
texlive/texlive.yaml:                ref: master
texlive/texlive.yaml:                ref: master
tomcat/tomcat.yaml:                ref: master
tomcat/tomcat.yaml:                ref: master
udisks2/udisks2.yaml:            bootstrap: master
udisks2/udisks2.yaml:            platform: master
udisks2/udisks2.yaml:            python3: master
varnish/varnish.yaml:            bootstrap: master
varnish/varnish.yaml:            base-runtime: master
X11-base/X11-base.yaml:            bootstrap: master
X11-base/X11-base.yaml:            platform: master
X11-base/X11-base.yaml:            fonts: master
X11-base/X11-base.yaml:            autotools: master

>  > > # The modulemd component ref is optional and defaults to
> master
>  > > Unless this got changed later, if the ref field is omitted, the value
>  > > defaults to "master". This is part of the specification and is
> handled
>  > > by libmodulemd. Not sure how to proceed here.
>  >
>  > Can we change the default?
>  
>  According to Vít that's already happened (for completely unrelated
>  reasons), so we're good here. 
ok.

>  > > And besides modularity:
>  > >
>  > > There are people and teams who use bots to autobuild their upstream
>  > > projects in Rawhide. If they have a bot account (and I hope they do),
>  > > they should be notified to update their tooling.
>  >
>  > We don't have much tracking on bot accounts. People make them and sign
>  > up for fas for them, etc.
>  >
>  > We can try and find things that are obvious, but we are likely to miss
>  > some. We can definitely help people who notice breakage tho.
>  
>  Ah, I kinda expected these accounts to be clearly marked as being
>  non-human. Oh well.
>  
>  Anyway, besides the magical module stream renames, all of this should
>  continue to work fine if we get the symbolic refs, I think? 
Well, I am ok with a symbolic ref from main to/from rawhide, but I don't
like the idea of a master symbolic ref. It kind of defeats the purpose
of the entire thing. ;( 

kevin

[Petr Šabata]

On Sat, Dec 5, 2020 at 7:46 PM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  On Fri, Dec 04, 2020 at 10:23:08PM +0100, Petr Šabata wrote:
>  > On Fri, Dec 4, 2020 at 8:48 PM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  > >
>  > > On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote:
>  > > > Also a couple of notes on modularity here:
>  > > >
>  > > > # By default, module stream name is derived from the branch name
>  > > > If we have any "master" modules, those will get unexpectedly
> renamed
>  > > > as soon as they get rebuilt. This might impact tagging or updates and
>  > > > cause confusion in general. We should check if there are any like that
>  > > > and decide on further steps.
>  > >
>  > > Good thing to check yes. I can try and do so.
>  >
>  > Thanks.
>
>  hum, but I am not 100% sure what I am looking for.
>  modules with a master branch and no name defined?
>  What does the name being defined look like in the yaml file? 
Yes. You could also query MBS for stream=master and see if there's
anything reasonably recent to narrow your search. But branches would
be enough.

In modulemd, stream name is defined as "stream: <streamname>".

>  > > > # Modules might be pulling components from their
> master branches to
>  > > > build Rawhide artifacts
>  > > > There are various use cases for this, too long to list. If the master
>  > > > ref is no longer available, these will not build. Modulemd files that
>  > > > pull components from master need to be updated after Phase 2.
>  > >
>  > > Yep. +1
>  >
>  > Great, will you do that, too?
>
>  There seems to be a bunch of them. ;( 
Many of those are definitely obsolete, though!

>  > > > # The modulemd component ref is optional and defaults
> to master
>  > > > Unless this got changed later, if the ref field is omitted, the value
>  > > > defaults to "master". This is part of the specification and is
> handled
>  > > > by libmodulemd. Not sure how to proceed here.
>  > >
>  > > Can we change the default?
>  >
>  > According to Vít that's already happened (for completely unrelated
>  > reasons), so we're good here.
>
>  ok.
>
>  > > > And besides modularity:
>  > > >
>  > > > There are people and teams who use bots to autobuild their upstream
>  > > > projects in Rawhide. If they have a bot account (and I hope they do),
>  > > > they should be notified to update their tooling.
>  > >
>  > > We don't have much tracking on bot accounts. People make them and sign
>  > > up for fas for them, etc.
>  > >
>  > > We can try and find things that are obvious, but we are likely to miss
>  > > some. We can definitely help people who notice breakage tho.
>  >
>  > Ah, I kinda expected these accounts to be clearly marked as being
>  > non-human. Oh well.
>  >
>  > Anyway, besides the magical module stream renames, all of this should
>  > continue to work fine if we get the symbolic refs, I think?
>
>  Well, I am ok with a symbolic ref from main to/from rawhide, but I don't
>  like the idea of a master symbolic ref. It kind of defeats the purpose
>  of the entire thing. ;( 
Well, okay. If we get the master ref, I'm happy as that's mostly a no-op for me.
If not, it implies a lot of downstream RHEL work we'll have to handle.
Just let us all know in due time.

P

[Kevin Fenzi]

On Mon, Dec 07, 2020 at 10:13:13PM +0100, Petr Šabata wrote:
>  On Sat, Dec 5, 2020 at 7:46 PM Kevin Fenzi <kevin(a)scrye.com&gt;
> wrote:
>  >
>  > On Fri, Dec 04, 2020 at 10:23:08PM +0100, Petr Šabata wrote:
>  > > On Fri, Dec 4, 2020 at 8:48 PM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  > > >
>  > > > On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote:
>  > > > > Also a couple of notes on modularity here:
>  > > > >
>  > > > > # By default, module stream name is derived from the branch name
>  > > > > If we have any "master" modules, those will get
> unexpectedly renamed
>  > > > > as soon as they get rebuilt. This might impact tagging or updates
> and
>  > > > > cause confusion in general. We should check if there are any like
> that
>  > > > > and decide on further steps.
>  > > >
>  > > > Good thing to check yes. I can try and do so.
>  > >
>  > > Thanks.
>  >
>  > hum, but I am not 100% sure what I am looking for.
>  > modules with a master branch and no name defined?
>  > What does the name being defined look like in the yaml file?
>  
>  Yes. You could also query MBS for stream=master and see if there's
>  anything reasonably recent to narrow your search. But branches would
>  be enough.
>  
>  In modulemd, stream name is defined as "stream: <streamname>". 
So, I looked back the last 3 months and I am pretty sure the only ones
are all flatpaks. (firefix, thunderbird, etc)

>  > > > > # Modules might be pulling components from their
> master branches to
>  > > > > build Rawhide artifacts
>  > > > > There are various use cases for this, too long to list. If the
> master
>  > > > > ref is no longer available, these will not build. Modulemd files
> that
>  > > > > pull components from master need to be updated after Phase 2.
>  > > >
>  > > > Yep. +1
>  > >
>  > > Great, will you do that, too?
>  >
>  > There seems to be a bunch of them. ;(
>  
>  Many of those are definitely obsolete, though! 
Well, I checked out all the modules from rawhide. How can I tell they
are obsolete?

>  > > > > # The modulemd component ref is optional and
> defaults to master
>  > > > > Unless this got changed later, if the ref field is omitted, the
> value
>  > > > > defaults to "master". This is part of the specification and
> is handled
>  > > > > by libmodulemd. Not sure how to proceed here.
>  > > >
>  > > > Can we change the default?
>  > >
>  > > According to Vít that's already happened (for completely unrelated
>  > > reasons), so we're good here.
>  >
>  > ok.
>  >
>  > > > > And besides modularity:
>  > > > >
>  > > > > There are people and teams who use bots to autobuild their upstream
>  > > > > projects in Rawhide. If they have a bot account (and I hope they
> do),
>  > > > > they should be notified to update their tooling.
>  > > >
>  > > > We don't have much tracking on bot accounts. People make them and
> sign
>  > > > up for fas for them, etc.
>  > > >
>  > > > We can try and find things that are obvious, but we are likely to miss
>  > > > some. We can definitely help people who notice breakage tho.
>  > >
>  > > Ah, I kinda expected these accounts to be clearly marked as being
>  > > non-human. Oh well.
>  > >
>  > > Anyway, besides the magical module stream renames, all of this should
>  > > continue to work fine if we get the symbolic refs, I think?
>  >
>  > Well, I am ok with a symbolic ref from main to/from rawhide, but I don't
>  > like the idea of a master symbolic ref. It kind of defeats the purpose
>  > of the entire thing. ;(
>  
>  Well, okay. If we get the master ref, I'm happy as that's mostly a no-op for me.
>  If not, it implies a lot of downstream RHEL work we'll have to handle.
>  Just let us all know in due time. 
Well, I don't want to keep master around in any form... and yeah, I
realize there's going to be fallout. ;( 

kevin

[Miro Hrončok]

On 12/8/20 11:54 PM, Kevin Fenzi wrote:
>  Well, I don't want to keep master around in any form... and yeah,
> I
>  realize there's going to be fallout. ;( 
Maybe we can phase it? First, provide the backwards compatible ref, see what 
breaks anyway. And only after some time, remove it?

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Christopher]

Wouldn't "rawhide" be the best name for most git repos, rather than
"main"?

On Tue, Dec 8, 2020, 18:28 Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

>  On 12/8/20 11:54 PM, Kevin Fenzi wrote:
>  > Well, I don't want to keep master around in any form... and yeah, I
>  > realize there's going to be fallout. ;(
>
>  Maybe we can phase it? First, provide the backwards compatible ref, see
>  what
>  breaks anyway. And only after some time, remove it?
>
>  --
>  Miro Hrončok
>  --
>  Phone: [phone]
>  IRC: mhroncok
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Kevin Fenzi]

On Wed, Dec 09, 2020 at 12:27:10AM +0100, Miro Hrončok wrote:
>  On 12/8/20 11:54 PM, Kevin Fenzi wrote:
>  > Well, I don't want to keep master around in any form... and yeah, I
>  > realize there's going to be fallout. ;(
>  
>  Maybe we can phase it? First, provide the backwards compatible ref, see what
>  breaks anyway. And only after some time, remove it? 
We could, but I think thats just kicking the can down the road and it's
better to just do it and fix things now when we have time, rather than
later when we might have less.

kevin

[Petr Šabata]

On Tue, Dec 8, 2020 at 11:57 PM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  On Mon, Dec 07, 2020 at 10:13:13PM +0100, Petr Šabata wrote:
>  > On Sat, Dec 5, 2020 at 7:46 PM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  > >
>  > > On Fri, Dec 04, 2020 at 10:23:08PM +0100, Petr Šabata wrote:
>  > > > On Fri, Dec 4, 2020 at 8:48 PM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  > > > >
>  > > > > On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote:
>  > > > > > Also a couple of notes on modularity here:
>  > > > > >
>  > > > > > # By default, module stream name is derived from the branch
> name
>  > > > > > If we have any "master" modules, those will get
> unexpectedly renamed
>  > > > > > as soon as they get rebuilt. This might impact tagging or
> updates and
>  > > > > > cause confusion in general. We should check if there are any
> like that
>  > > > > > and decide on further steps.
>  > > > >
>  > > > > Good thing to check yes. I can try and do so.
>  > > >
>  > > > Thanks.
>  > >
>  > > hum, but I am not 100% sure what I am looking for.
>  > > modules with a master branch and no name defined?
>  > > What does the name being defined look like in the yaml file?
>  >
>  > Yes. You could also query MBS for stream=master and see if there's
>  > anything reasonably recent to narrow your search. But branches would
>  > be enough.
>  >
>  > In modulemd, stream name is defined as "stream: <streamname>".
>
>  So, I looked back the last 3 months and I am pretty sure the only ones
>  are all flatpaks. (firefix, thunderbird, etc) 
https://mbs.fedoraproject.org/module-build-service/1/module-builds/?strea...

I can also see avocado:master built for f33 there on the first page.
But it could also matter for flatpaks if the name is referenced in the
build process.

CC'ing Owen.

>  > > > > > # Modules might be pulling components from
> their master branches to
>  > > > > > build Rawhide artifacts
>  > > > > > There are various use cases for this, too long to list. If the
> master
>  > > > > > ref is no longer available, these will not build. Modulemd files
> that
>  > > > > > pull components from master need to be updated after Phase 2.
>  > > > >
>  > > > > Yep. +1
>  > > >
>  > > > Great, will you do that, too?
>  > >
>  > > There seems to be a bunch of them. ;(
>  >
>  > Many of those are definitely obsolete, though!
>
>  Well, I checked out all the modules from rawhide. How can I tell they
>  are obsolete? 
Uh; I was fairly certain some of those were my dev modules from the Boltron era.
If I recall correctly, Merlin was working on marking modules as
obsolete at some point. Maybe we didn't actually run it all of them
and they're being built automatically. We should review everything
that's in Rawhide and obviously isn't supposed to be.

CC'ing Merlin.

P

>  > > > > > # The modulemd component ref is optional and
> defaults to master
>  > > > > > Unless this got changed later, if the ref field is omitted, the
> value
>  > > > > > defaults to "master". This is part of the
> specification and is handled
>  > > > > > by libmodulemd. Not sure how to proceed here.
>  > > > >
>  > > > > Can we change the default?
>  > > >
>  > > > According to Vít that's already happened (for completely unrelated
>  > > > reasons), so we're good here.
>  > >
>  > > ok.
>  > >
>  > > > > > And besides modularity:
>  > > > > >
>  > > > > > There are people and teams who use bots to autobuild their
> upstream
>  > > > > > projects in Rawhide. If they have a bot account (and I hope they
> do),
>  > > > > > they should be notified to update their tooling.
>  > > > >
>  > > > > We don't have much tracking on bot accounts. People make them and
> sign
>  > > > > up for fas for them, etc.
>  > > > >
>  > > > > We can try and find things that are obvious, but we are likely to
> miss
>  > > > > some. We can definitely help people who notice breakage tho.
>  > > >
>  > > > Ah, I kinda expected these accounts to be clearly marked as being
>  > > > non-human. Oh well.
>  > > >
>  > > > Anyway, besides the magical module stream renames, all of this should
>  > > > continue to work fine if we get the symbolic refs, I think?
>  > >
>  > > Well, I am ok with a symbolic ref from main to/from rawhide, but I don't
>  > > like the idea of a master symbolic ref. It kind of defeats the purpose
>  > > of the entire thing. ;(
>  >
>  > Well, okay. If we get the master ref, I'm happy as that's mostly a no-op for
> me.
>  > If not, it implies a lot of downstream RHEL work we'll have to handle.
>  > Just let us all know in due time.
>
>  Well, I don't want to keep master around in any form... and yeah, I
>  realize there's going to be fallout. ;(
>
>  kevin
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Merlin Mathesius]

On Wed, Dec 9, 2020 at 1:54 AM Petr Šabata <contyk(a)redhat.com&gt; wrote:

>  On Tue, Dec 8, 2020 at 11:57 PM Kevin Fenzi <kevin(a)scrye.com&gt;
> wrote:
>  >
>  > On Mon, Dec 07, 2020 at 10:13:13PM +0100, Petr Šabata wrote:
>  > > On Sat, Dec 5, 2020 at 7:46 PM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  > > >
>  > > > On Fri, Dec 04, 2020 at 10:23:08PM +0100, Petr Šabata wrote:
>  > > > > On Fri, Dec 4, 2020 at 8:48 PM Kevin Fenzi <kevin(a)scrye.com&gt;
>  wrote:
>  > > > > >
>  > > > > > On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote:
>  > > > > > > Also a couple of notes on modularity here:
>  > > > > > >
>  > > > > > > # By default, module stream name is derived from the
> branch
>  name
>  > > > > > > If we have any "master" modules, those will get
> unexpectedly
>  renamed
>  > > > > > > as soon as they get rebuilt. This might impact tagging or
>  updates and
>  > > > > > > cause confusion in general. We should check if there are
> any
>  like that
>  > > > > > > and decide on further steps.
>  > > > > >
>  > > > > > Good thing to check yes. I can try and do so.
>  > > > >
>  > > > > Thanks.
>  > > >
>  > > > hum, but I am not 100% sure what I am looking for.
>  > > > modules with a master branch and no name defined?
>  > > > What does the name being defined look like in the yaml file?
>  > >
>  > > Yes. You could also query MBS for stream=master and see if there's
>  > > anything reasonably recent to narrow your search. But branches would
>  > > be enough.
>  > >
>  > > In modulemd, stream name is defined as "stream: <streamname>".
>  >
>  > So, I looked back the last 3 months and I am pretty sure the only ones
>  > are all flatpaks. (firefix, thunderbird, etc)
>
>
>  https://mbs.fedoraproject.org/module-build-service/1/module-builds/?strea...
>
>  I can also see avocado:master built for f33 there on the first page.
>  But it could also matter for flatpaks if the name is referenced in the
>  build process.
>
>  CC'ing Owen.
>
>  > > > > > > # Modules might be pulling components from their master
>  branches to
>  > > > > > > build Rawhide artifacts
>  > > > > > > There are various use cases for this, too long to list. If
> the
>  master
>  > > > > > > ref is no longer available, these will not build. Modulemd
>  files that
>  > > > > > > pull components from master need to be updated after Phase
> 2.
>  > > > > >
>  > > > > > Yep. +1
>  > > > >
>  > > > > Great, will you do that, too?
>  > > >
>  > > > There seems to be a bunch of them. ;(
>  > >
>  > > Many of those are definitely obsolete, though!
>  >
>  > Well, I checked out all the modules from rawhide. How can I tell they
>  > are obsolete?
>
>  Uh; I was fairly certain some of those were my dev modules from the
>  Boltron era.
>  If I recall correctly, Merlin was working on marking modules as
>  obsolete at some point. Maybe we didn't actually run it all of them
>  and they're being built automatically. We should review everything
>  that's in Rawhide and obviously isn't supposed to be.
>
>  CC'ing Merlin.
>  
I created https://pagure.io/releng/issue/8887 last year to clean up a bunch
of obsolete module stream branches, but it's still on the back burner.

Merlin

P
>  > > > > > > # The modulemd component ref is optional and defaults to
> master
>  > > > > > > Unless this got changed later, if the ref field is
> omitted,
>  the value
>  > > > > > > defaults to "master". This is part of the
> specification and is
>  handled
>  > > > > > > by libmodulemd. Not sure how to proceed here.
>  > > > > >
>  > > > > > Can we change the default?
>  > > > >
>  > > > > According to Vít that's already happened (for completely
> unrelated
>  > > > > reasons), so we're good here.
>  > > >
>  > > > ok.
>  > > >
>  > > > > > > And besides modularity:
>  > > > > > >
>  > > > > > > There are people and teams who use bots to autobuild their
>  upstream
>  > > > > > > projects in Rawhide. If they have a bot account (and I
> hope
>  they do),
>  > > > > > > they should be notified to update their tooling.
>  > > > > >
>  > > > > > We don't have much tracking on bot accounts. People make
> them
>  and sign
>  > > > > > up for fas for them, etc.
>  > > > > >
>  > > > > > We can try and find things that are obvious, but we are likely
>  to miss
>  > > > > > some. We can definitely help people who notice breakage tho.
>  > > > >
>  > > > > Ah, I kinda expected these accounts to be clearly marked as being
>  > > > > non-human. Oh well.
>  > > > >
>  > > > > Anyway, besides the magical module stream renames, all of this
>  should
>  > > > > continue to work fine if we get the symbolic refs, I think?
>  > > >
>  > > > Well, I am ok with a symbolic ref from main to/from rawhide, but I
>  don't
>  > > > like the idea of a master symbolic ref. It kind of defeats the
>  purpose
>  > > > of the entire thing. ;(
>  > >
>  > > Well, okay. If we get the master ref, I'm happy as that's mostly a
>  no-op for me.
>  > > If not, it implies a lot of downstream RHEL work we'll have to handle.
>  > > Just let us all know in due time.
>  >
>  > Well, I don't want to keep master around in any form... and yeah, I
>  > realize there's going to be fallout. ;(
>  >
>  > kevin
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  > Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>
>

[Jean-Baptiste Holcroft]

hi,

I see some pagure.io project are automatically handled by this change

could teams register their repositories to be migrated automatically?
if so, what's the deadline to ask for our repositories to be included in this change?

[Kevin Fenzi]

On Wed, Dec 09, 2020 at 09:21:34PM -0000, Jean-Baptiste Holcroft wrote:
>  hi,
>  
>  I see some pagure.io project are automatically handled by this change
>  
>  could teams register their repositories to be migrated automatically?
>  if so, what's the deadline to ask for our repositories to be included in this change?
Yes, I think we could look at doing more on an opt-in basis if that was
something folks wanted. 

I'd say get the list into us the week before?
Or if after just file a infrastructure ticket with list and we can do it
then (although it might be nice to do as the same time as others I
agree). 

kevin

[Stuart D Gathman]

Wouldn't "rawhide" be more consistent with the other branch names?

On Thu, 3 Dec 2020, Ben Cotton wrote:

> https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>
> == Summary ==
>
> This Change will move Fedora git repositories to use "main" as the
> default git branch instead of "master". Specific repositories will be
> manually moved and default git branch for new projects will be set to
> use "main".

[Kevin Fenzi]

On Wed, Dec 09, 2020 at 04:25:53PM -0500, Stuart D Gathman wrote:
>  Wouldn't "rawhide" be more consistent with the other
> branch names? 
This has been discussed elsewhere in the thread.

I think we agreed to add a sym-ref between rawhide and main (ie, either
would work). 

I can get the change updated. 

kevin
--
>  
>  On Thu, 3 Dec 2020, Ben Cotton wrote:
>  
>  > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  > 
>  > == Summary ==
>  > 
>  > This Change will move Fedora git repositories to use "main" as the
>  > default git branch instead of "master". Specific repositories will be
>  > manually moved and default git branch for new projects will be set to
>  > use "main".
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Robert-André Mauchin]

On 12/3/20 4:02 PM, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  
>  == Summary ==
>  
>  This Change will move Fedora git repositories to use "main" as the
>  default git branch instead of "master". Specific repositories will be
>  manually moved and default git branch for new projects will be set to
>  use "main".
>  
>  The Fedora Community strives to be open and welcoming. Some language
>  around our git repositories is dated and could be more inclusive. Many
>  git repositories currently use "master" as the default branch. This
>  Change will move many repositories (see below) to use a "main" branch
>  as default. This small bit of naming adjustment is in-line with
>  Fedora's vision for free and open source software built by inclusive,
>  welcoming, and open-minded communities.
>  
>   
How does it work for the enduser? I have thousand of git repos locally 
with the master branch, will it rename automatically master to main when 
I git pull or do I need to run a special command?

[Kevin Fenzi]

On Thu, Dec 10, 2020 at 10:36:36AM +0100, Robert-André Mauchin wrote:
>  On 12/3/20 4:02 PM, Ben Cotton wrote:
>  > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  > 
>  > == Summary ==
>  > 
>  > This Change will move Fedora git repositories to use "main" as the
>  > default git branch instead of "master". Specific repositories will be
>  > manually moved and default git branch for new projects will be set to
>  > use "main".
>  > 
>  > The Fedora Community strives to be open and welcoming. Some language
>  > around our git repositories is dated and could be more inclusive. Many
>  > git repositories currently use "master" as the default branch. This
>  > Change will move many repositories (see below) to use a "main" branch
>  > as default. This small bit of naming adjustment is in-line with
>  > Fedora's vision for free and open source software built by inclusive,
>  > welcoming, and open-minded communities.
>  > 
>  > 
>  
>  How does it work for the enduser? I have thousand of git repos locally with
>  the master branch, will it rename automatically master to main when I git
>  pull or do I need to run a special command? 
You will need to reclone or run some commands in those existing
checkouts. 

If you have a clone that has 'master' branch and we delete that, and you
'git pull' you will get: 

Fetching origin
Your configuration specifies to merge with the ref 'refs/heads/master'
from the remote, but no such ref was fetched.

So you will need to do: 

git checkout main
git branch --set-upstream-to=origin/main main

then git pull. 

I don't think there's anything we can do on the server side to make that
easier. Pingou any ideas?

kevin

[Pierre-Yves Chibon]

On Thu, Dec 10, 2020 at 10:29:12AM -0800, Kevin Fenzi wrote:
>  On Thu, Dec 10, 2020 at 10:36:36AM +0100, Robert-André Mauchin
> wrote:
>  > On 12/3/20 4:02 PM, Ben Cotton wrote:
>  > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  > > 
>  > > == Summary ==
>  > > 
>  > > This Change will move Fedora git repositories to use "main" as the
>  > > default git branch instead of "master". Specific repositories will
> be
>  > > manually moved and default git branch for new projects will be set to
>  > > use "main".
>  > > 
>  > > The Fedora Community strives to be open and welcoming. Some language
>  > > around our git repositories is dated and could be more inclusive. Many
>  > > git repositories currently use "master" as the default branch. This
>  > > Change will move many repositories (see below) to use a "main"
> branch
>  > > as default. This small bit of naming adjustment is in-line with
>  > > Fedora's vision for free and open source software built by inclusive,
>  > > welcoming, and open-minded communities.
>  > > 
>  > > 
>  > 
>  > How does it work for the enduser? I have thousand of git repos locally with
>  > the master branch, will it rename automatically master to main when I git
>  > pull or do I need to run a special command?
>  
>  You will need to reclone or run some commands in those existing
>  checkouts. 
>  
>  If you have a clone that has 'master' branch and we delete that, and you
>  'git pull' you will get: 
>  
>  Fetching origin
>  Your configuration specifies to merge with the ref 'refs/heads/master'
>  from the remote, but no such ref was fetched.
>  
>  So you will need to do: 
>  
>  git checkout main
>  git branch --set-upstream-to=origin/main main 
Since the main branch will exist on the remote, you may be able to do:
git fetch
git checkout main

and I think the git branch --set-upstream-to is no longer needed then

>  then git pull. 
>  
>  I don't think there's anything we can do on the server side to make that
>  easier. Pingou any ideas? 
Not at the moment.


Pierre

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 11, 2020 at 08:15:19AM +0100, Pierre-Yves Chibon wrote:
>  On Thu, Dec 10, 2020 at 10:29:12AM -0800, Kevin Fenzi wrote:
>  > On Thu, Dec 10, 2020 at 10:36:36AM +0100, Robert-André Mauchin wrote:
>  > > On 12/3/20 4:02 PM, Ben Cotton wrote:
>  > > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  > > > 
>  > > > == Summary ==
>  > > > 
>  > > > This Change will move Fedora git repositories to use "main" as
> the
>  > > > default git branch instead of "master". Specific repositories
> will be
>  > > > manually moved and default git branch for new projects will be set to
>  > > > use "main".
>  > > > 
>  > > > The Fedora Community strives to be open and welcoming. Some language
>  > > > around our git repositories is dated and could be more inclusive. Many
>  > > > git repositories currently use "master" as the default branch.
> This
>  > > > Change will move many repositories (see below) to use a "main"
> branch
>  > > > as default. This small bit of naming adjustment is in-line with
>  > > > Fedora's vision for free and open source software built by inclusive,
>  > > > welcoming, and open-minded communities.
>  > > > 
>  > > > 
>  > > 
>  > > How does it work for the enduser? I have thousand of git repos locally with
>  > > the master branch, will it rename automatically master to main when I git
>  > > pull or do I need to run a special command?
>  > 
>  > You will need to reclone or run some commands in those existing
>  > checkouts. 
>  > 
>  > If you have a clone that has 'master' branch and we delete that, and you
>  > 'git pull' you will get: 
>  > 
>  > Fetching origin
>  > Your configuration specifies to merge with the ref 'refs/heads/master'
>  > from the remote, but no such ref was fetched.
>  > 
>  > So you will need to do: 
>  > 
>  > git checkout main
>  > git branch --set-upstream-to=origin/main main
>  
>  Since the main branch will exist on the remote, you may be able to do:
>  git fetch
>  git checkout main
>  
>  and I think the git branch --set-upstream-to is no longer needed then
>  
>  > then git pull. 
>  > 
>  > I don't think there's anything we can do on the server side to make that
>  > easier. Pingou any ideas?
>  
>  Not at the moment. 
A silent failure to update would be bad. But since there will be a clear
error message, I think that's good enough.

Please make that 'git fetch && git switch main' (or '... rawhide')
though.

Zbyszek

[Julen Landa Alustiza]

On src.fp.o, could we inject a custom message when someone trys to 
fetch/clone a master branch via pagure-dist-git ?

Something like "this branch is deprecated, more info on https://foo.bar"

20/12/11 08:15(e)an, Pierre-Yves Chibon igorleak idatzi zuen:
> On Thu, Dec 10, 2020 at 10:29:12AM -0800, Kevin Fenzi wrote:
>> On Thu, Dec 10, 2020 at 10:36:36AM +0100, Robert-André Mauchin wrote:
>>> On 12/3/20 4:02 PM, Ben Cotton wrote:
>>>> https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>>>>
>>>> == Summary ==
>>>>
>>>> This Change will move Fedora git repositories to use "main" as
the
>>>> default git branch instead of "master". Specific repositories
will be
>>>> manually moved and default git branch for new projects will be set to
>>>> use "main".
>>>>
>>>> The Fedora Community strives to be open and welcoming. Some language
>>>> around our git repositories is dated and could be more inclusive. Many
>>>> git repositories currently use "master" as the default branch.
This
>>>> Change will move many repositories (see below) to use a "main"
branch
>>>> as default. This small bit of naming adjustment is in-line with
>>>> Fedora's vision for free and open source software built by
inclusive,
>>>> welcoming, and open-minded communities.
>>>>
>>>>
>>>
>>> How does it work for the enduser? I have thousand of git repos locally with
>>> the master branch, will it rename automatically master to main when I git
>>> pull or do I need to run a special command?
>>
>> You will need to reclone or run some commands in those existing
>> checkouts.
>>
>> If you have a clone that has 'master' branch and we delete that, and you
>> 'git pull' you will get:
>>
>> Fetching origin
>> Your configuration specifies to merge with the ref 'refs/heads/master'
>> from the remote, but no such ref was fetched.
>>
>> So you will need to do:
>>
>> git checkout main
>> git branch --set-upstream-to=origin/main main
> 
> Since the main branch will exist on the remote, you may be able to do:
> git fetch
> git checkout main
> 
> and I think the git branch --set-upstream-to is no longer needed then
> 
>> then git pull.
>>
>> I don't think there's anything we can do on the server side to make that
>> easier. Pingou any ideas?
> 
> Not at the moment >
> 
> Pierre
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Sérgio Basto]

I'm strongly against change master to main , just because master
suggest that is a racist word as master/slave, is like change chess and
play not with black and white pieces but maybe with green and blue .
This change will deprecate all I.T. books since Turing machine and it
will be just a big a mess, first because we don't have a unanimous
name, so here it will be main, in other place will be devel etc etc it
will be a big confusion
And I don't see any benefit, words will always be words and their
meaning is given by the context.

On Thu, 2020-12-03 at 10:02 -0500, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  
>  == Summary ==
>  
>  This Change will move Fedora git repositories to use "main" as the
>  default git branch instead of "master". Specific repositories will be
>  manually moved and default git branch for new projects will be set to
>  use "main".
>  
>  The Fedora Community strives to be open and welcoming. Some language
>  around our git repositories is dated and could be more inclusive.
>  Many
>  git repositories currently use "master" as the default branch. This
>  Change will move many repositories (see below) to use a "main" branch
>  as default. This small bit of naming adjustment is in-line with
>  Fedora's vision for free and open source software built by inclusive,
>  welcoming, and open-minded communities.
>  
>  
>  == Owner ==
>  
>  * Name: [[User:Kevin| Kevin Fenzi]], [[User:bcotton| Ben Cotton]],
>  [[User:pingou| pingou]], [[User:mohanboddu| Mohan Boddu]],
>  [[User:till| Till Maas]]
>  * Email: kevin(a)scrye.com, bcotton(a)redhat.com, pingou(a)pingoured.fr,
>  mboddu(a)bhujji.com, opensource(a)till.name
>  
>  
>  == Detailed Description ==
>  
>  The Fedora Project controls a number of git repositories. This change
>  will move the default branch (that is, the git branch used when
>  nothing is specified) from 'master' to 'main'. Existing git clones
>  will need to pull to get the changed default branch. Existing Pull
>  Requests against the 'master' branch will need to be rebased against
>  the 'main' branch. Documentation will be updated.
>  
>  
>  
>  == Benefit to Fedora ==
>  
>  The Fedora Project will be a more welcoming place for new
>  contributors.
>  
>  
>  == Scope ==
>  
>  This change will take place in a number of phases:
>  
>  === Phase0 - 2020-12-14 ===
>  
>     A guide will be published to explain how maintainers/project
>  managers can change the default
>     branch on pagure.io, which they can then do based in their
>  projects desires.
>  
>  === Phase1 - 2020-12-15 ===
>  
>  The following repos will be switched:
>  
>    src.fedoraproject.org/flatpacks/*
>    pagure.io:
>      releng
>      releng/*
>      fedora-comps
>      fedora-kickstarts
>      fedora-infrastructure
>      fedora-lorax-templates
>      fedora-mediawikitheme
>      fedora-packager
>      fedora-infra/*
>      infra-docs
>      koji-fedmsg-plugin
>      workstation-ostree-config
>      pungi-fedora
>    github.com
>      fedora-infra/*
>  
>  === Phase2 - 2021-01-13 ===
>  
>     src.fedoraproject.org/*
>     pagure.io default for new projects will be changed to 'main'
>  
>  * Proposal owners:
>  
>     Switching all above listed projects git repos to use 'main'
>     Deleting the 'master' branch
>     Announcing when changes have been made on devel-announce / other
>  lists.
>  
>  * Other developers:
>  
>     Other developers are encouraged to change their upstream projects
>  on pagure.io, github or gitlab.
>  
>  * Release engineering:
>  
>     Releng will adjust any scripts that assume 'master' branch to use
>  'main' instead. The list includes and maybe few more
>     [https://pagure.io/releng/blob/master/f/scripts/update-critpath.py
>  update-critpath.py]
>     [https://pagure.io/releng/blob/master/f/scripts/block_retired.py
>  block_retired.py]
>     [https://pagure.io/releng/blob/master/f/scripts/update-docs.sh
>  update-docs.sh]
>     [
>  https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py
>  find_unblocked_orphans.py]
>     [
>  https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-second-run.py
>  mass-rebuild-second-run.py]
>     [
>  https://pagure.io/releng/blob/master/f/scripts/adjust-eol-modules.py
>  adjust-eol-modules.py]
>     [
>  https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py
>  adjust-eol-modules.py]
>     [
>  https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py
>  adjust-eol-modules.py]
>     [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol.py
>  adjust-eol.py]
>     [
>  https://pagure.io/releng/blob/master/f/scripts/pdc/create-new-release-bra...
>  create-new-release-branches.py]
>     [
>  https://pagure.io/releng/blob/master/f/scripts/pdc/create-branch.py
>  create-branch.py]
>     [
>  https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-all.py
>  adjust-eol-all.py]
>     [
>  https://pagure.io/releng/blob/master/f/scripts/check-unretirement.py
>  check-unretirement.py]
>     [
>  https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-special.py
>  mass-rebuild-special.py]
>     [https://pagure.io/releng/blob/master/f/scripts/need-rebuild.py
>  need-rebuild.py]
>     [
>  https://pagure.io/releng/blob/master/f/scripts/distgit-branch-unused.py
>  distgit-branch-unused.py]
>     [
>  https://pagure.io/releng/blob/master/f/scripts/create-new-release-branche...
>  create-new-release-branches.py]
>  
>  * Policies and guidelines: N/A
>  
>  * Trademark approval: N/A
>  
>  * Alignment with Objectives:
>  
>  
>  == Upgrade/compatibility impact ==
>  
>  Users with old checkouts will need to update their git configuration
>  or re-clone repositories that have changed before they can see any
>  new
>  changes.
>  
>  Repos used to build content for docs.fedoraproject.org can change the
>  default git branch, but the Antora module version (in `antora.yml`)
>  should remain `master` pending support for alternate "unversioned"
>  versions upstream.
>  
>  
>  == How To Test ==
>  
>  # git clone <one of the listed repositories>
>  # cd <repositoryname>
>  # git branch
>  
>  should return: `* main`
>  
>  
>  == User Experience ==
>  
>  Users and developers will see more welcoming language and that the
>  fedora project expended effort to be more welcoming to them.
>  
>  
>  == Dependencies ==
>  
>  none
>  
>  
>  == Contingency Plan ==
>  
>  * Contingency mechanism: Revert repositories, scripts, and docs back
>  to the unwelcoming 'master'
>  * Contingency date: 2020-01-13
>  
>  
>  == Documentation ==
>  
>  A short guide on how to change this for pagure.io will be produced.
>  
>  
>  == Release Notes ==
>  
>  Many git repositories used to create Fedora releases were moved to
>  use
>  a 'main' branch instead of a 'master' branch. The Fedora Project
>  envisions a world where everyone benefits from free and open source
>  software built by inclusive, welcoming, and open-minded communities.
>  
>  
>  -- 
>  Ben Cotton
>  He / Him / His
>  Senior Program Manager, Fedora & CentOS Stream
>  Red Hat
>  TZ=America/Indiana/Indianapolis
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: 
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: 
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedoraproject.org/archives/list/[e-mail] 
-- 
Sérgio M. B.

[stan]

On Sat, 12 Dec 2020 15:28:57 +0000
Sérgio Basto <sergio(a)serjux.com&gt; wrote:

>  I'm strongly against change master to main , just because master
>  suggest that is a racist word as master/slave, is like change chess
>  and play not with black and white pieces but maybe with green and
>  blue . This change will deprecate all I.T. books since Turing machine
>  and it will be just a big a mess, first because we don't have a
>  unanimous name, so here it will be main, in other place will be devel
>  etc etc it will be a big confusion
>  And I don't see any benefit, words will always be words and their
>  meaning is given by the context. 
I also think this is window dressing.  Every human being alive on the
planet today has a slave (of some description) among their ancestors,
or as a relative of their ancestors. I'm curious who came up with this
as a remedy for the effects of slavery on the descendants of slaves, and
how they decided that this was a meaningful gesture.  To me it looks
like virtue signaling designed to have a minimal impact on the bottom
line.

What does a poll of programmers who encounter the word master in code
indicate about their attitudes towards it?  Especially meaningful
would be to hear from the programmers this is meant to help.

There are millions of actual slaves on the planet as I type this, and
there are even countries where slavery is still legal, and there is at
least one religion with slavery sanctified in their scriptures.  Across
the globe sex slaves are trafficked from poorer countries to richer
countries.  Is this really the best use of resources to combat that?

If it is, then we can look forward to the demonizing of words like hit,
chain, bound, bind, submit, control in code across the globe.  It's a
good thing the people implementing this are masters of their craft, and
have lots of spare time.

[stan]

On Sat, 12 Dec 2020 09:09:46 -0700
stan <upaitag(a)zoho.com&gt; wrote:
>  Is this really the best use of resources to combat
>  that? 
What if all the money dedicated to implementing this across the tech
industry was dedicated instead to a stem scholarship fund.  Students
who qualify to a stem program at a certified university, and who are
disadvantaged, could apply for such scholarships.  Those scholarships
could be fewer full ride, or more partial ride.  The background hardship
of the student could be taken into account in addition to poverty.
Growing up a nerd in the inner city is a magnitude more difficult than
growing up a nerd in a suburban school.  In New York state, there are
charter schools for disadvantaged students that protect studious
students from disruptive students by expelling the disruptive students.
The public schools can't do that, so studious students there are in a
toxic environment, and their performance shows that.  The students of
those charter schools perform at levels equivalent to students in
suburban schools.

Just an alternative idea.

[Kevin Fenzi]

On Sat, Dec 12, 2020 at 12:01:32PM -0700, stan via devel wrote:
>  On Sat, 12 Dec 2020 09:09:46 -0700
>  stan <upaitag(a)zoho.com&gt; wrote:
>  > Is this really the best use of resources to combat
>  > that?
>   
...snip...
>  
>  Just an alternative idea. 
I think it's easy for people to misunderstand what we are trying to do
here. I would encourage you to watch Rich Bowens nest talk:
https://www.youtube.com/watch?v=o0shU2g4IoI

To answer some of the points: This isn't about what the dictionary
definitions of the words mean, or that you personally don't find them
unwelcoming. It's about doing the right thing and showing that our
community is welcoming and we are willing to do some work to make it so. 

If we had a pile of money could we find better ways to spend it? Sure!
But we don't. We have time and some adjustments to our workflows that we
can do right now to show we care and are not jerks. So, instead of doing
nothing, lets do this! 

kevin

[Christopher]

Even if people don't agree that "main" is better for other reasons, surely
people can agree that "rawhide" is much better than "master" for our
dist-git branch names for our RPMs, simply because it follows our naming
conventions and makes things easier from that perspective. The only reason
they were ever named "master" in the first place is because it was git's
default name. Nobody chose it to be "master" for Fedora... we just accepted
the tyranny of the default. We should have always had it named "rawhide".
I'm not in favor of changing it to "main", because if we're interested
in
changing it, we should take the opportunity to use a better name... one
that is meaningful to us... rather than just accept a new default naming
convention that doesn't mean anything to us. "rawhide" has a special
meaning in Fedora, but "main" doesn't. Let's use "rawhide".

On Sat, Dec 12, 2020 at 3:49 PM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:

>  On Sat, Dec 12, 2020 at 12:01:32PM -0700, stan via devel wrote:
>  > On Sat, 12 Dec 2020 09:09:46 -0700
>  > stan <upaitag(a)zoho.com&gt; wrote:
>  > > Is this really the best use of resources to combat
>  > > that?
>  >
>  ...snip...
>  >
>  > Just an alternative idea.
>
>  I think it's easy for people to misunderstand what we are trying to do
>  here. I would encourage you to watch Rich Bowens nest talk:
>  https://www.youtube.com/watch?v=o0shU2g4IoI
>
>  To answer some of the points: This isn't about what the dictionary
>  definitions of the words mean, or that you personally don't find them
>  unwelcoming. It's about doing the right thing and showing that our
>  community is welcoming and we are willing to do some work to make it so.
>
>  If we had a pile of money could we find better ways to spend it? Sure!
>  But we don't. We have time and some adjustments to our workflows that we
>  can do right now to show we care and are not jerks. So, instead of doing
>  nothing, lets do this!
>
>  kevin
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Neal Gompa]

On Mon, Dec 14, 2020 at 10:30 AM Christopher <ctubbsii(a)fedoraproject.org&gt; wrote:
>  Even if people don't agree that "main" is better for other reasons, surely
> people can agree that "rawhide" is much better than "master" for our
> dist-git branch names for our RPMs, simply because it follows our naming conventions and
> makes things easier from that perspective. The only reason they were ever named
> "master" in the first place is because it was git's default name. Nobody
> chose it to be "master" for Fedora... we just accepted the tyranny of the
> default. We should have always had it named "rawhide". I'm not in favor of
> changing it to "main", because if we're interested in changing it, we should
> take the opportunity to use a better name... one that is meaningful to us... rather than
> just accept a new default naming convention that doesn't mean anything to us.
> "rawhide" has a special meaning in Fedora, but "main" doesn't.
> Let's use "rawhide".
>  
+1



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Mark E. Fuller]

Am Montag, dem 14.12.2020 um 11:12 -0500 schrieb Neal Gompa:
>  On Mon, Dec 14, 2020 at 10:30 AM Christopher <
>  ctubbsii(a)fedoraproject.org&gt; wrote:
>  >
>  > Even if people don't agree that "main" is better for other reasons,
>  > surely people can agree that "rawhide" is much better than
> "master"
>  > for our dist-git branch names for our RPMs, simply because it
>  > follows our naming conventions and makes things easier from that
>  > perspective. The only reason they were ever named "master" in the
>  > first place is because it was git's default name. Nobody chose it
>  > to be "master" for Fedora... we just accepted the tyranny of the
>  > default. We should have always had it named "rawhide". I'm not in
>  > favor of changing it to "main", because if we're interested in
>  > changing it, we should take the opportunity to use a better name...
>  > one that is meaningful to us... rather than just accept a new
>  > default naming convention that doesn't mean anything to us.
>  > "rawhide" has a special meaning in Fedora, but "main"
> doesn't.
>  > Let's use "rawhide".
>  >
>
>  +1
>  
I also strongly favor this solution and logic
>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines:
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail] 
--
Mark E. Fuller, Ph.D.
Robensstraße 57
52070 Aachen
[phone]
[phone]
mark.e.fuller(a)gmail.com
mark.e.fuller(a)gmx.de
@mefuller:matrix.org
https://mefuller.github.io/

[Robert-André Mauchin]

On 12/14/20 4:29 PM, Christopher wrote:
>  Even if people don't agree that "main" is better for
> other reasons, 
>  surely people can agree that "rawhide" is much better than "master"
> for 
>  our dist-git branch names for our RPMs, simply because it follows our 
>  naming conventions and makes things easier from that perspective. The 
>  only reason they were ever named "master" in the first place is because 
>  it was git's default name. Nobody chose it to be "master" for Fedora... 
>  we just accepted the tyranny of the default. We should have always had 
>  it named "rawhide". I'm not in favor of changing it to "main",
> because 
>  if we're interested in changing it, we should take the opportunity to 
>  use a better name... one that is meaningful to us... rather than just 
>  accept a new default naming convention that doesn't mean anything to us. 
>  "rawhide" has a special meaning in Fedora, but "main" doesn't.
> Let's use 
>  "rawhide".
>  
>  On Sat, Dec 12, 2020 at 3:49 PM Kevin Fenzi <kevin(a)scrye.com 
>  <mailto:[e-mail]>> wrote:
>  
>      On Sat, Dec 12, 2020 at 12:01:32PM -0700, stan via devel wrote:
>       > On Sat, 12 Dec 2020 09:09:46 -0700
>       > stan <upaitag(a)zoho.com <mailto:[e-mail]>> wrote:
>       > > Is this really the best use of resources to combat
>       > > that?
>       >
>      ...snip...
>       >
>       > Just an alternative idea.
>  
>      I think it's easy for people to misunderstand what we are trying to do
>      here. I would encourage you to watch Rich Bowens nest talk:
>      https://www.youtube.com/watch?v=o0shU2g4IoI
>      <https://www.youtube.com/watch?v=o0shU2g4IoI>
>  
>      To answer some of the points: This isn't about what the dictionary
>      definitions of the words mean, or that you personally don't find them
>      unwelcoming. It's about doing the right thing and showing that our
>      community is welcoming and we are willing to do some work to make it
>      so.
>  
>      If we had a pile of money could we find better ways to spend it? Sure!
>      But we don't. We have time and some adjustments to our workflows that we
>      can do right now to show we care and are not jerks. So, instead of doing
>      nothing, lets do this!
>  
>      kevin
>      _______________________________________________
>  
I am lazy, main is easier to type than rawhide

[Gary Buhrmaster]

On Mon, Dec 14, 2020 at 3:30 PM Christopher <ctubbsii(a)fedoraproject.org&gt; wrote:
>  Even if people don't agree that "main" is better for other reasons, surely
> people can agree that "rawhide" is much better than "master" 
I disagree, my opinion is that main is better than
master, and master is better than rawhide.

One should not try to put words in others mouths
(that is not being respectful of others opinions),
but only offer their own opinion as an opinion.

[Christopher]

On Mon, Dec 14, 2020 at 2:22 PM Gary Buhrmaster <gary.buhrmaster(a)gmail.com&gt;
wrote:

>  On Mon, Dec 14, 2020 at 3:30 PM Christopher
> <ctubbsii(a)fedoraproject.org&gt;
>  wrote:
>  >
>  > Even if people don't agree that "main" is better for other reasons,
>  surely people can agree that "rawhide" is much better than "master"
>
>  I disagree, my opinion is that main is better than
>  master, and master is better than rawhide.
>
>  One should not try to put words in others mouths
>  (that is not being respectful of others opinions),
>  but only offer their own opinion as an opinion.
>  
I've never heard the phrase "surely X" used as anything other than as a
mechanism to propose a hypothesis based on the speaker's current beliefs
and presented for others to challenge (which you have done, and I stand
corrected). I've definitely never heard it used as disrespect or as
speaking for others. So, I'm surprised you seem to have taken offense at
that. But, I'm sorry for my intentions not being more clear, and thank you
for your response that demonstrated my hypothesis to be false.

I'm surprised by your opinion, and wonder how prevalent it is, but I
appreciate the correction nevertheless. I now know that we cannot all agree
that "rawhide" is better. *shrugs*

[Nico Kadel-Garcia]

On Mon, Dec 14, 2020 at 2:21 PM Gary Buhrmaster
<gary.buhrmaster(a)gmail.com&gt; wrote:
>  On Mon, Dec 14, 2020 at 3:30 PM Christopher <ctubbsii(a)fedoraproject.org&gt; wrote:
>  >
>  > Even if people don't agree that "main" is better for other reasons,
> surely people can agree that "rawhide" is much better than "master"
>
>  I disagree, my opinion is that main is better than
>  master, and master is better than rawhide. 
A label that exists only in theory, with no history and no convention
associated with a project, is  like demanding a new pronoun. It
generally only pleases a few people and generally causes far more
confusion than clarity..

[Tomas Tomecek]

What's the progress on this change? Is it going to land in one week? I
just want to be sure that our tooling is ready and works with this
change since we hardcode "fedora-master" in many places.


Thanks!

Tomas

On Thu, Dec 3, 2020 at 4:06 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>
>  == Summary ==
>
>  This Change will move Fedora git repositories to use "main" as the
>  default git branch instead of "master". Specific repositories will be
>  manually moved and default git branch for new projects will be set to
>  use "main".
>
>  The Fedora Community strives to be open and welcoming. Some language
>  around our git repositories is dated and could be more inclusive. Many
>  git repositories currently use "master" as the default branch. This
>  Change will move many repositories (see below) to use a "main" branch
>  as default. This small bit of naming adjustment is in-line with
>  Fedora's vision for free and open source software built by inclusive,
>  welcoming, and open-minded communities.
>
>
>  == Owner ==
>
>  * Name: [[User:Kevin| Kevin Fenzi]], [[User:bcotton| Ben Cotton]],
>  [[User:pingou| pingou]], [[User:mohanboddu| Mohan Boddu]],
>  [[User:till| Till Maas]]
>  * Email: kevin(a)scrye.com, bcotton(a)redhat.com, pingou(a)pingoured.fr,
>  mboddu(a)bhujji.com, opensource(a)till.name
>
>
>  == Detailed Description ==
>
>  The Fedora Project controls a number of git repositories. This change
>  will move the default branch (that is, the git branch used when
>  nothing is specified) from 'master' to 'main'. Existing git clones
>  will need to pull to get the changed default branch. Existing Pull
>  Requests against the 'master' branch will need to be rebased against
>  the 'main' branch. Documentation will be updated.
>
>
>
>  == Benefit to Fedora ==
>
>  The Fedora Project will be a more welcoming place for new contributors.
>
>
>  == Scope ==
>
>  This change will take place in a number of phases:
>
>  === Phase0 - 2020-12-14 ===
>
>     A guide will be published to explain how maintainers/project
>  managers can change the default
>     branch on pagure.io, which they can then do based in their projects desires.
>
>  === Phase1 - 2020-12-15 ===
>
>  The following repos will be switched:
>
>    src.fedoraproject.org/flatpacks/*
>    pagure.io:
>      releng
>      releng/*
>      fedora-comps
>      fedora-kickstarts
>      fedora-infrastructure
>      fedora-lorax-templates
>      fedora-mediawikitheme
>      fedora-packager
>      fedora-infra/*
>      infra-docs
>      koji-fedmsg-plugin
>      workstation-ostree-config
>      pungi-fedora
>    github.com
>      fedora-infra/*
>
>  === Phase2 - 2021-01-13 ===
>
>     src.fedoraproject.org/*
>     pagure.io default for new projects will be changed to 'main'
>
>  * Proposal owners:
>
>     Switching all above listed projects git repos to use 'main'
>     Deleting the 'master' branch
>     Announcing when changes have been made on devel-announce / other lists.
>
>  * Other developers:
>
>     Other developers are encouraged to change their upstream projects
>  on pagure.io, github or gitlab.
>
>  * Release engineering:
>
>     Releng will adjust any scripts that assume 'master' branch to use
>  'main' instead. The list includes and maybe few more
>     [https://pagure.io/releng/blob/master/f/scripts/update-critpath.py
>  update-critpath.py]
>     [https://pagure.io/releng/blob/master/f/scripts/block_retired.py
>  block_retired.py]
>     [https://pagure.io/releng/blob/master/f/scripts/update-docs.sh
>  update-docs.sh]
>     [https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py
>  find_unblocked_orphans.py]
>     [https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-second-run.py
>  mass-rebuild-second-run.py]
>     [https://pagure.io/releng/blob/master/f/scripts/adjust-eol-modules.py
>  adjust-eol-modules.py]
>     [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py
>  adjust-eol-modules.py]
>     [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py
>  adjust-eol-modules.py]
>     [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol.py
>  adjust-eol.py]
>     [https://pagure.io/releng/blob/master/f/scripts/pdc/create-new-release-bra...
>  create-new-release-branches.py]
>     [https://pagure.io/releng/blob/master/f/scripts/pdc/create-branch.py
>  create-branch.py]
>     [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-all.py
>  adjust-eol-all.py]
>     [https://pagure.io/releng/blob/master/f/scripts/check-unretirement.py
>  check-unretirement.py]
>     [https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-special.py
>  mass-rebuild-special.py]
>     [https://pagure.io/releng/blob/master/f/scripts/need-rebuild.py
>  need-rebuild.py]
>     [https://pagure.io/releng/blob/master/f/scripts/distgit-branch-unused.py
>  distgit-branch-unused.py]
>     [https://pagure.io/releng/blob/master/f/scripts/create-new-release-branche...
>  create-new-release-branches.py]
>
>  * Policies and guidelines: N/A
>
>  * Trademark approval: N/A
>
>  * Alignment with Objectives:
>
>
>  == Upgrade/compatibility impact ==
>
>  Users with old checkouts will need to update their git configuration
>  or re-clone repositories that have changed before they can see any new
>  changes.
>
>  Repos used to build content for docs.fedoraproject.org can change the
>  default git branch, but the Antora module version (in `antora.yml`)
>  should remain `master` pending support for alternate "unversioned"
>  versions upstream.
>
>
>  == How To Test ==
>
>  # git clone <one of the listed repositories>
>  # cd <repositoryname>
>  # git branch
>
>  should return: `* main`
>
>
>  == User Experience ==
>
>  Users and developers will see more welcoming language and that the
>  fedora project expended effort to be more welcoming to them.
>
>
>  == Dependencies ==
>
>  none
>
>
>  == Contingency Plan ==
>
>  * Contingency mechanism: Revert repositories, scripts, and docs back
>  to the unwelcoming 'master'
>  * Contingency date: 2020-01-13
>
>
>  == Documentation ==
>
>  A short guide on how to change this for pagure.io will be produced.
>
>
>  == Release Notes ==
>
>  Many git repositories used to create Fedora releases were moved to use
>  a 'main' branch instead of a 'master' branch. The Fedora Project
>  envisions a world where everyone benefits from free and open source
>  software built by inclusive, welcoming, and open-minded communities.
>
>
>  --
>  Ben Cotton
>  He / Him / His
>  Senior Program Manager, Fedora & CentOS Stream
>  Red Hat
>  TZ=America/Indiana/Indianapolis
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Kevin Fenzi]

On Tue, Jan 05, 2021 at 12:26:45PM +0100, Tomas Tomecek wrote:
>  What's the progress on this change? Is it going to land in one
> week? I 
For src.fedoraproject.org yes. It's planned for next week.
(some pagure.io projects we control should go tomorrow (Phase1))

>  just want to be sure that our tooling is ready and works with this
>  change since we hardcode "fedora-master" in many places. 
We are meeting up later today to do some planning, I hope we can get
staging moved over sooner and then you could test against that? 

kevin
--
>  Thanks!
>  
>  Tomas
>  
>  On Thu, Dec 3, 2020 at 4:06 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  >
>  > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  >
>  > == Summary ==
>  >
>  > This Change will move Fedora git repositories to use "main" as the
>  > default git branch instead of "master". Specific repositories will be
>  > manually moved and default git branch for new projects will be set to
>  > use "main".
>  >
>  > The Fedora Community strives to be open and welcoming. Some language
>  > around our git repositories is dated and could be more inclusive. Many
>  > git repositories currently use "master" as the default branch. This
>  > Change will move many repositories (see below) to use a "main" branch
>  > as default. This small bit of naming adjustment is in-line with
>  > Fedora's vision for free and open source software built by inclusive,
>  > welcoming, and open-minded communities.
>  >
>  >
>  > == Owner ==
>  >
>  > * Name: [[User:Kevin| Kevin Fenzi]], [[User:bcotton| Ben Cotton]],
>  > [[User:pingou| pingou]], [[User:mohanboddu| Mohan Boddu]],
>  > [[User:till| Till Maas]]
>  > * Email: kevin(a)scrye.com, bcotton(a)redhat.com, pingou(a)pingoured.fr,
>  > mboddu(a)bhujji.com, opensource(a)till.name
>  >
>  >
>  > == Detailed Description ==
>  >
>  > The Fedora Project controls a number of git repositories. This change
>  > will move the default branch (that is, the git branch used when
>  > nothing is specified) from 'master' to 'main'. Existing git clones
>  > will need to pull to get the changed default branch. Existing Pull
>  > Requests against the 'master' branch will need to be rebased against
>  > the 'main' branch. Documentation will be updated.
>  >
>  >
>  >
>  > == Benefit to Fedora ==
>  >
>  > The Fedora Project will be a more welcoming place for new contributors.
>  >
>  >
>  > == Scope ==
>  >
>  > This change will take place in a number of phases:
>  >
>  > === Phase0 - 2020-12-14 ===
>  >
>  >    A guide will be published to explain how maintainers/project
>  > managers can change the default
>  >    branch on pagure.io, which they can then do based in their projects desires.
>  >
>  > === Phase1 - 2020-12-15 ===
>  >
>  > The following repos will be switched:
>  >
>  >   src.fedoraproject.org/flatpacks/*
>  >   pagure.io:
>  >     releng
>  >     releng/*
>  >     fedora-comps
>  >     fedora-kickstarts
>  >     fedora-infrastructure
>  >     fedora-lorax-templates
>  >     fedora-mediawikitheme
>  >     fedora-packager
>  >     fedora-infra/*
>  >     infra-docs
>  >     koji-fedmsg-plugin
>  >     workstation-ostree-config
>  >     pungi-fedora
>  >   github.com
>  >     fedora-infra/*
>  >
>  > === Phase2 - 2021-01-13 ===
>  >
>  >    src.fedoraproject.org/*
>  >    pagure.io default for new projects will be changed to 'main'
>  >
>  > * Proposal owners:
>  >
>  >    Switching all above listed projects git repos to use 'main'
>  >    Deleting the 'master' branch
>  >    Announcing when changes have been made on devel-announce / other lists.
>  >
>  > * Other developers:
>  >
>  >    Other developers are encouraged to change their upstream projects
>  > on pagure.io, github or gitlab.
>  >
>  > * Release engineering:
>  >
>  >    Releng will adjust any scripts that assume 'master' branch to use
>  > 'main' instead. The list includes and maybe few more
>  >    [https://pagure.io/releng/blob/master/f/scripts/update-critpath.py
>  > update-critpath.py]
>  >    [https://pagure.io/releng/blob/master/f/scripts/block_retired.py
>  > block_retired.py]
>  >    [https://pagure.io/releng/blob/master/f/scripts/update-docs.sh
>  > update-docs.sh]
>  >    [https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py
>  > find_unblocked_orphans.py]
>  >    [https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-second-run.py
>  > mass-rebuild-second-run.py]
>  >    [https://pagure.io/releng/blob/master/f/scripts/adjust-eol-modules.py
>  > adjust-eol-modules.py]
>  >    [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py
>  > adjust-eol-modules.py]
>  >    [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py
>  > adjust-eol-modules.py]
>  >    [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol.py
>  > adjust-eol.py]
>  >   
> [https://pagure.io/releng/blob/master/f/scripts/pdc/create-new-release-bra...
>  > create-new-release-branches.py]
>  >    [https://pagure.io/releng/blob/master/f/scripts/pdc/create-branch.py
>  > create-branch.py]
>  >    [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-all.py
>  > adjust-eol-all.py]
>  >    [https://pagure.io/releng/blob/master/f/scripts/check-unretirement.py
>  > check-unretirement.py]
>  >    [https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-special.py
>  > mass-rebuild-special.py]
>  >    [https://pagure.io/releng/blob/master/f/scripts/need-rebuild.py
>  > need-rebuild.py]
>  >    [https://pagure.io/releng/blob/master/f/scripts/distgit-branch-unused.py
>  > distgit-branch-unused.py]
>  >    [https://pagure.io/releng/blob/master/f/scripts/create-new-release-branche...
>  > create-new-release-branches.py]
>  >
>  > * Policies and guidelines: N/A
>  >
>  > * Trademark approval: N/A
>  >
>  > * Alignment with Objectives:
>  >
>  >
>  > == Upgrade/compatibility impact ==
>  >
>  > Users with old checkouts will need to update their git configuration
>  > or re-clone repositories that have changed before they can see any new
>  > changes.
>  >
>  > Repos used to build content for docs.fedoraproject.org can change the
>  > default git branch, but the Antora module version (in `antora.yml`)
>  > should remain `master` pending support for alternate "unversioned"
>  > versions upstream.
>  >
>  >
>  > == How To Test ==
>  >
>  > # git clone <one of the listed repositories>
>  > # cd <repositoryname>
>  > # git branch
>  >
>  > should return: `* main`
>  >
>  >
>  > == User Experience ==
>  >
>  > Users and developers will see more welcoming language and that the
>  > fedora project expended effort to be more welcoming to them.
>  >
>  >
>  > == Dependencies ==
>  >
>  > none
>  >
>  >
>  > == Contingency Plan ==
>  >
>  > * Contingency mechanism: Revert repositories, scripts, and docs back
>  > to the unwelcoming 'master'
>  > * Contingency date: 2020-01-13
>  >
>  >
>  > == Documentation ==
>  >
>  > A short guide on how to change this for pagure.io will be produced.
>  >
>  >
>  > == Release Notes ==
>  >
>  > Many git repositories used to create Fedora releases were moved to use
>  > a 'main' branch instead of a 'master' branch. The Fedora Project
>  > envisions a world where everyone benefits from free and open source
>  > software built by inclusive, welcoming, and open-minded communities.
>  >
>  >
>  > --
>  > Ben Cotton
>  > He / Him / His
>  > Senior Program Manager, Fedora & CentOS Stream
>  > Red Hat
>  > TZ=America/Indiana/Indianapolis
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Sérgio Basto]

On Tue, 2021-01-05 at 10:09 -0800, Kevin Fenzi wrote:
>  On Tue, Jan 05, 2021 at 12:26:45PM +0100, Tomas Tomecek wrote:
>  > What's the progress on this change? Is it going to land in one
>  > week? I
>  
>  For src.fedoraproject.org yes. It's planned for next week.
>  (some pagure.io projects we control should go tomorrow (Phase1)) 

>  > just want to be sure that our tooling is ready and works with
> this
>  > change since we hardcode "fedora-master" in many places. 
for example fedpkg 
if release == 'master':
   return 'rawhide'

https://pagure.io/fedpkg/blob/master/f/fedpkg/__init__.py#_172
https://pagure.io/fedpkg/blob/master/f/fedpkg/__init__.py#_206
https://pagure.io/fedpkg/blob/master/f/fedpkg/__init__.py#_213


>  We are meeting up later today to do some planning, I hope we can get
>  staging moved over sooner and then you could test against that?  

>  kevin
>  --
>  > Thanks!
>  > 
>  > Tomas
>  > 
>  > On Thu, Dec 3, 2020 at 4:06 PM Ben Cotton <bcotton(a)redhat.com&gt;
>  > wrote:
>  > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  > > 
>  > > == Summary ==
>  > > 
>  > > This Change will move Fedora git repositories to use "main" as
>  > > the
>  > > default git branch instead of "master". Specific repositories
>  > > will be
>  > > manually moved and default git branch for new projects will be
>  > > set to
>  > > use "main".
>  > > 
>  > > The Fedora Community strives to be open and welcoming. Some
>  > > language
>  > > around our git repositories is dated and could be more inclusive.
>  > > Many
>  > > git repositories currently use "master" as the default branch.
>  > > This
>  > > Change will move many repositories (see below) to use a "main"
>  > > branch
>  > > as default. This small bit of naming adjustment is in-line with
>  > > Fedora's vision for free and open source software built by
>  > > inclusive,
>  > > welcoming, and open-minded communities.
>  > > 
>  > > 
>  > > == Owner ==
>  > > 
>  > > * Name: [[User:Kevin| Kevin Fenzi]], [[User:bcotton| Ben
>  > > Cotton]],
>  > > [[User:pingou| pingou]], [[User:mohanboddu| Mohan Boddu]],
>  > > [[User:till| Till Maas]]
>  > > * Email: kevin(a)scrye.com, bcotton(a)redhat.com, pingou(a)pingoured.fr
>  > > ,
>  > > mboddu(a)bhujji.com, opensource(a)till.name
>  > > 
>  > > 
>  > > == Detailed Description ==
>  > > 
>  > > The Fedora Project controls a number of git repositories. This
>  > > change
>  > > will move the default branch (that is, the git branch used when
>  > > nothing is specified) from 'master' to 'main'. Existing git
>  > > clones
>  > > will need to pull to get the changed default branch. Existing
>  > > Pull
>  > > Requests against the 'master' branch will need to be rebased
>  > > against
>  > > the 'main' branch. Documentation will be updated.
>  > > 
>  > > 
>  > > 
>  > > == Benefit to Fedora ==
>  > > 
>  > > The Fedora Project will be a more welcoming place for new
>  > > contributors.
>  > > 
>  > > 
>  > > == Scope ==
>  > > 
>  > > This change will take place in a number of phases:
>  > > 
>  > > === Phase0 - 2020-12-14 ===
>  > > 
>  > >    A guide will be published to explain how maintainers/project
>  > > managers can change the default
>  > >    branch on pagure.io, which they can then do based in their
>  > > projects desires.
>  > > 
>  > > === Phase1 - 2020-12-15 ===
>  > > 
>  > > The following repos will be switched:
>  > > 
>  > >   src.fedoraproject.org/flatpacks/*
>  > >   pagure.io:
>  > >     releng
>  > >     releng/*
>  > >     fedora-comps
>  > >     fedora-kickstarts
>  > >     fedora-infrastructure
>  > >     fedora-lorax-templates
>  > >     fedora-mediawikitheme
>  > >     fedora-packager
>  > >     fedora-infra/*
>  > >     infra-docs
>  > >     koji-fedmsg-plugin
>  > >     workstation-ostree-config
>  > >     pungi-fedora
>  > >   github.com
>  > >     fedora-infra/*
>  > > 
>  > > === Phase2 - 2021-01-13 ===
>  > > 
>  > >    src.fedoraproject.org/*
>  > >    pagure.io default for new projects will be changed to 'main'
>  > > 
>  > > * Proposal owners:
>  > > 
>  > >    Switching all above listed projects git repos to use 'main'
>  > >    Deleting the 'master' branch
>  > >    Announcing when changes have been made on devel-announce /
>  > > other lists.
>  > > 
>  > > * Other developers:
>  > > 
>  > >    Other developers are encouraged to change their upstream
>  > > projects
>  > > on pagure.io, github or gitlab.
>  > > 
>  > > * Release engineering:
>  > > 
>  > >    Releng will adjust any scripts that assume 'master' branch to
>  > > use
>  > > 'main' instead. The list includes and maybe few more
>  > >    [
>  > > https://pagure.io/releng/blob/master/f/scripts/update-critpath.py
>  > > update-critpath.py]
>  > >    [
>  > > https://pagure.io/releng/blob/master/f/scripts/block_retired.py
>  > > block_retired.py]
>  > >    [https://pagure.io/releng/blob/master/f/scripts/update-docs.sh
>  > > update-docs.sh]
>  > >    [
>  > > https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py
>  > > find_unblocked_orphans.py]
>  > >    [
>  > > https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-second-run.py
>  > > mass-rebuild-second-run.py]
>  > >    [
>  > > https://pagure.io/releng/blob/master/f/scripts/adjust-eol-modules.py
>  > > adjust-eol-modules.py]
>  > >    [
>  > > https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py
>  > > adjust-eol-modules.py]
>  > >    [
>  > > https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py
>  > > adjust-eol-modules.py]
>  > >    [
>  > > https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol.py
>  > > adjust-eol.py]
>  > >    [
>  > >
> https://pagure.io/releng/blob/master/f/scripts/pdc/create-new-release-bra...
>  > > create-new-release-branches.py]
>  > >    [
>  > > https://pagure.io/releng/blob/master/f/scripts/pdc/create-branch.py
>  > > create-branch.py]
>  > >    [
>  > > https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-all.py
>  > > adjust-eol-all.py]
>  > >    [
>  > > https://pagure.io/releng/blob/master/f/scripts/check-unretirement.py
>  > > check-unretirement.py]
>  > >    [
>  > > https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-special.py
>  > > mass-rebuild-special.py]
>  > >    [
>  > > https://pagure.io/releng/blob/master/f/scripts/need-rebuild.py
>  > > need-rebuild.py]
>  > >    [
>  > > https://pagure.io/releng/blob/master/f/scripts/distgit-branch-unused.py
>  > > distgit-branch-unused.py]
>  > >    [
>  > > https://pagure.io/releng/blob/master/f/scripts/create-new-release-branche...
>  > > create-new-release-branches.py]
>  > > 
>  > > * Policies and guidelines: N/A
>  > > 
>  > > * Trademark approval: N/A
>  > > 
>  > > * Alignment with Objectives:
>  > > 
>  > > 
>  > > == Upgrade/compatibility impact ==
>  > > 
>  > > Users with old checkouts will need to update their git
>  > > configuration
>  > > or re-clone repositories that have changed before they can see
>  > > any new
>  > > changes.
>  > > 
>  > > Repos used to build content for docs.fedoraproject.org can change
>  > > the
>  > > default git branch, but the Antora module version (in
>  > > `antora.yml`)
>  > > should remain `master` pending support for alternate
>  > > "unversioned"
>  > > versions upstream.
>  > > 
>  > > 
>  > > == How To Test ==
>  > > 
>  > > # git clone <one of the listed repositories>
>  > > # cd <repositoryname>
>  > > # git branch
>  > > 
>  > > should return: `* main`
>  > > 
>  > > 
>  > > == User Experience ==
>  > > 
>  > > Users and developers will see more welcoming language and that
>  > > the
>  > > fedora project expended effort to be more welcoming to them.
>  > > 
>  > > 
>  > > == Dependencies ==
>  > > 
>  > > none
>  > > 
>  > > 
>  > > == Contingency Plan ==
>  > > 
>  > > * Contingency mechanism: Revert repositories, scripts, and docs
>  > > back
>  > > to the unwelcoming 'master'
>  > > * Contingency date: 2020-01-13
>  > > 
>  > > 
>  > > == Documentation ==
>  > > 
>  > > A short guide on how to change this for pagure.io will be
>  > > produced.
>  > > 
>  > > 
>  > > == Release Notes ==
>  > > 
>  > > Many git repositories used to create Fedora releases were moved
>  > > to use
>  > > a 'main' branch instead of a 'master' branch. The Fedora
> Project
>  > > envisions a world where everyone benefits from free and open
>  > > source
>  > > software built by inclusive, welcoming, and open-minded
>  > > communities.
>  > > 
>  > > 
>  > > --
>  > > Ben Cotton
>  > > He / Him / His
>  > > Senior Program Manager, Fedora & CentOS Stream
>  > > Red Hat
>  > > TZ=America/Indiana/Indianapolis
>  > > _______________________________________________
>  > > devel mailing list -- devel(a)lists.fedoraproject.org
>  > > To unsubscribe send an email to 
>  > > devel-leave(a)lists.fedoraproject.org
>  > > Fedora Code of Conduct: 
>  > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  > > List Guidelines: 
>  > > https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > > List Archives: 
>  > > https://lists.fedoraproject.org/archives/list/[e-mail]
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  > Fedora Code of Conduct: 
>  > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  > List Guidelines: 
>  > https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > List Archives: 
>  > https://lists.fedoraproject.org/archives/list/[e-mail]
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: 
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: 
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedoraproject.org/archives/list/[e-mail] 
-- 
Sérgio M. B.

[Renich Bon Ciric]

I haven't read the whole thread but I cannot believe everybody just
went with it.

What is the practical purpose of changing master to main? I see no
benefit whatsoever. We're only making this politicized.

I haven't checked the tickets but I'd bet my left arm on us not having
a single ticket from an individual telling us they were discouraged to
participate in any of our projects due to our use of "master" in git.
This, for me, is beyond ridiculous but, even more incredible that
nobody dared to lift their arm against it.

This isn't helping anyone. It's just succumbing to political pressure.
And here I was thinking that people here wouldn't have it.

I, for one, totally disagree with this change. Especially for the
reasons it's being done.

[Kevin Fenzi]

On Tue, Mar 02, 2021 at 11:36:45AM -0600, Renich Bon Ciric wrote:
>  I haven't read the whole thread but I cannot believe everybody
> just
>  went with it.
>  
>  What is the practical purpose of changing master to main? I see no
>  benefit whatsoever. We're only making this politicized.
>  
>  I haven't checked the tickets but I'd bet my left arm on us not having
>  a single ticket from an individual telling us they were discouraged to
>  participate in any of our projects due to our use of "master" in git.
>  This, for me, is beyond ridiculous but, even more incredible that
>  nobody dared to lift their arm against it.
>  
>  This isn't helping anyone. It's just succumbing to political pressure.
>  And here I was thinking that people here wouldn't have it.
>  
>  I, for one, totally disagree with this change. Especially for the
>  reasons it's being done. 
So, I think it's pretty moot at this point, since the change was already
discussed, approved and implemented and the chances of us reverting it
are very small. 

That said, I think you deserve at least a reply here. 

The purpose here is to make the Fedora project a more welcoming place to
people who _do_ find those terms unwelcome. That doesn't mean everyone
does. It means we want to be welcoming and not jerks. 

I'm personally happy to do things to make people more welcome. 
Even if they are small things and cause a small amount of work for us
existing contributors.

If you have a few minutes, take a look at:
https://www.youtube.com/watch?v=o0shU2g4IoI
(Rich Bowens talk at nest with fedora on this topic). 

kevin

[Tim Landscheidt]

Kevin Fenzi <kevin(a)scrye.com&gt; wrote:

>  […] 
>  The purpose here is to make the Fedora project a more welcoming place
> to
>  people who _do_ find those terms unwelcome. That doesn't mean everyone
>  does. It means we want to be welcoming and not jerks. 
                             
               ^^^^^^^^^
>  I'm personally happy to do things to make people more welcome.
>  Even if they are small things and cause a small amount of work for us
>  existing contributors. 
>  […] 
"Disagreement is no excuse for poor behavior and poor man-
ners."

Tim

[David Kaufmann]

On Wed, Mar 03, 2021 at 06:00:55PM +0000, Tim Landscheidt wrote:
>  Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  
>  > […]
>  
>  > The purpose here is to make the Fedora project a more welcoming place to
>  > people who _do_ find those terms unwelcome. That doesn't mean everyone
>  > does. It means we want to be welcoming and not jerks.
>                                               ^^^^^^^^^
>  > I'm personally happy to do things to make people more welcome.
>  > Even if they are small things and cause a small amount of work for us
>  > existing contributors.
>  
>  > […]
>  
>  "Disagreement is no excuse for poor behavior and poor man-
>  ners." 
I also disagree with the reasons which are usually given for the change
and don't think it is *any* improvement on being more welcoming.

To achieve that the focus would have to be more on the inviting and
mentoring part.

There seems to be a group of people which are very vocal with regard to
this topic and also seem to believe those reasons are valid and
important, so if this fixes their issue I'm fine with that.

I don't do it on the git-servers I host, but for Fedora this was
decided, implemented, didn't break too much and probably won't be
reverted.
It doesn't make packaging not much more difficult, so I don't see any
major disadvantages to having it this way.

All the best,
Astra

[Eugene Syromiatnikov]

On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  
>  == Summary ==
>  
>  This Change will move Fedora git repositories to use "main" as the
>  default git branch instead of "master". Specific repositories will be
>  manually moved and default git branch for new projects will be set to
>  use "main". 
The way this change has been performad made at least rpms/microcode_ctl
repository unusable[1][2] by koji.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=62174686
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=62174675

[Miro Hrončok]

On 17. 02. 21 19:46, Eugene Syromiatnikov wrote:
>  On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> >
> > == Summary ==
> >
> > This Change will move Fedora git repositories to use "main" as the
> > default git branch instead of "master". Specific repositories will be
> > manually moved and default git branch for new projects will be set to
> > use "main".
>  
>  The way this change has been performad made at least rpms/microcode_ctl
>  repository unusable[1][2] by koji.
>  
>  [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=62174686
>  [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=62174675 
The same happens locally:

$ fedpkg clone microcode_ctl
Cloning into 'microcode_ctl'...
remote: Enumerating objects: 994, done.
remote: Counting objects: 100% (994/994), done.
remote: Compressing objects: 100% (773/773), done.
remote: Total 994 (delta 477), reused 411 (delta 208), pack-reused 0
Receiving objects: 100% (994/994), 3.30 MiB | 3.01 MiB/s, done.
Resolving deltas: 100% (477/477), done.
fatal: cannot process 'refs/remotes/origin/rawhide' and 
'refs/remotes/origin/rawhide/user/kyle/amd-ucode-2011-01-11' at the same time
Could not execute clone: Failed to execute command.


-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Pierre - Yves Chibon]

On Wed, Feb 17, 2021 at 08:00:49PM +0100, Miro Hrončok wrote:
>  On 17. 02. 21 19:46, Eugene Syromiatnikov wrote:
>  > On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote:
>  > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  > > 
>  > > == Summary ==
>  > > 
>  > > This Change will move Fedora git repositories to use "main" as the
>  > > default git branch instead of "master". Specific repositories will
> be
>  > > manually moved and default git branch for new projects will be set to
>  > > use "main".
>  > 
>  > The way this change has been performad made at least rpms/microcode_ctl
>  > repository unusable[1][2] by koji.
>  > 
>  > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=62174686
>  > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=62174675
>  
>  The same happens locally:
>  
>  $ fedpkg clone microcode_ctl
>  Cloning into 'microcode_ctl'...
>  remote: Enumerating objects: 994, done.
>  remote: Counting objects: 100% (994/994), done.
>  remote: Compressing objects: 100% (773/773), done.
>  remote: Total 994 (delta 477), reused 411 (delta 208), pack-reused 0
>  Receiving objects: 100% (994/994), 3.30 MiB | 3.01 MiB/s, done.
>  Resolving deltas: 100% (477/477), done.
>  fatal: cannot process 'refs/remotes/origin/rawhide' and
>  'refs/remotes/origin/rawhide/user/kyle/amd-ucode-2011-01-11' at the same
>  time
>  Could not execute clone: Failed to execute command. 
Could you try again?

refs/heads/rawhide/user/kyle/amd-ucode-2011-01-11 has been renamed to
refs/heads/rawhide_old/user/kyle/amd-ucode-2011-01-11
that should remove the conflict.


Pierre

[Eugene Syromiatnikov]

On Wed, Feb 17, 2021 at 08:14:47PM +0100, Pierre - Yves Chibon wrote:
>  On Wed, Feb 17, 2021 at 08:00:49PM +0100, Miro Hrončok wrote:
>  > On 17. 02. 21 19:46, Eugene Syromiatnikov wrote:
>  > > On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote:
>  > > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  > > > 
>  > > > == Summary ==
>  > > > 
>  > > > This Change will move Fedora git repositories to use "main" as
> the
>  > > > default git branch instead of "master". Specific repositories
> will be
>  > > > manually moved and default git branch for new projects will be set to
>  > > > use "main".
>  > > 
>  > > The way this change has been performad made at least rpms/microcode_ctl
>  > > repository unusable[1][2] by koji.
>  > > 
>  > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=62174686
>  > > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=62174675
>  > 
>  > The same happens locally:
>  > 
>  > $ fedpkg clone microcode_ctl
>  > Cloning into 'microcode_ctl'...
>  > remote: Enumerating objects: 994, done.
>  > remote: Counting objects: 100% (994/994), done.
>  > remote: Compressing objects: 100% (773/773), done.
>  > remote: Total 994 (delta 477), reused 411 (delta 208), pack-reused 0
>  > Receiving objects: 100% (994/994), 3.30 MiB | 3.01 MiB/s, done.
>  > Resolving deltas: 100% (477/477), done.
>  > fatal: cannot process 'refs/remotes/origin/rawhide' and
>  > 'refs/remotes/origin/rawhide/user/kyle/amd-ucode-2011-01-11' at the same
>  > time
>  > Could not execute clone: Failed to execute command.
>  
>  Could you try again?
>  
>  refs/heads/rawhide/user/kyle/amd-ucode-2011-01-11 has been renamed to
>  refs/heads/rawhide_old/user/kyle/amd-ucode-2011-01-11
>  that should remove the conflict. 
It is working now, thank you!

>  
>  Pierre
>