from:"Aleksandra Fedorova"

On 4/21/23 16:15, Solomon Peachy via devel wrote:

On Fri, Apr 21, 2023 at 11:42:20AM +0200, Aleksandra Fedorova wrote:

That's a slight exaggeration of course, but so is your statement. People
come to Fedora via many ways. But I doubt any of it starts with e-mail
nowadays. And the fact that you don't see newcomers _here_ actually proves
the point, isn't it?

Correlation is not causation.

Distro building isn't "fun", or sexy. There are much more immediately
(and fiscally) rewarding things for "newcomers" to mess with.

Let's not get into a "who would you miss more" competition and work on a
solution which actually helps us to bridge the gap and allows us to
compromise between different use cases.

Oh, I know my contributions here are miniscule, but my point is that
we'd lose a ton of voices that collectively represent a ton of
experience and use cases.

In all seriousness, I would advise you to hang out at the current
discussion.fedoraproject.org and feel the vibe a bit.

You kinda just demonstrated my point -- "hanging out at
and feel the vibe" is going to take time, attention, and distruption.
My total available time/attention is fixed, which means this "hanging
out" will have to come at the cost of something else that frankly
matters _more_. And I won't personally gain anything from the effort --
at _best_ it will break even vs what I have now.

No, not really. I advised you to look into it, because you may actually
get more from it personally, than you currently expect. I haven't
proposed it to become a required Fedora activity, I gave you the
unsolicited advice. Which maybe I shouldn't have.

Distributions _are_ cool and sexy. And people have ideas and interest in
them. Some of them are totally wrong and misplaced, some may be very old,
and some are better. But that's how it should be.

I'm sorry, the numbers are _not_ on your side here, not just with Fedora
itself but the bigger picture of distributions in general. It's not
"email" that is keeping folks away, it's the nature of the work. And
_work_ it absolutely is.

And now you try to tell me that "coolness" is defined by numbers. Sorry,
I don't agree. I don't need everyone in the world to work on Linux
distribution. I don't want majority of people to work on Linux
distribution. I don't even need "more than in Ubuntu" people to work on
Fedora Linux distribution. That is not the point at all, and it is not
what makes things cool.

But with my Fedora Ambassador hat on I can tell you that the problem we
see right now is not that we don't have people coming to Fedora. We have
a problem helping people to connect to where the work is happening in a
way that they can contribute.

And this includes both mentoring them to be able to contribute, but also
accepting the fact that new people can bring new ideas, and we should
provide them space to work on them and not just expect them to follow
and do what they were told to do.

(And I say this as someone who has spent most of the past couple of
decades working on low-level infrastructure-type stuff. Sure, I find it
fun/enjoyable but I freely acknowledge I am several standard deviations
from the mean)

It seems you feel like you are cornered, but it is you who put yourself in
the corner by ignoring the part of the community, which actually can and
wants to support you.

By that same token bananas could make themselves more appealing to
people that like oranges if they'd only be more orange-like.

This isn't me "putting myself in a corner", it's Fedora moving the tent
that I was underneath and expecting me to move with it. (Because they
either don't understand _why_ anyone wouldn't want to move, or
understand, and do it anyway. I can actually respect the latter
position, even if I think it's not going to yield the expected results.
But I think this is yet another case of the former)

But whatever, I won't lose any sleep over this. As I already mentioned,
I have plenty of other things to do, both in the F/OSS world and in
(gasp) meatspace where I won't have to look at yet another screen.

[1] Splitting into the "core" developers (ie those paid/compensated for
participating) and an endless summer of newbs seeking help/support;
the middle gets completely hollowed out.

FWIW, I stand by this analogy.

The middle doesn't magically appear out of nowhere. It appears when you
build paths for newbies to grow into it. And it it sort of
responsibility of the current middle to grow the next one.

We think the communication channels change is one of the initiatives
which helps with that. Mentorship is the other.

There are currently three initiatives under Sustainable Community
objective and everyone's feedback is welcome:

https://discussion.fedoraproject.org/t/fedora-strategy-2028-focus-area-review-community-sustainability/79277

- Solomon

Re: It’s time to transform the Fedora devel list into something new


On 4/21/23 15:25, Christopher Klooz wrote:

Just a slight addition about "archaic email" and related comments:

Email and its capability for being used in conjunction with OpenPGP 
ensures two major institutions in kernel development and elsewhere: 
"Trusting the developers, not infrastructure" [1], and, assume "any part 
of the infrastructure can be compromised at any time" [1]. This avoids 
single points of failure, and complements the chain of trust.


I am not sure if Discourse is capable to be used in conjunction with 
OpenPGP if it reformats contents or if it removes attachments (maybe 
someone knows?). This leads to the possibility that discourse introduces 
a single point of failure (or, single point of vulnerability), which 
breaks the above institutions.


Having said that, as far as I follow our devel mailing list, I think the 
argument above is of minor relevance, because I think this mailing list 
is not used to forward code or to do reviews. Signatures seem to be not 
omnipresent at the moment anyway.


From security or impersonation point of view our current mailing list 
is actually the worst. Both Matrix and Discourse are at least tied to 
FAS account. And while it can be considered a single point of failure, 
it is at least the one which exists and is properly maintained by the 
project.


We had the issue with impersonation over e-mail before, and that was not 
nice.


However, I just wanted to remind that the issue is a little more complex 
than just assuming "email is old and has to be replaced by modern": 
there is another consideration, too. And we have to be aware that if 
discourse does not support OpenPGP signatures practically, we loose the 
possibility to ensure "security of integrity" in the mailing list in 
cases WHEN it is necessary - IF there are such cases (which I cannot 
determine).


I think we really try hard to not oversimplify the conversation to the 
point of "old" vs "new", or "us" vs "them" approach, though many of the 
replies in this thread are pulling us into that direction.


Matthew's mail in my opinion does a good job to highlight that there is 
no single "we want a new shiny thing for newbies" driver behind the 
switch. There are multiple reasons for it. And making discussions more 
secure and better maintained is on that list too.


And like, hey, e-mail is a still a thing. Use it where you need it, and 
where it fits. There is no fight against the technology.


But for this particular purpose within this particular environment the 
mailing list just doesn't work(*), and we see it.


(*) Works = provides shared space where old and new Fedora contributors 
can discuss changes and other project-related topics in a collaborative 
way to advance the project.


This is the problem which we must solve. And it won't go away on its own 
if just wait for it.


Again, the goal is not to fight against Fedora contributors using the 
e-mail technology. The goal is to find a solution.


And if the requirement for that solution is to improve the Discourse 
mail interface, can we at least try to look into it with open mind and 
actually list what needs to be done to make it work.


We are a group of FOSS developers using FOSS tools, and we have a year 
long plan to make the tool working for us and everyone else.


Let's maybe work on it?


Just some thoughts :)

[1] 
https://www.kernel.org/doc/html/latest/process/maintainer-pgp-guide.html


Chris



--
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new


Hi,

On 4/21/23 10:47, Daniel P. Berrangé wrote:

I agree with most of your points, but I wanted to comment on the Change 
process.


(...skipped a lot...)


First, I’d like to move the Changes discussion. They will still be
posted to devel-announce, but responses directed to Project Discussion
in a new #changes tag. Ben tells me that this is a FESCo decision,
which seems reasonable.


Early you mentioned that lots of teams have moved discussions into
tickets in Pagure/GitHub/etc.  I think that is an entirely natural
thing to do for task oriented discussions.

I think that Change proposals are precisely that - a task oriented
discussion, and thus would naturally fit into issue tracker model.
You then have the associated tools for tracking, tagging the changes,
linking between related tickets, and more, all in one place. The
way we use wiki categories to tag Change proposal pages, and then
have to have discussions somewhere else entirely, is effectively
reinventing a poor-mans' issue tracker. Just use a real issue tracker
here and stop splitting the process around multiple tools.


I think the issue with the Change process is that while the change 
itself is a task, its discussion has a property of generating 
sub-threads and sidetracks going in all directions, which shape the rest 
of the fedora-devel discourse.


So while from the execution point of view having it in the issue tracker 
makes a lot of sense, from the communication point of view Change 
discussion is a seed, which when planted on a forum can create a whole 
forest.


The hope is that forum tooling can be used to split the subthreads and 
to let them live on their own. So instead of strict moderation of the 
conversation in the issue tracker, which would be required to keep it on 
point, we will allow conversations to spread out but in a way that you 
have a possibility to choose your track.



P.S. It is funny how even though I consider myself a "seasoned" Fedora 
Contributor, every time I send a mail to a mailing list, I still go to a 
Hyper-Kitty interface to verify that I did everything correctly.


--
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new

 never occurs, or even
RH/Fedora's near-perfect abysmal record of framing core infrastructure
changes like this as a "discussion" when the decision has already been
made and will happen no matter what the masses have to say about it.

At the end of the day, distro development, like most other
infrastructure, isn't sexy or glamorous, and the humongous effort that
goes into it is rarely rewarded with anything other than abuse.  "Who
cares about distros?  I just use Docker containers!"


In all seriousness, I would advise you to hang out at the current 
discussion.fedoraproject.org and feel the vibe a bit.


Distributions _are_ cool and sexy. And people have ideas and interest in 
them. Some of them are totally wrong and misplaced, some may be very 
old, and some are better. But that's how it should be.


It seems you feel like you are cornered, but it is you who put yourself 
in the corner by ignoring the part of the community, which actually can 
and wants to support you.



[1] Splitting into the "core" developers (ie those paid/compensated for
 participating) and an endless summer of newbs seeking help/support;
 the middle gets completely hollowed out.

  - Solomon


--
Aleksandra Fedorova
bookwar

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [RFC] Build tag in RPM: from NVR to NVRB

2022-06-23 Thread Aleksandra Fedorova

Hi, Miro,

On Thu, Jun 23, 2022 at 12:15 PM Miro Hrončok  wrote:
>
> On 18. 06. 22 13:05, Aleksandra Fedorova wrote:
> > Hi, all,
> >
> > I'd like to discuss how we can add Build tag in the RPM.
> >
> > As one of the key points is to turn it into a common standard for rpm
> > packages across the ecosystem, the conversation is currently opened
> > upstream [1] and in RHEL Engineering. And I'd like to get Fedora
> > community on board.
> >
> > This is not a finalized proposal and I think it is not ready yet to be
> > a Fedora Change.
> > But I want to start a conversation and ask for opinions. There are
> > also some open questions which need help, especially the requirements
> > around build reason. And alternative suggestions are welcome as well.
> >
> > I've posted long version at
> >https://discussion.fedoraproject.org/t/rfc-build-tag-in-rpms/39954
> >
> > You can comment there (simply login with your FAS id) or here on the
> > mailing list.
> > And I am going to update that post with the new feedback.
> >
> > Shorter version:
> > 
> > We'd like to introduce Build Number/Tag/Id in the rpm metadata.
> >
> > By this change we would like to:
> > * Provide a possibility to change build environment and rebuild rpm
> > packages without changing their content: neither sources nor spec
> > files.
> > * Set a common standard for the RPM-based ecosystem, which can be used
> > not just within Fedora, but also by Remixes, downstreams, SIGs and
> > other distributions.
> >
> > The most visible impact of the proposal would be the filename change:
> >
> >Current: dnf-4.9.0-12.fc36.noarch.rpm
> >Proposed: dnf-4.9.0-12.fc36.34897715.noarch.rpm
> >
> > It can be implemented in two steps:
> >
> > 1) Now → Compatibility mode
> >
> > * Introduce Build tag in the rpm metadata
> > * Introduce “build reason” to be added to rpm changelog as a top entry
> > * Enable passing Build tag value to the build in Koji. The value of
> > the Build tag will be set from Koji build id.
> > * Introduce macro in Release field of the rpm spec files, which adds
> > Build tag after the usual disttag
> >  Release: 12.%{?dist}%{?build:.%{build}}
> > * Introduce option to pass “build reason” to a Koji build via koji cli
> > and fedpkg/centpkg tooling.
> >
> > 2) Compatibility mode → Final
> >
> > * Implement support for the upgrade path on the rpm side in a
> > compatible way. So that NV(R’=R+B) and NVRB are treated the same.
> > * Remove %{build} part from Release tag and use independent Build tag
> > for versioning.
> > 
> >
> > [1] https://github.com/rpm-software-management/rpm/discussions/2031
>
> I have couple concerns/questions.
>
> When modularity was introduced, local builds (outside of MSB) were side 
> tracked
> not to be part of the MVP. Implementing this later proved out to be rather
> complicated. So let's focus on the following gotchas from the start here
> instead please:

I think these are very valid questions. I didn't think about them at
first, but then added at the last moment under the name:
"Cross-distribution upgrade paths" in the doc. But I like how you
mention Copr and local builds as especially important cases of this,
so I will adjust the wording.

I don't have a ready to go answer, because I am not sure about the
goal. How do we want this to work?

Here are just some considerations.

>
> 1) An user rebuilds a package from Fedora dist-git in local mock, what will be
> the value of the build tag? How will the local build sort over the official
> Fedora builds?

Afaik currently, if you do a local build, you need to bump an NVR to
ensure the upgrade path is set. Then if the base distribution upgrades
or rebuilds the package, you would need to bump your version again if
you like to preserve the upgrade path.

This approach would work exactly the same way after the change, as
bumping the Release tag in the sources makes build-related versioning
irrelevant.

We can agree that by default Build tag in mock environment is unset.
Local builds have no build id, and to make clean upgrades bump of
Release tag is required.

But there are some new possibilities:

If you want to create a local rebuild without Release bump, you would
be able to pass the build tag value manually and set to whatever you
want. For example you can add 1 to existing build tag. Or you could
set it to 0. Or to .

The latter is less likely though.

If I were to create local builds which are always higher or always

Re: [RFC] Build tag in RPM: from NVR to NVRB

2022-06-18 Thread Aleksandra Fedorova

Hi,

On Sat, Jun 18, 2022 at 1:24 PM Vitaly Zaitsev via devel
 wrote:
>
> On 18/06/2022 13:05, Aleksandra Fedorova wrote:
> > * Provide a possibility to change build environment and rebuild rpm
> > packages without changing their content: neither sources nor spec
> > files.
>
> I have a better solution - let's move all packages to %autorelease +
> %autochangelog.

rpmautospec is a shortcut which allows you to not fill Release tag in
the dist-git manually. But to rebuild a package you still need at
least one additional commit to dist-git, which will change the value
that macro calculates. In the end the number is tied to dist-git
history.

rpmautospec automates the Release tag itself (as a version for spec
files), it doesn’t have a Build component in it. Thus, while
rpmautospec is a valuable tool for working on dist-git sources, its
development doesn’t overlap with the Build tag topic.

And, for example, rpmautospec will not help in the case we need to
update a build on pull request update: When you work with
pull-requests you don’t necessarily add commits, you rework the
history of a branch from which you run a PR. Sometimes even reducing
the number of commits in it.

(I added this answer as a section to the main post.)

> > Release: 12.%{?dist}%{?build:.%{build}}
>
> Looks ugly.

1) This is a temporary solution until we get full support of the Build
tag upstream
2) It probably can be simplified.

I am no expert in RPM macro language, but, for example, if we agree to
set default Build value to 0, it can be just Release:
12.%{?dist}.%{build}

But this is indeed one of the open questions, where we are looking for
more options.

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[RFC] Build tag in RPM: from NVR to NVRB

2022-06-18 Thread Aleksandra Fedorova

Hi, all,

I'd like to discuss how we can add Build tag in the RPM.

As one of the key points is to turn it into a common standard for rpm
packages across the ecosystem, the conversation is currently opened
upstream [1] and in RHEL Engineering. And I'd like to get Fedora
community on board.

This is not a finalized proposal and I think it is not ready yet to be
a Fedora Change.
But I want to start a conversation and ask for opinions. There are
also some open questions which need help, especially the requirements
around build reason. And alternative suggestions are welcome as well.

I've posted long version at
  https://discussion.fedoraproject.org/t/rfc-build-tag-in-rpms/39954

You can comment there (simply login with your FAS id) or here on the
mailing list.
And I am going to update that post with the new feedback.

Shorter version:

We'd like to introduce Build Number/Tag/Id in the rpm metadata.

By this change we would like to:
* Provide a possibility to change build environment and rebuild rpm
packages without changing their content: neither sources nor spec
files.
* Set a common standard for the RPM-based ecosystem, which can be used
not just within Fedora, but also by Remixes, downstreams, SIGs and
other distributions.

The most visible impact of the proposal would be the filename change:

  Current: dnf-4.9.0-12.fc36.noarch.rpm
  Proposed: dnf-4.9.0-12.fc36.34897715.noarch.rpm

It can be implemented in two steps:

1) Now → Compatibility mode

* Introduce Build tag in the rpm metadata
* Introduce “build reason” to be added to rpm changelog as a top entry
* Enable passing Build tag value to the build in Koji. The value of
the Build tag will be set from Koji build id.
* Introduce macro in Release field of the rpm spec files, which adds
Build tag after the usual disttag
Release: 12.%{?dist}%{?build:.%{build}}
* Introduce option to pass “build reason” to a Koji build via koji cli
and fedpkg/centpkg tooling.

2) Compatibility mode → Final

* Implement support for the upgrade path on the rpm side in a
compatible way. So that NV(R’=R+B) and NVRB are treated the same.
* Remove %{build} part from Release tag and use independent Build tag
for versioning.


[1] https://github.com/rpm-software-management/rpm/discussions/2031

-- 
Aleksandra Fedorova
CI for Fedora/CentOS Stream/RHEL
bookwar on Matrix/IRC
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Take the Fedora Annual Contributor Survey 2022

2022-06-02 Thread Aleksandra Fedorova

Hello, everyone,

Please participate in the Fedora Annual Contributor Survey 2022!

* https://fedoraproject.limequery.com/2022

The survey is anonymous, it has 44 questions targeting Fedora
contributors of all kinds and asks about your default choices of
applications and services.

This is the second run of the survey. The questions are the same as
last year with more variants added according to the data we have
collected. We will compare answers for this year with the previous
year results.

At the end of the survey you will get the claim link for the badge.

For questions and feedback please refer to the forum thread:

* 
https://discussion.fedoraproject.org/t/we-want-to-hear-from-you-take-the-fedora-annual-contributor-survey-for-2022/39576

Thank you for your contribution!

--
Aleksandra Fedorova
bookwar on Matrix/IRC
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@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/devel-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Take the Fedora Annual Contributor Survey 2022

2022-06-02 Thread Aleksandra Fedorova

Hello, everyone,

Please participate in the Fedora Annual Contributor Survey 2022!

* https://fedoraproject.limequery.com/2022

The survey is anonymous, it has 44 questions targeting Fedora
contributors of all kinds and asks about your default choices of
applications and services.

This is the second run of the survey. The questions are the same as
last year with more variants added according to the data we have
collected. We will compare answers for this year with the previous
year results.

At the end of the survey you will get the claim link for the badge.

For questions and feedback please refer to the forum thread:

* 
https://discussion.fedoraproject.org/t/we-want-to-hear-from-you-take-the-fedora-annual-contributor-survey-for-2022/39576

Thank you for your contribution!

--
Aleksandra Fedorova
bookwar on Matrix/IRC
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@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/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: NVIDIA Open-Source GPU Kernel Modules: How does that affect Fedora Linux?

2022-05-12 Thread Aleksandra Fedorova

Hi,

On Thu, May 12, 2022 at 7:44 AM Miro Hrončok  wrote:

> Hello Fedorans. I suppose this changes things, right? But how?
>
>
> https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/
>
> As far as I know this would still not be acceptable in Fedora due to the
> "No
> external kernel modules" rule, right?
>
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#_no_external_kernel_modules
>
>

Christian Schaller has posted an article on that:

https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux/

As I understood it, there is still a lot of work to be done for this driver
to be usable in generic use cases.

This step is a huge thing for NVIDIA and the industry, but it is just a
first step. And it seems that the most immediate impact we will see is the
changes and improvements in the noveau driver.


-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Change proposal: make Change proposals more obvious

2022-04-28 Thread Aleksandra Fedorova

Hi, Adam,

On Thu, Apr 28, 2022 at 1:50 AM Adam Williamson
 wrote:
>
> OK, so this is a bit meta, but I couldn't resist :P
>
> Since the Fedora 37 proposed Changes got posted, we have got the now-
> inevitable round of news stories which talk about proposed Changes as
> if they're approved already, like this one:
>
> https://forums.theregister.com/forum/all/2022/04/27/fedora_starts_to_simplify_linux/
>
> Could we consider, in future, posting a clarification for journalists
> in flaming six-foot high letters (I exaggerate only slightly) at the
> top of *every* proposed Change page, and *every* official mail relating
> to a proposed Change, which clarifies that it's *proposed* not
> *accepted*, and that means it might not happen? I feel like we'd have
> to firefight less if we could do that.

Thanks for bringing it up. I had exactly the same feeling about
several Fedora-related news recently.

I think adding a disclaimer like:

   This is a Change Proposal. For details about our community-driven
open Change Process refer to the doc [..]

could help.

I would leave it to Ben to decide how much ASCII-art it needs.

> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: More declarative RPMs

2022-02-16 Thread Aleksandra Fedorova

Hi,

