Question about package module development

[Coty Sutherland]

Hi all,

I'm working on (learning modularity) and developing a module for my package
and created a not-so-great (super long) branch name in the dist-git rpm and
module repo before I realized that it would be the stream's name too. Also,
it seems that the incomplete module was picked up and included in F31;
someone was nice enough to open a BZ and tell me it's broken. There are
builds associated with the branch, so I probably can't delete it outright,
but is there a way for me to hide (or something) that branch and use the
correct one that I just requested? I think that `fedpkg retire` is the way
to do it, but wanted to ask first since I can't find any supporting
documentation. Or now that it's been included in F31 am I stuck with it
(even thought it doesn't work)?



TIA,

-Coty

[Jun Aruga]

>  I'm working on (learning modularity) and developing a module for
> my package and created a not-so-great (super long) branch name in the dist-git rpm and
> module repo before I realized that it would be the stream's name too. 
I faced similar situation. Ruby module was released as
"private-jaruga-master" stream.
Now the branch is empty, as we can not delete it.
https://src.fedoraproject.org/modules/ruby/tree/private-jaruga-master

>  Also, it seems that the incomplete module was picked up and included
> in F31 
Policy Decision: In-development streams
https://pagure.io/modularity/issue/156#comment-600856

Right now "master", "devel" and "rolling" stream names are
used to
test a module before releasing version "X.Y" stream.
it's unofficial way. There is a discussion about it on above URL.

>  someone was nice enough to open a BZ and tell me it's broken.
Agree. Some checks before releasing are useful.

>  but is there a way for me to hide (or something) that branch and use
> the correct one that I just requested? 
Yes, you can hide the branch from the result of "dnf module list". I
asked it to someone to hide "private-jaruga-master" stream.
But I forget the way.

>  but wanted to ask first since I can't find any supporting
> documentation. Or now that it's been included in F31 am I stuck with it (even thought
> it doesn't work)? 
This is the documentation. But I do not think it is covering your concerns.
https://docs.fedoraproject.org/en-US/modularity/making-modules/

--
Jun

[Coty Sutherland]

Thanks for responding!

On Fri, Sep 27, 2019 at 8:54 AM Jun Aruga <jaruga(a)redhat.com&gt; wrote:

>  > I'm working on (learning modularity) and developing a module
> for my
>  package and created a not-so-great (super long) branch name in the dist-git
>  rpm and module repo before I realized that it would be the stream's name
>  too.
>
>  I faced similar situation. Ruby module was released as
>  "private-jaruga-master" stream.
>  Now the branch is empty, as we can not delete it.
>  https://src.fedoraproject.org/modules/ruby/tree/private-jaruga-master 

It appears that you retired the branch, which is what I was thinking of
doing.


>  > Also, it seems that the incomplete module was picked up and included in
>  F31
>
>  Policy Decision: In-development streams
>  https://pagure.io/modularity/issue/156#comment-600856
>
>  Right now "master", "devel" and "rolling" stream names are
> used to
>  test a module before releasing version "X.Y" stream.
>  it's unofficial way. There is a discussion about it on above URL.
>  
Thanks for that tip, I'll use the master branch for now then.


>  > someone was nice enough to open a BZ and tell me it's broken.
>
>  Agree. Some checks before releasing are useful.
>
>  > but is there a way for me to hide (or something) that branch and use the
>  correct one that I just requested?
>
>  Yes, you can hide the branch from the result of "dnf module list". I
>  asked it to someone to hide "private-jaruga-master" stream.
>  But I forget the way.
>  
Maybe someone else can help :D


>  > but wanted to ask first since I can't find any supporting documentation.
>  Or now that it's been included in F31 am I stuck with it (even thought it
>  doesn't work)?
>
>  This is the documentation. But I do not think it is covering your concerns.
>  https://docs.fedoraproject.org/en-US/modularity/making-modules/ 

Yeah, I've already read that a few times, but there's nothing about removal.


>  --
>  Jun
>  _______________________________________________
>  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]
>  

-- 

Coty Sutherland, RHCSA, RHCE, JBCAA

Senior Software Engineer

Red Hat <https://www.redhat.com/>

coty(a)redhat.com
@RedHat <https://twitter.com/redhat>   Red Hat
<https://www.linkedin.com/company/red-hat>  Red Hat
<https://www.facebook.com/RedHatInc>
<https://red.ht/sig>

[Jun Aruga]

> > Yes, you can hide the branch from the result of "dnf module
> list". I
> > asked it to someone to hide "private-jaruga-master" stream.
> > But I forget the way.
>
>
>  Maybe someone else can help :D 
I remembered the way after searching my past emails. :D
You can open a ticket on releng to hide it like this.

Untag modules/ruby stream private-jaruga-master from fedora-modular-30 repo
https://pagure.io/releng/issue/8279

-- 
Jun | He - His - Him

[Kevin Kofler]

Coty Sutherland wrote:
>  I'm working on (learning modularity) and developing a module for
> my
>  package and created a not-so-great (super long) branch name in the
>  dist-git rpm and module repo before I realized that it would be the
>  stream's name too. Also, it seems that the incomplete module was picked up
>  and included in F31; someone was nice enough to open a BZ and tell me it's
>  broken. There are builds associated with the branch, so I probably can't
>  delete it outright, but is there a way for me to hide (or something) that
>  branch and use the correct one that I just requested? I think that `fedpkg
>  retire` is the way to do it, but wanted to ask first since I can't find
>  any supporting documentation. Or now that it's been included in F31 am I
>  stuck with it (even thought it doesn't work)? 
So Modularity will happily unleash experimental branches that were never 
intended to be released onto unsuspecting users of stable releases? How can 
this not be an absolute showstopper? This failed Modularity experiment needs 
to end NOW!

        Kevin Kofler

[Jun Aruga]

>  So Modularity will happily unleash experimental branches that were
> never 
intended to be released onto unsuspecting users of stable releases? How can
this not be an absolute showstopper? This failed Modularity experiment needs
to end NOW!

As far as I know, there was no rule for the branch name, first and now.
The modularity team did not create any limitation intentionally. There
was a discussion to limit branch name in a past time.
That's the why each developer can create the branch technically.
Of course I know there is a document of a version branch name for modularity.

In case of fNN branch of rpms/foo, it is created by below command like this.

For example: https://bugzilla.redhat.com/show_bug.cgi?id=1326504#c35

```
$ fedpkg request-branch --repo htslib f31
https://pagure.io/releng/fedora-scm-requests/issue/17764
```

When running "fedpkg request-branch" command, the ticket is created newly.
Then, someone can check the branch is valid or not, before it is
actually created.
So, that's no problem. The branch can not be created wrongly.

But in case of module, each developer can create any branch
technically under their responsibility, but they can not remove the
branch, even it is created by mistake, and released in a short term.
The rule "developer can not remove the branch they created and
released" was created before the age of modurarity.
I feel the rule can be adjusted considering current situation of modularity.

-- 
Jun | He - His - Him

[Kevin Kofler]

Jun Aruga wrote:
>  But in case of module, each developer can create any branch
>  technically under their responsibility, 
And that is the issue, really.

        Kevin Kofler