4:36 a.m.
This is the Minimization Objective [0] update.
Status: Discovery phase
== Next phase approval ==
Next phase proposal [1] is being voted on by the Council — only positive
votes so far!
== Feedback Pipeline ==
A few new features developed!
1/ A history chart for base images [2] is now being generated — includes
data since 25 September. It's a bit rough initial implementation, but it's
there!
2/ All tables are now data tables that support sorting and filtering. See
an example [3].
3/ Just a little touch: a better use case (and base image) list view [4] to
help navigate with the growing number of use cases.
== Kickstarts and comps groups ==
We're starting to look at kickstarts and comps groups to see if anything
minimization-related could be done here. We realize changes could break
things, we're just looking for options at the moment, potentially
experimenting on the side. Actual changes would be of course coordinated.
== How to get involved ==
See if there is anything interesting to you on action plan [42], or reach
out with something you think is useful but is missing there. Open a ticket
in the tracker [43] or discuss in #fedora-devel on IRC.
Cheers,
Adam
[0] Objective: https://docs.fedoraproject.org/en-US/minimization/
[1] Next phase proposal: https://pagure.io/Fedora-Council/tickets/issue/274
[2] History graph:
https://minimization.github.io/reports/report-base-definition--fedora-con...
[3] Sorting and filtering:
https://minimization.github.io/reports/report-by-use-case--mariadb-contai...
[4] Use case list view:
https://minimization.github.io/reports/view--use-cases-on-bases.html
[42] Action plan:
https://docs.fedoraproject.org/en-US/minimization/action-plan/
[43] Issue tracker: https://pagure.io/minimization/issues
--
Adam Šamalík
---------------------------
Senior Software Engineer
Red Hat
12:16 p.m.
Adam Samalik <asamalik(a)redhat.com> writes:
This is the Minimization Objective [0] update.
Status: Discovery phase
== Next phase approval ==
Next phase proposal [1] is being voted on by the Council — only positive
votes so far!
== Feedback Pipeline ==
A few new features developed!
1/ A history chart for base images [2] is now being generated — includes
data since 25 September. It's a bit rough initial implementation, but it's
there!
This is a neat graph. However, it doesn't index the Y-axis from 0.
Could you please fix that?
Thanks,
--Robbie
[2] History graph:
https://minimization.github.io/reports/report-base-definition--fedora-con...
4:38 p.m.
Adam Samalik wrote:
1/ A history chart for base images [2] is now being generated —
includes
data since 25 September. It's a bit rough initial implementation, but it's
there!
Almost 2 months of work to save… 0.5%! That does not look like a huge
success to me. You simply cannot win against the creeping bloat. :-(
Kevin Kofler
1:20 p.m.
On Fri, 2019-11-15 at 23:38 +0100, Kevin Kofler wrote:
Adam Samalik wrote:
> 1/ A history chart for base images [2] is now being generated — includes
> data since 25 September. It's a bit rough initial implementation, but it's
> there!
Almost 2 months of work to save… 0.5%! That does not look like a huge
success to me. You simply cannot win against the creeping bloat. :-(
Ahem.
In the spirit of positivity and collaboration, I spent a few minutes
looking at the results given to try to find some easy wins. Here's what
I found:
python3-libs ships multiple copies of its pyc files, corresponding to
different optimization levels. I don't know what a good packaging
solution to that would look like, but if we only shipped the -O2 kind
(which seems appropriate for minimization, as they're smallest) we
could drop about 13M out of 32M, which seems pretty great.
About 2/3 of glib2 is translations. If it was langpacked like glibc you
could drop another 8M. Likewise about 9M out of 10M for coreutils-
common, 4.5 out of 7.5 for bash, 4 out of 10 for gnupg2.
You're not using coreutils-single, which would save you another 6M or
so.
It's hard to understand why dejavu-sans-fonts is in there, since there
are zero font libraries installed in the container base. Probably
that's brought in by the langpacks somewhere along the line, but it
seems like fonts and translations should be logically separate here (no
point installing fonts if you're not going to be printing or making
images, right?). That's another 5.5M.
That's about 44M worth of potential savings out of a 204M base image, a
bit over 20%. I'll happily file proper bug reports for these somewhere
if we want, but it took me like 30 minutes to look into this. If you're
not even willing to put in _that_ little effort, then forgive me for
not taking your assertion that "you simply cannot win" very seriously.
- ajax
1:32 p.m.
New subject: Not shipping 3 types of bytecode in python3-libs?
On 19. 11. 19 20:20, Adam Jackson wrote:
In the spirit of positivity and collaboration, I spent a few minutes
looking at the results given to try to find some easy wins. Here's what
I found:
python3-libs ships multiple copies of its pyc files, corresponding to
different optimization levels. I don't know what a good packaging
solution to that would look like, but if we only shipped the -O2 kind
(which seems appropriate for minimization, as they're smallest) we
could drop about 13M out of 32M, which seems pretty great.
Note that it would make more sense to drop the optimized ones, as most of our
packages invoke Python without -O or -OO.
It would certainly need more planning and figuring out what shall happen if the
optimized bytecode is not there and users actually run Python with -O or -OO,
but we can discusses that if you want.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2:55 p.m.
New subject: Not shipping 3 types of bytecode in python3-libs?
On Tue, Nov 19, 2019 at 8:32 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 19. 11. 19 20:20, Adam Jackson wrote:
> In the spirit of positivity and collaboration, I spent a few minutes
> looking at the results given to try to find some easy wins. Here's what
> I found:
>
> python3-libs ships multiple copies of its pyc files, corresponding to
> different optimization levels. I don't know what a good packaging
> solution to that would look like, but if we only shipped the -O2 kind
> (which seems appropriate for minimization, as they're smallest) we
> could drop about 13M out of 32M, which seems pretty great.
Note that it would make more sense to drop the optimized ones, as most of our
packages invoke Python without -O or -OO.
It would certainly need more planning and figuring out what shall happen if the
optimized bytecode is not there and users actually run Python with -O or -OO,
but we can discusses that if you want.
I wonder, does running python programs with -O2 actually yield
noticeably better performance?
If that's the case, maybe we could discuss setting -O2 as a
distro-wide default setting?
Fabio
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
3:29 p.m.
New subject: Not shipping 3 types of bytecode in python3-libs?
On 19. 11. 19 21:55, Fabio Valentini wrote:
On Tue, Nov 19, 2019 at 8:32 PM Miro Hrončok
<mhroncok(a)redhat.com> wrote:
>
> On 19. 11. 19 20:20, Adam Jackson wrote:
>> In the spirit of positivity and collaboration, I spent a few minutes
>> looking at the results given to try to find some easy wins. Here's what
>> I found:
>>
>> python3-libs ships multiple copies of its pyc files, corresponding to
>> different optimization levels. I don't know what a good packaging
>> solution to that would look like, but if we only shipped the -O2 kind
>> (which seems appropriate for minimization, as they're smallest) we
>> could drop about 13M out of 32M, which seems pretty great.
>
> Note that it would make more sense to drop the optimized ones, as most of our
> packages invoke Python without -O or -OO.
>
> It would certainly need more planning and figuring out what shall happen if the
> optimized bytecode is not there and users actually run Python with -O or -OO,
> but we can discusses that if you want.
I wonder, does running python programs with -O2 actually yield
noticeably better performance?
If that's the case, maybe we could discuss setting -O2 as a
distro-wide default setting?
It drops asserts and docstrings. Some code require both to function, hence
defaulting to this would be dangerous.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3:35 p.m.
New subject: Not shipping 3 types of bytecode in python3-libs?
On Tue, Nov 19, 2019, 22:30 Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 19. 11. 19 21:55, Fabio Valentini wrote:
> On Tue, Nov 19, 2019 at 8:32 PM Miro Hrončok <mhroncok(a)redhat.com>
wrote:
>>
>> On 19. 11. 19 20:20, Adam Jackson wrote:
>>> In the spirit of positivity and collaboration, I spent a few minutes
>>> looking at the results given to try to find some easy wins. Here's what
>>> I found:
>>>
>>> python3-libs ships multiple copies of its pyc files, corresponding to
>>> different optimization levels. I don't know what a good packaging
>>> solution to that would look like, but if we only shipped the -O2 kind
>>> (which seems appropriate for minimization, as they're smallest) we
>>> could drop about 13M out of 32M, which seems pretty great.
>>
>> Note that it would make more sense to drop the optimized ones, as most
of our
>> packages invoke Python without -O or -OO.
>>
>> It would certainly need more planning and figuring out what shall
happen if the
>> optimized bytecode is not there and users actually run Python with -O
or -OO,
>> but we can discusses that if you want.
>
> I wonder, does running python programs with -O2 actually yield
> noticeably better performance?
> If that's the case, maybe we could discuss setting -O2 as a
> distro-wide default setting?
It drops asserts and docstrings. Some code require both to function, hence
defaulting to this would be dangerous.
Yeah I guess so :D
Thanks for the clarification!
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
7:53 p.m.
Adam Jackson wrote:
That's about 44M worth of potential savings out of a 204M base
image, a
bit over 20%. I'll happily file proper bug reports for these somewhere
if we want, but it took me like 30 minutes to look into this. If you're
not even willing to put in _that_ little effort, then forgive me for
not taking your assertion that "you simply cannot win" very seriously.
I am not the one who spent 2 months gaining 0.5%…
Also, most of your suggestions (and also most of the ideas the Minimization
team has been floating so far) are very specific to the cloud image and will
do absolutely nothing to decrease the size of real-world Fedora
installations and live images.
Kevin Kofler
3:02 a.m.
On Fri, Nov 15, 2019 at 7:16 PM Robbie Harwood <rharwood(a)redhat.com> wrote:
Adam Samalik <asamalik(a)redhat.com> writes:
> This is the Minimization Objective [0] update.
>
> Status: Discovery phase
>
> == Next phase approval ==
>
> Next phase proposal [1] is being voted on by the Council — only positive
> votes so far!
>
> == Feedback Pipeline ==
>
> A few new features developed!
>
> 1/ A history chart for base images [2] is now being generated — includes
> data since 25 September. It's a bit rough initial implementation, but
it's
> there!
This is a neat graph. However, it doesn't index the Y-axis from 0.
Could you please fix that?
Thanks for the feedback, I'll look into that!
Thanks,
--Robbie
> [2] History graph:
>
https://minimization.github.io/reports/report-base-definition--fedora-con...
--
Adam Šamalík
---------------------------
Senior Software Engineer
Red Hat
3:09 a.m.
On Fri, Nov 15, 2019 at 11:42 PM Kevin Kofler <kevin.kofler(a)chello.at>
wrote:
Adam Samalik wrote:
> 1/ A history chart for base images [2] is now being generated — includes
> data since 25 September. It's a bit rough initial implementation, but
it's
> there!
Almost 2 months of work to save… 0.5%! That does not look like a huge
success to me. You simply cannot win against the creeping bloat. :-(
Looking at more than two months, ideally at times where this was an active
focus, you can see the base image went from ~300 MB to ~200 MB. [1] To be
super clear, a lot of the work has been done by the Container Team [2].
But I'm glad this is helping you to see the progress, and I'm looking
forward to see even more progress.
[1] https://asamalik.fedorapeople.org/fedora-base-image-sizes.png
[2] https://docs.fedoraproject.org/en-US/containers/
Kevin Kofler
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Adam Šamalík
---------------------------
Senior Software Engineer
Red Hat
3:24 a.m.
New subject: Not shipping 3 types of bytecode in python3-libs?
Dne 19. 11. 19 v 20:32 Miro Hrončok napsal(a):
On 19. 11. 19 20:20, Adam Jackson wrote:
> In the spirit of positivity and collaboration, I spent a few minutes
> looking at the results given to try to find some easy wins. Here's what
> I found:
>
> python3-libs ships multiple copies of its pyc files, corresponding to
> different optimization levels. I don't know what a good packaging
> solution to that would look like, but if we only shipped the -O2 kind
> (which seems appropriate for minimization, as they're smallest) we
> could drop about 13M out of 32M, which seems pretty great.
Note that it would make more sense to drop the optimized ones, as most
of our packages invoke Python without -O or -OO.
It would certainly need more planning and figuring out what shall
happen if the optimized bytecode is not there and users actually run
Python with -O or -OO, but we can discusses that if you want.
Not mentioning that when we ship the .pyc files, the .py files should be
moved into optionally installed -src subpackages, as every other
compiled language does. Now with weak dependencies, even the camp who
thinks that it is very valuable to have .py files installed alongside
the .pyc files could be satisfied by default.
Vít
10:22 a.m.
On Wed, 2019-11-20 at 02:53 +0100, Kevin Kofler wrote:
Adam Jackson wrote:
> That's about 44M worth of potential savings out of a 204M base image, a
> bit over 20%. I'll happily file proper bug reports for these somewhere
> if we want, but it took me like 30 minutes to look into this. If you're
> not even willing to put in _that_ little effort, then forgive me for
> not taking your assertion that "you simply cannot win" very seriously.
I am not the one who spent 2 months gaining 0.5%…
You're right, you spend two months achieving zero towards this goal,
and complaining about what progress they _have_ made. You have provided
zero constructive feedback, and your defeatist attitude helps nobody.
Consider the option of not being gratuitously unpleasant.
- ajax
11:04 a.m.
On Wed, 2019-11-20 at 11:22 -0500, Adam Jackson wrote:
On Wed, 2019-11-20 at 02:53 +0100, Kevin Kofler wrote:
> Adam Jackson wrote:
> > That's about 44M worth of potential savings out of a 204M base
> > image, a
> > bit over 20%. I'll happily file proper bug reports for these
> > somewhere
> > if we want, but it took me like 30 minutes to look into this. If
> > you're
> > not even willing to put in _that_ little effort, then forgive me
> > for
> > not taking your assertion that "you simply cannot win" very
> > seriously.
>
> I am not the one who spent 2 months gaining 0.5%…
You're right, you spend two months achieving zero towards this goal,
and complaining about what progress they _have_ made. You have
provided
zero constructive feedback, and your defeatist attitude helps nobody.
Consider the option of not being gratuitously unpleasant.
It's better to light a candle than curse the darkness.
Writing a script that automates figuring out how many candles are
needed (and where) is also better than cursing the darkness.
Dave
11:48 a.m.
On Wed, Nov 20, 2019 at 6:05 PM David Malcolm <dmalcolm(a)redhat.com> wrote:
On Wed, 2019-11-20 at 11:22 -0500, Adam Jackson wrote:
> On Wed, 2019-11-20 at 02:53 +0100, Kevin Kofler wrote:
> > Adam Jackson wrote:
> > > That's about 44M worth of potential savings out of a 204M base
> > > image, a
> > > bit over 20%. I'll happily file proper bug reports for these
> > > somewhere
> > > if we want, but it took me like 30 minutes to look into this. If
> > > you're
> > > not even willing to put in _that_ little effort, then forgive me
> > > for
> > > not taking your assertion that "you simply cannot win" very
> > > seriously.
> >
> > I am not the one who spent 2 months gaining 0.5%…
>
> You're right, you spend two months achieving zero towards this goal,
> and complaining about what progress they _have_ made. You have
> provided
> zero constructive feedback, and your defeatist attitude helps nobody.
>
> Consider the option of not being gratuitously unpleasant.
It's better to light a candle than curse the darkness.
Writing a script that automates figuring out how many candles are
needed (and where) is also better than cursing the darkness.
I am so going to make a poster on my wall with this message.
Thank you, Dave.
--
Aleksandra Fedorova
bookwar
12:10 p.m.
Adam Jackson wrote:
You're right, you spend two months achieving zero towards this
goal,
Well, just a few days ago, I managed to stop a Change that would have almost
doubled Python 3's size wherever both the python3 executable and the
libpython3 library are needed, and to point out an alternative (though Jan
Kratochvil beat me to it by ~64 minutes) that brings the same performance
gain without the size increase (-fno-semantic-interposition).
I am constantly trying to fight bloat, but it is usually a political rather
than a technical fight. And the typical outcome (see, e.g., MiniDebugInfo)
is where my "defeatist attitude" comes from.
Kevin Kofler
3:29 p.m.
----- Original Message -----
From: "Kevin Kofler" <kevin.kofler(a)chello.at>
To: devel(a)lists.fedoraproject.org
Sent: Wednesday, November 20, 2019 7:10:32 PM
Subject: Re: Minimization Objective report
Adam Jackson wrote:
> You're right, you spend two months achieving zero towards this goal,
Well, just a few days ago, I managed to stop a Change that would have almost
doubled Python 3's size wherever both the python3 executable and the
libpython3 library are needed, and to point out an alternative (though Jan
Kratochvil beat me to it by ~64 minutes) that brings the same performance
gain without the size increase (-fno-semantic-interposition).
I am constantly trying to fight bloat, but it is usually a political rather
than a technical fight. And the typical outcome (see, e.g., MiniDebugInfo)
is where my "defeatist attitude" comes from.
Kevin Kofler
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
I'm sorry but how exactly did you manage to 'stop' the change? All you did was
started shouting about the size increase and then proposed something already mentioned
beforehand in the thread.
Your feedback was NOT helpful and it basically pushed people away from wanting to
participate to the thread. Luckily sorting through the useful info was possible but still
frustrating in between your rants.
We heard the feedback and did a lot of experimentation and benchmarking with a ton of
different options so I really can't fathom how you are taking credit for something
that others invested so much time in.
/offtopic rant over
--
Regards,
Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
6:08 p.m.
Charalampos Stratakis wrote:
We heard the feedback and did a lot of experimentation and
benchmarking
with a ton of different options so I really can't fathom how you are
taking credit for something that others invested so much time in.
The new Feature page:
https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup
explicitly credits 4 people, one of whom is me:
https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeed...
Shout-out: Jan Kratochvíl for first suggesting this instead of the
original proposal, followed by Kevin Kofler. Florian Weimer for providing
answers to our questions. David Gray for originally suggesting to link
Python statically to gain performance.
Kevin Kofler
6:23 p.m.
On 21. 11. 19 1:08, Kevin Kofler wrote:
Charalampos Stratakis wrote:
> We heard the feedback and did a lot of experimentation and benchmarking
> with a ton of different options so I really can't fathom how you are
> taking credit for something that others invested so much time in.
The new Feature page:
https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup
explicitly credits 4 people, one of whom is me:
https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeed...
> Shout-out: Jan Kratochvíl for first suggesting this instead of the
> original proposal, followed by Kevin Kofler. Florian Weimer for providing
> answers to our questions. David Gray for originally suggesting to link
> Python statically to gain performance.
That was put there by me. I understood from the mailing list discussions that
you suggested the same thing as Jan, not just repeated what he said.
However, I see that not everybody might have seen it that way.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6:31 p.m.
----- Original Message -----
From: "Kevin Kofler" <kevin.kofler(a)chello.at>
To: devel(a)lists.fedoraproject.org
Sent: Thursday, November 21, 2019 1:08:34 AM
Subject: Re: Minimization Objective report
Charalampos Stratakis wrote:
> We heard the feedback and did a lot of experimentation and benchmarking
> with a ton of different options so I really can't fathom how you are
> taking credit for something that others invested so much time in.
The new Feature page:
https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup
explicitly credits 4 people, one of whom is me:
https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeed...
> Shout-out: Jan Kratochvíl for first suggesting this instead of the
> original proposal, followed by Kevin Kofler. Florian Weimer for providing
> answers to our questions. David Gray for originally suggesting to link
> Python statically to gain performance.
Kevin Kofler
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Yes. My point still stands.
--
Regards,
Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
5:30 a.m.
On Tue, Nov 19, 2019 at 8:22 PM Adam Jackson <ajax(a)redhat.com> wrote:
On Fri, 2019-11-15 at 23:38 +0100, Kevin Kofler wrote:
> Adam Samalik wrote:
> > 1/ A history chart for base images [2] is now being generated —
includes
> > data since 25 September. It's a bit rough initial implementation, but
it's
> > there!
>
> Almost 2 months of work to save… 0.5%! That does not look like a huge
> success to me. You simply cannot win against the creeping bloat. :-(
Ahem.
In the spirit of positivity and collaboration, I spent a few minutes
looking at the results given to try to find some easy wins. Here's what
I found:
python3-libs ships multiple copies of its pyc files, corresponding to
different optimization levels. I don't know what a good packaging
solution to that would look like, but if we only shipped the -O2 kind
(which seems appropriate for minimization, as they're smallest) we
could drop about 13M out of 32M, which seems pretty great.
About 2/3 of glib2 is translations. If it was langpacked like glibc you
could drop another 8M. Likewise about 9M out of 10M for coreutils-
common, 4.5 out of 7.5 for bash, 4 out of 10 for gnupg2.
You're not using coreutils-single, which would save you another 6M or
so.
It's hard to understand why dejavu-sans-fonts is in there, since there
are zero font libraries installed in the container base. Probably
that's brought in by the langpacks somewhere along the line, but it
seems like fonts and translations should be logically separate here (no
point installing fonts if you're not going to be printing or making
images, right?). That's another 5.5M.
That's about 44M worth of potential savings out of a 204M base image, a
bit over 20%. I'll happily file proper bug reports for these somewhere
if we want, but it took me like 30 minutes to look into this. If you're
not even willing to put in _that_ little effort, then forgive me for
not taking your assertion that "you simply cannot win" very seriously.
Hey Adam,
Thanks for looking into that. If you could file those bugs that would be
fantastic.
I'm sure we can win if there are enough eyes looking for improvements :-)
Especially if we have tooling / services that will help us to _keep_ things
over time.
Cheers,
Adam
- ajax
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Adam Šamalík
---------------------------
Senior Software Engineer
Red Hat
1612
days inactive
1622
days old
21 comments
10 participants
participants (10)
-
Adam Jackson -
Adam Samalik -
Aleksandra Fedorova -
Charalampos Stratakis -
David Malcolm -
Fabio Valentini -
Kevin Kofler -
Miro Hrončok -
Robbie Harwood -
Vít Ondruch