On Wed, Feb 16, 2022 at 9:18 AM Miroslav Suchý  wrote:
>
> Dne 15. 02. 22 v 22:08 Matthew Kenigsberg napsal(a):
>
> It sounds like there's already some effort to make tasks in RPMs like adding 
> users more declarative: 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
>
> Which is still not finished and you still need to call the old scriptlet when 
> you need the user to exist during %post. :(
>
> Do you think it would be possible to move some of the configuration tasks 
> performed in scriptlets into something declarative that could be merged with 
> other configuration?
>
> Yes. Take the
>
>   https://src.fedoraproject.org/lookaside/rpm-specs-latest.tar.xz
>
> grep for common scriptlets and resolve them one-by-one. Starting with common 
> one. But it is huge task!
>
> You can choose where you will start:
>
> * mkfontdir - which can be replaced by filetriggers.
>
> * update-desktop-database - which - I believe - has been already replaced by 
> filetriggers, but it is still used.
>
> *update-alternatives - which no one yet touched
>
>  and many many others

Do I understand correctly that there is a general agreement that it is
the right direction to take, and the main reason why we are not there
yet is the size of the effort?

I tried to find any good doc but the page in Packaging Guidelines
doesn't say anything about scriptlets being discouraged:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/

Maybe we should make some long-term landing page for this initiative,
similarly to what Miro and the Python team did for Python 2 to Python
3 migration? So that it is easier to get people started on it.

The list you posted can already be a good start.

And I don't think proven packagers rights will be really necessary as
the work can be done via merge requests and should be accessible for
all.

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: use unit names in systemd output by default?

2021-06-25 Thread Aleksandra Fedorova

Hi,

On Fri, Jun 25, 2021 at 12:21 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> Hi,
>
> systemd has systemd.status_unit_format= / [Manager].StatusUnitFormat=
> / -Dstatus-unit-format-default= option to use unit names instead of the
> Description in messages on the kernel console and in logs:
>
> - Jun 20 22:04:48 krowka systemd[1]: Started Rule-based Manager for Device 
> Events and Files.
> + Jun 20 22:04:48 krowka systemd[1]: Started systemd-udevd.service.
>
> I find this more convenient because it's briefer, so it fits better on
> a terminal, but primarily because I can select the unit name for
> further lookup. When Description is used, and I'm not familiar with
> the unit, I'll often use grep first to figure out what the unit name
> actually is. Finally, unit Descriptions are often not very good, and
> the name is at least as informative…

I would vote for unit-names over description, as I can use them to
search information in the logs or in docs.

But I wonder why don't we consider having both unit name and description

Could something like

   Jun 20 22:04:48 krowka systemd[1]: Starting systemd-udevd.service -
Rule-based Manager for Device Events...
   Jun 20 22:04:48 krowka systemd[1]: Started systemd-udevd.service.

be an option?

You mention brevity, but do we really need to save space here?

> Would people be opposed to making this the default (setting
> -Dstatus-unit-format-default=name in build options)? People who like
> the old default could set StatusUnitFormat=description in systemd.conf
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure


-- 
Aleksandra Fedorova
bookwar on Libera Chat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RFC: Banning bots from submitting automated koji builds

2021-06-20 Thread Aleksandra Fedorova

ban things TBH.
> >
>
> Most of our rules are designed to make sure there's someone ultimately
> responsible for everything going into Fedora. Unfortunately, bots are
> the opposite of that, because there's no one to reach to stop bad
> behavior when it happens.
>
> Rawhide is still not your CI environment.

By the way I think we need to reconsider this statement.

I think I understand the intent, but the statement itself is
misleading, if not wrong, when taken out of context. For a person
outside of the bubble it is hard to understand and it seems to be
contradicting with the idea of Rawhide being the integrated
development branch of the Fedora Linux distribution.

While normally we do use words "CI" as a replacement for the word
"testing", we should be more careful in official statements and
policies, or at least should provide the context and explanation,
rather than just a slogan.

> Years ago, we got rid of
> alphas for the express purpose to stabilize Rawhide into alpha
> quality. Stuff like this degrades the quality of Rawhide because they
> make the assumption that nobody cares about the quality of Rawhide.

And I'd rather see us writing the requirements for the things
themselves, which supposed to land in Rawhide, than requirements on
the implementation of _how_ these things get there.

> If you want the features of Rawhide for CI, then we should talk about
> enabling this in more places. For example, there's no technical reason
> we couldn't do OpenQA runs for packages in COPR. There are serious
> consequences to shipping packages into Rawhide, not the least of which
> is that it locks an NVR forever into Koji and ships it to people using
> Rawhide as a daily driver. Also having the ability to have COPR
> auto-rebuild as stuff changes in the build root makes the CI case work
> better, and that's something we literally can't do in Koji (by policy
> and by design).
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Take the new Annual Fedora Contributor Survey

2021-06-02 Thread Aleksandra Fedorova

Hello, everyone,

Please participate in the Annual Fedora Contributor Survey 2021!

* https://fedoraproject.limequery.com/2021

The survey is anonymous, it has 44 questions and It is targeting
Fedora contributors of all kinds and asks about your default choices
of applications and services.

At the end of the survey you will get the claim link for the badge.

As this is our first Fedora Contributor Survey, please be patient and
provide your feedback, ideas, suggestions for the next round via the
comment field in the survey or discussion thread:

* https://discussion.fedoraproject.org/t/annual-fedora-community-survey/30354/10

(you can use your FAS id to login and comment)

Thank you for your contribution!

-- 
Aleksandra Fedorova
bookwar
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@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/devel-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Take the new Annual Fedora Contributor Survey

2021-06-02 Thread Aleksandra Fedorova

Hello, everyone,

Please participate in the Annual Fedora Contributor Survey 2021!

* https://fedoraproject.limequery.com/2021

The survey is anonymous, it has 44 questions and It is targeting
Fedora contributors of all kinds and asks about your default choices
of applications and services.

At the end of the survey you will get the claim link for the badge.

As this is our first Fedora Contributor Survey, please be patient and
provide your feedback, ideas, suggestions for the next round via the
comment field in the survey or discussion thread:

* https://discussion.fedoraproject.org/t/annual-fedora-community-survey/30354/10

(you can use your FAS id to login and comment)

Thank you for your contribution!

-- 
Aleksandra Fedorova
bookwar
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@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/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What to do about ELN-related "spam"?

2020-12-17 Thread Aleksandra Fedorova

Hi, Fabio,

On Thu, Dec 17, 2020 at 1:22 PM Fabio Valentini  wrote:
>
> On Thu, Dec 17, 2020 at 12:37 PM Petr Šabata  wrote:
> >
> > On Thu, Dec 17, 2020 at 12:27 PM Fabio Valentini  
> > wrote:
> > >
> > > Hi everybody,
> > >
> > > I'm unsure how to deal with this, so I'm asking here if anybody has ideas.
> > >
> > > - I'm getting serious spam from fedora-notif on IRC about successful -
> > > and a lot more failed - ELN builds for my packages (triggered either
> > > by ELN developers or automatically by their CI)
> >
> > I hope successful builds aren't too much of a pain; failed builds
> > should preferably be addressed, ideally by you. Unless it's clearly
> > not a problem in your package.
> >
> > > - bodhi is spamming bugzilla by changing the "Fixed in Version" field
> > > every time a new ELN build succeds with a new %dist value (one
> > > bugzilla email each for eln106, eln107, eln108, etc.)
> >
> > This sounds wrong to me but maybe it's relevant for potential ELN
> > consumers to know if a bug was also addressed in ELN. Is that an
> > issue?
> >
> > > At this point, almost half of the bugzilla mail I get and a majority
> > > of the IRC notifications are "ELN spam" that I do not know how to deal
> > > with / is not actionable for me. It's now so bad that I'd like to get
> > > the packages that are failing to build (multiple times a day) in ELN
> > > fixed just so I don't get spammed with "failed to build" notifications
> > > anymore ...
> >
> > I wonder why you're getting so many build notifications. These should
> > only be triggered when you update your package in Rawhide. But again,
> > fixing build failures would generally be a good thing.
>
> I maintain 400 (co-maintain 1600) packages and have submitted almost
> 300 package updates in the past month alone. That's probably the
> reason for the amount.
>
> The build failures are certainly not my problem, because the packages
> built (and still build) fine in rawhide.
>
> I assume they fail because they're getting built in the wrong order in
> ELN (I use side tags for order-sensitive builds), or they're missing
> new dependencies that are not in ELN yet.
> I can do nothing about either of those things, only wait until the CI
> submits the failed builds often enough until they land in the correct
> order, which takes n! tries in the "random" order the CI submits the
> builds, resulting in a large number of failed koji builds.

Unfortunately there is no way to manage these notifications from the
ELN SIG side. The ELN automation doesn't send any messages on its own.
(We do file BZ's for ELN FTBFS issues for RHEL developers under RHEL
Product umbrella in bugzilla, but this is done on agreement with RHEL
Engineering)

The notifications you get are sent by Koji and Bodhi.

The issue was reported for Bodhi some time ago[1]

The IRC notifications can be controlled via Notifications App.
Afaik, by default they are configured so that you get notified about
all builds for packages you maintain, no matter the target or owner of
the build. But it can be changed in the app interface.

We welcome contributors to the ELN SIG, but we have no intent to push
any responsibility regarding ELN builds on people who have no interest
in them. It is only the limitation of the current messaging
infrastructure, which creates the inconvenience.

[1] https://github.com/fedora-infra/bodhi/issues/4094
[2] https://apps.fedoraproject.org/notifications


>
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar on IRC
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

2020-11-12 Thread Aleksandra Fedorova

Hi, all,

On Thu, Oct 22, 2020 at 2:27 PM Aleksandra Fedorova  wrote:
>
> Hi, all,
>
> this is the informational message, no action required.
>
> Upon agreement between gcc maintainers and ELN SIG we would like to
> switch ELN buildroot to use GCC11 ahead of Fedora Rawhide.
>
> Though ELN is defined as the buildroot where Fedora Rawhide code is
> rebuilt into EL-like environment, in the ELN proposal we also
> mentioned that ELN can be used to test certain buildroot-related
> features on the side so it doesn't block Fedora Rawhide development.
>
> We think that GCC11 is one such feature, where we can benefit from
> testing it first on a small subset of the Fedora content in a separate
> environment.
>
> We would like to invite everyone to join this effort.
>
> The work is currently tracked on Github:
> https://github.com/fedora-eln/eln/issues/8
>
> Once GCC11 is merged to the eln tag in koji, one would be able to use
> it via, for example, mock or container environment:
> quay.io/fedoraci/fedora:eln-x86_64
>
> For more info on ELN please refer to ELN Docs (as soon as I update
> them, which hopefully happens later today):
>
> https://docs.fedoraproject.org/en-US/eln/
>
> --
> Aleksandra Fedorova
> bookwar at #fedora-devel and #fedora-ci

Small update on the topic:

GCC11 has not landed in the ELN buildroot yet.

After we tried the first mass rebuild of ELN packages in a sidetag,
several issues were found by gcc maintainers. Jeff has more info on
that, but afaiu one issue is related to glib2 and waits for the
upstream fix.

Once the issue is fixed we may try new ELN mass-rebuild in the
sidetag, before doing any real updates in the buildroot itself. Exact
timing is yet to be defined.

We will be running this mass rebuild with the lowest priority, so that
it won't get in the way of regular Fedora builds. (We had a
misconfiguration in the rebuild script, which caused the queue on the
build system before. This issue is now fixed)

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

[ELN] Achieved milestone - first installable ELN compose

2020-10-28 Thread Aleksandra Fedorova

Hi, all,

this is yet another informational message from the ELN SIG, no action required.

On Monday we achieved a major milestone for the ELN project: we got
the first installable ELN compose artifact.

As many of you know, ELN is the alternative buildroot for Fedora,
where we rebuild Fedora Rawhide sources with disabled %(fedora} and
enabled %{rhel} macro, see [0] for more info. ELN is similar to RHEL,
CentOS and EPEL environments.

In the early discussions of the ELN proposal the concerns were raised
whether it is even possible to get a working system from such
conditionals, without branching and forking too much of the code and
infrastructure. The current result proves that this goal is indeed
achievable.

Of course one needs to be careful with the definition of the term "the
working system". ELN is a development tool, it is not tested and it is
not intended to be used for any Fedora deployments.

But the working installation process provides us a reasonable
baseline, a reference point for the future work.

For more information on how to run ELN environment see [1]

Some additional data on the current state of the buildroot:

SAME: 4588
OLD: 23
NEW: 32
NONE: 20
total: 4665

ELN Buildroot now is defined as 4665 packages. 4588 of them are in
sync with the rawhide, 23 packages are older than rawhide, 32 are
newer and 20 are failed to build (NONE).

Packages can be newer in ELN if they have been built from the tip of
the rawhide branch in dist-git, rather than from the same commit as
the rawhide package.

The up to date state of the ELN per package is published at the docs site [2]
If you(unlike me) have some JavaScript skills and would like to
improve the Status page, check the issue [3]

P.S. gcc11 has not been merged in the ELN Buildroot yet. The work is
tracked in [4]

[0] https://docs.fedoraproject.org/en-US/eln/buildroot/
[1] https://docs.fedoraproject.org/en-US/eln/deliverables/
[2] https://docs.fedoraproject.org/en-US/eln/status/
[3] https://github.com/fedora-eln/eln/issues/11
[4] https://github.com/fedora-eln/eln/issues/8

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

2020-10-26 Thread Aleksandra Fedorova

On Mon, Oct 26, 2020 at 12:20 AM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Saturday, 24 October 2020 at 12:28, Aleksandra Fedorova wrote:
> [...]
> > On top of generic sidetag functionality, ELN has additional features
> > like automated continuous rebuilds of Rawhide packages, regular
> > composes and container builds[1], and people watching after them.
> > Note that we have spent three months on ELN automation and it still
> > has a lot of gaps in it.
>
> Very cool. That's exactly what was missing in the original announcement.
> If you had included that, I'm sure there would have been a lot less
> misunderstanding. Please keep that in mind and make sure you include not
> only "what you're doing" but also "why you're doing it that way" in
> future announcements.

As I said above, communication is not an easy task. And I may skip
some parts because they seem obvious to me, or because I've just
forgotten to mention.
In such cases, please ask. I will try to answer and eventually
document the answers in the ELN docs.

> Can we assume that those features are going to be part of regular
> rawhide at some not-too-distant point in the future?

Which features do you mean?

Regular composes and containers builds are already available in
Rawhide. Most features of ELN are about how to make a generic sidetag
look more like Rawhide. So we rather bring features from Rawhide to
ELN, not the other way. For example, one of the next steps is to
support the rebuild of dynamic sidetags, not just mirror individual
builds from Rawhide as we do now.

I think one of the future goals for ELN automation should be to make
it less ELN-specific and more generic, so that, as Neal suggested, we
may apply the same approach for other activities. But this needs some
time and effort.

> Regards,
> Dominik
> --
> Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

2020-10-24 Thread Aleksandra Fedorova

On Fri, Oct 23, 2020 at 10:43 PM Neal Gompa  wrote:

..skipped..

> There's actually nothing wrong with this idea in itself, because at
> the crux of it is that there is a desire to have a side-tag to build
> gcc11 with a limited compose to regression test and further evaluate
> the development of GCC earlier. This is something I'd like to have
> available for more things, and it's a great idea. But there is
> basically no reason to stuff it into ELN other than it already exists
> as a gap in our existing process. Instead, I'd like to have that
> formally approved by FESCo in a way that releng would make a dedicated
> side tag for it and allow OSCI to be configured for mini-composes for
> the purpose of assisting in GCC development. Then it can be a regular
> part of GCC rebase processes.

On top of generic sidetag functionality, ELN has additional features
like automated continuous rebuilds of Rawhide packages, regular
composes and container builds[1], and people watching after them.
Note that we have spent three months on ELN automation and it still
has a lot of gaps in it.

Collaboration between GCC11 maintainers and ELN SIG allows us to save
the resources, both technical and human, and use the already existing
infrastructure pieces built for ELN to temporarily (for three weeks)
test the GCC11 too.

You are suggesting now that someone goes and duplicates this work. If
you know people somewhere ready to do this, let them step in and we
can discuss it.

I also don't see why you think that landing GCC11 in ELN three weeks
ahead on Rawhide contradicts with the idea of ELN being a development
preview of future RHEL.

[1] https://docs.fedoraproject.org/en-US/eln/deliverables/

> [1]: https://fedoraproject.org/wiki/Changes/GatingRawhidePackages
> [2]: https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> [3]: https://fedoraproject.org/wiki/Changes/ArbitraryBranching
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

2020-10-24 Thread Aleksandra Fedorova

On Fri, Oct 23, 2020 at 9:58 PM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Friday, 23 October 2020 at 20:36, Jeff Law wrote:
> > On 10/23/20 8:01 AM, Dominik 'Rathann' Mierzejewski wrote:
> > > On Friday, 23 October 2020 at 14:45, Aleksandra Fedorova wrote:
> [...]
> > And as I've mentioned before on this thread, we're trying to figure out
> > how to drop that change in earlier than we have in the past.   There's
> > technical as well as non-technical concerns.  The time period Jakub and
> > myself were looking at was dropping it in at the end of stage1 upstream
> > gcc development which would be mid Nov.  But we both feel it's
> > imperative that the implications be discussed here and that the change
> > in procedure gets highlighted in the usual change proposal.
>
> Great! I'm all for landing major GCC updates as early as it makes sense
> for both upstream and Fedora. Does landing the update in ELN first give
> us any benefits compared to landing it directly in rawhide? Everybody
> involved with the ELN-GCC11 proposal in this thread seems to be avoiding
> the answer to this question.

The question why GCC11 can not land in Rawhide right now has been
answered by Jakub.

> > >> This activity could have been done internally in RHEL, or externally
> > >> in some upstream working groups. But ELN now allows us to do this work
> > >> in public in Fedora, and invite Fedora community to join it, if they
> > >> _want_.
> > > How can we join, then? How is this better than doing this, say, in COPR?
> > > Or a rawhide side-tag.
> >
> > Right now the build is on a side tag and hasn't been merged into ELN (to
> > the best of my knowledge).  Once the bits are merged in then I expect
> > anyone can join in the "fun".
>
> And yet the post starting this thread invited everyone to join. So which
> is it? Can I join now or must I wait until the tag is merged?

I did share the details of the upcoming update in advance.
Specifically for the purpose that people can join the conversation
about it in the issue I linked.

If you are interested in the coordination of this update, or you can
join now and provide your feedback. If you are only interested in the
states of packages built with GCC11, you need to wait for until the
update is merged

> > >> As we promised by the ELN Change we have provided the platform for GCC
> > >> upstream, RHEL downstream and Fedora community to collaborate on the
> > >> work for Fedora, and motivation for Red Hat to sponsor this effort.
> > > So far I haven't seen any clear instructions on how I can, say, rebuild
> > > my packages with GCC11 to catch any fall-out early. Or where you're
> > > going to publish (if at all) the results of any rebuilds you'll perform.
>
> > We don't generally publish them -- though we've certainly discussed it
> > in the past and the only impediment is my time.  The jenkins server
> > which drives my testing is on Red Hat's internal network, but there's a
> > publisher that would allow us to push the build info out to a public
> > facing server.  There's nothing inherently private and/or secret about
> > the work.  We also use that jenkins system to do wide scale testing of
> > GCC work before it lands in upstream GCC.
>
> I wasn't implying there was anything secret anywhere. Thanks for the
> background details, though.
>
> > If you have specific packages in mind, I'm happy to let you know their
> > build status with gcc-11.  It's just some clicking.
>
> Well, let's see. I'm interested in all my packages which have gcc* in
> their BuildRequires.
>
> Regards,
> Dominik
> --
> Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

2020-10-23 Thread Aleksandra Fedorova

On Fri, Oct 23, 2020 at 12:40 PM Miro Hrončok  wrote:
>
> On 10/23/20 11:52 AM, Aleksandra Fedorova wrote:
> > On Thu, Oct 22, 2020 at 7:12 PM Miro Hrončok  wrote:
> >>
> >> On 10/22/20 6:33 PM, Aleksandra Fedorova wrote:
> >>> On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok  wrote:
> >>>>
> >>>> On 10/22/20 2:51 PM, Aleksandra Fedorova wrote:
> >>>>> Hi, Vit.
> >>>>> On Thu, Oct 22, 2020 at 2:37 PM Vít Ondruch  wrote:
> >>>>>> I was asking for ELN branch for ages and it was always denied and there
> >>>>>> you have it [1]. So what is the current stance on this topic?
> >>>>> You were asking for a branch to overcome the issue with building a
> >>>>> package in ELN. And we have a suggestion for the alternative solution
> >>>>> which wouldn't require maintaining a separate eln branch forever.
> >>>>>
> >>>>> For gcc we are using a temporary branch for the development of a new
> >>>>> feature in Fedora.
> >>>>> I would have named it "gcc11" branch rather than "eln", but it is a
> >>>>> bikeshedding exercise.
> >>>>
> >>>> This is not about naming / bikeshedding. Whatever you call it, this is a 
> >>>> "branch
> >>>> used exclusively to build in ELN". Vít wanted this, I wanted this and 
> >>>> many other
> >>>> Fedora/RHEL packagers wanted this. Yet you argued so passionately 
> >>>> against it.
> >>>> For example you said:
> >>>>
> >>>>> I think that not having eln-branch is very important part of the
> >>>>> concept as we don't want to fork Fedora.
> >>>>
> >>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WRJNM7I5TFQ5TEBOUKKH757K5ME3I47F/
> >>>>
> >>>> But there were countless other arguments against having such branches. 
> >>>> Have the
> >>>> situation changed? Can other packages have eln branches as well?
> >>>
> >>> No, the situation has not changed.
> >>
> >> Glad to hear that, because that eln branch in gcc was a big surprise for 
> >> all of
> >> us who have been told this is not an option.
> >>
> >>> I'll reiterate:
> >>>
> >>> We don't want to fork packages from the Fedora Rawhide. We don't want
> >>> to provide eln-branch as an option to overcome build failures in ELN.
> >>> ELN's purpose is to provide motivation and tooling for downstream
> >>> developers to work on Fedora, not to share parts of Fedora
> >>> infrastructure for downstream developers to do their downstream work.
> >>
> >>   From where I stand, this gcc eln branch / update in ELN seem to be 
> >> primarily
> >> motivated by downstream. But I agree that I might miss all the important
> >> information to make that claim, so I'll try to not be biased.
> >
> > It would be nice if we could stop playing political games and start
> > looking at the content of the work, rather than discussing who brings
> > it.
>
> I am not playing any political games. I express my opinion that this is not 
> how
> I expect changes to land in Fedora. There's nothing political about that. What
> do you actually mean by political in this context?
>
> > eln-branch to handle downstream incompatibility with rawhide and
> > eln-branch made to test Fedora features are two different types of
> > work.
>
> You said "no ELN branches". Is that no longer true?

You can keep taking my words out of context, I can only keep bringing
the context back as the answer.

> >>> We expect downstream to have its own infrastructure and process for
> >>> branched packages. And we do have it in RHEL. If you want to discuss
> >>> how exactly RHEL downstream does it, I can provide more information.
> >>> But I consider it to be offtopic in this mailing list, or at least in
> >>> this thread.
> >>
> >> I thought I have a decent idea about how this is done. For example that 
> >> there
> >> will be no eln branches and this will be done "somewhere else later". At 
> >> least
> >> that is what we've been told when ELN was introduced. So I seem to have the
> >> wrong idea. Could you please summarize this? What kind of downstream 
> >> changes
> >> will happ

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

2020-10-23 Thread Aleksandra Fedorova

On Thu, Oct 22, 2020 at 7:12 PM Miro Hrončok  wrote:
>
> On 10/22/20 6:33 PM, Aleksandra Fedorova wrote:
> > On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok  wrote:
> >>
> >> On 10/22/20 2:51 PM, Aleksandra Fedorova wrote:
> >>> Hi, Vit.
> >>> On Thu, Oct 22, 2020 at 2:37 PM Vít Ondruch  wrote:
> >>>> I was asking for ELN branch for ages and it was always denied and there
> >>>> you have it [1]. So what is the current stance on this topic?
> >>> You were asking for a branch to overcome the issue with building a
> >>> package in ELN. And we have a suggestion for the alternative solution
> >>> which wouldn't require maintaining a separate eln branch forever.
> >>>
> >>> For gcc we are using a temporary branch for the development of a new
> >>> feature in Fedora.
> >>> I would have named it "gcc11" branch rather than "eln", but it is a
> >>> bikeshedding exercise.
> >>
> >> This is not about naming / bikeshedding. Whatever you call it, this is a 
> >> "branch
> >> used exclusively to build in ELN". Vít wanted this, I wanted this and many 
> >> other
> >> Fedora/RHEL packagers wanted this. Yet you argued so passionately against 
> >> it.
> >> For example you said:
> >>
> >>> I think that not having eln-branch is very important part of the
> >>> concept as we don't want to fork Fedora.
> >>
> >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WRJNM7I5TFQ5TEBOUKKH757K5ME3I47F/
> >>
> >> But there were countless other arguments against having such branches. 
> >> Have the
> >> situation changed? Can other packages have eln branches as well?
> >
> > No, the situation has not changed.
>
> Glad to hear that, because that eln branch in gcc was a big surprise for all 
> of
> us who have been told this is not an option.
>
> > I'll reiterate:
> >
> > We don't want to fork packages from the Fedora Rawhide. We don't want
> > to provide eln-branch as an option to overcome build failures in ELN.
> > ELN's purpose is to provide motivation and tooling for downstream
> > developers to work on Fedora, not to share parts of Fedora
> > infrastructure for downstream developers to do their downstream work.
>
>  From where I stand, this gcc eln branch / update in ELN seem to be primarily
> motivated by downstream. But I agree that I might miss all the important
> information to make that claim, so I'll try to not be biased.

It would be nice if we could stop playing political games and start
looking at the content of the work, rather than discussing who brings
it.

eln-branch to handle downstream incompatibility with rawhide and
eln-branch made to test Fedora features are two different types of
work.

> > We expect downstream to have its own infrastructure and process for
> > branched packages. And we do have it in RHEL. If you want to discuss
> > how exactly RHEL downstream does it, I can provide more information.
> > But I consider it to be offtopic in this mailing list, or at least in
> > this thread.
>
> I thought I have a decent idea about how this is done. For example that there
> will be no eln branches and this will be done "somewhere else later". At least
> that is what we've been told when ELN was introduced. So I seem to have the
> wrong idea. Could you please summarize this? What kind of downstream changes
> will happen in ELN branches and what kind of downstream changes will happen
> "somewhere else later"?

Again, you are mixing up changes made in downstream and changes in
Fedora sponsored by downstream.

GCC11 is not a downstream change.

Of course downstream is interested in landing GCC11 in Fedora as fast
and as clean as possible, why wouldn't it. And yes downstream sponsors
this work in Fedora.

> > At the same time, we would like to use ELN as an experimental
> > playground for features, when it makes sense, when it is helpful for
> > Fedora and when these additional features don't contradict the primary
> > purpose of the ELN buildroot.
>
> Do I understand correctly that as long as the downstream work aligns with
> "helpful for Fedora" it is OK to have an eln branch?

As long as it is not a downstream work, but a feature of Fedora.

> > We consider the update to GCC11 to be one of such features. It is not
> > a fork of the Rawhide into a downstream branch, it is a future Fedora
> > feature.
>
> Fedora features are coordinated via the Fedora change process. May we please
> have a GCC 11 Fedora change

Re: [ELN] Missing /usr/bin/bzr in ELN (solved, but open questions)

On Thu, Oct 22, 2020 at 7:41 PM Miro Hrončok  wrote:
>
> On 10/22/20 7:03 PM, Aleksandra Fedorova wrote:
> > Hi, Miro,
> >
> > On Thu, Oct 22, 2020 at 6:54 PM Miro Hrončok  wrote:
> >>
> >> On 10/22/20 1:59 AM, Neal Gompa wrote:
> >>>>>> 3) When I fix breezy, should I resubmit the eln rebuilds of pip and 
> >>>>>> Python?
> >>>>>>
> >>>>> No. Just submit to Rawhide and the Jenkins job for ELN will take care
> >>>>> of it for you after it succeeds in Rawhide.
> >>>> Python and pip succeeded in rawhide already, this is an ELN-only fix.
> >>>>
> >>> I mean that their bot listens for packages built in Rawhide and
> >>> triggers a rebuild automatically for ELN.
> >>
> >> I've just built breezy in rawhide and it an automatic build was triggered 
> >> in
> >> ELN, as expected.
> >>
> >> My question however is, whether I shall now build python-pip and later 
> >> python3.9
> >> in ELN myself or wait for some retry builds (which could take up to 
> >>  >> time> to happen in the correct order).
> >
> > It definitely will help if you submit the builds on your own.
> >
> > We have a rebuild loop for the missing updates, and we have ELN SIG
> > reviewing the status of the repository [2]. But submitting the builds
> > will indeed be faster.
>
> Thanks. What is the correct way?
>
> $ fedpkg build --target=eln
>
> ?

Yes. Thank you.

I was sure it has been documented already, but apparently we
documented everything about buildroot, except this part. I'll add it.

> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: [ELN] Missing /usr/bin/bzr in ELN (solved, but open questions)

Hi, Miro,

On Thu, Oct 22, 2020 at 6:54 PM Miro Hrončok  wrote:
>
> On 10/22/20 1:59 AM, Neal Gompa wrote:
> >>>> 3) When I fix breezy, should I resubmit the eln rebuilds of pip and 
> >>>> Python?
> >>>>
> >>> No. Just submit to Rawhide and the Jenkins job for ELN will take care
> >>> of it for you after it succeeds in Rawhide.
> >> Python and pip succeeded in rawhide already, this is an ELN-only fix.
> >>
> > I mean that their bot listens for packages built in Rawhide and
> > triggers a rebuild automatically for ELN.
>
> I've just built breezy in rawhide and it an automatic build was triggered in
> ELN, as expected.
>
> My question however is, whether I shall now build python-pip and later 
> python3.9
> in ELN myself or wait for some retry builds (which could take up to  time> to happen in the correct order).

It definitely will help if you submit the builds on your own.

We have a rebuild loop for the missing updates, and we have ELN SIG
reviewing the status of the repository [2]. But submitting the builds
will indeed be faster.

[1] https://docs.fedoraproject.org/en-US/eln/status/

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok  wrote:
>
> On 10/22/20 2:51 PM, Aleksandra Fedorova wrote:
> > Hi, Vit.
> > On Thu, Oct 22, 2020 at 2:37 PM Vít Ondruch  wrote:
> >> I was asking for ELN branch for ages and it was always denied and there
> >> you have it [1]. So what is the current stance on this topic?
> > You were asking for a branch to overcome the issue with building a
> > package in ELN. And we have a suggestion for the alternative solution
> > which wouldn't require maintaining a separate eln branch forever.
> >
> > For gcc we are using a temporary branch for the development of a new
> > feature in Fedora.
> > I would have named it "gcc11" branch rather than "eln", but it is a
> > bikeshedding exercise.
>
> This is not about naming / bikeshedding. Whatever you call it, this is a 
> "branch
> used exclusively to build in ELN". Vít wanted this, I wanted this and many 
> other
> Fedora/RHEL packagers wanted this. Yet you argued so passionately against it.
> For example you said:
>
> > I think that not having eln-branch is very important part of the
> > concept as we don't want to fork Fedora.
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WRJNM7I5TFQ5TEBOUKKH757K5ME3I47F/
>
> But there were countless other arguments against having such branches. Have 
> the
> situation changed? Can other packages have eln branches as well?

No, the situation has not changed.

I'll reiterate:

We don't want to fork packages from the Fedora Rawhide. We don't want
to provide eln-branch as an option to overcome build failures in ELN.
ELN's purpose is to provide motivation and tooling for downstream
developers to work on Fedora, not to share parts of Fedora
infrastructure for downstream developers to do their downstream work.

We expect downstream to have its own infrastructure and process for
branched packages. And we do have it in RHEL. If you want to discuss
how exactly RHEL downstream does it, I can provide more information.
But I consider it to be offtopic in this mailing list, or at least in
this thread.

At the same time, we would like to use ELN as an experimental
playground for features, when it makes sense, when it is helpful for
Fedora and when these additional features don't contradict the primary
purpose of the ELN buildroot.

We consider the update to GCC11 to be one of such features. It is not
a fork of the Rawhide into a downstream branch, it is a future Fedora
feature.

It is also not the only one, which we can handle through ELN. We were
considering the update of the baseline of the x86 cpu's to be such a
feature, but then it was discarded. The other example would be the
Default Module Streams setup.

If you would like to propose another Fedora feature, and you would
like to work together with the ELN SIG on it - please file a ticket in
the ELN tracker [1].
We are open to the ideas, and we may consider options, including
branching, to make it work.

[1] https://github.com/fedora-eln/eln/issues

> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

Hi, Jeff,

On Thu, Oct 22, 2020 at 4:14 PM Jeff Law  wrote:
>
>
> On 10/22/20 8:09 AM, Daniel P. Berrangé wrote:
> > On Thu, Oct 22, 2020 at 04:03:33PM +0200, Aleksandra Fedorova wrote:
> >> Hi, Daniel,
> >>
> >> On Thu, Oct 22, 2020 at 3:01 PM Daniel P. Berrangé  
> >> wrote:
> >>> On Thu, Oct 22, 2020 at 02:27:13PM +0200, Aleksandra Fedorova wrote:
> >>>> Hi, all,
> >>>>
> >>>> this is the informational message, no action required.
> >>>>
> >>>> Upon agreement between gcc maintainers and ELN SIG we would like to
> >>>> switch ELN buildroot to use GCC11 ahead of Fedora Rawhide.
> >>>>
> >>>> Though ELN is defined as the buildroot where Fedora Rawhide code is
> >>>> rebuilt into EL-like environment, in the ELN proposal we also
> >>>> mentioned that ELN can be used to test certain buildroot-related
> >>>> features on the side so it doesn't block Fedora Rawhide development.
> >>>>
> >>>> We think that GCC11 is one such feature, where we can benefit from
> >>>> testing it first on a small subset of the Fedora content in a separate
> >>>> environment.
> >>> I'm not very enthusiastic about this change.
> >>>
> >>> Fedora maintainers can largely ignore ELN right now, because if stuff
> >>> works in rawhide, it will generally work in ELN, and someone else is
> >>> taking care of ELN builds.
> >>>
> >>>
> >>> New GCC releases almost always trigger new compile warnings or bugs
> >>> in code. So by pushing GCC 11 into ELN, it feels like we're making
> >>> it much more likely that ELN builds will fail, and now Fedora
> >>> maintainers have to debug ELN specific problems that won't reproduce
> >>> in rawhide branches :-(
> >> Expectations for Fedora maintainers does not change.
> >> ELN is a development playground. Think about sidetag, with slightly
> >> better automation around it.
> >>
> >> We provide ELN as the opportunity, option to play with early releases
> >> of the GCC11 on the side. We are not requiring Fedora maintainers to
> >> participate, we are inviting people who may be interested in this
> >> work.
> > As Fedora maintainer I've been sent details of ELN failures / bugs, and
> > asked to deal with fixes for ELN branches, so there's clearly an expectation
> > placed on Fedora maintainers to be engaged in ELN.
>
> And that's unfortunate.  I've tried to signal to the ELN/Bakery folks
> that they should be contacting me first as any build failure related to
> teh compiler change I've probably already seen in one form or another.
> But it doesn't seem to have sunk in.

We haven't merged gcc11 into ELN yet, and there are no builds or tasks
filed about it to Fedora maintainers.
So I am not sure which issues Daniel is referring to.

Of course if a package needs an adjustment of a spec file to be built
in ELN buildroot, members of the ELN SIG might reach out and ask for
help, or suggest a pull request.
And yes, the expectation is that one member of the community can reach
out to another for the specific issue. I honestly believe that this is
how open source collaboration works.

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

Hi, Daniel,

On Thu, Oct 22, 2020 at 3:01 PM Daniel P. Berrangé  wrote:
>
> On Thu, Oct 22, 2020 at 02:27:13PM +0200, Aleksandra Fedorova wrote:
> > Hi, all,
> >
> > this is the informational message, no action required.
> >
> > Upon agreement between gcc maintainers and ELN SIG we would like to
> > switch ELN buildroot to use GCC11 ahead of Fedora Rawhide.
> >
> > Though ELN is defined as the buildroot where Fedora Rawhide code is
> > rebuilt into EL-like environment, in the ELN proposal we also
> > mentioned that ELN can be used to test certain buildroot-related
> > features on the side so it doesn't block Fedora Rawhide development.
> >
> > We think that GCC11 is one such feature, where we can benefit from
> > testing it first on a small subset of the Fedora content in a separate
> > environment.
>
> I'm not very enthusiastic about this change.
>
> Fedora maintainers can largely ignore ELN right now, because if stuff
> works in rawhide, it will generally work in ELN, and someone else is
> taking care of ELN builds.
>
>
> New GCC releases almost always trigger new compile warnings or bugs
> in code. So by pushing GCC 11 into ELN, it feels like we're making
> it much more likely that ELN builds will fail, and now Fedora
> maintainers have to debug ELN specific problems that won't reproduce
> in rawhide branches :-(

Expectations for Fedora maintainers does not change.
ELN is a development playground. Think about sidetag, with slightly
better automation around it.

We provide ELN as the opportunity, option to play with early releases
of the GCC11 on the side. We are not requiring Fedora maintainers to
participate, we are inviting people who may be interested in this
work.

> Now rawhide will be the latest stream, except for when it is not
> the latest stream :-(

Fedora Rawhide is the latest stream of Fedora.

This doesn't contradict to the fact that certain "heavy" changes can
be tested in the sidetag or copr repositories before landing in
Rawhide. This is the usual practice for many subprojects, from desktop
to Python.
We are not moving the usual gcc11-related work from Rawhide into ELN,
we are adding the preliminary step to it.


> 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 :|
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

--
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

Hi, Vit.
On Thu, Oct 22, 2020 at 2:37 PM Vít Ondruch  wrote:
>
> I was asking for ELN branch for ages and it was always denied and there
> you have it [1]. So what is the current stance on this topic?

You were asking for a branch to overcome the issue with building a
package in ELN. And we have a suggestion for the alternative solution
which wouldn't require maintaining a separate eln branch forever.

For gcc we are using a temporary branch for the development of a new
feature in Fedora.
I would have named it "gcc11" branch rather than "eln", but it is a
bikeshedding exercise.

> Vít
>
>
> [1] https://src.fedoraproject.org/rpms/gcc/commits/eln
>
>
> Dne 22. 10. 20 v 14:27 Aleksandra Fedorova napsal(a):
> > Hi, all,
> >
> > this is the informational message, no action required.
> >
> > Upon agreement between gcc maintainers and ELN SIG we would like to
> > switch ELN buildroot to use GCC11 ahead of Fedora Rawhide.
> >
> > Though ELN is defined as the buildroot where Fedora Rawhide code is
> > rebuilt into EL-like environment, in the ELN proposal we also
> > mentioned that ELN can be used to test certain buildroot-related
> > features on the side so it doesn't block Fedora Rawhide development.
> >
> > We think that GCC11 is one such feature, where we can benefit from
> > testing it first on a small subset of the Fedora content in a separate
> > environment.
> >
> > We would like to invite everyone to join this effort.
> >
> > The work is currently tracked on Github:
> > https://github.com/fedora-eln/eln/issues/8
> >
> > Once GCC11 is merged to the eln tag in koji, one would be able to use
> > it via, for example, mock or container environment:
> > quay.io/fedoraci/fedora:eln-x86_64
> >
> > For more info on ELN please refer to ELN Docs (as soon as I update
> > them, which hopefully happens later today):
> >
> > https://docs.fedoraproject.org/en-US/eln/
> >
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

[ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

Hi, all,

this is the informational message, no action required.

Upon agreement between gcc maintainers and ELN SIG we would like to
switch ELN buildroot to use GCC11 ahead of Fedora Rawhide.

Though ELN is defined as the buildroot where Fedora Rawhide code is
rebuilt into EL-like environment, in the ELN proposal we also
mentioned that ELN can be used to test certain buildroot-related
features on the side so it doesn't block Fedora Rawhide development.

We think that GCC11 is one such feature, where we can benefit from
testing it first on a small subset of the Fedora content in a separate
environment.

We would like to invite everyone to join this effort.

The work is currently tracked on Github:
https://github.com/fedora-eln/eln/issues/8

Once GCC11 is merged to the eln tag in koji, one would be able to use
it via, for example, mock or container environment:
quay.io/fedoraci/fedora:eln-x86_64

For more info on ELN please refer to ELN Docs (as soon as I update
them, which hopefully happens later today):

https://docs.fedoraproject.org/en-US/eln/

-- 
Aleksandra Fedorova
bookwar at #fedora-devel and #fedora-ci
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: [ELN] need a working build of systemtap for a rebuild of qemu

2020-09-23 Thread Aleksandra Fedorova

Hi, Kamil,

On Wed, Sep 23, 2020 at 12:41 PM Kamil Dudka  wrote:
>
> The latest eln build of systemtap fails to install, which prevents qemu
> from being built:
>
> https://bugzilla.redhat.com/1881342
>
> The maintainer of systemtap says that it is the eln rebuild what went wrong.
> So he created a new rawhide build in the hope that it will trigger a new eln
> build, which would afterwards be installable in the eln buildroot.
>
> But there is no eln (re)build of systemtap-4.4-0.20200922git05179173e71c.fc34
> yet despite builds that landed into rawhide much later are already rebuilt.
>
> Could someone from the ELN team please check what happened?

Thanks for the heads-up. There was a CI cluster downtime yesterday and
the build was impacted by it. I restarted it, and it passed

https://osci-jenkins-1.ci.fedoraproject.org/job/eln-build-pipeline/17459/

The systemtap-4.4-0.20200922git05179173e71c.eln103 is now available in
ELN buildroot.

> Kamil
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org



-- 

Aleksandra Fedorova
bookwar at #osci
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Side tag rebuilds an ELN

2020-09-21 Thread Aleksandra Fedorova

Hi, Florian,

On Mon, Sep 21, 2020 at 11:35 AM Florian Weimer  wrote:
>
> How do side tag rebuilds and ELN interact?  If we do a complicated
> synchronous package update in a side tag, will ELN track this closely?
> Or will someone have to redo the same steps in ELN manually?

For now we react on tagging events and process each "package is tagged
to f34" koji event separately.
For sidetags this means that we will try to rebuild all packages from
the sidetag, but the order of rebuilds is not preserved.

We are waiting for permissions to create sidetags for ELN in
https://pagure.io/fedora-infrastructure/issue/9329

Once it is available we will be setting up the automation for sidetag
rebuilds in the same order as they were built for Rawhide.
The work will be tracked by https://github.com/fedora-eln/eln/issues/2


> Thanks,
> Florian
> --
> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael 
> O'Neill
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org



-- 

Aleksandra Fedorova
bookwar at #osci
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Does ELN SIG have some issue tracker?

2020-08-25 Thread Aleksandra Fedorova

Hi, Vit,

On Tue, Aug 25, 2020 at 11:21 AM Vít Ondruch  wrote:
>
> Looking at the ELN SIG page [1], there is no contact information, no ML,
> no issue tracker. I would like to discuss bootstrapping issues such as
> [2], but there is no place to provide any feedback. Is this group
> working under cover?
>
> (Using the minimization tracker [3], where a lot of ELN stuff appears to
> end up, does not feel appropriate).

Thank you for the question.

The ELN wiki page is outdated, I am working on moving the content to
ELN Docs site [1] right now. I will add contact and contribution info
there as well.

The minimization tracker [2] is indeed better suited for the content
set discussions.

For generic ELN topics please use issues in https://github.com/fedora-eln/eln

[1] https://docs.fedoraproject.org/en-US/eln/
[2] https://github.com/minimization/content-resolver-input

> Vít
>
>
> [1] https://fedoraproject.org/wiki/ELN
>
> [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=1599965
>
> [3] https://github.com/minimization/
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-18.eln103 failed to build

2020-08-06 Thread Aleksandra Fedorova

Hi,

On Thu, Aug 6, 2020 at 5:01 AM Orion Poplawski  wrote:
>
> So, I'm getting one of these messages every couple of hours and I'd
> really rather not.  Who do I need to talk to about it?

You can talk about it with the ELN SIG [1] or Fedora CI SIG [2]. Mail
thread on devel works, we recommend to use [ELN] as a tag in the
subject, but this works too.

So let me explain first what is going on, and then what we are going
to do about it.

1) Why do you get the message?

We don't send messages to you or anyone directly. We trigger koji
builds for packages which are considered part of the ELN buildroot.

Koji sends messages about all new builds to the Fedora Messaging bus.
Then Fedora Notification [3] App reads messages from the message bus
and sends you notifications based on your filters. It has some default
settings, thus it sends you notifications about all builds for the
package you maintain, but this can be changed via the app interface.

2) Why do you get them so often?

The goal of the ELN is to contain exactly the same versions of the
packages which were built for Rawhide.

To achieve that goal we have automation, which rebuilds Rawhide
packages for the ELN buildroot. This automation is triggered when a
new package is tagged to f33 koji tag.
Thus ideally you would get just one eln-related message per package update.

Now, as Fedora Mass Rebuild happened over the weekend, there was a
mass retagging event, which automation couldn't process at once. And
we got the backlog of 3500 packages, which we need to rebuild for eln.

To not overload koji, rather than sending all of these packages to be
built at once, we added a background process, which regularly chooses
some random packages from the backlog and sends it to koji.

With this helper script in three days we managed to reduce the backlog
to 190 packages, and then, with some additional filtering, to 40. So
now we have about 40 packages and the script which chooses random
packages from the list hits you package again and again. Sorry for
that.

3) What can you do about it?

Option 1: do nothing.
Since the majority of builds is now processed, with only real failures
left, we will disable the periodic script and will only keep the
rebuild pipeline triggered on new package updates.
You are going to get messages about ELN builds occasionally, but not as often.

Option 2: configure filters in Fedora Notification App so you are not
notified about builds done for 'eln' tag or by this particular user.
Note: we are going to get a proper user for CI automation (something
like `fedora-ci-bot`)[4] so you might need to adjust the filter later.

Option 3: Join the ELN effort :)

For more info on ELN I recommend to check the talk by Stephen
Gallagher at Fedora Nest this Sunday [5].

> FWIW - It seems to fail because of missing deps:
>
> DEBUG util.py:621:  No matching package to install: 'cmake(Qt5)'
> DEBUG util.py:621:  No matching package to install: 'cmake(Qt5X11Extras)'
>

Thanks for looking at it.

Afaik we have qt5-5.14.2-4.eln103 in the eln buildroot, so it is not
clear for me why this dependency resolution fails, but we will look
into it.

> Thanks,
>
>Orion

[1] https://fedoraproject.org/wiki/SIGs/ELN
[2] https://fedoraproject.org/wiki/SIGs/CI
[3] https://apps.fedoraproject.org/notifications
[4] https://pagure.io/releng/issue/9619
[5] https://hopin.to/events/nest-with-fedora#schedule

>  Forwarded Message 
> Subject: bpeck/jenkins-continuous-infra.apps.ci.centos.org's
> vtk-8.2.0-18.eln103 failed to build
> Date: Wed,  5 Aug 2020 19:17:12 + (GMT)
> From: notificati...@fedoraproject.org
> To: or...@fedoraproject.org
>
> Notification time stamped 2020-08-05 19:14:23 UTC
>
> bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-18.eln103
> failed to build
> http://koji.fedoraproject.org/koji/buildinfo?buildID=1546696
>
> --
> Orion Poplawski
> Manager of NWRA Technical Systems  720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar on IRC
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:

Re: Can we use emulation of other architectures to run integration tests?

2020-07-30 Thread Aleksandra Fedorova

Hi, Nikos,

On Thu, Jul 30, 2020 at 1:48 PM Nikos Mavrogiannopoulos  wrote:
>
> On Thu, Jul 30, 2020 at 12:25 PM Aleksandra Fedorova  
> wrote:
> >
> > Hi, all,
> >
> > I'd like to get some understanding on the current state of emulation
> > of other architectures.
> >
> > In the current CI infra we have infinite(*) access to x86_64 compute
> > resources, but we haven't yet got our hands on any non x86_64
> > hardware.
> >
> > As COPR has recently got support for s390 builds, the question is: if
> > emulation is good enough for building packages, can we use it for
> > testing? What are the limitations there? Is it worth it?
>
> Few years ago we transformed the gnutls' upstream CI from baremetal
> h/w to qemu-user [0] (reasoning was pretty much what you mention, we
> had x86-64 systems for free, and we had to pay for everything else).
> This eliminated the need for such dedicated hardware, and in practice
> the years it was in use I believe it eliminated issues in
> compatibility with non-x86-64 architectures  and also helped catch
> problems in new code (such as alignment issues). For an upstream test
> suite it was totally worth it, and I believe it eliminated all issues
> we were getting with non-x86 hardware support. The only drawback that
> was noticed is that it could not be used to test some special features
> of these CPUs, but that's also a problem with dedicated hardware
> (e.g., when it doesn't support the particular instruction set you'd
> like to introduce).

Thanks for the example.

If I understand correctly in the emulated environment you run _build_
of the gnutls. Do you also run any arch-specific integration tests?

Basically I am trying to find value we could bring on top of the
existing s390x-scratch builds, which are already done by Koji.

> regards,
> Nikos
>
> [0]. https://gitlab.com/gnutls/gnutls/-/blob/master/.gitlab-ci.yml#L718
> ___
> CI mailing list -- c...@lists.fedoraproject.org
> To unsubscribe send an email to ci-le...@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/c...@lists.fedoraproject.org

--
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Can we use emulation of other architectures to run integration tests?

2020-07-30 Thread Aleksandra Fedorova

Hi, Rich,

On Thu, Jul 30, 2020 at 1:10 PM Richard W.M. Jones  wrote:
>
> On Thu, Jul 30, 2020 at 12:24:19PM +0200, Aleksandra Fedorova wrote:
> > Hi, all,
> >
> > I'd like to get some understanding on the current state of emulation
> > of other architectures.
> >
> > In the current CI infra we have infinite(*) access to x86_64 compute
> > resources, but we haven't yet got our hands on any non x86_64
> > hardware.
> >
> > As COPR has recently got support for s390 builds, the question is: if
> > emulation is good enough for building packages, can we use it for
> > testing? What are the limitations there? Is it worth it?
> >
> > If yes, can you suggest some links, tips on the topic?
>
> To be clear, are we talking qemu-system-X, qemu-user, or something
> else entirely?  Are you planning to do the tests in a full VM (eg. in
> qemu-system-X)?

Thank you for the question. I think I am actually interested in both.

The scenario we use for current x86 dist-git tests is based on vms: we
spin up a full vm with qemu-kvm, ssh inside it, install a package and
run the test script.
Should it be possible to do the same with qemu-system-s390x? Maybe
even with nested virtualization, with s390x inside x86?

> Rich.
>
> >
> > (*) Not really, and some of our infra services are not yet good at
> > scaling up, but we are getting better at it.
> >
> > --
> > Aleksandra Fedorova
> > bookwar
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Can we use emulation of other architectures to run integration tests?

2020-07-30 Thread Aleksandra Fedorova

Hi, all,

I'd like to get some understanding on the current state of emulation
of other architectures.

In the current CI infra we have infinite(*) access to x86_64 compute
resources, but we haven't yet got our hands on any non x86_64
hardware.

As COPR has recently got support for s390 builds, the question is: if
emulation is good enough for building packages, can we use it for
testing? What are the limitations there? Is it worth it?

If yes, can you suggest some links, tips on the topic?


(*) Not really, and some of our infra services are not yet good at
scaling up, but we are getting better at it.

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: fedpkg fork broken?

2020-05-22 Thread Aleksandra Fedorova

On Mon, 18 May 2020, 14:18 Richard Shaw,  wrote:

> I'm trying this for the first time (hadn't even noticed it was there!).
> I've been using the src.fp.o github style forking from the web.
>
> I cloned a random project of mine and then tried:
> $ fedpkg fork
> Could not execute do_distgit_fork: The following error occurred while
> creating a new fork: Invalid or expired token. Please visit
> https://src.fedoraproject.org/settings#nav-api-tab to get or renew your
> API token.
> For invalid or expired token refer to "fedpkg fork -h" to set a token in
> your user configuration.
>
> I checked src.fp.o/settings and even though my key was still valid, it was
> going to expire this month so I went ahead and generated a new api token
> and saved it in the specified location:
> ~/.config/rpkg/fedpkg.conf
>
> But I still get the same message 10 minutes later.
>

I've got the same problem. I think it uses wrong remote path:

a...@pkgs.fedoraproject.org

Maybe it was working before, but then certain update happened.

If you check clone options in UI in Pagure interface, the url will look
like:

ssh://book...@pkgs.fedoraproject.org/forks/bookwar/rpms/minetest.git

There is no variant with "any".

The API token is valid and works, as the fork is created. It is only the
remote path which is broken.

So I ended up calling git remote explicitly after the fork command to
change the remote uri.

And I think forking your own repo for pull-requests makes perfect sense,
especially since distgit doesn't allow you to remove temporary branches
from the main repo.

--
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: FreeCAD dist-git check, WAS:Re: Aggressive updating (Python 3.9): Are we trying to hard?

2020-05-22 Thread Aleksandra Fedorova

Hi, Nico,

On Fri, May 22, 2020 at 2:38 PM Nico Kadel-Garcia  wrote:
>
> On Thu, May 21, 2020 at 1:04 PM Richard Shaw  wrote:
> >
> > On Thu, May 21, 2020 at 11:56 AM Aleksandra Fedorova  
> > wrote:
> >>
> >> On Thu, May 21, 2020 at 6:30 PM Richard Shaw  wrote:
> >> >
> >> > On Thu, May 21, 2020 at 10:37 AM Przemo Firszt  wrote:
> >> >>
> >> >> "FreeCAD -t 0" performs approx 470 tests. No GUI required. Example
> >> >> output starts here:
> >> >> https://travis-ci.org/github/FreeCAD/FreeCAD/jobs/689681966#L9103
> >> >
> >> >
> >> > May need some work to get working from inside mock:
> >> >
> >> > # ./FreeCAD -t 0
> >> > FreeCAD 0.18, Libs: 0.18RUnknown
> >> > © Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2019
> >> >   #   ###   
> >> >   ##  # #   #   #
> >> >   # ##     # #   #  #   #
> >> >     # # #  # #  #  # #  #   #
> >> >   # #      ## # #   #
> >> >   # #   ## ## # #   #  ##  ##  ##
> >> >   # #       ### # #    ##  ##  ##
> >> >
> >> > Aborted (core dumped)
> >>
> >> Please don't run it inside mock.
>
> Mock testing is extremely useful for testing in a completely defined
> environment, for standalone laptop environments with no active
> network, and also for testing docker and small VM compatibility. If
> tests need to be segregated for entirely local, or isolated testing,
> then perhaps the tests can be segregated with some "local" option?
>
> Since a mistyped "%build" step can do "rm -rf /" as the build user,
> it's just a lot safer for everyonr in the build environments to use
> the mock or other chroot cages or docker images.

I used the wrong term here. Running tests in a mock environment is ok,
if it fits the use case.

What I tried to highlight was running tests as a part of the %check
section of the RPM spec file. This means running tests in a very
specific mock environment of the koji builder during the build of the
binary rpm.

The downsides of this approach are:

1) you don't test the installed package, you test a binary you have just built
You can not check this way that configuration files for that binary
are put into the right places

2) this environment is "dirty" as it has all build files in the
working directory and environment has all build requirements installed
These build files are not going to be packaged and won't appear on the
target environment, but they could cause side effects on the test run.

3) it couples testing with builds.
You can not test package you already have. You can not retrigger test
with the same package if the test failure was caused by infra issue or
the issue with the dependency. You can not reuse test from one package
to test the compose or another package.

4) it creates load on koji builders
When we run integration tests via Fedora CI we use cloud
infrastructure outside of Koji. We can run heavier tests and retrigger
them as much as needed.

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: FreeCAD dist-git check, WAS:Re: Aggressive updating (Python 3.9): Are we trying to hard?

2020-05-22 Thread Aleksandra Fedorova

Hi, Petr,

On Fri, May 22, 2020 at 9:29 AM Petr Pisar  wrote:
>
> On Thu, May 21, 2020 at 07:29:35PM +0200, Aleksandra Fedorova wrote:
> > On Thu, May 21, 2020 at 7:04 PM Richard Shaw  wrote:
> > >
> > > On Thu, May 21, 2020 at 11:56 AM Aleksandra Fedorova  
> > > wrote:
> > >>
> > >> To run the command above as the integration test you need to put
> > >> tests/tests.yml file in dist-git repo with the following content:
> > >>
> > >> - hosts: localhost
> > >>   roles:
> > >>   - role: standard-test-basic
> > >> tags:
> > >> - classic
> > >> tests:
> > >> - simple:
> > >> dir: .
> > >> run: "FreeCAD -t 0"
> > >>
> > >> Note how here you will be using the install FreeCAD binary, not the 
> > >> local one.
> > >
> > >
> > > Is this only run on "real" builds, or is it possible to run locally or 
> > > for scratch builds?
> >
> > We run it for pull-requests and for "real builds.
> >
> > It runs in the following way:
> >
> > 1) we take latest Fedora Rawhide qcow image,
> > 2) we run virtual machine via qemu-kvm from it,
> > 3) inside the vm we install the package,
> > 4) we run the command defined by "run" key in that YAML file.
> >
> > And it is all orchestrated by Ansible.
> >
> > It is possible to reproduce the test locally with all the CI wrappers
> > around it, but I wouldn't recommend it. To debug the test I would just
> > run the VM with the same Rawhide image [1], install the package and
> > run the test command manually.
>
> I'd like to point out that there is a difference in the enviroments between
> these two approaches.
>
> While the manual procedure only installs a binary package (and its
> dependencies), the OSCI procedure installs all binary packages produced by the
> source package (and their depenencies).

You are right here. Jenkins pipeline tries to install all packages
from the koji build before running the test.

And this approach has already hit us many times: there are packages
where binary subpackages conflict with each other (as in curl), or
where different tests require different subpackages to be installed.
There is also a case for reverse dependency check, where we would like
to run test suite from a package A to test the package B, where the
koji build we are installing is different from what is expected by the
test.

In Fedora CI SIG we are discussing if we should just disable this
functionality and make it mandatory to specify all packages explicitly
in the tests.yml under "required_packages" tag, as in [1]

The downside is:
 you would need to maintain list of required packages in the tests.yml

We haven't brought this topic to a wider audience yet, but we should.

> In case of freecad, it does not matter, because the freecad component has only
> one binary package. But in general it's not true.
>
> And here I'd like to ask Aleksandra whether the same applies to modules or
> not. In general case, a module build produces two binary modules - a non-devel
> module and a devel module. Does OSCI install components from both of them? 
> And does
> it install the components explicitly, or does it rather install a default
> profile of the module ("dnf module install" command)?

We don't have test for modules yet in Fedora CI. So I would say the
question here is:

how do you like it to work?

We can do "dnf module install" but then the same issues would appear:
if you need additional flexibility to test parts of the module, you
would need to revert this default behavior somehow.
Or we can do nothing and only provide environment with repositories
with the updates. So that configuration of the environment is done in
the test metadata.

[1] 
https://docs.fedoraproject.org/en-US/ci/how-to-add-dist-git-test/#_tests_in_a_subpackage


-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: FreeCAD dist-git check, WAS:Re: Aggressive updating (Python 3.9): Are we trying to hard?

2020-05-21 Thread Aleksandra Fedorova

On Thu, May 21, 2020 at 7:04 PM Richard Shaw  wrote:
>
> On Thu, May 21, 2020 at 11:56 AM Aleksandra Fedorova  
> wrote:
>>
>> On Thu, May 21, 2020 at 6:30 PM Richard Shaw  wrote:
>> >
>> > On Thu, May 21, 2020 at 10:37 AM Przemo Firszt  wrote:
>> >>
>> >> "FreeCAD -t 0" performs approx 470 tests. No GUI required. Example
>> >> output starts here:
>> >> https://travis-ci.org/github/FreeCAD/FreeCAD/jobs/689681966#L9103
>> >
>> >
>> > May need some work to get working from inside mock:
>> >
>> > # ./FreeCAD -t 0
>> > FreeCAD 0.18, Libs: 0.18RUnknown
>> > © Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2019
>> >   #   ###   
>> >   ##  # #   #   #
>> >   # ##     # #   #  #   #
>> >     # # #  # #  #  # #  #   #
>> >   # #      ## # #   #
>> >   # #   ## ## # #   #  ##  ##  ##
>> >   # #       ### # #    ##  ##  ##
>> >
>> > Aborted (core dumped)
>>
>> Please don't run it inside mock.
>>
>> RPM %check tests are good for unit testing, but they should тще be
>> used for extensive integration test suites.
>> The build environment is very different from the target user system.
>> It has build requirements installed it may have side effects on the
>> test you run.
>> Also you would be testing the binary in you working directory, where
>> you have just executed `make` command.
>>
>> To run tests in the environment which resembles the actual user
>> environment we have the STR framework and gating infrastructure [1].
>>
>> To run the command above as the integration test you need to put
>> tests/tests.yml file in dist-git repo with the following content:
>>
>> - hosts: localhost
>>   roles:
>>   - role: standard-test-basic
>> tags:
>> - classic
>> tests:
>> - simple:
>> dir: .
>> run: "FreeCAD -t 0"
>>
>> Note how here you will be using the install FreeCAD binary, not the local 
>> one.
>
>
> Is this only run on "real" builds, or is it possible to run locally or for 
> scratch builds?

We run it for pull-requests and for "real builds.

It runs in the following way:

1) we take latest Fedora Rawhide qcow image,
2) we run virtual machine via qemu-kvm from it,
3) inside the vm we install the package,
4) we run the command defined by "run" key in that YAML file.

And it is all orchestrated by Ansible.

It is possible to reproduce the test locally with all the CI wrappers
around it, but I wouldn't recommend it. To debug the test I would just
run the VM with the same Rawhide image [1], install the package and
run the test command manually.
The exact command we use to run qemu can be seen in default_provisioners.log [2]

Now, as soon as you figure out the test itself and you know that it is
working, you can verify that it works when wrapped in CI
orchestration.
You can do that by submitting pull-request with this test
configuration via src.fedoraproject.org.

On pull request we do additional step: we take the patch from the pull
request and submit the scratch build to Koji.
Once scratch build is done, we run the test as described above.

The test result is then published on the pull request page under the
name Fedora CI.
See the right side labels on the example page [3]

[1] 
https://jenkins-continuous-infra.apps.ci.centos.org/job/fedora-rawhide-image-test/lastSuccessfulBuild/artifact/Fedora-Rawhide.qcow2
[2] 
https://jenkins-continuous-infra.apps.ci.centos.org/job/fedora-rawhide-pr-pipeline/3623/artifact/nvr-verify/logs/default_provisioners.log
[3] https://src.fedoraproject.org/rpms/libdnf-plugin-swidtags/pull-request/5

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Aggressive updating (Python 3.9): Are we trying to hard?

2020-05-21 Thread Aleksandra Fedorova

On Thu, May 21, 2020 at 6:30 PM Richard Shaw  wrote:
>
> On Thu, May 21, 2020 at 10:37 AM Przemo Firszt  wrote:
>>
>> "FreeCAD -t 0" performs approx 470 tests. No GUI required. Example
>> output starts here:
>> https://travis-ci.org/github/FreeCAD/FreeCAD/jobs/689681966#L9103
>
>
> May need some work to get working from inside mock:
>
> # ./FreeCAD -t 0
> FreeCAD 0.18, Libs: 0.18RUnknown
> © Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2019
>   #   ###   
>   ##  # #   #   #
>   # ##     # #   #  #   #
>     # # #  # #  #  # #  #   #
>   # #      ## # #   #
>   # #   ## ## # #   #  ##  ##  ##
>   # #       ### # #    ##  ##  ##
>
> Aborted (core dumped)

Please don't run it inside mock.

RPM %check tests are good for unit testing, but they should тще be
used for extensive integration test suites.
The build environment is very different from the target user system.
It has build requirements installed it may have side effects on the
test you run.
Also you would be testing the binary in you working directory, where
you have just executed `make` command.

To run tests in the environment which resembles the actual user
environment we have the STR framework and gating infrastructure [1].

To run the command above as the integration test you need to put
tests/tests.yml file in dist-git repo with the following content:

- hosts: localhost
  roles:
  - role: standard-test-basic
tags:
- classic
tests:
- simple:
dir: .
run: "FreeCAD -t 0"

Note how here you will be using the install FreeCAD binary, not the local one.

[1] https://docs.fedoraproject.org/en-US/ci/how-to-add-dist-git-test/

>
>
> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

[CI][gating.yaml] Test names starting with org.centos.prod.ci.pipeline.. are deprecated

2020-05-21 Thread Aleksandra Fedorova

Hi, all,

if you use gating.yaml to configure gating[1], please be aware that
test names staring with "org.centos.prod.ci.pipeline" are now
deprecated.

New name for the dist-git test is
fedora-ci.koji-build.tier0.functional.

We plan to switch off sending messages for old test names on Tuesday,
May 26 2020.

See [2] for details

Open pull-requests to affected projects:

buildah https://src.fedoraproject.org/rpms/buildah/pull-request/10
clang https://src.fedoraproject.org/rpms/clang/pull-request/68
clang9.0 https://src.fedoraproject.org/rpms/clang9.0/pull-request/1
conmon https://src.fedoraproject.org/rpms/conmon/pull-request/2
container-selinux
https://src.fedoraproject.org/rpms/container-selinux/pull-request/4
dnsmasq https://src.fedoraproject.org/rpms/dnsmasq/pull-request/4
libdnf-plugin-swidtags
https://src.fedoraproject.org/rpms/libdnf-plugin-swidtags/pull-request/5
libkcapi https://src.fedoraproject.org/rpms/libkcapi/pull-request/17
libomp https://src.fedoraproject.org/rpms/libomp/pull-request/20
lld https://src.fedoraproject.org/rpms/lld/pull-request/24
llvm https://src.fedoraproject.org/rpms/llvm/pull-request/51
llvm-test-suite
https://src.fedoraproject.org/rpms/llvm-test-suite/pull-request/20
llvm9.0 https://src.fedoraproject.org/rpms/llvm9.0/pull-request/2
podman https://src.fedoraproject.org/rpms/podman/pull-request/31
python-ansi2html
https://src.fedoraproject.org/rpms/python-ansi2html/pull-request/2
skopeo https://src.fedoraproject.org/rpms/skopeo/pull-request/8
swid-tools https://src.fedoraproject.org/rpms/swid-tools/pull-request/3

[1] https://docs.fedoraproject.org/en-US/ci/gating/
[2] https://pagure.io/fedora-ci/general/issue/110

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Getting deprecation warning about hawkey.Repo class

2020-05-20 Thread Aleksandra Fedorova

Hi, all,

I am looking for some background and info on this deprecation warning:

/usr/lib64/python3.8/site-packages/hawkey/__init__.py:348:
DeprecationWarning: The class hawkey.Repo is deprecated. Please use
dnf.repo.Repo instead. The class will be removed on 2019-12-31.

I have found this mail [1] from 18 March 2019. It says in Fedora 32
hawkey subpackages will be removed from libdnf. But we have rpmdeplint
running on Fedora 32, which gets this message, see [2].

Koschei service also seems to have the same issue [3]

What is the latest status of this? Has the deprecation happened? Is it
still planned? Are there any tips for tool maintainers, how to deal
with it?


[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/P2YXWI77MDX6QZ5H35JZ7ZLRTFZBC5EH/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1832171
[3] https://github.com/fedora-infra/koschei/issues/292


-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Aggressive updating (Python 3.9): Are we trying to hard?

2020-05-19 Thread Aleksandra Fedorova

On Tue, 19 May 2020, 18:10 Adam Williamson, 
wrote:

> On Tue, 2020-05-19 at 10:43 -0500, Richard Shaw wrote:
> > On Tue, May 19, 2020 at 10:31 AM Adam Williamson <
> adamw...@fedoraproject.org>
> > wrote:
> >
> > > On Tue, 2020-05-19 at 08:49 -0500, Richard Shaw wrote:
> > > > I think here we need better ways of testing software in Rawhide other
> > > than
> > > > well, running Rawhide (VM or bare metal), besides the old mock chroot
> > > xnest
> > > > hack. I'm open to suggestion here.
> > >
> > > https://docs.fedoraproject.org/en-US/ci/ ?
> > >
> >
> > Ok, so obviously CI can be very helpful, but is part of the expectation
> for
> > all packagers to learn how to set this up?
>
> If by "set this up" you mean "what to put in place to run some specific
> test(s) on your package", yes. That's what the docs are for.
>

I would suggest to start with
https://docs.fedoraproject.org/en-US/ci/how-to-add-dist-git-test/

As it describes the most simple way to start testing.

With more complex test setup you can reach out to Fedora CI SIG, for
example, via issue at
https://pagure.io/fedora-ci/general


> We're currently working on implementing what we call "generic" testing
> in Fedora CI - that is, tests that automatically run on every package,
> the way Taskotron used to do it, as opposed to tests being associated
> with packages, the way Fedora CI initially expected - but that doesn't
> seem like the desire here.
>
> >  It's non-trivial unless it's
> > something you already know how to do, and in this case we didn't know
> there
> > was a problem until an end user ran FreeCAD with the update and noticed
> the
> > crash...
>
> Well sure, but now you know it's a thing that *can* go wrong, so you
> want to test it in future. I'm not saying you should have done it
> already, just that now you know it needs testing, that's one way to go
> about it...though if you need to do graphical testing Fedora CI is
> probably not the way...
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: ELN Reasons (was Re: Proposal: Revise FESCo voting policy)

2020-05-13 Thread Aleksandra Fedorova

e
> Fedora's. No other Red Hat project has formal structures to allow the
> community to have as strong of a voice as it does. A lot of Red Hat
> projects are in fact set up the *opposite* way: there is no way for
> the community to have a strong influence without getting a Red Hat
> employee to be on their side. It's quite interesting, because if you
> look at projects like Kubernetes that are very successful, they are
> structured very similarly to how Fedora is. Many of the concepts and
> governance structures are extremely similar to how the Fedora Project
> works. The difference between Fedora and Kubernetes is that Fedora
> doesn't have people paid to advocate for the community and encourage
> folks to participate in it.

Nitpicking here, as less than two years old RedHatter and more than 10
years old Fedora contributor, I am actively against separating Red
Hatters who contribute to Fedora from the rest of Fedora community.
And some of the Red Hatters I know are the most fierce Fedora
advocates you can ask for.

(I am not that fierce yet, but sometimes I am trying)

> When *I* look at Fedora, I see something special: a community with
> massively unrealized potential. We're a huge passionate group of folks
> that try to work diligently and amicably with the communities that
> make the projects that the Fedora Linux distribution ships. We are
> also often the drivers of innovation. In many cases, this is obvious
> (UsrMerge, systemd, PipeWire, Wayland, EarlyOOM, etc.). In some cases,
> it's not (Koji, fedmsg, HyperKitty, Pagure, Dist-Git, Ansible,
> AppStream, RPM-OSTree, etc.). And a great deal of this is driven by
> people in the community who *aren't* from Red Hat!
>
> But a lot of people don't see it this way, and many of us bristle when
> they bring up the RHEL point. Just look at Phoronix, Reddit, or any
> other place, and you'll see the comments about people being "free
> labor" or "free QA" for Red Hat. This is an unfair characterization
> that speaks to a deep misunderstanding of how this relationship is
> supposed to work.
> And it goes both ways: both Fedorans and Red Hatters
> misunderstand this and mischaracterize it in ways that are
> counterproductive.

Indeed, as Fedora Ambassador I see this happening a lot in various
communities, usually already hostile by some other reasons. Over the
years I learned to accept the fact that Fedora is indeed balancing on
this edge, all the time.
It is hard and it is complicated, but we are doing it for quite some
time already. With some downsides and upsides, we keep moving.

This balancing act on one hand causes frustration, but on the other -
it is something which feeds our evolution as a project. If you don't
have the downstream, you don't have a use case, which could bring you
down to earth and to real world tasks, and you don't have resources to
make something big. If you don't have upstream and community, no one
challenges your decisions, and no one forces you or teaches you to
prove yourself, again and again.


But I am quite disappointed that we are discussing this under the ELN
topic. As it was designed exactly to not allow this attitude to grow.
It is maybe us not explaining it better, or maybe some generic
historical baggage, which we carry, played the role. But honestly, it
is just sad.

For me one of the main achievements (I should probably say challenges,
as we haven't achieved it yet), or better, one of the _defining_
properties of the ELN effort is that we keep Fedora Project and Fedora
maintainers in charge of the whole thing.
This is what we were fighting for, internally and externally.

So rather than just creating some place where RHEL engineers can share
their code to public (which would be so much easier to do), we create
an incentive for RHEL engineers to come to Fedora Project and Fedora
community, bringing their work, their expertise and their resources,
and putting it into Fedora development under Fedora guidelines.

And while it may bring additional conversation topics to non-RedHat
Fedora community members, it is actually a much larger challenge for
RHEL developers. And people who commit to it, who try to bring
something useful to Fedora, who find time to make it work in between
of all of their downstream activities, they deserve the respect for
what they are doing. They _are_ the Open Source developers, and they
are Fedora community too.

> So I guess, in the end, what I want to see is RHEL becoming more like
> Fedora: more participatory and better able to respond to the needs of
> the community as well as Red Hat's customers. To me, I think ELN, when
> done right, can do just that.

I agree with this goal.

And, yes, I would love to be called out on specific things, which we
are not doing right, and hear suggestions on how we can make it
better.

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Proposal: Revise FESCo voting policy

2020-05-13 Thread Aleksandra Fedorova

On Wed, May 13, 2020 at 2:46 PM Vít Ondruch  wrote:
>
>
> Dne 12. 05. 20 v 14:22 Aleksandra Fedorova napsal(a):
> > Hi,
> >
> > On Tue, May 12, 2020 at 10:19 AM Vít Ondruch  wrote:
> >>
> >> Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
> >>> Hi,
> >>>
> >>> On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher  
> >>> wrote:
> >>>> During today's FESCo meeting, we encountered an unusual voting
> >>>> situation for the first time: Four FESCo members voted in favor (+1)
> >>>> of a measure and five FESCo members opted to abstain (0) for various
> >>>> reasons. However, the FESCo voting policy currently reads: "A majority
> >>>> of the committee (that is, five out of nine) is required to pass a
> >>>> proposal in a meeting." As a result, we were actually at an impasse
> >>>> until two of the FESCo members opted to change their votes to +1 to
> >>>> resolve the confusion.
> >>>>
> >>>> It was subsequently suggested that we revise the policy to avoid this
> >>>> pitfall in the future. I volunteered to put together a proposal for
> >>>> how this could work and send it to the Fedora Development list for
> >>>> discussion. I propose the following changes to the FESCo voting
> >>>> policy:
> >>>>
> >>>> * To pass any measure, a majority — defined as the greater of half the
> >>>> eligible votes (rounded up) — must vote in favor of the measure. The
> >>>> standard set of eligible votes is one vote per FESCo member. No
> >>>> measure may pass without at least one vote in favor.
> >>>>
> >>>> * Abstaining from a vote (aka "voting 0") is considered to have
> >>>> removed that FESCo member's vote from the set of eligible votes. This
> >>>> must be done explicitly and is never to be assumed from lack of
> >>>> communication.
> >>>>
> >>>> A practical effect of the new abstention rule is that if two FESCo
> >>>> members abstain, the measure would then require only a +4 vote to
> >>>> pass. (A single abstention would still require a +5 vote).
> >>> I don't like this idea.
> >>>
> >>> I think if FESCo members don't have enough data or understanding to
> >>> vote on the topic, this means that FESCo needs to put more effort in
> >>> it.
> >>>
> >>> Find some subject matter experts in the community, make additional
> >>> steps to learn the subject.
> >>> Or, when topic has no technical foundation but more of the personal
> >>> preference, bring it for a full community vote.
> >>>
> >>> In the end FESCo supposed to channel the community voice.
> >>> If FESCo can not make a decision, it means delegation of the decision
> >>> to FESCo by community failed. So let's go back to community?
> >>>
> >>> So how about the alternative:
> >>> if FESCo can't come up with the decision, it announces the stalled
> >>> decision to fedora-announce and requests help. Better summary, more
> >>> arguments, etc..
> >>>
> >>> This would encourage people who are against the change to participate.
> >>
> >> I agree with Aleksandra up until here.
> >>
> >>
> >>> And if there are no such people to provide convincing arguments
> >>> against the change in a reasonable time frame, than FESCo decides in
> >>> favor of the submitter.
> >>
> >> I disagree here. If such proposal does not have enough support, then it
> >> should not be accepted and should be revisited/abandoned/rejected. I
> >> cannot imagine any even hypothetical situation where the opposite was
> >> beneficial.
> > The proposal has at least support of its owners, who stepped in and
> > spent some time describing the idea.
> >
> > If there are no convincing reasons against this proposal, then it is
> > their opinion, which matters. They have an idea, and they are willing
> > to do the job and take the responsibility.
> > I don't see the reason to block it then.
>
>
> When the change process was established, I always proposed that the
> change should be always pre-approved by default. The changes would be
> judged by the amount of feedback received on ML after their
> announcement. If somebody had strong concerns, it would be possible to
> b

Re: Proposal: Revise FESCo voting policy

2020-05-12 Thread Aleksandra Fedorova

Hi,

On Tue, May 12, 2020 at 10:19 AM Vít Ondruch  wrote:
>
>
> Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
> > Hi,
> >
> > On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher  
> > wrote:
> >> During today's FESCo meeting, we encountered an unusual voting
> >> situation for the first time: Four FESCo members voted in favor (+1)
> >> of a measure and five FESCo members opted to abstain (0) for various
> >> reasons. However, the FESCo voting policy currently reads: "A majority
> >> of the committee (that is, five out of nine) is required to pass a
> >> proposal in a meeting." As a result, we were actually at an impasse
> >> until two of the FESCo members opted to change their votes to +1 to
> >> resolve the confusion.
> >>
> >> It was subsequently suggested that we revise the policy to avoid this
> >> pitfall in the future. I volunteered to put together a proposal for
> >> how this could work and send it to the Fedora Development list for
> >> discussion. I propose the following changes to the FESCo voting
> >> policy:
> >>
> >> * To pass any measure, a majority — defined as the greater of half the
> >> eligible votes (rounded up) — must vote in favor of the measure. The
> >> standard set of eligible votes is one vote per FESCo member. No
> >> measure may pass without at least one vote in favor.
> >>
> >> * Abstaining from a vote (aka "voting 0") is considered to have
> >> removed that FESCo member's vote from the set of eligible votes. This
> >> must be done explicitly and is never to be assumed from lack of
> >> communication.
> >>
> >> A practical effect of the new abstention rule is that if two FESCo
> >> members abstain, the measure would then require only a +4 vote to
> >> pass. (A single abstention would still require a +5 vote).
> > I don't like this idea.
> >
> > I think if FESCo members don't have enough data or understanding to
> > vote on the topic, this means that FESCo needs to put more effort in
> > it.
> >
> > Find some subject matter experts in the community, make additional
> > steps to learn the subject.
> > Or, when topic has no technical foundation but more of the personal
> > preference, bring it for a full community vote.
> >
> > In the end FESCo supposed to channel the community voice.
> > If FESCo can not make a decision, it means delegation of the decision
> > to FESCo by community failed. So let's go back to community?
> >
> > So how about the alternative:
> > if FESCo can't come up with the decision, it announces the stalled
> > decision to fedora-announce and requests help. Better summary, more
> > arguments, etc..
> >
> > This would encourage people who are against the change to participate.
>
>
> I agree with Aleksandra up until here.
>
>
> > And if there are no such people to provide convincing arguments
> > against the change in a reasonable time frame, than FESCo decides in
> > favor of the submitter.
>
>
> I disagree here. If such proposal does not have enough support, then it
> should not be accepted and should be revisited/abandoned/rejected. I
> cannot imagine any even hypothetical situation where the opposite was
> beneficial.

The proposal has at least support of its owners, who stepped in and
spent some time describing the idea.

If there are no convincing reasons against this proposal, then it is
their opinion, which matters. They have an idea, and they are willing
to do the job and take the responsibility.
I don't see the reason to block it then.

Given that "change is out of scope of Fedora" and "support is very
limited and the risk is too high" still can be a convincing reason to
reject the change in some cases. But then it must be stated
explicitly.

> Vít
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: LibRaw 0.20 Beta; soname bump

2020-05-12 Thread Aleksandra Fedorova

On Tue, May 12, 2020 at 12:21 PM Aleksandra Fedorova  wrote:
>
> Hi,
>
> On Tue, May 12, 2020 at 12:05 PM Miro Hrončok  wrote:
> >
> > On 12. 05. 20 10:46, Daniel P. Berrangé wrote:
> > > Are we ever going to get gating on rawhide, so that soname bumps are 
> > > blocked
> > > from entering the dist until rebuilds of deps are ready ?
> >
> > We wanted to, Taskotron was able to figure this out, but was recently EOLed,
> > before a viable alternative existed in Fedora CI (it still doesn't exist).
> >
> > https://pagure.io/fesco/issue/2343
>
> Inn Fedora CI SIG we are working on the updated version of the
> rpmdeplint test, see [1].

And I forgot the links

https://teams.fedoraproject.org/project/ci/epic/68 for the pipelines
and
https://github.com/fedora-ci/rpmdeplint-pipeline for rpmdeplint
pipeline specifically.

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: LibRaw 0.20 Beta; soname bump

2020-05-12 Thread Aleksandra Fedorova

Hi,

On Tue, May 12, 2020 at 12:05 PM Miro Hrončok  wrote:
>
> On 12. 05. 20 10:46, Daniel P. Berrangé wrote:
> > Are we ever going to get gating on rawhide, so that soname bumps are blocked
> > from entering the dist until rebuilds of deps are ready ?
>
> We wanted to, Taskotron was able to figure this out, but was recently EOLed,
> before a viable alternative existed in Fedora CI (it still doesn't exist).
>
> https://pagure.io/fesco/issue/2343

Inn Fedora CI SIG we are working on the updated version of the
rpmdeplint test, see [1].
Unfortunately, this work was delayed by Community Shift cluster
migration as we need to look for a better home for the Jenkins master
now.

The current plan is to deploy a temporary Jenkins master on whatever
infrastructure we find, and start running the pipeline from there.

The rpmdeplint is the first pipeline we'd like to get running. As it
is the most simple one.

Then we have a prototype for Koschei integration, which can test
sidetag-based gating events.
And generally we would like to be able to create new pipelines from
basically any script.

I'll post an update as soon as Jenkins situation is resolved.

>
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/OXK6BKUPCOMNGWWLWL4GDQGGJIWNZCR6/
>
> > It seems we have some automated process detecting this, as I received a
> > bug report this morning warning me that entangle was broken by LibRaw
> > soname bump
>
> Those are scripts run by people who care. Possibly Igor this time.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Proposal: Revise FESCo voting policy

2020-05-11 Thread Aleksandra Fedorova

On Mon, May 11, 2020 at 11:22 PM Chris Murphy  wrote:
>
> On Mon, May 11, 2020 at 2:21 PM Gary Buhrmaster
>  wrote:
> >
> > On Mon, May 11, 2020 at 7:40 PM Chris Murphy  
> > wrote:
> >
> > > Bias is not the same thing as a conflict of interest. And it doesn't
> > > inherently result in unfairness.
> >
> > Sometimes it is a matter avoiding even the appearance
> > of impropriety that could be raised at a later date to
> > question the process/motives/decisions (which often
> > just delays the inevitable, but sometimes the delay is
> > the point).
>
> Of course voting members need to trust their instincts. I only mean to
> indicate bias is not the same thing as a conflict of interest; and
> also further that a very strong preference that's predicated on
> evidence and experience isn't even bias, certainly not in the
> prejudiced sense. Anyone who thinks their objectivity is compromised
> on some topic should recuse; and anyone who knows another's
> objectivity is compromised should feel comfortable to point this out
> and ask for recusal.
>
> > Regardless, I would suggest that along the way, if
> > FESCo does not have a set of guidelines regarding
> > if recusal on any vote is appropriate, they should consider
> > writing down whatever they decide is appropriate (or
> > just point to some other groups process if that is
> > appropriate), even if the decision is no recusal is
> > ever required, so we don't have this discussion all
> > over again in a year or two when everyone has
> > forgotten this one.
>
> It's reasonable to have clarity on the issue. I'm not an ombudsman or
> ethicist, but there is such a person or group within Red Hat who could
> answer this question. It might even be as straightforward as each
> voting member filling out a questionnaire so that their possible
> conflicts are known, and they can steer clear of such areas. But I
> think Fedora has quite a lot of compartmentalization in the
> organizational structure that just inherently avoids the problem.
>
> Anyway I came across this which is informative, even though it applies
> mainly to charities (Fedora is a non-profit so it's approximate).
> https://charitylawyerblog.com/2014/02/10/managing-conflicts-of-interest/

Sorry but this is exactly the conversation I didn't want to have.

The methods described there are needed when you don't have other ways
to resolve the described issues.
And these methods are ugly. Yes, in case you have such a problem,
there are no good ways out, so you have to do something.

Fortunately, we just don't have this problem.

We are Open Source community based on knowledge, skill and trust. Yes,
some of us found ways to get paid for the work we love to do anyways,
some of us spend free time on it, many do both. And it doesn't really
matter, because we can evaluate our decisions and argue about them.

And if I support a change, i support a change. You can scratch my name
from it and put anyone else's. If it has the same content, I am still
going to support it.
You can write your own change, but if you convince me, it becomes _my_
Change, Change in my Fedora, which I am going to defend for FESCo, or
for Fedora community, or as a Fedora Ambassador for the outside world.

So I don't want us to _solve_ conflicts of interest, I think that we
don't really have them.

And we shouldn't _bring_ them artificially either.

> --
> Chris Murphy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Proposal: Revise FESCo voting policy

2020-05-11 Thread Aleksandra Fedorova

Hi,

On Mon, May 11, 2020 at 8:06 PM Miro Hrončok  wrote:
>
> On 11. 05. 20 19:36, Zbigniew Jędrzejewski-Szmek wrote:
> > One strong argument for the proposed change is that, currently, an
> > abstention or recusal (TIL that's the proper term) is essentially
> > equivalent to a negative vote. (As long as we require +5 to pass,
> > any vote apart from +1 has the same effect.)
> >
> > In a hypothetical case where three or four FESCo members were involved
> > in a change and decided to recuse themselves, a proposal gets a very
> > high bar of 5/6 or 5/7 votes. If one or two voting members are absent,
> > the change may not even pass even if*all*  non-abstaining members are
> > in favour.
>
> If that is the only problem we are trying to solve here, I think we might very
> well create a concept of formal recusal and only lower the bar on such 
> occasion.

I'd rather ditch the idea of a recusal.

I don't really understand the reason behind it.

You are on FESCo, because community voted for you to bring some expertise.
When you participate in the change, you make use of this expertise,
and you know what this change is all about, and how community will
benefit from it.

So why would we silence you from giving us the vote on the topic, if
it is backed by your arguments and knowledge?

And if you go for a _formal_ recuse process, how far we are going to
get?  Should I stop receiving a post cards from Fedora members(not
that I've got any, but still :) ), so that they don't compromise my
decisions, when and if these members may create a Change for Fedora?

And what if I _like_ the idea of a Change and become a supporter? If I
decide to work on this Change? Does it make me affiliated now? If I
express support for it, should it be forbidden for me to vote?

I'd rather not bring these layers of political complexities into FESCo.

I believe we should be driven by the technology aspect, and your
knowledge and skills don't change based on who submits a Change, you
evaluate the change based on the content of the Change, and you should
vote for it.

> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Proposal: Revise FESCo voting policy

2020-05-11 Thread Aleksandra Fedorova

Hi,

On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher  wrote:
>
> During today's FESCo meeting, we encountered an unusual voting
> situation for the first time: Four FESCo members voted in favor (+1)
> of a measure and five FESCo members opted to abstain (0) for various
> reasons. However, the FESCo voting policy currently reads: "A majority
> of the committee (that is, five out of nine) is required to pass a
> proposal in a meeting." As a result, we were actually at an impasse
> until two of the FESCo members opted to change their votes to +1 to
> resolve the confusion.
>
> It was subsequently suggested that we revise the policy to avoid this
> pitfall in the future. I volunteered to put together a proposal for
> how this could work and send it to the Fedora Development list for
> discussion. I propose the following changes to the FESCo voting
> policy:
>
> * To pass any measure, a majority — defined as the greater of half the
> eligible votes (rounded up) — must vote in favor of the measure. The
> standard set of eligible votes is one vote per FESCo member. No
> measure may pass without at least one vote in favor.
>
> * Abstaining from a vote (aka "voting 0") is considered to have
> removed that FESCo member's vote from the set of eligible votes. This
> must be done explicitly and is never to be assumed from lack of
> communication.
>
> A practical effect of the new abstention rule is that if two FESCo
> members abstain, the measure would then require only a +4 vote to
> pass. (A single abstention would still require a +5 vote).

I don't like this idea.

I think if FESCo members don't have enough data or understanding to
vote on the topic, this means that FESCo needs to put more effort in
it.

Find some subject matter experts in the community, make additional
steps to learn the subject.
Or, when topic has no technical foundation but more of the personal
preference, bring it for a full community vote.

In the end FESCo supposed to channel the community voice.
If FESCo can not make a decision, it means delegation of the decision
to FESCo by community failed. So let's go back to community?

So how about the alternative:
if FESCo can't come up with the decision, it announces the stalled
decision to fedora-announce and requests help. Better summary, more
arguments, etc..

This would encourage people who are against the change to participate.
And if there are no such people to provide convincing arguments
against the change in a reasonable time frame, than FESCo decides in
favor of the submitter.

>
> I'd also like to propose an additional policy modification that
> occurred to me while writing this message:
>
> * A FESCo member may grant their proxy vote to another member of the
> Fedora community if they cannot be in attendance for a vote. If they
> do so, that vote is counted equivalently to any other. Proxy votes
> MUST be limited to predetermined topics and time period. (e.g. I can
> say "bookwar has my proxy vote on any topic directly related to ELN"
> while I am on vacation from MMDD until MMDD, but I cannot give my
> FESCo seat to a person of my choosing.)

I think this might be ok-ish in the example of ELN conversations as we
both are owners of the change and work on it. But in a slightly
different situation, on a generic topic, I would prefer if people
announce their vacation, and then FESCo will wait for a vote from the
person if it can change the outcome.

If someone goes on PTO for more than three weeks, that's a different
story, but your approach won't work in this case either, as you won't
be able to learn in advance which exact topics you need to delegate.

So -1 here as well.

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Summary/Minutes from today's FESCo Meeting (2020-04-27)

2020-04-27 Thread Aleksandra Fedorova


#fedora-meeting-1: fesco



Meeting started by bookwar at 15:00:30 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-04-27/fesco.2020-04-27-15.00.log.html




Meeting summary
---
* init process  (bookwar, 15:00:54)

* #2372 F33 Self-contained Change: Network Time Security  (bookwar,
  15:02:34)
  * AGREED: postpone discussion until TBD items are resolved (+8, 0, 0)
(bookwar, 15:06:52)

* #2382 systemd default service exception for rpmdb-rebuild service
  (bookwar, 15:07:39)
  * ACTION: sgallagh to update the ticket with the new proposed approach
and try to help test it  (sgallagh, 15:17:01)

* #2371 F33 System-Wide Change: Removal of the glibc-headers package
  (bookwar, 15:17:52)
  * AGREED: APPROVED (+6, 2, 0)  (bookwar, 15:23:48)

* Next week's chair  (bookwar, 15:24:08)
  * ACTION: decathorpe to chair next one  (bookwar, 15:25:29)

* Open floor  (bookwar, 15:25:43)
  * Issue #2383: fesco statement on the dist-git change process
(bookwar, 15:57:02)

Meeting ended at 15:57:43 UTC.




Action Items

* sgallagh to update the ticket with the new proposed approach and try
  to help test it
* decathorpe to chair next one




Action Items, by person
---
* decathorpe
  * decathorpe to chair next one
* sgallagh
  * sgallagh to update the ticket with the new proposed approach and try
to help test it
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* bookwar (70)
* zbyszek (45)
* sgallagh (27)
* nirik (24)
* zodbot (19)
* adamw (13)
* mhroncok (6)
* bcotton (5)
* decathorpe (5)
* dcantrell (4)
* contyk (4)
* ignatenkobrain (0)


-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Schedule for Mondays's FESCo Meeting (2020-04-27)

2020-04-27 Thread Aleksandra Fedorova

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2020-04-27 15:00 UTC'

Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

Update libgit2 from 0.99.0 to 1.0.0 in F32 (post-release)
https://pagure.io/fesco/issue/2377
APPROVED (+3, 0, -0)

F33 System-Wide Change: Perl 5.32
https://pagure.io/fesco/issue/2376
APPROVED  (+6, 0, -0)

Remove appstream-data from automatic blockers
https://pagure.io/fesco/issue/2374
APPROVED  (+7, 0, -0)

F33 System-Wide Change: OpenSSL3.0
https://pagure.io/fesco/issue/2373
APPROVED (+7, 0, -0)


= Followups =

#topic #2372 F33 Self-contained Change: Network Time Security
https://pagure.io/fesco/issue/2372

= New business =

#topic #2382 systemd default service exception for rpmdb-rebuild service
https://pagure.io/fesco/issue/2382

#topic #2371 F33 System-Wide Change: Removal of the glibc-headers package
https://pagure.io/fesco/issue/2371

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

2020-04-08 Thread Aleksandra Fedorova

On Mon, 6 Apr 2020, 21:26 clime,  wrote:

> On Mon, 6 Apr 2020 at 17:52, Leigh Griffin  wrote:
> >
> >
> >
> > On Mon, Apr 6, 2020 at 4:25 PM Adam Williamson <
> adamw...@fedoraproject.org> wrote:
> >>
> >> On Mon, 2020-04-06 at 15:35 +0100, Leigh Griffin wrote:
> >> >
> >> > > Does it mean you didn't consider dist-git<->zuul integration vs.
> Gitlab
> >> > > CI? I.e. technical differences and advantages of each? If you did,
> can you,
> >> > > please, publish it? It would be valuable info for the community and
> >> > > something we can comment on.
> >> > >
> >> >
> >> > Gitlab CI was not part of our evaluation, we are aware it's a service
> that
> >> > is offered but did not evaluate it as it wasn't within the scope of
> our
> >> > exercise.
> >>
> >> So, how does that track with this quote from the decision blog post?
> >>
> >> "Some top level requirements which helped us arrive at this decision
> >> [to choose Gitlab]:
> >>
> >> There is a need for CentOS Stream to integrate with a kernel workflow
> >> that is an automated bot driven merging solution (merge trains). This
> >> allows for richer CI capabilities and minimises the need for human
> >> interaction"
> >>
> >> If you did not evaluate Gitlab CI (and presumably CI capabilities of
> >> the three systems more widely), how did the need for a CI feature -
> >> that is what "merge trains" are - act as a "top level requirement"
> >> which "helped us arrive at this decision"?
> >
> >
> > I'm talking specifically about CI as a capability, in that specific
> integrations at a CI level for hooks and other nice stuff which has several
> known issues in Pagure at an API level, we evaluated that high level
> requirement. Some stakeholders do not want to use the built in Gitlab CI as
> we have CentOS CI used extensively and some have homebrewed systems that
> they use. Hence why we did not go deep on CI at a very functional level
> outside of known limitations and desires that came up as direct
> requirements.
> >
> > Merge trains and that capability is plugin / CI based and was explicit
> in it's scope (it was called out as a need to have merge train
> functionality) Vs CI in general as it was named as a need. We had discussed
> that Zuul was a possibility around Pagure as part of that.
>
> Discussed with whom, do you have logs? You didn't provide any material
> from which the conclusions could be reproducibly drawn, you just came
> and told us: "Hey, we decided this and this, you don't have any other
> choice than to comply". It doesn't work like that or at least it
> shouldn't, in my opinion.
>
> It doesn't seem that you have considered CI future for Fedora _at
> all_, i.e. work needed for pagure-based solution vs. work needed for
> gitlab-based solution. Sorry but if you don't have a clear and
> presentable vision of the different setups and how they compare to
> each other with respect to initial setup, maintenance cost, and
> feature set relevant for packager workflows, you shouldn't be making
> decisions like those. Your "let's go to Gitlab" is shooting in the
> dark at best.
>

Let me add here: we had conversation on CI with CPE both as Fedora CI SIG
and as RHEL CI team.

We do want to keep existing CI infrastructure based on message exchange
with distributed CI systems. As Gitlab has API and messages in a certain
form, I don't expect huge problems here.

And we mentioned Zuul in that conversation. We discussed the possibility
for Zuul to work with Gitlab at Devconf in January. And my understanding
alignes with what Fabien said in this thread, that Zuul _can_ work with
Gitlab. Though it might require some adjustments.

Personally, I believe that Zuul is superior to any other CI system when it
comes to managing pull-requests workflow, and I would like to see its usage
increased in Fedora and beyond. But I think changing the Git Forge to
Gitlab doesn't on its own create a problem for this view.

What I would consider a problem: if we take Gitlab as GitForge, but then
users start to request more "nice features", more "easy integrations" and
more Gitlab-specific workflows... The git forge itself is not as harmful,
as the scope creep in can bring.

But this is not something the CPE team should manage alone, it is us as
users who need to be disciplined in the usage of this tool and our requests
to it.



> clime
>
> >
> >
> >>
> >> --
> >> Adam Williamson
> >> Fedora QA Community Monkey
> >> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> >> http://www.happyassassin.net
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> >
> >
> >
> > --

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

2020-04-07 Thread Aleksandra Fedorova

On Tue, Apr 7, 2020 at 7:55 PM Neal Gompa  wrote:
>
> On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova  wrote:
> >
> > Hi,
> >
> > On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok  wrote:
> > >
> > > On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
> > > >> What I'm confused about is the hangup with versioning the ELN tree.
> > > >> Why is this a problem?
> > > > I explained it in one of the previous threads:
> > > >
> > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
> > > >
> > > > But I guess we need to extend this conversion by answering:
> > > > 1) versioning of what exactly?
> > > > 2) versioning by which number?
> > > >
> > > >  From the problem you describe, it looks like the solution for it is to
> > > > have %{?dist} resolved to a versioned data. But the versioning here
> > > > should be independent from both RHEL and Fedora versioning. It should
> > > > be based on changes in eln buildroot configuration itself: As soon as
> > > > we want to have a non-disruptive rebuild in eln buildroot, we
> > > > increment the number in %{?dist} for eln, and rebuild the same srpm.
> > > > And this action is not linked to Fedora or RHEL releases. This number
> > > > may as well be the date, or a simple counter.
> > > >
> > > > If we do versioning in this way, then it resolves both concerns I had
> > > > in my reply there:
> > > > 1) we don't try to link to particular RHEL release;
> > > > 2) we don't version the koji tag and target, and we don't need to
> > > > update Koji configuration every time Fedora creates a branch. Thus the
> > > > pipelines we create for building eln packages can still be
> > > > unversioned.
> > >
> > >
> > > What you say here is very inconsistent with %{eln} and %{rhel} value. In
> > > particular "the versioning here should be independent from RHEL" and "we 
> > > don't
> > > try to link to particular RHEL release" is very weird considering that 
> > > %{eln}
> > > and %{rhel} will evaluate to "next RHEL version".
> >
> > You are right. Originally we were thinking of %{eln} as a boolean,
> > rather than a meaningful data. So the important part was that we set
> > it to something, so that in those very rare cases where we may want to
> > have a condition based on eln, we can use it.
> > We defined %{eln} to be "something", and that something just happened
> > to be %{rhel}.
> >
> > But since we are talking about versioning for eln now, it makes sense
> > to use this macro to store the actual data about eln buildroot.
> >
> > So I am thinking of adjusting the change in the following form:
> >
> > 
> > * %{rhel} will be set and will return a number one higher than the
> > most recent major release of Red Hat Enterprise Linux (at present,
> > that will be 9).
> > * %{eln} will be set and will expand to the ELN version (independent
> > of Fedora and RHEL) in a format "X.Y".  X will be bumped for mass
> > rebuilds, Y - for other changes.
> > * %{dist} will be set to "eln%{eln}"
> >
> > Explicit usage of %{eln} macro in spec files should be discouraged. As
> > its main purpose is the versioning of the build environment, not
> > adjusting the sources.
> > 
> >
> > This way we can experiment with the configuration ELN-buildroot
> > without bumping package sources.
> >
> > And we will have RHEL versioning available, but not directly, which
> > adds some flexibility in relation between ELN and RHEL.
> >
>
> This definitely solves the issue I've been thinking of. I'm not sure I
> understand why we want to disconnect the ELN version from the upcoming
> RHEL version, even in the DistTag? It seems to be a weird hoop to
> separate when we all know this is about building the next RHEL major,
> and we all know what the next version is, and we all know the
> timelines.

Don't get me wrong, I am not trying to hide the fact that we are
building RHEL type of packages.

But
1) aligning those versions is a more complex task than it looks.

Historically we had this %rhel macro to map to next release version
working, because we were building Fedora content for RHEL only during
the specific phase of RHEL development, where this number is known and
fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And
it is not tha

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

2020-04-07 Thread Aleksandra Fedorova

Hi,

On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok  wrote:
>
> On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
> >> What I'm confused about is the hangup with versioning the ELN tree.
> >> Why is this a problem?
> > I explained it in one of the previous threads:
> >
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
> >
> > But I guess we need to extend this conversion by answering:
> > 1) versioning of what exactly?
> > 2) versioning by which number?
> >
> >  From the problem you describe, it looks like the solution for it is to
> > have %{?dist} resolved to a versioned data. But the versioning here
> > should be independent from both RHEL and Fedora versioning. It should
> > be based on changes in eln buildroot configuration itself: As soon as
> > we want to have a non-disruptive rebuild in eln buildroot, we
> > increment the number in %{?dist} for eln, and rebuild the same srpm.
> > And this action is not linked to Fedora or RHEL releases. This number
> > may as well be the date, or a simple counter.
> >
> > If we do versioning in this way, then it resolves both concerns I had
> > in my reply there:
> > 1) we don't try to link to particular RHEL release;
> > 2) we don't version the koji tag and target, and we don't need to
> > update Koji configuration every time Fedora creates a branch. Thus the
> > pipelines we create for building eln packages can still be
> > unversioned.
>
>
> What you say here is very inconsistent with %{eln} and %{rhel} value. In
> particular "the versioning here should be independent from RHEL" and "we don't
> try to link to particular RHEL release" is very weird considering that %{eln}
> and %{rhel} will evaluate to "next RHEL version".

You are right. Originally we were thinking of %{eln} as a boolean,
rather than a meaningful data. So the important part was that we set
it to something, so that in those very rare cases where we may want to
have a condition based on eln, we can use it.
We defined %{eln} to be "something", and that something just happened
to be %{rhel}.

But since we are talking about versioning for eln now, it makes sense
to use this macro to store the actual data about eln buildroot.

So I am thinking of adjusting the change in the following form:

* %{rhel} will be set and will return a number one higher than the
most recent major release of Red Hat Enterprise Linux (at present,
that will be 9).
* %{eln} will be set and will expand to the ELN version (independent
of Fedora and RHEL) in a format "X.Y".  X will be bumped for mass
rebuilds, Y - for other changes.
* %{dist} will be set to "eln%{eln}"

Explicit usage of %{eln} macro in spec files should be discouraged. As
its main purpose is the versioning of the build environment, not
adjusting the sources.

This way we can experiment with the configuration ELN-buildroot
without bumping package sources.

And we will have RHEL versioning available, but not directly, which
adds some flexibility in relation between ELN and RHEL.

>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

--
--
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

2020-04-07 Thread Aleksandra Fedorova

Hi, Neal,

On Tue, Apr 7, 2020 at 12:49 AM Neal Gompa  wrote:
>
> On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher  wrote:
> >
> >
> >
> > On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa  wrote:
> >>
> >> * The DistTag should be versioned. Either .eln.elX (e.g. .eln.el9),
> >> .elnX (e.g. .eln9), or just plain .elX (e.g. .el9).
> >> * Likewise, I think the Koji tags should be versioned too.
> >>
> >> I've personally been burned enough times by not having versioned
> >> DistTags for personal rebuilds that I would strongly suggest you
> >> reconsider having unversioned ones.
> >
> > Would you mind explaining some of the situations in which you were burned? 
> > I’m not ruling this out, but I’d like a clear justification if we were to 
> > change something.
> >
>
> So, prior to me building my packages in OBS and getting auto-bumping
> Releases, I used to bump into issues all the time with building
> openSUSE packages in an environment like Koji's, where the NVR is the
> key for a unique package. openSUSE does *not* define a DistTag or the
> %dist variable, so %{?dist} evaluates to nothing. If you're doing
> rebuilds of your packages with no source changes from one release of
> openSUSE to the next, or rebuilding for new Tumbleweed snapshots,
> you're going to get collisions all the time, and builds will just fail
> because the NVR already exists.
>
> This is utter chaos and you *really* don't want that problem on your
> hands. Having the freedom to do a rebuild cycle for ELN whenever you
> want to rebootstrap to a new major without changing sources is a
> hugely valuable thing to be able to do.
>
> And honestly, I expect the ELN tree to exist for a long time once it's
> in Fedora. So some of this is also planning for a future where we
> always have Fedora ELN along with Rawhide and regular Fedora stable
> releases.
>
> What I'm confused about is the hangup with versioning the ELN tree.
> Why is this a problem?

I explained it in one of the previous threads:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/

But I guess we need to extend this conversion by answering:
1) versioning of what exactly?
2) versioning by which number?

From the problem you describe, it looks like the solution for it is to
have %{?dist} resolved to a versioned data. But the versioning here
should be independent from both RHEL and Fedora versioning. It should
be based on changes in eln buildroot configuration itself: As soon as
we want to have a non-disruptive rebuild in eln buildroot, we
increment the number in %{?dist} for eln, and rebuild the same srpm.
And this action is not linked to Fedora or RHEL releases. This number
may as well be the date, or a simple counter.

If we do versioning in this way, then it resolves both concerns I had
in my reply there:
1) we don't try to link to particular RHEL release;
2) we don't version the koji tag and target, and we don't need to
update Koji configuration every time Fedora creates a branch. Thus the
pipelines we create for building eln packages can still be
unversioned.

> >
> >>
> >> Finally, there is no adequate explanation for why ELN content can't go
> >> out to the mirrors like Rawhide content does. I'd vastly prefer that
> >> simply to have similar levels of availability as consumers of ELN
> >> content. I would prefer seeing it go to the mirror network like
> >> everything else.
> >
> >
> >
> > It’s not so much that it *cannot* as that we are trying not to overload the 
> > mirror network with content not useful to non-developers.
> >
>
> Unless you plan to get Red Hat to do CDN delivery of ELN, I think
> you're going to want it on the mirror network anyway. Ultimately,
> contributors like myself need to be able to *use* the content, and not
> having it delivered via the mirror network means that it's going to be
> painful for a large cross-section of contributors and developers.
>

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: %bcond_with/%bcond_without

2020-04-04 Thread Aleksandra Fedorova

Hi,

On Fri, Apr 3, 2020 at 10:38 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Fri, Apr 03, 2020 at 02:23:12PM -0400, Stephen Gallagher wrote:
> > Fabio Valenti made this comment in the FESCo ticket[1].
> >
> > "Side note: I think more people would be amenable to including
> > "conditionals" into their packages if they weren't only shown off as
> > `%if eln this else that`. I think there's more value in doing "feature
> > flags" rather than conditionalize everything based on the `dist` tag,
> > for example something like this might even be useful in fedora
> > branches (e.g. for bootstrapping):
> >
> > ```spec
> > # at the top of the .spec file, where it's easily visible
> > %if 0%{?eln}
> > %bcond_with docs
> > %else
> > %bconf_without docs
> > %endif
> >
> > # ...
> >
> > %if %{with docs}
> > # do something
> > %endif
> > ```
> >
> > This makes conditionals (when they are necessary) much easier to
> > maintain (and understand), in my experience."
>
> This is a side topic, and I didn't want to clutter the FESCo ticket
> with that. But here we have threads, so I hope that you'll forgive me ;)
>
> If find the %bcond_with/%bcond_without pattern abhorrent.
>
> 1. The logic is reversed: when I see "with" I think something is enabled,
>when I see "without" I think something is disabled. But it's actually
>the other way around here, which I find very confusing and often get
>the condition reversed on the first try.
>
> 2. The value ('0%{?eln}') in this example is expressed before the name
>('docs'), which is like saying 'value =: name'.
>
> 3. It takes five (!) lines to express the something that should be one
>line.
>
> So... could we please get a way to express this in rpm with a sane syntax:
>
> %define_cond docs 0%{?fedora} > 0

I am all for clarity and cleaner syntax.
But I don't think this particular example is a good illustration for
it. If we have more then one switch, or more than one set of switches
it won't work.

Something like:

%if 0%{?fedora} > 0
%define_cond docs 1
%define_cond tests 1
%endif

%if 0%{?rhel} > 0
%define_cond docs 0
%define_cond tests 1
%endif

is more readable than

%define_cond docs 0%{?fedora} > 0
%define_cond tests (0%{?fedora} > 0 OR 0%{?rhel} > 0)

even though there are more lines in it.

>
> (Naming and details of syntax are just examples, but the important
> parts are: one line, name before value, positive logic).
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

2020-04-03 Thread Aleksandra Fedorova

On Fri, Apr 3, 2020 at 8:23 PM Stephen Gallagher  wrote:
>
> On Fri, Apr 3, 2020 at 1:27 PM Matthew Miller  
> wrote:
> >
> > On Thu, Apr 02, 2020 at 10:32:31PM +0200, Nicolas Mailhot via devel wrote:
> > > Would it be possible to formalize the kind of spec processing ELN wants
> > > available in a set of generic operations with generic arguments (or
> > > control variables)?
> > >
> > > I would not mind seeing a set of ELN macro calls in my rawhide specs,
> > > that evaluate to nothing for Fedora. *declarative* syntax is a lot less
> > > scary maintenance-wise than free-form spec programming.
> >
> > This seems like a great suggestion in general and the direction we should be
> > going anyway.
>
> Fabio Valenti made this comment in the FESCo ticket[1].
>
> "Side note: I think more people would be amenable to including
> "conditionals" into their packages if they weren't only shown off as
> `%if eln this else that`. I think there's more value in doing "feature
> flags" rather than conditionalize everything based on the `dist` tag,
> for example something like this might even be useful in fedora
> branches (e.g. for bootstrapping):
>
> ```spec
> # at the top of the .spec file, where it's easily visible
> %if 0%{?eln}
> %bcond_with docs
> %else
> %bconf_without docs
> %endif
>
> # ...
>
> %if %{with docs}
> # do something
> %endif
> ```
>
> This makes conditionals (when they are necessary) much easier to
> maintain (and understand), in my experience."
>
> First, let me say that I agree wholeheartedly and I think that when
> we're using conditionals this is the best way to do it.
>
> I had some thoughts here on how we could accomplish the above without
> cluttering the spec file (though it does add a bit of complexity to
> the dist-git contents). We could take a page from build-systems and
> have essentially a separate "configure" and "build" step for RPM. (No,
> I'm not proposing changes to RPM itself).
>
> At the top of the specfile (above even the `Name:` directive), we
> would have constructs of the following type:
>
> %if 0%{?rhel} < 9
> %include rpmconfig_rhel_old.inc
> %elif 0%{?rhel} >= 9
> %include rpmconfig_rhel_new.inc
> %else
> %include rpmconfig_fedora.inc
> %endif
>
> Contents of rpmconfig_rhel_old.inc:
> %bcond_without pregen_docs
> %bcond_with openssl3
>
> Contents of rpmconfig_rhel_new.inc:
> %bcond_without pregen_docs
> %bcond_without openssl3
>
> Contents rpmconfig_fedora.inc:
> %bcond_with pregen_docs
> %bcond_without openssl3
>
>
> Then the main specfile can use the `%if %{with FEATURE}` construct
> instead of dealing with the clutter in the main specfile (and merges
> will likely be easier).

I was also thinking about something alone those lines.

But if I understood Neil's comment right in [1] then we don't even
need the .inc-files in each spec file, because the flag can be
switched globally on the build environment.
We would need a dedicated namespace for such flags and the way to
track them. And then we could build Fedora Rawhide according to the
predefined set of global switches.


[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UOO3JNM7S4HKBR5VFNVAQT6J33TZQLWV/




> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org



-- 
-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

2020-04-03 Thread Aleksandra Fedorova

; > these repositories. We're going to be opening up some of the "secret
> > sauce" so that more of the community can see what we are testing. They
> > will have greater insight into the potential usage of their packages.
> >
> >> For the stated reasons I am *-1 for this change in its current form*.
> >
> > That is your privilege as a member of FESCo. As I've said, however, I
> > think you've misunderstood the situation.
> >
> >> As said on the mailing list, I'd appreciate if you take the feedback 
> >> provided by
> >> the packagers more seriously and adjust the proposal accordingly.
> >
> > I have read and responded to the feedback as best I know how. Please
> > do not confuse "I disagree and here are my reasons" with not listening
> > to the feedback.
> >
> >
> > Lastly, I don't know if you reread the latest updates (that I made
> > around three hours ago to the Change Proposal), but I *did*
> > acknowledge that we are going to incorporate the possibility of
> > maintaining separate specs for ELN and Rawhide for any maintainer who
> > absolutely wants to do more manual work. The exact mechanism is going
> > to at least partly depend on the results of the dist-git forge move,
> > so I haven't incorporated that into the proposal. Functionally, it
> > will be very similar to maintaining a separate branch, though.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> >
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

2020-04-02 Thread Aleksandra Fedorova

 feedback provided 
> by
> the packagers more seriously and adjust the proposal accordingly.
>
> As a side note, I'd like to continue the discussion on the mailing list, as I
> believe there's still plenty to discuss. That's why I'll also post this text
> there, so you can quote-reply.
>
> ---
>
> ¹ For any interested Red Hatters reading this: Apart form the feedback 
> received
> on the devel mailing list, I discussed this internally with my Red Hat team,
> Python-maint .The whole team shares my concerns, as do other members of Core
> Services.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2

2020-03-30 Thread Aleksandra Fedorova

Hi,

On Mon, Mar 30, 2020 at 1:13 PM Miro Hrončok  wrote:
>
> On 30. 03. 20 12:59, Aleksandra Fedorova wrote:
> >> Put all the other feedback aside, if we actually decide that this change is
> >> happening, can we not build ELN during the datacenter move [1], when Koji 
> >> will
> >> have a very limited capacity [2]?
> > I think we should go with Kevin's suggestion and deprioritize eln
> > builds from the start.
>
> I'm afraid that this won't be good enough. Other (Fedora) builds will be
> submitted with lower prio as well. For example our Python 3.N+1 rebuilds are
> usually submitted as such, so the wave of 3k packages doesn't block individual
> packagers. So unless Koji has multiple levels of priorities, I would have 2 
> choices:
>
>   - do --background and be blocked by ELN
>   - don't do --background and block individual packagers
>
> I think the automatic ELN builds should be disabled during the datacenter move
> (and it might be easier to actually wait for the move before the builds even
> start, if that's doable on schedule).

I am not even sure that we will have the automation ready by that time.

I'd like not to wait with the change till then, because we first need
to do some preparation work, to get those infrastructure bits and
pieces - disttag, koji target, basic buildroot. Then we would do some
test runs, find issues with the process... iterate.
It will take time to even start building anything, and I'd rather not
delay this work.

But then I agree we should adjust the timeline to take datacenter move
into account.

> > If this is not going to be enough for the
> > datacenter move, then we can disable ELN pipelines for two weeks.
> > As we will use external service (most likely Jenkins pipeline) to
> > trigger the builds, we will be able to switch them on and off without
> > changing anything on the infrastructure.
>
> Thanks.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2

2020-03-30 Thread Aleksandra Fedorova

Hi, Miro,

On Mon, Mar 30, 2020 at 12:09 PM Miro Hrončok  wrote:
>
> On 27. 03. 20 16:07, Stephen Gallagher wrote:
> > Please see the newly-updated
> > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>
> > Setup automation to trigger new ELN build every time there is a new update 
> > submitted to Fedora Rawhide.
>
> Put all the other feedback aside, if we actually decide that this change is
> happening, can we not build ELN during the datacenter move [1], when Koji will
> have a very limited capacity [2]?

I think we should go with Kevin's suggestion and deprioritize eln
builds from the start. If this is not going to be enough for the
datacenter move, then we can disable ELN pipelines for two weeks.
As we will use external service (most likely Jenkins pipeline) to
trigger the builds, we will be able to switch them on and off without
changing anything on the infrastructure.

>
> (Either not build yet or stop the builds if they already run at that time.)
>
> [1] https://pagure.io/fesco/issue/2221
> [2]
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KURIBFQXUPCH7OW7ED4UIA37S2RIXTI5/
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2

2020-03-30 Thread Aleksandra Fedorova

On Mon, Mar 30, 2020 at 11:11 AM Vít Ondruch  wrote:
>
> It is kind of irony, that the ELN branch idea is still rejected.

I've made several attempts to explain this decision. You are ignoring them.

> Therefore there will be PRs coming from Stephen's and Alexandra's (or
> anybody else in ELN SIG) forks of packages, containing changes needed to
> build some packages in ELN, which nobody is going to merge. In the
> meantime, the ELN builds will keep failing.
>
> I wonder why there can't be PR's coming from ELN branch. That would
>
> 1) Allow the ELN builds to pass.
>
> 2) Audit the work to do.
>
> 3) Give it some structure and therefore discoverability.
>
>
> Just to be clear, I don't plan to accept any PR adding any "if rhel" and
> similar into package I currently maintain in Fedora, sorry. Being
> maintainer in Fedora and RHEL, I could have done it any time and I did
> not. In every package I adopted/inherited during the years, I have
> removed such conditionals, because they are PITA. While the proposal
> helps with the maintenance of such conditionals, it would still harm
> freedom of Fedora to innovate. I understand what is the cost and it is
> not worth of it.

To be honest, I see a completely different kind of irony here.

For years Fedora packagers have to deal with nonresponsive upstreams.

How often we go to upstream developers, trying to convince them to
remove bundled libraries, adjust the licensing, to add a configuration
option, to split into subcomponents, to stop hardcoding docker in
their build system..
We know this struggle, we talk about it a lot, we discuss how we can
make upstream to listen to us, how we should help each other..

And then, when we play the role of the upstream, we completely forget about it.

Now, I understand people's concerns about merging some downstream
specific changes into the upstream sources without proper design or
without agreement. And we highlighted several times that we are not
going to do that.

But the fact that I need to convince Fedora packagers that they should
at least listen to the problem downstream has, and at least try to
think about how it can be addressed, through conditionals or through
refactoring, or through upstream changes.. this surprises me. I
definitely didn't expect the "don't even try to bother me with those
topics" reaction.

>
> Vít
>
>
> Dne 27. 03. 20 v 16:07 Stephen Gallagher napsal(a):
> > There has been a lot of (really good!) discussion on the original
> > proposal thread, but as it has grown too large to follow anymore, I'm
> > restarting it. I have made numerous changes to the Change Proposal
> > page to improve the scope of the proposal as well as clarify some of
> > the questions that have come up repeatedly in the original thread.
> >
> > Please see the newly-updated
> > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> > for more details[1].
> >
> > == Summary ==
> > ELN is a new buildroot and compose process for Fedora that will take
> > Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
> > compose. Feedback from this build, compose and integration testing
> > will be provided to Fedora packagers so that they can see the
> > potential impact of their changes on RHEL development.
> >
> > == Owner ==
> >
> > * Name: [[User:Bookwar| Aleksandra Fedorova]]
> > * Email: al...@bookwar.info
> > * Name: [[User:Sgallagh | Stephen Gallagher]]
> > * Email: sgall...@redhat.com
> >
> >
> >
> > [1] List of changes between the original and new versions:
> > https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose=revision=569655=569549
> > ___
> > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> > To unsubscribe send an email to
> devel-announce-le...@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/devel-annou...@lists.fedoraproject.org
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
>
> ___
> devel maili

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2

2020-03-29 Thread Aleksandra Fedorova

On Sun, Mar 29, 2020 at 2:36 PM clime  wrote:
>
> On Sun, 29 Mar 2020 at 13:34, Aleksandra Fedorova  wrote:
> >
> > Hi,
> >
> > On Sat, Mar 28, 2020 at 11:25 PM clime  wrote:
> > >
> > > From the proposal:
> > >
> > >  %if 0%{?fedora} < 32 && 0%{?rhel} <= 8
> > >
> > > The fix will be done via a pull request that states a time limit. We
> > > want the regular maintainers to see / comment / commit, but we also
> > > don't want things to stall for months and get forgotten about.
> > >
> > > ---
> > >
> > > What kind of pull request is that? It's like saying either merge or ...
> > > In other words, great way to lose community members.
> >
> > This is a better version of what proven packages already do nowadays.
> >
> > If package already has a disttag-specific conditional, and this
> > conditional leads to a build failure in the eln-environment, then we
> > need a fix for that. Here we are not talking about introducing new
> > conditionals, feature switches or dependency adjustments. We will be
> > fixing the existing conditional so that package can be built.
> >
> > Currently proven packagers fix such build failures directly. We will
> > propose changes via pull requests, so that maintainer has a
> > possibility to say "no", or to say "do it differently". But if we can
> > not get any feedback from a maintainer on it, we will fix the build
> > failure.
>
> Hi,
>
> I think it would be nice to say in the change that it's okay to say
> "no"

It is a common sense. I don't see how it can be interpreted the other way.

> and what
> ELN SIG will do in that case.

It is described as other options in the change: We talk, we look into
options, we may consider removing the conditional altogether, if it is
not relevant anymore and continue using a clean "unconditionalized"
package.

If you are asking me what I am going to do if I meet Fedora packager,
who deliberately _adds_ conditional to the package to make this
package to fail to build in the eln environment and refuses to remove
it, then the answer is - I don't know. But I will be surprised, and I
will start questioning my life choices, for sure.

> clime
>
> >
> > --
> > Aleksandra Fedorova
> > bookwar
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2

2020-03-29 Thread Aleksandra Fedorova

Hi,

On Sat, Mar 28, 2020 at 11:25 PM clime  wrote:
>
> From the proposal:
>
>  %if 0%{?fedora} < 32 && 0%{?rhel} <= 8
>
> The fix will be done via a pull request that states a time limit. We
> want the regular maintainers to see / comment / commit, but we also
> don't want things to stall for months and get forgotten about.
>
> ---
>
> What kind of pull request is that? It's like saying either merge or ...
> In other words, great way to lose community members.

This is a better version of what proven packages already do nowadays.

If package already has a disttag-specific conditional, and this
conditional leads to a build failure in the eln-environment, then we
need a fix for that. Here we are not talking about introducing new
conditionals, feature switches or dependency adjustments. We will be
fixing the existing conditional so that package can be built.

Currently proven packagers fix such build failures directly. We will
propose changes via pull requests, so that maintainer has a
possibility to say "no", or to say "do it differently". But if we can
not get any feedback from a maintainer on it, we will fix the build
failure.

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2

2020-03-29 Thread Aleksandra Fedorova

 packagers, even via ELN option, then downstream does the
branching. But this branching is not in the scope of the proposed ELN
change.

> Fabio
>
> > Please see the newly-updated
> > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> > for more details[1].
> >
> > == Summary ==
> > ELN is a new buildroot and compose process for Fedora that will take
> > Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
> > compose. Feedback from this build, compose and integration testing
> > will be provided to Fedora packagers so that they can see the
> > potential impact of their changes on RHEL development.
> >
> > == Owner ==
> >
> > * Name: [[User:Bookwar| Aleksandra Fedorova]]
> > * Email: al...@bookwar.info
> > * Name: [[User:Sgallagh | Stephen Gallagher]]
> > * Email: sgall...@redhat.com
> >
> >
> >
> > [1] List of changes between the original and new versions:
> > https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose=revision=569655=569549
> > -BEGIN PGP SIGNATURE-
> >
> > iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5+FpgACgkQRduFpWgo
> > bRE90QwAu8gIRcPcyct73D2jF+MBzmy7XFdlilLIcL4Z3RWINKgHcNUTw+jC9n3K
> > jJdBMOUji1DAD+fw1UeuJ+x0ThMCg1zqYgRDalYE/7AiRWxjD73rQ5V3q7EKLycJ
> > 6Al+n3rB+P5vy+TB9m/mB223hjmUxv5+FXEqmkNcpvZiRsTqIk5Ss+22zSoFhs8D
> > 6DJE6yPTPiNiygJZBIgE508pXakHsl2CCpKNccHEpj5eNU0t93kbb7oWVJXf6i6Z
> > Y09jvZLO4mVcn1vUIJRtpFJvNWbzIEIGyFuELgvHoVT66xSe4MwxvW0A6ChIwngQ
> > mvNM43Ild6Lq29+qtVCje6fovh3yPzRWitoEwdClg4HOj5C2wymeQWO01a/ydQNg
> > lUwmNnFHPZ4/2TtHWw64QkKdm9QP6bfmdMYJOy+iKhibmUiws4WheTB5L6zyh4ED
> > pvLLszQvReqDj5N56Oghr5YquRdQLIACEfqm5s4A/iipwDEj3WY5niHzAt0jBz1q
> > 6DnLPiZt
> > =42JI
> > -END PGP SIGNATURE-
> > ___
> > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> > To unsubscribe send an email to devel-announce-le...@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/devel-annou...@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org



-- 
-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-28 Thread Aleksandra Fedorova

On Fri, Mar 27, 2020 at 8:09 PM David Cantrell  wrote:
>
> On Fri, Mar 27, 2020 at 01:48:15PM -0500, Justin Forbes wrote:
> >On Fri, Mar 27, 2020 at 10:47 AM David Cantrell  wrote:
> >>
> >> On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote:
> >> >As Ben is on PTO, I'd like to present the System-Wide Change
> >> >
> >> >https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> >> [snip]
> >>
> >> It has taken me some time, but I have read through the entire thread in
> >> addition to the change proposal.  The idea sounds really interesting to me 
> >> and
> >> a lot of points have come up on the thread.  I decided to group my 
> >> responses
> >> together as this single email after reading through the entire thread to 
> >> make
> >> it a bit easier to read (and to write).
> >>
> >> TL;DR -- I think this proposal should be broken up in to 2 proposals
> >>
> >> The turning point for me in the change proposal was the discussion of the 
> >> RPM
> >> spec file macros and getting in to the mechanics of how ELN will work.  It
> >> looks like a lot of other people had the same reaction because many of the
> >> responses get in to the technical details and for some questions, there 
> >> are no
> >> answers yet.  After thinking about it for a while, it would make sense to 
> >> me
> >> to have ELN come up in multiple phases/proposals.
> >>
> >> Suggested Proposals:
> >>
> >> 1) ELN buildroot and install media
> >>
> >> In this proposal, I'd like to see the ELN buildroot defined, the Koji
> >> changes implemented, the automated builds implemented, and install 
> >> media
> >> composes happening.
> >>
> >> The expectation here should be that it is rough around the edges.  But
> >> doing this gives the community something to see, use, and discuss 
> >> further
> >> when reviewing the next change proposals.
> >>
> >> We should have some community goals with this proposal to capture a 
> >> list of
> >> EL vs. Fedora differences and how to address those per package and in 
> >> the
> >> context of ELN.
> >>
> >> 2) ELN lifecycle
> >>
> >> This gets in to more of the mechanics of how ELN builds can be handled 
> >> by
> >> the community.  I do not think there is a one size fits all and we 
> >> should
> >> give developers control over how best to handle this for the packages 
> >> they
> >> maintain.
> >>
> >> The spec file macros, git branch ideas, inheritance, pull request 
> >> workflow,
> >> what builds block what composes, who is responsible for ELN failures, 
> >> and
> >> other expectations of package maintainers (both Fedora and RHEL) 
> >> should be
> >> discussed here.  This proposal is definitely the policy side of 
> >> things, but
> >> I think it would be easier to talk about after #1 is done.
> >>
> >> Having seen multiple efforts to do a "RHEL rawhide" in a way (one even 
> >> called
> >> rhel-rawhide at one point), the ELN idea is one where the work is being
> >> targeted in the right place.  As a Fedora contributor, I see RHEL as a
> >> customer and if we can make their work easier, I want to do that.  As a 
> >> RHEL
> >> package maintainer, I see Fedora as a place where I can make my job easier 
> >> as
> >> a RHEL package maintainer.  The more things we get right on the community 
> >> side
> >> of things, the easier it is to produce RHEL.
> >>
> >> Various comments from reading the thread:
> >>
> >> * I'm not crazy about the %{?rhel} macro name.  I would prefer we use 'el'
> >>instead to cover RHEL and CentOS and EPEL.  Or at least have a 'el' 
> >> macro
> >>that covers all three of those.
> >>
> >
> >The %{?rhel} macro name currently exists and is in use in some
> >packages as I recall.
>
> Sorry, what I meant was I'm not crazy about the %{?rhel} macro for this work.
> I would prefer a new macro for the ELN work to distinguish it from the
> existing macros.
>
> >> * I prefer the '.eln' dist tag carry a number indicating N+1 from the RHEL
> >>major release.  This should be ok in the community since Red Hat 
> >> ultimately
>

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

l
in that particular spec file are not relevant to ELN.

> Another approach is compat packages, but Brainfuck 8 is backwards compatible
> with 7, so it brings no benefit for Fedora.
>
> Another approach is modularity, but the Ook! SIG doesn't want to use modules
> because they want their Ook-based apps to be easily available to Fedora users.
>
> Sorry for going artificial with the example, but I didn't want you to say "you
> are always talking about Python, what you say is Python specific" -- because 
> it
> isn't.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On Fri, Mar 27, 2020 at 11:00 AM Vít Ondruch  wrote:
>
>
> Dne 27. 03. 20 v 10:16 Aleksandra Fedorova napsal(a):
> > On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch  wrote:
> >>
> >> Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a):
> >>> On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch  wrote:
> >>>> Dne 25. 03. 20 v 20:22 James Cassell napsal(a):
> >>>>> On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
> >>>>>> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
> >>>>>>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
> >>>>> [snip]
> >>>>>>>> We can come up with guidelines, for example:
> >>>>>>>>
> >>>>>>>> 1) Try to find a way to resolve the issue without any conditionals 
> >>>>>>>> first.
> >>>>>>>>
> >>>>>>>> There should be a reason why package X needs a dependency Y in Fedora
> >>>>>>>> and there should be a reason why it is a required dependency and not 
> >>>>>>>> a
> >>>>>>>> recommended one. So why in that case downstream wants it differently?
> >>>>>>>> The first approach is just to talk through it. I can assume cases
> >>>>>>>> where downstream adds a dependency, as well as Fedora package 
> >>>>>>>> removing
> >>>>>>>> them.
> >>>>>>>>
> >>>>>>>> Note that bloated dependency trees is a common problem for all binary
> >>>>>>>> distributions, it is not an "EL-thing" and we can work on that
> >>>>>>>> together.
> >>>>>>>>
> >>>>>>>> Nicolas has pointed out to another reason why we would get
> >>>>>>>> EL-conditionals: the outdated rpm stack in RHEL. But we don't have
> >>>>>>>> this problem with ELN, as we are building Rawhide, and rpm stack is
> >>>>>>>> going to be the Rawhide rpm stack as well.
> >>>>>>>>
> >>>>>>>> 2) Minimize and isolate the conditional, and track the reason.
> >>>>>>>>
> >>>>>>>> As ELN SIG we need to have a place where we collect known reasons for
> >>>>>>>> such conditionals. The overall goal is to reduce this set, not to 
> >>>>>>>> grow
> >>>>>>>> indefinitely. As Stephen said we expect it to be about couple of
> >>>>>>>> hundred packages. We will be able to track each one of them. (We have
> >>>>>>>> rpminspect to run package diffs for us).
> >>>>>>>>
> >>>>>>>> 3) In complex cases - bring it to community and FESCo.
> >>>>>>>>
> >>>>>>>> We don't know what those complex cases might be, one of the goals is
> >>>>>>>> to find them. So we keep it as an option to bring individual case to 
> >>>>>>>> a
> >>>>>>>> wider audience. To ask for help and to decide on it.
> >>>>>>>>
> >>>>>>> It seems there are missing real life examples of what we sometimes do 
> >>>>>>> in
> >>>>>>> RHEL, so please see attached patch. This patch is coming from RHEL
> >>>>>>> version of the espeak-ng. Now somebody tell me what it does for what
> >>>>>>> purpose and which scenario from the above three should be applied 
> >>>>>>> here.
> >>>>>>>
> >>>>>>>
> >>>>>>> Vít
> >>>>>>>
> >>>>>> And here is another example for the curious.
> >>>>>>
> >>>>> Both of these examples have to do with docs generation and trying to 
> >>>>> reduce dependencies for that process. "Process the man page using 
> >>>>> kramdown and remove the ronn dependency."
> >>>> The point is that these types of changes are not upstreamable. And the
> >>>> conditions would also be awful. Having these changes in separate branch
> >>>> would be much preferable IMO, because honestly, I would like every
> >>>> Fedora maintainer save f

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On Thu, Mar 26, 2020 at 3:55 PM Petr Viktorin  wrote:
>
> On 2020-03-25 17:33, Aleksandra Fedorova wrote:
> > [Branching] removes community maintainer from the conversation about what
> > downstream is doing. While we want to give community member a voice in
> > that conversation.
>
> I fear that this proposal *forces* the community member to participate
> in the discussion. That is a very different thing than giving them a voice.
>
>
> On 2020-03-25 17:10, Miro Hrončok wrote:
> > On 25. 03. 20 16:47, Stephen Gallagher wrote:
> >> I think we managed to miss a few key points in the Change Proposal
> >> which is directly resulting in a bit of the confusion here.
> >
> > Reading the rest of you e-mail I must agree that this is what happened.
> > Would you mind putting the change back to incomplete state and resend it
> > once more for feedback once this is addressed?
> >
> >> The first and most important of these is that ELN will*not*  be
> >> building the complete Fedora package set. We're going to be building a
> >> selected subset of packages (derived from packages in RHEL 8 and
> >> EPEL). Our current expectation is that we are going to be looking at
> >> fewer than 2500 source packages. We are still working up the initial
> >> list of these and we will update the Change Proposal with it (as well
> >> as providing a fedora-devel post breaking down the known owners).
> >
> > Glad to hear that.
> >
> >> Second, from this reduced subset, we expect that the overwhelming
> >> majority of the maintainers are Red Hat employees that already work on
> >> RHEL. With this in mind, we think that the level of concern about how
> >> this will affect non-Red Hat contributors is premature. We will reach
> >> out directly to those non-Red Hat contributors we identify.
>
> This actually worries me very much.
>
> The subset of packages will need to form a working system; it will
> include the most important packages. I hope this doesn't end up limiting
> maintainers of Fedora's most central packages to only Red Hatters or
> those that agree to play by RHEL rules that they have no say in.
>
> I am pretty sure that most packages/packagers will be OK with the ELN
> change. But "most" is not enough. We do need to take the "worst cases"
> into account. Consider a package that:
> - is needed in RHEL, but only as a dependency of something vital; the
> RHEL maintainer doesn't care too much about it outside their work duties
> - has an enthusiastic packager in Fedora, who prefers to leave RHEL work
> to paid developers
>
> (As member of a team that, some time ago, used to be catch-all RHEL
> maintainer for anything that happened to be written in Python, I can
> definitely imagine situations similar to this.)
>
> For such a package, we need to avoid pushing ELN macros into the
> package, otherwise we lose an enthusiastic contributor who does amazing
> work in Fedora.
>
> Such a package might even be hypothetical right now, but the case still
> needs to be adressed. A package can fall into this category at any time
> in the future. It's not enough to identifying packagers that are
> affected now, and work with them. There needs to be a process for cases
> like these, and it can't be "merge these ELN macros now, there's a
> deadline coming; maybe we'll come up with a better process in the
> future". (Especially if Red Hat is unlikely to drive setting up a better
> process.)
>
> IMO, any changes needed in EL need to be opt-in, with the understanding
> that opting in will be (almost always) beneficial for everyone involved.
> They need to feel like a gift ("Hello fedora packager, please accept
> this PR with EL macros; it'll make it easier to work on this together!")
> rather than forced ("Red Hat needs this; merge it or else").

I wonder how we ended up with people feeling like we are proposing
latter rather than the former.
I guess I took couple of wrong turns in this discussion, and I'd like
to step back and try again.

Me, Stephen and Troy are going to update the proposal, and come up
with a better description of how opt-in will look like.

> To borrow Neal Gompa's words, ELN needs to not feel "like it's written
> for Red Hat people to move their sandbox outside of Red Hat into Fedora
> without anyone else to be able to play in the sandbox."
>
>
> For ELN changes to be to be opt-in, there essentially needs to be a
> place to diverge -- a place for ELN hotfixes to live while polishing
> them and debating their usefulness in Fedora and further upstreams.
> Here by "hotfix" I need something required in

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch  wrote:
>
>
> Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a):
> > On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch  wrote:
> >>
> >> Dne 25. 03. 20 v 20:22 James Cassell napsal(a):
> >>> On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
> >>>> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
> >>>>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
> >>> [snip]
> >>>>>> We can come up with guidelines, for example:
> >>>>>>
> >>>>>> 1) Try to find a way to resolve the issue without any conditionals 
> >>>>>> first.
> >>>>>>
> >>>>>> There should be a reason why package X needs a dependency Y in Fedora
> >>>>>> and there should be a reason why it is a required dependency and not a
> >>>>>> recommended one. So why in that case downstream wants it differently?
> >>>>>> The first approach is just to talk through it. I can assume cases
> >>>>>> where downstream adds a dependency, as well as Fedora package removing
> >>>>>> them.
> >>>>>>
> >>>>>> Note that bloated dependency trees is a common problem for all binary
> >>>>>> distributions, it is not an "EL-thing" and we can work on that
> >>>>>> together.
> >>>>>>
> >>>>>> Nicolas has pointed out to another reason why we would get
> >>>>>> EL-conditionals: the outdated rpm stack in RHEL. But we don't have
> >>>>>> this problem with ELN, as we are building Rawhide, and rpm stack is
> >>>>>> going to be the Rawhide rpm stack as well.
> >>>>>>
> >>>>>> 2) Minimize and isolate the conditional, and track the reason.
> >>>>>>
> >>>>>> As ELN SIG we need to have a place where we collect known reasons for
> >>>>>> such conditionals. The overall goal is to reduce this set, not to grow
> >>>>>> indefinitely. As Stephen said we expect it to be about couple of
> >>>>>> hundred packages. We will be able to track each one of them. (We have
> >>>>>> rpminspect to run package diffs for us).
> >>>>>>
> >>>>>> 3) In complex cases - bring it to community and FESCo.
> >>>>>>
> >>>>>> We don't know what those complex cases might be, one of the goals is
> >>>>>> to find them. So we keep it as an option to bring individual case to a
> >>>>>> wider audience. To ask for help and to decide on it.
> >>>>>>
> >>>>> It seems there are missing real life examples of what we sometimes do in
> >>>>> RHEL, so please see attached patch. This patch is coming from RHEL
> >>>>> version of the espeak-ng. Now somebody tell me what it does for what
> >>>>> purpose and which scenario from the above three should be applied here.
> >>>>>
> >>>>>
> >>>>> Vít
> >>>>>
> >>>> And here is another example for the curious.
> >>>>
> >>> Both of these examples have to do with docs generation and trying to 
> >>> reduce dependencies for that process. "Process the man page using 
> >>> kramdown and remove the ronn dependency."
> >>
> >> The point is that these types of changes are not upstreamable. And the
> >> conditions would also be awful. Having these changes in separate branch
> >> would be much preferable IMO, because honestly, I would like every
> >> Fedora maintainer save from this cruft not because I would like to hide
> >> something, but for their own sanity.
> > I disagree actually.
> >
> > Disabling docs to reduce dependencies makes sense. And it is not a
> > RHEL-only thing.
>
>
> I am sorry but you have not passed the test. The test question was "Now
> somebody tell me what it does for what
> purpose and which scenario from the above three should be applied here."
> I would really appreciate, if you could pay  attention to the two
> patches I post and what they do. Including careful analysis why they
> were applied and why they were not put into Fedora nor upstreamed.
>
> Hint: They don't disable any documentation.

You put two patches on the thread without context. I assumed that they
remove t

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-26 Thread Aleksandra Fedorova

Hi, Neil,

On Thu, Mar 26, 2020 at 2:41 PM Neal Gompa  wrote:
>
> On Thu, Mar 26, 2020 at 7:41 AM Aleksandra Fedorova  
> wrote:
> >
> > On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch  wrote:
> > >
> > >
> > > Dne 25. 03. 20 v 20:22 James Cassell napsal(a):
> > > > On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
> > > >> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
> > > >>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
> > > > [snip]
> > > >>>> We can come up with guidelines, for example:
> > > >>>>
> > > >>>> 1) Try to find a way to resolve the issue without any conditionals 
> > > >>>> first.
> > > >>>>
> > > >>>> There should be a reason why package X needs a dependency Y in Fedora
> > > >>>> and there should be a reason why it is a required dependency and not 
> > > >>>> a
> > > >>>> recommended one. So why in that case downstream wants it differently?
> > > >>>> The first approach is just to talk through it. I can assume cases
> > > >>>> where downstream adds a dependency, as well as Fedora package 
> > > >>>> removing
> > > >>>> them.
> > > >>>>
> > > >>>> Note that bloated dependency trees is a common problem for all binary
> > > >>>> distributions, it is not an "EL-thing" and we can work on that
> > > >>>> together.
> > > >>>>
> > > >>>> Nicolas has pointed out to another reason why we would get
> > > >>>> EL-conditionals: the outdated rpm stack in RHEL. But we don't have
> > > >>>> this problem with ELN, as we are building Rawhide, and rpm stack is
> > > >>>> going to be the Rawhide rpm stack as well.
> > > >>>>
> > > >>>> 2) Minimize and isolate the conditional, and track the reason.
> > > >>>>
> > > >>>> As ELN SIG we need to have a place where we collect known reasons for
> > > >>>> such conditionals. The overall goal is to reduce this set, not to 
> > > >>>> grow
> > > >>>> indefinitely. As Stephen said we expect it to be about couple of
> > > >>>> hundred packages. We will be able to track each one of them. (We have
> > > >>>> rpminspect to run package diffs for us).
> > > >>>>
> > > >>>> 3) In complex cases - bring it to community and FESCo.
> > > >>>>
> > > >>>> We don't know what those complex cases might be, one of the goals is
> > > >>>> to find them. So we keep it as an option to bring individual case to 
> > > >>>> a
> > > >>>> wider audience. To ask for help and to decide on it.
> > > >>>>
> > > >>> It seems there are missing real life examples of what we sometimes do 
> > > >>> in
> > > >>> RHEL, so please see attached patch. This patch is coming from RHEL
> > > >>> version of the espeak-ng. Now somebody tell me what it does for what
> > > >>> purpose and which scenario from the above three should be applied 
> > > >>> here.
> > > >>>
> > > >>>
> > > >>> Vít
> > > >>>
> > > >> And here is another example for the curious.
> > > >>
> > > > Both of these examples have to do with docs generation and trying to 
> > > > reduce dependencies for that process. "Process the man page using 
> > > > kramdown and remove the ronn dependency."
> > >
> > >
> > > The point is that these types of changes are not upstreamable. And the
> > > conditions would also be awful. Having these changes in separate branch
> > > would be much preferable IMO, because honestly, I would like every
> > > Fedora maintainer save from this cruft not because I would like to hide
> > > something, but for their own sanity.
> >
> > I disagree actually.
> >
> > Disabling docs to reduce dependencies makes sense. And it is not a
> > RHEL-only thing.
> >
> > I had the conversation at the latest Devconf with people who are
> > aiming to build Linux distribution with a reduced buildroot footprint
> > for security purposes. So tha

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-26 Thread Aleksandra Fedorova

On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch  wrote:
>
>
> Dne 25. 03. 20 v 20:22 James Cassell napsal(a):
> > On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
> >> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
> >>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
> > [snip]
> >>>> We can come up with guidelines, for example:
> >>>>
> >>>> 1) Try to find a way to resolve the issue without any conditionals first.
> >>>>
> >>>> There should be a reason why package X needs a dependency Y in Fedora
> >>>> and there should be a reason why it is a required dependency and not a
> >>>> recommended one. So why in that case downstream wants it differently?
> >>>> The first approach is just to talk through it. I can assume cases
> >>>> where downstream adds a dependency, as well as Fedora package removing
> >>>> them.
> >>>>
> >>>> Note that bloated dependency trees is a common problem for all binary
> >>>> distributions, it is not an "EL-thing" and we can work on that
> >>>> together.
> >>>>
> >>>> Nicolas has pointed out to another reason why we would get
> >>>> EL-conditionals: the outdated rpm stack in RHEL. But we don't have
> >>>> this problem with ELN, as we are building Rawhide, and rpm stack is
> >>>> going to be the Rawhide rpm stack as well.
> >>>>
> >>>> 2) Minimize and isolate the conditional, and track the reason.
> >>>>
> >>>> As ELN SIG we need to have a place where we collect known reasons for
> >>>> such conditionals. The overall goal is to reduce this set, not to grow
> >>>> indefinitely. As Stephen said we expect it to be about couple of
> >>>> hundred packages. We will be able to track each one of them. (We have
> >>>> rpminspect to run package diffs for us).
> >>>>
> >>>> 3) In complex cases - bring it to community and FESCo.
> >>>>
> >>>> We don't know what those complex cases might be, one of the goals is
> >>>> to find them. So we keep it as an option to bring individual case to a
> >>>> wider audience. To ask for help and to decide on it.
> >>>>
> >>> It seems there are missing real life examples of what we sometimes do in
> >>> RHEL, so please see attached patch. This patch is coming from RHEL
> >>> version of the espeak-ng. Now somebody tell me what it does for what
> >>> purpose and which scenario from the above three should be applied here.
> >>>
> >>>
> >>> Vít
> >>>
> >> And here is another example for the curious.
> >>
> > Both of these examples have to do with docs generation and trying to reduce 
> > dependencies for that process. "Process the man page using kramdown and 
> > remove the ronn dependency."
>
>
> The point is that these types of changes are not upstreamable. And the
> conditions would also be awful. Having these changes in separate branch
> would be much preferable IMO, because honestly, I would like every
> Fedora maintainer save from this cruft not because I would like to hide
> something, but for their own sanity.

I disagree actually.

Disabling docs to reduce dependencies makes sense. And it is not a
RHEL-only thing.

I had the conversation at the latest Devconf with people who are
aiming to build Linux distribution with a reduced buildroot footprint
for security purposes. So that they can audit the content of the
buildroot, and get to a certain level of certification with it.
I think It can not be done directly in Fedora, but if we add the
flexibility into our builds (with conditionals), then we could
eventually get a new downstream supported by a certain governmental
entity.

What we should avoid is using conditionals randomly and inconsistently.

So let's agree that we are not scattering "%if 0%{?rhel} && (!
0%{?epel})" all over the spec file, but rather define it once at the
top of the spec file:

%if 0%{?rhel} && (! 0%{?epel})
%bcond_with docs
%else
%bcond_without docs
%endif

And use later in a form
...
%if %{with doc}
%package doc
...
%endif

Yes, for now we would go with a "%if 0%{?rhel} && (! 0%{?epel})" in
the header of the affected spec file. But eventually we can think
about adding a USE-flag like functionality to the build process, and
create a global profile for the build system.
This is a very much forward-looking statement, but idea is already
making its round by the dnf team.

So there are some interesting ways how this approach can be developed
further, if we can make it work for a smaller subset first.

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On Wed, Mar 25, 2020 at 3:10 PM Miro Hrončok  wrote:
>
> On 25. 03. 20 14:06, Aleksandra Fedorova wrote:
> >>> By contributing to Fedora Rawhide sources and consuming them as ELN
> >>> repositories for testing purposes.
> >>
> >> The change proposal literally says "There is no user-facing part in this 
> >> change.
> >> No ELN artifacts are going to be shipped to the end-user."
> >>
> >> As a contributor, how do I consume the content if I cannot consume the 
> >> content?
> >> As I understand it, the "end-user" and "user-facing" terms must have 
> >> different
> >> meanings in this context, right? What is this meaning?
> >
> > Looks like terminology issue. For me user is a person who uses
> > released Fedora, like Fedora 31 Workstation, on their laptop, or
> > Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
> > for Fedora server.
> > Basically anyone who needs Fedora to solve their own problems, which
> > are not related to development of the distribution.
> >
> > Fedora Rawhide is not a user-facing branch in Fedora, because it's
> > purpose is to develop Fedora, not something else.
> > Same with ELN. It is not a Fedora Server edition, there is no reason
> > to ever use it on a server. It is a rebuild of Fedora Rawhide, and
> > it's purpose is the development of Fedora, and help others to
> > contribute to that development.
> >
> > So it is facing contributors, not users.
> >
> > Different types of contributors though.
>
> I consider rawhide users our users and I assume many other do consider them 
> our
> users as well. I consider upstream projects who run their CI on Fedora our
> users. You are not incorrect that this is a terminology issue, however I think
> this is a different mindset issue. Please do consider rawhide users and 
> upstream
> projects our users when designing things.

You are misinterpreting what I said. And it is a terminology issue.

You somehow assume that if we call people users - we care about them,
and if we call them contributors, they are _just_ contributors, so we
don't.
This is not what I have said, and please don't put such a mindset on me.

The difference between users and contributors is not how you treat
them, but a level of knowledge about Fedora internals which is
expected from them.
Using rawhide on your workstation is possible, but you need to learn
first what rawhide is and you need to make an educated choice to use
it.
Same with ELN.

It does not have impact on Fedora Workstation user experience. My
grandma, who is Fedora user since Fedora 8, will not see this change
on her laptop and she doesn't need to be informed about it.

> For example, there is a point to run an ELN on a server - e.g. to run a 
> buildbot
> worker on it for some CI tests.

I think this is not the server Neil meant.
My point was to highlight that ELN is not a "stable edition" like
Fedora Server. ELN is Rawhide, its quality is no better than Rawhide
quality, its stability is Rawhide stability, its target audience is
Rawhide audience.

>
> >> I'd rather discuss this here and only come to FPC for approval of new 
> >> guidelines
> >> when ready. The FPC members who are likely to discuss this are already
> >> discussing this here. Why spitting the discussion into two places?
> >
> > Sorry, my understanding of why we need RelEng and FPC tickets was
> > completely the opposite. Mailing list discussion about the Change is
> > generic, and gets side-tracked to one side or the other and digging
> > through it to get the pieces which are relevant to FPC topic is
> > harder. While ticket has a fixed topic, discussion associated to it
> > and the outcome of that discussion. I don't see how you can prevent
> > people from discussing the topic in the ticket and move it to the
> > mailing list.
> >
> > If you see FPC ticket as a "request to vote" only, why do we need it
> > then? Can't we just invite FPC representative to vote on a FESCo
> > ticket?
>
> We could, but there are existing workflows based on the committees using their
> own ticketing tracker to do the voting.

Ok.

>
> >> This is all nice only as long as you prefer conditionals over branching. 
> >> For a
> >> Fedora maintainer who doesn't, this is just "unnecessary cruft" in the 
> >> spec file.
> >
> > It is not really about personal preferences. These are two different
> > approaches with different purposes, different results and different
> > requirements.
> > There are consequences on choosing one other the oth

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

Hi, Miro,

On Wed, Mar 25, 2020 at 1:28 PM Miro Hrončok  wrote:
>
> On 25. 03. 20 12:49, Aleksandra Fedorova wrote:
> > Going back to the questions. See comments inline.
>
> Thanks.
>
> >>> The goal of the ELN project is to continuously build Fedora Rawhide
> >>> packages and composes in the way which resembles the CentOS and RHEL
> >>> build process and to provide a feedback loop for Fedora maintainers on
> >>> the status of those builds.
> >>
> >> Form a Fedora POV, this doesn't state what's being "changed" at all.
> >> I would appreciate if it actually said something about the ELN Buildroot 
> >> and
> >> Compose.
> >
> > It says that we are going to continuously build el-like compose. We
> > are adding new pieces of infrastructure to make that happen.
> > This is an infrastructure change, which doesn't change Fedora content.
>
> It will eventually change Fedora sources. But even with "this doesn't change
> anything" argument, I find the current summary confusing a bit without reading
> the rest of the proposal. Can a second sentence like "A new buildroot will be
> added Koji that will automatically build packages from master but it have a
> different set of macros and config." be added?
>
> >>> ELN is an evolution of the request for an alternate buildroot for
> >>> newer x86_64 processors. The reasoning behind that new buildroot was
> >>> that we expected that the next major release of RHEL would likely drop
> >>> support for older hardware and therefore could take advantage of
> >>> enhancements and processor extensions available for newer hardware. As
> >>> plans for this proceeded, they expanded into a desire to do more than
> >>> just test out the processor architecture. Instead, we want to have a
> >>> complete alternative compose of Fedora Rawhide that resembles the way
> >>> that Red Hat and CentOS builds their packages. The idea being that
> >>> Fedora developers and third-party vendors who rely on Red Hat
> >>> Enterprise Linux have a place where they can directly contribute to
> >>> what will eventually become the next RHEL.
> >>
> >> I don't understand from the rest of the change how do they contribute to 
> >> ELN.
> >
> > By contributing to Fedora Rawhide sources and consuming them as ELN
> > repositories for testing purposes.
>
> The change proposal literally says "There is no user-facing part in this 
> change.
> No ELN artifacts are going to be shipped to the end-user."
>
> As a contributor, how do I consume the content if I cannot consume the 
> content?
> As I understand it, the "end-user" and "user-facing" terms must have different
> meanings in this context, right? What is this meaning?

Looks like terminology issue. For me user is a person who uses
released Fedora, like Fedora 31 Workstation, on their laptop, or
Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
for Fedora server.
Basically anyone who needs Fedora to solve their own problems, which
are not related to development of the distribution.

Fedora Rawhide is not a user-facing branch in Fedora, because it's
purpose is to develop Fedora, not something else.
Same with ELN. It is not a Fedora Server edition, there is no reason
to ever use it on a server. It is a rebuild of Fedora Rawhide, and
it's purpose is the development of Fedora, and help others to
contribute to that development.

So it is facing contributors, not users.

Different types of contributors though.

> >>> ELN (Enterprise Linux Next) is going to be that place. What we want to
> >>> do is establish a set of RPM conditionals that can be used for the set
> >>> of packages that may need to be built differently for a RHEL-like
> >>> target as compared to a Fedora one. (For example, we may want to skip
> >>> regenerating documentation during package-build and instead use
> >>> pre-built docs from the tarball or SRPM.)
> >>
> >> What set of RPM conditionals? This is more clear from the FPC ticket:
> >>
> >> https://pagure.io/packaging-committee/issue/955
> >>
> >> But even there, it seem that any new conditionals will be discouraged, so 
> >> what
> >> are the new conditionals this change is talking about?
> >
> > As a nitpick, it doesn't say _new_ conditionals there. As we don't
> > want to branch Fedora Rawhide we need a possibility for certain
> > package to be built differently in the ELN environment.
>
> The ticket says the "new" c

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On Wed, Mar 25, 2020 at 12:48 PM Miro Hrončok  wrote:
>
> On 25. 03. 20 12:37, Fabio Valentini wrote:
> >> So let's assume for the sake of the argument, that Python is broken in ELN 
> >> and
> >> the Python maintainers don't want 0%{?rhel}/0%{?eln} conditionals in their 
> >> spec
> >> files. Now all 3600+ Python packages will fail to build in ELN because of 
> >> this
> >> and the feedback provided in bodhi will be moot. What will happen then?
> > What about using an additional "eln" branch in dist-git?
> >
> > - For most packages, the master branch should be able to be merged
> > into eln regularly (or even automatically, triggered by master
> > commits).
> > - For the packages that need "unacceptable in master" adjustments, an
> > automatic rebase on top of new master commits could be attempted, and
> > if that fails, human intervention is necessary anyway.
>
> Yes, that makes sense to me. Especially with automation (bacause without it, 
> the
> branch would simply get stalled, you cannot rebase all Fedora packages 
> manually
> at this scale).

As I mentioned in the previous mail, branching goes against the
purpose of the effort.

What we like to achieve is to create a continuous flow from Fedora
Rawhide through branched Fedora all the way to downstream, which is
sometimes CentOS and sometimes EPEL.

Doing this with branches is going to be much harder. When you update
package with conditionals you do need to care about the effect on
various ifs, but you do need to change the package only once at one
place. And then the tree of branches which we create from Fedora
Rawhide will get this change automatically with no effort.

Of course not ifs are equal. It may require some refactoring on the
code side to make the ifs cleaner. I know kernel people did that with
a kernel package to reorganize patches which are applied.

But this is exactly the work we are looking for: the negotiation
between downstream maintainers and Fedora maintainers to make things
work together. We already have branching, it is easier as it allow us
not to talk to each other, but it doesn't solve anything.

And yes, it means that people are going to be _bothered_, and
_pressured_ on figuring out the best way to collaborate. But isn't it
our job?

And again, if you make it easier for downstream to work with Fedora,
you give downstream the reasons to bring their resources. Things like
quality assurance and help with bug triage and bug fixes, things like
cross-project feature development. This is a two-way collaboration
effort.

>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

Going back to the questions. See comments inline.

On Tue, Mar 24, 2020 at 3:17 PM Miro Hrončok  wrote:
>
> On 24. 03. 20 10:32, Aleksandra Fedorova wrote:
> > As Ben is on PTO, I'd like to present the System-Wide Change
> >
> > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> >
> > == Summary ==
> >
> > The goal of the ELN project is to continuously build Fedora Rawhide
> > packages and composes in the way which resembles the CentOS and RHEL
> > build process and to provide a feedback loop for Fedora maintainers on
> > the status of those builds.
>
> Form a Fedora POV, this doesn't state what's being "changed" at all.
> I would appreciate if it actually said something about the ELN Buildroot and
> Compose.

It says that we are going to continuously build el-like compose. We
are adding new pieces of infrastructure to make that happen.
This is an infrastructure change, which doesn't change Fedora content.

> > ELN is an evolution of the request for an alternate buildroot for
> > newer x86_64 processors. The reasoning behind that new buildroot was
> > that we expected that the next major release of RHEL would likely drop
> > support for older hardware and therefore could take advantage of
> > enhancements and processor extensions available for newer hardware. As
> > plans for this proceeded, they expanded into a desire to do more than
> > just test out the processor architecture. Instead, we want to have a
> > complete alternative compose of Fedora Rawhide that resembles the way
> > that Red Hat and CentOS builds their packages. The idea being that
> > Fedora developers and third-party vendors who rely on Red Hat
> > Enterprise Linux have a place where they can directly contribute to
> > what will eventually become the next RHEL.
>
> I don't understand from the rest of the change how do they contribute to ELN.

By contributing to Fedora Rawhide sources and consuming them as ELN
repositories for testing purposes. But also by contributing directly
to ELN compose configuration.

> > ELN (Enterprise Linux Next) is going to be that place. What we want to
> > do is establish a set of RPM conditionals that can be used for the set
> > of packages that may need to be built differently for a RHEL-like
> > target as compared to a Fedora one. (For example, we may want to skip
> > regenerating documentation during package-build and instead use
> > pre-built docs from the tarball or SRPM.)
>
> What set of RPM conditionals? This is more clear from the FPC ticket:
>
> https://pagure.io/packaging-committee/issue/955
>
> But even there, it seem that any new conditionals will be discouraged, so what
> are the new conditionals this change is talking about?

As a nitpick, it doesn't say _new_ conditionals there. As we don't
want to branch Fedora Rawhide we need a possibility for certain
package to be built differently in the ELN environment. For that we
need rpm conditionals based on disttag.

This is a chicken and egg problem, to be honest. To figure out the
details we need FPC and others contribution, but then to start talking
to FPC we need a Change Proposal so that you get the idea what are we
trying to achieve and why.

> > This includes:
> >
> > * buildroot configuration, rpm macro and compile flags,
> > * comps files and the compose content,
> > * compose itself and the pipeline which builds it.
>
> Where are those rpm macros and compile flags be defined if this builds from
> master? Will there be an alternative branch for (and only for)
> redhat-rpm-config, or will redhat-rpm-config be full of such new conditionals?
> Are the maintainers of redhat-rpm-config on board?
>
> > ... Some unknown number of packages that rely on `if !
> > 0%{?fedora}` will require manual intervention.
>
> And many other cases, see the FPC ticket.

Let's discuss it in the ticket then?

> > * CentOS Stream, EPEL and RHEL
> > ** We are going to build Fedora packages into a compose similar to the
> > multi-repo structure of CentOS and RHEL.
>
> This lacks any details in the description.

I am not sure what kind of details you expect.

Will it help if I add a link to CentOS compose? Like this one
http://mirror.centos.org/centos/8.1.1911/

>
> > ** The feedback pipelines built for the project will allow downstream
> > developers to open up their work and bring it closer to Fedora. In
> > particular, it will enable projects like OpenShift to do their work in
> > Fedora.
>
> I don't understand how. Do you have more details?

For third-parties who develop services and tools for CentOS and RHEL
it is important to have development environment which is close to what
they will achieve in the r

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On Tue, Mar 24, 2020 at 6:01 PM Miro Hrončok  wrote:
>
> On 24. 03. 20 16:23, Aleksandra Fedorova wrote:
> > I am going to answer generally in this mail, before we dive in into
> > discussing the details.
> >
> > I think your approach to assessment of the Change is not fair.
>
> Ouch. It's just that reading the proposal raises all of those questions. Sorry
> if that's not fair.

Sorry if that sounded offensive. I didn't really mean it. And I am not
against asking questions, please do.

I do think that not all questions need to be answered now. Not all an
be answered and not all should. So I was trying to propose splitting
it up into what needs to be decided now, and why. And what can be left
later.

But going too meta probably was a wrong move by me here. So let's get
back to the actual questions.

> > It is an infrastructure change, not a code one. Figuring out all of
> > the questions you are asking is exactly what this change is about. And
> > you are requesting that we put the entire solution into the change
> > proposal. This is not going to work this way. And it shouldn't work
> > this way.
>
> The way I see it, it, the change proposal currently describes an "idea".
> I would like it to describe how things are planned to work (at least an 
> initial
> plan for that).
>
> > There is a reason why Change Template has Description section and does
> > not have Design or Implementation. Because design and implementation
> > are left for the owners of the change as we will figure out the
> > details on our way to it.
> >
> > The goal of the Change process is to assess the idea, the impact, to
> > check whether there is a disruption this change brings, and to find
> > people who are interested in it. Then we can work on the change
> > together, working through all those questions you have mentioned.
>
> I wasn't aware that this is the change process goal. Most of the (approved)
> changes in Fedora actually describe what's going to happen. Changes that only
> describe the end goal are often rejected or significantly amended.
>
> "Change proposals should be shared as early as possible, before the change is
> implemented and even in the very early state of the idea, to gather community
> feedback and review."
>
> https://docs.fedoraproject.org/en-US/program_management/changes_policy/
>
> This exactly happened here and I am glad it did. But in my opinion, outright
> rejecting the feedback is not fair either.
>
> > You are asking good questions and I value your feedback. But yes, the
> > current answer to most of them is "we do not know yet".
> > For example, even though the structure of the buildroot is proposed in
> > the releng ticket, and we would like it to inherit rawhide buildroot
> > at this point, we may want to change it later.
> >
> > So I'd ask you to split the conversation into two parts:
> >
> > 1) what are the expectation, requirements, impact and risk for this Change
> > This is what we do need to add into the Change proposal, as it sets
> > the boundaries in which we should operate.
>
> The main risk I see is that this will generate a need for mass pushing various
> conditionals all over Fedora. And while some maintainers like those, some 
> don't.
> And I'm afraid this is not fair to them, if we approve this without knowing.

Do you have a suggestion, how to make it clear that there will be no
enforcement?

We've put it in the proposal that we are going to provide feedback in
terms of test results visible on the bodhi page using Rawhide Gating.
There are no plans to make gating on that test mandatory, as we leave
it to package maintainers to configure gating in general.

We may also propose pull requests with changes to some packages when
we'd like to suggest a fix for the dependency or adjust compile flags.

> The change should at least describe what level of involvement is required from
> other contributors. It it is "no involvement needed" and "we will not bother 
> you
> with conditionals" than I see no risk for Fedora (distro) (but I see a huge 
> risk
> for the ELN project, because it will be unable to fix itself).

The answer here is that we _may_ bother you with conditionals, but we
don't know yet how often it may happen.
Do you want us to keep track on usage of %{eln} in spec files? I think
this is doable.

> > 2) how it is going to work
> > This goes to design docs and implementation. We will definitely take
> > all comments from the mailing thread into account. As soon as we
> > figure out the place where we track the effort (most likely, Taiga) we
> > will transfer it all there. But we would like to postpone making
> >

Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

As Ben is on PTO, I'd like to present the System-Wide Change

https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose

== Summary ==

The goal of the ELN project is to continuously build Fedora Rawhide
packages and composes in the way which resembles the CentOS and RHEL
build process and to provide a feedback loop for Fedora maintainers on
the status of those builds.

== Owner ==

* Name: [[User:Bookwar| Aleksandra Fedorova]]
* Email: al...@bookwar.info
* Name: [[User:Sgallagh | Stephen Gallagher]]
* Email: sgall...@redhat.com

== Detailed Description ==

This Change supersedes the previously-approved [[Changes/Additional
buildroot to test x86-64 micro-architecture update|Change]] to enable
an additional buildroot. During development, its scope has expanded to
include the entire process of how the Fedora sources are built and
composed into shippable artifacts.

ELN is an evolution of the request for an alternate buildroot for
newer x86_64 processors. The reasoning behind that new buildroot was
that we expected that the next major release of RHEL would likely drop
support for older hardware and therefore could take advantage of
enhancements and processor extensions available for newer hardware. As
plans for this proceeded, they expanded into a desire to do more than
just test out the processor architecture. Instead, we want to have a
complete alternative compose of Fedora Rawhide that resembles the way
that Red Hat and CentOS builds their packages. The idea being that
Fedora developers and third-party vendors who rely on Red Hat
Enterprise Linux have a place where they can directly contribute to
what will eventually become the next RHEL.

ELN (Enterprise Linux Next) is going to be that place. What we want to
do is establish a set of RPM conditionals that can be used for the set
of packages that may need to be built differently for a RHEL-like
target as compared to a Fedora one. (For example, we may want to skip
regenerating documentation during package-build and instead use
pre-built docs from the tarball or SRPM.)

This includes:

* buildroot configuration, rpm macro and compile flags,
* comps files and the compose content,
* compose itself and the pipeline which builds it.

Under this umbrella we are going to have:
* RPM variables for conditionals to allow tweaking rpm spec files
* A new Koji tag which allows control of the buildroot,
* A fork of the pungi configuration which describes the compose configuration,
* A pipeline which builds a periodic compose based on that configuration,
* Storage for such composes and additional pipelines which will verify
the quality of the compose and test additional scenarios on top of it.

The RPM variables:

* `%{dist}` will return `.eln` (no numerical suffix)
* `%{fedora}` will return `.fcXX` (where XX is the Fedora version
represented by Rawhide).
* `%{rhel}` will be set and will return a number one higher than the
most recent major release of Red Hat Enterprise Linux (at present,
that will be `9`).
* `%{eln}` will be set and will expand to `%{rhel}`

The reasoning behind this approach is so that we break as little as
possible when we implement this new build and compose. Existing
packages that are using conditionals such as `if 0%{?rhel} > 7` will
transition over to building "like RHEL" automatically. Any packages
that do not have a shared Fedora/RHEL specfile will continue to build
as normal. Some unknown number of packages that rely on `if !
0%{?fedora}` will require manual intervention.

The `%{eln}` variable will be set primarily to allow for the
possibility of needing conditionals that apply to ELN only and should
not carry over to RHEL, but we expect its use to be exceptionally
rare.

== Benefit to Fedora ==

Who benefits from the implementation of this feature:
* Fedora Infrastructure
** As we are going to try and test new, more easily maintainable
infrastructure for composes.
* Fedora Minimization
** As we are going to modify the compose content according to
minimization goals and provide feedback to Fedora maintainers on the
results
* CentOS Stream, EPEL and RHEL
** We are going to build Fedora packages into a compose similar to the
multi-repo structure of CentOS and RHEL.
* Fedora Community
** The feedback pipelines built for the project will allow downstream
developers to open up their work and bring it closer to Fedora. In
particular, it will enable projects like OpenShift to do their work in
Fedora.
** Making Fedora friendlier to its downstream will justify bringing
more resources and more contributions to Fedora Rawhide. So that
downstream not only tries to catch up with Fedora going forward, but
actively participates in Fedora development and testing.
** The tooling developed for this project will allow further
development of changes in Fedora Infrastructure without blocking the
regular Fedora packaging and release process.

== Scope ==
* Proposal owners:
** Setup build environment for a new disttag (`eln`).
** Setup automati

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On Tue, Mar 24, 2020 at 3:17 PM Miro Hrončok  wrote:
>
> On 24. 03. 20 10:32, Aleksandra Fedorova wrote:
> > As Ben is on PTO, I'd like to present the System-Wide Change
> >
> > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> >
> > == Summary ==
> >
> > The goal of the ELN project is to continuously build Fedora Rawhide
> > packages and composes in the way which resembles the CentOS and RHEL
> > build process and to provide a feedback loop for Fedora maintainers on
> > the status of those builds.
>
> Form a Fedora POV, this doesn't state what's being "changed" at all.
> I would appreciate if it actually said something about the ELN Buildroot and
> Compose.
>
> > ELN is an evolution of the request for an alternate buildroot for
> > newer x86_64 processors. The reasoning behind that new buildroot was
> > that we expected that the next major release of RHEL would likely drop
> > support for older hardware and therefore could take advantage of
> > enhancements and processor extensions available for newer hardware. As
> > plans for this proceeded, they expanded into a desire to do more than
> > just test out the processor architecture. Instead, we want to have a
> > complete alternative compose of Fedora Rawhide that resembles the way
> > that Red Hat and CentOS builds their packages. The idea being that
> > Fedora developers and third-party vendors who rely on Red Hat
> > Enterprise Linux have a place where they can directly contribute to
> > what will eventually become the next RHEL.
>
> I don't understand from the rest of the change how do they contribute to ELN.
>
> > ELN (Enterprise Linux Next) is going to be that place. What we want to
> > do is establish a set of RPM conditionals that can be used for the set
> > of packages that may need to be built differently for a RHEL-like
> > target as compared to a Fedora one. (For example, we may want to skip
> > regenerating documentation during package-build and instead use
> > pre-built docs from the tarball or SRPM.)
>
> What set of RPM conditionals? This is more clear from the FPC ticket:
>
> https://pagure.io/packaging-committee/issue/955
>
> But even there, it seem that any new conditionals will be discouraged, so what
> are the new conditionals this change is talking about?
>
> > This includes:
> >
> > * buildroot configuration, rpm macro and compile flags,
> > * comps files and the compose content,
> > * compose itself and the pipeline which builds it.
>
> Where are those rpm macros and compile flags be defined if this builds from
> master? Will there be an alternative branch for (and only for)
> redhat-rpm-config, or will redhat-rpm-config be full of such new conditionals?
> Are the maintainers of redhat-rpm-config on board?
>
> > ... Some unknown number of packages that rely on `if !
> > 0%{?fedora}` will require manual intervention.
>
> And many other cases, see the FPC ticket.
>
> > * CentOS Stream, EPEL and RHEL
> > ** We are going to build Fedora packages into a compose similar to the
> > multi-repo structure of CentOS and RHEL.
>
> This lacks any details in the description.
>
> > ** The feedback pipelines built for the project will allow downstream
> > developers to open up their work and bring it closer to Fedora. In
> > particular, it will enable projects like OpenShift to do their work in
> > Fedora.
>
> I don't understand how. Do you have more details?
>
> > == Scope ==
> > * Proposal owners:
> > ** Setup build environment for a new disttag (`eln`).
> > ** Setup automation to trigger new ELN build every time there is a new
> > update submitted to Fedora Rawhide.
> > ** Post build result to Fedora Messaging, so that it appears in Bodhi
> > and can be used as a
> > [https://docs.fedoraproject.org/en-US/rawhide-gating/ gating test].
> > ** Setup automation to run periodic partial composes (via ODCS)
> > without installation media to generate repositories with these
> > packages.
> > ** Update packaging documentation to mention new disttag and how it can be 
> > used.
> >
> > * Other developers:
> > *: Anyone who wants to produce different content for the ELN compose
> > will need to implement the new macros in their specfile. The
> > overwhelming majority of packages will require no modification.
>
> I don't understand the meaning of "implement the new macros". Do I read it 
> that
> if I want to produce different content for the ELN compose, I need to use %if
> conditionals for %{rhel}? What if I don't want such conditionals, because I
> p

Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

As Ben is on PTO, I'd like to present the System-Wide Change

https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose

== Summary ==

The goal of the ELN project is to continuously build Fedora Rawhide
packages and composes in the way which resembles the CentOS and RHEL
build process and to provide a feedback loop for Fedora maintainers on
the status of those builds.

== Owner ==

* Name: [[User:Bookwar| Aleksandra Fedorova]]
* Email: al...@bookwar.info
* Name: [[User:Sgallagh | Stephen Gallagher]]
* Email: sgall...@redhat.com

== Detailed Description ==

This Change supersedes the previously-approved [[Changes/Additional
buildroot to test x86-64 micro-architecture update|Change]] to enable
an additional buildroot. During development, its scope has expanded to
include the entire process of how the Fedora sources are built and
composed into shippable artifacts.

ELN is an evolution of the request for an alternate buildroot for
newer x86_64 processors. The reasoning behind that new buildroot was
that we expected that the next major release of RHEL would likely drop
support for older hardware and therefore could take advantage of
enhancements and processor extensions available for newer hardware. As
plans for this proceeded, they expanded into a desire to do more than
just test out the processor architecture. Instead, we want to have a
complete alternative compose of Fedora Rawhide that resembles the way
that Red Hat and CentOS builds their packages. The idea being that
Fedora developers and third-party vendors who rely on Red Hat
Enterprise Linux have a place where they can directly contribute to
what will eventually become the next RHEL.

ELN (Enterprise Linux Next) is going to be that place. What we want to
do is establish a set of RPM conditionals that can be used for the set
of packages that may need to be built differently for a RHEL-like
target as compared to a Fedora one. (For example, we may want to skip
regenerating documentation during package-build and instead use
pre-built docs from the tarball or SRPM.)

This includes:

* buildroot configuration, rpm macro and compile flags,
* comps files and the compose content,
* compose itself and the pipeline which builds it.

Under this umbrella we are going to have:
* RPM variables for conditionals to allow tweaking rpm spec files
* A new Koji tag which allows control of the buildroot,
* A fork of the pungi configuration which describes the compose configuration,
* A pipeline which builds a periodic compose based on that configuration,
* Storage for such composes and additional pipelines which will verify
the quality of the compose and test additional scenarios on top of it.

The RPM variables:

* `%{dist}` will return `.eln` (no numerical suffix)
* `%{fedora}` will return `.fcXX` (where XX is the Fedora version
represented by Rawhide).
* `%{rhel}` will be set and will return a number one higher than the
most recent major release of Red Hat Enterprise Linux (at present,
that will be `9`).
* `%{eln}` will be set and will expand to `%{rhel}`

The reasoning behind this approach is so that we break as little as
possible when we implement this new build and compose. Existing
packages that are using conditionals such as `if 0%{?rhel} > 7` will
transition over to building "like RHEL" automatically. Any packages
that do not have a shared Fedora/RHEL specfile will continue to build
as normal. Some unknown number of packages that rely on `if !
0%{?fedora}` will require manual intervention.

The `%{eln}` variable will be set primarily to allow for the
possibility of needing conditionals that apply to ELN only and should
not carry over to RHEL, but we expect its use to be exceptionally
rare.

== Benefit to Fedora ==

Who benefits from the implementation of this feature:
* Fedora Infrastructure
** As we are going to try and test new, more easily maintainable
infrastructure for composes.
* Fedora Minimization
** As we are going to modify the compose content according to
minimization goals and provide feedback to Fedora maintainers on the
results
* CentOS Stream, EPEL and RHEL
** We are going to build Fedora packages into a compose similar to the
multi-repo structure of CentOS and RHEL.
* Fedora Community
** The feedback pipelines built for the project will allow downstream
developers to open up their work and bring it closer to Fedora. In
particular, it will enable projects like OpenShift to do their work in
Fedora.
** Making Fedora friendlier to its downstream will justify bringing
more resources and more contributions to Fedora Rawhide. So that
downstream not only tries to catch up with Fedora going forward, but
actively participates in Fedora development and testing.
** The tooling developed for this project will allow further
development of changes in Fedora Infrastructure without blocking the
regular Fedora packaging and release process.

== Scope ==
* Proposal owners:
** Setup build environment for a new disttag (`eln`).
** Setup automati

Re: Fedora CI update 2020-03-11

2020-03-12 Thread Aleksandra Fedorova

Hi,

On Thu, Mar 12, 2020 at 10:46 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> Hi,
> thanks for the update, it seems nice progress is being made.
>
> > ### Dist-git tests support multipackage updates
> >
> > You can define package tests in dist-git via STR format
> >
> > https://docs.fedoraproject.org/en-US/ci/standard-test-roles/
>
> The docs have a "Quick Start Guide", but it describes a relatively
> complex case — the bash package which shares tests with other packages
> using a separate repo, which obviously adds another layer of complexity.
> (The repo we are looking at has a playbook which just clones another
> repo with another playbook, which then runs the playbooks from
> standard-test-roles. Wow.)
>
> Simply following the procedure as described does not work, the command
> fails with "This command has to be run under the root user.". I guess
> 'sudo ...' might be the answer, but it's not obvious, because of the layers
> of indirection. (Should ansible's "become" be used instead?)
>
> The docs also talks about many different kinds of tests... For example
> something using docker. In F32, docker doesn't even run out of the
> box, so it probably shouldn't be mentioned in any kind of beginner
> docs.
>
> In the "Examples" section, there's an example for "did" package.
> I copy-pasted that, and after running it (under sudo), the command
> does not fail, but it seems the tests failed based on the text output.
> This made me realize that the docs don't describe how to check if
> the tests pass. (I hope reading the transcript is not the answer.)
>
> There's a mention somewhere that this destructively modifies the host
> machine, and using a VM is suggested. But not in the "Quick Start
> Guide". I'd expect this to be prominently mentioned at the top.
>
> After looking at the docs as they are, this all seems s complex.
> Maybe this complexity is unavoidable, but I would love to see an
> introductory howto, from beginning to the checking of the test
> results and hooking up to bodhi gating, for a _simple_ case, in
> particular no separate tests repo cloned over the network from a
> server.

Thanks for the feedback. I will revise a Quick Start doc and make updates to it.

And I have just pushed the doc I had in drafts for too long, please take a look

https://docs.fedoraproject.org/en-US/ci/how-to-add-dist-git-test/

Dist-git tests are actually easy, I agree we made them look
unnecessarily complex.

>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora CI update 2020-03-11

2020-03-11 Thread Aleksandra Fedorova

Hi,

On Wed, Mar 11, 2020 at 6:14 PM Sudhir D  wrote:
>
>
> On 3/11/20 7:14 PM, Aleksandra Fedorova wrote:
> > Hi, all.
> >
> > Here is the summary of CI-related work happening in Fedora.
> >
> > If you have questions or topics to discuss you can also join Fedora CI
> > SIG bi-weekly meeting. Next session is today in #fedora-ci IRC channel
> > at 15:30 UTC
> >
> > https://apps.fedoraproject.org/calendar/SIGs/#m9618
> >
> > 
> >
> > ### Dist-git tests support multipackage updates
> >
> > You can define package tests in dist-git via STR format
> >
> > https://docs.fedoraproject.org/en-US/ci/standard-test-roles/
> >
> > Note that dist-git/STR tests are different from running %check tests
> > in the rpm building phase. STR tests are executed in a clean virtual
> > machine with proper setup of repositories for the latest Fedora
> > Rawhide packages. This environment is better suited for integration
> > tests, which need to test the installed package, not the sources of
> > it.
> >
> > Dist-git tests are fully compatible with the dynamic sidetag approach:
> > if you create a dynamic sidetag for the multi-package update, test
> > environment will be created with the content of the entire sidetag,
> > not an individual package.
> >
> > Status: Ready to Use
> > Contact: Bruno Goncalves (bgoncalv) and #fedora-ci IRC channel.
> >
> > ### New test: rpminspect
> >
> > There is a new rpminspect test running in Fedora Rawhide gating
> > enabled by default for all packages in a non-blocking mode.
> >
> > More details:
> > https://github.com/rpminspect/rpminspect
> >
> > Status: Ready to Use
> > Contact: David Cantrell (dcantrell)
>
>
> Thanks for sending out all this information, Aleksandra :)
>
> I also want to call out Tim Flink (irc: tflink) from Fedora QA team who
> worked extensively on getting rpminspect to run in a way that its
> results could show up in bodhi.

I somehow took it for granted that everyone knows Tim is there.

Thanks for clearing that out.

> >
> > ### Tests for pull-requests via Zuul
> >
> > Zuul team has enabled Zuul CI engine to test Pagure pull requests.
> >
> > You can opt-in to Zuul CI per package.
> >
> > On every pull-request Zuul will
> > * run a scratch build
> > * run rpminspect on that build
> > * run dist-git test defined in STR format(if available)
> > * provide comment in the pull-request
> > * wait for you to put an manual approval on the PR
> > * merge the PR
> >
> > * you can also get Zuul to handle merge events, so that it will
> > automatically build the regular koji build, after the merge.
> >
> > Zuul now has support for EPEL8 branches.
> >
> > More details:
> > https://fedoraproject.org/wiki/Zuul-based-ci
> >
> > Status: Ready to use
> > Contact: Fabien Boucher (fbo)
> >
> > ### Koschei as a gating test
> >
> > With sidetag gating feature enabled it is now possible to run Koschei
> > for each dynamic sidetag and make it a part of the gating process.
> >
> > We do have Koschei deployed on Fedora infrastructure. There is
> > on-going work by Mikolaj Izdebski to get it integrated with the Fedora
> > Messaging, so that sidetags are submitted in Koschei when created.
> >
> > Status: research and prototyping
> > Contact: Serhii Turivnyi (sturivny)
> >
> > ### Infra change: new Jenkins master
> >
> > New Jenkins master to run generic tests and inherit Taskotron pipelines.
> >
> > Our current Jenkins master, which is used for dist-git tests, was not
> > updated for some time and it is by design bundled to the pipeline it
> > runs. So adding new pipelines and separating pipelines from the
> > Jenkins master configuration is problematic.
> >
> > The goal here is to have a Jenkins master setup which is easy to
> > update. It will have a set of plugins pre-installed and configured for
> > Fedora infrastructure endpoints, but jobs configuration will be
> > applied to it independently.
> >
> > More details:
> > Current work is done on a Communishift project. Code will be available
> > soon at https://github.com/fedora-ci
> >
> > Status: WIP
> > Contact: Jim Bair (jbair)
> >
> > ### Infra change: common repository and common format for generic tests
> >
> > We are refactoring the Groovy pipeline library so it is better suited
> > to run generic tests.
> >
> > One of

Fedora CI update 2020-03-11

2020-03-11 Thread Aleksandra Fedorova

/

Then there is another repository with docs on Rawhide Gating:

https://pagure.io/cpe/rawhide-gating-docs/

And result is available at:

https://docs.fedoraproject.org/en-US/rawhide-gating/

There are some rather deep or generic items there, which are not
always suitable for newcomers and are not easy to consume.

What I think we need is a smaller scale how-to’s answering specific
questions and implementing specific use-cases, which hook the CI and
gating into the packager workflow.

If you have experience with sidetag gating or CI in Fedora and figured
out the way how _you_ work with it, please share.

You can drop me a mail or write a draft page and send a pull request
to one of the repositories. We will figure out later in which section
to land it.

Status: Needs help
Contact: Aleksandra Fedorova (bookwar)

### Testing of GitHub PRs via Packit / Testing Farm on Fedora/CentOS

Packit service makes it possible to test copr builds built from GitHub
PRs on all Fedora released (including Rawhide), CentOS 6/7 and CentOS
stream via Testing Farm. Note that the Testing Farm deployed for
Packit is different from the one we are open sourcing, and once that
is ready i will replace this one.

Documentation:
https://packit.dev/testing-farm/

Status: In production (since August 2019)
Contact: Miroslav Vadkerti (mvadkert)



For any of those topics you can contact Fedora CI SIG at #fedora-ci IRC channel.

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

On Wed, Jan 22, 2020 at 2:21 PM Miro Hrončok  wrote:
>
> On 22. 01. 20 14:03, Aleksandra Fedorova wrote:
> > can we have the power, scalability and feature-richness of a platform
> > like Gerrit, but (optionally) hidden under the hood so that there is a
> > "simple mode" for people who just need a one-time contribution?
>
> I won't go there, becasue I don't think we need the power, scalability and
> feature-richness of a platform like gerrit in the first place.
>
> 1. Not for dist git

This is where we disagree heavily I guess.

We do need scalability, especially if we consider moving from source
tarballs to unpacked sources at some point. And I hope we do (which is
a yet another discussion we need to have).

In my previous life we hosted Gerrit server for the entire custom
Linux distribution (syncing all OpenStack commits in "real-time") on a
VM with 2Gb of RAM, which never had an issue.

We do need feature richness in terms of central management of the
repositories in src.fp.org: default policies, groups, users,
permissions, CI labels, branching,..
We do need integration, which Gerrit provides through the stream of
events. And we already have CI system (Zuul engine) which can
integrate nicely with it.
We do need features like topics, where pull-requests to different
projects are linked together as an implementation of one larger
cross-project feature. This is something Git Forges don't have as an
object at all, as they treat individual projects as isolated custom
playgrounds, each with a separate workflow.

If we don't get these features from a platform, we are going to
implement it on our own, through bots and external services. Which
will not make the contributor life easier. See the k8s link above:
when integrations are done by bots rather than by internal platform
features, they are not going to look nice or easy.

> 2. Not for ticketing projects on pagure.io
> 3. Code projects on pagure.io can choose a platform that fits their needs

Pagure.io story is different.

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

On Wed, Jan 22, 2020 at 1:25 PM Miro Hrončok  wrote:
>
> On 22. 01. 20 13:12, Aleksandra Fedorova wrote:
> > I think that it would be more productive if you try to rationalize this 
> > opinion.
> > I don't want to argue about the feeling you have, but I would be
> > interested in comparing notes on what exactly "Gerrit workflow" means
> > to you, and whether or not it is the same thing to me.
>
> Note that I don't describe an experience with a workflow. I am describing a
> drive by contributor experience:
>
> 1. you send a Pull Request over a familiar channel
> 2. a bot tells you that you cannot do this and you need to follow this 
> tutorial
> instead
> 3. you push your code to some place that is far to overocmplicated to navigate
> 4. magic happens, there is no way to see what's going on unless you have
> experienced this before
> 5. you get dozens of bot e-mail you don't understand
> 6. eventually hopefully the bot merges the thing
>
> I realize that (4) might be true about "anything new". What I am trying to say
> is that e-mail is a familiar channel. GitHub / GitLab / Pagure etc. almost 
> looks
> like a bulletin board or a more code-oriented Facebook comments. However 
> gerrit
> is like a nuclear power plant control center -> you are afraid to touch
> anything. You need a tutorial to handle it. It's not beginners friendly and it
> enhances a cargo cult behavior.

OK, I can understand that.

Though when people talk about simplicity of the GitHub interface, I
usually tend to point at this page:
   https://github.com/kubernetes/kubernetes/pulls and the k8s-bot actions there
If this page doesn't look overwhelming for you, I don't know what does :)

I admit, being a gerrit user for couple of years I actually miss the
"nuclear plant" interface, where you can get a full state of a change
request in one glance, rather then by browsing through several
"Facebook-like" tabs and pages to see the full picture: comments, ci
results, files changed, people who need to review the task, their
comments,..

And we haven't even started about the CLI interface (git review) it
has, which none of GitLab/GitHub things can compete with.

So you argument for me sounds like Gerrit is too powerful and too
good. Which is a valid argument, actually. We don't want newcomer to
go the full speed with it from a day one.

The question here is:

can we have the power, scalability and feature-richness of a platform
like Gerrit, but (optionally) hidden under the hood so that there is a
"simple mode" for people who just need a one-time contribution?

I've just checked, there is a GitHub plugin [1] for Gerrit which
manages the integration. Could it be the option?

[1] https://gerrit.googlesource.com/plugins/github/

--
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

reported a year ago, without a fix so far:
>
> During running tests, it's very hard to see what's happening
> https://pagure.io/fedora-ci/general/issue/2
>
> CI errors are undecipherable
> https://pagure.io/fedora-ci/general/issue/43
>
> CI errors happen far to often
> https://pagure.io/fedora-ci/general/issue/44
>
>
> I've been trying to make those issues a priority when we adapted gating, but I
> was outvoted at FESCo.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog