Hi all,
The modularity team will be holding a discussion about the recent mailing
list thread with a subject line of "RFC: Modularity Simplified" which can
be found on hyperkitty here[1]. Discussion will take place tomorrow (Dec.
5) at 10am (eastern, 15h UTC) in irc://irc.freenode.n
Petr Pisar wrote:
> On 2019-12-02, John M. Harris Jr wrote:
>> On Monday, December 2, 2019 12:17:20 AM MST Igor Gnatenko wrote:
>>> Sure, we just have to accept this until perl is made
>>> parallel-installable. Which may or may not happen, but if I have
>>> choice between "only one version of per
On 12/1/19 10:37 PM, Kevin Kofler wrote:
I definitely want some mechanism which will tell to user that "THIS
PACKAGE IS NOT FULLY SUPPORTED."
And I think telling that to the user is absolutely unfair and against the
spirit of Fedora.
The dilemma is, how to allow the useful stuff to remain, whil
Igor Gnatenko wrote:
> Yes, however maintainer of nodejs does not want to rename binaries and
> patch sources to be parallel-installable.
And that is exactly the problem.
> And today, we would block adding such "compat" package into the
> repositories.
Which is exactly how it should be.
> I agr
On 2019-12-02, John M. Harris Jr wrote:
> On Monday, December 2, 2019 12:17:20 AM MST Igor Gnatenko wrote:
>> Sure, we just have to accept this until perl is made
>> parallel-installable. Which may or may not happen, but if I have
>> choice between "only one version of perl and no bugzilla" or "tw
On Monday, December 2, 2019 12:17:20 AM MST Igor Gnatenko wrote:
> Sure, we just have to accept this until perl is made
> parallel-installable. Which may or may not happen, but if I have
> choice between "only one version of perl and no bugzilla" or "two
> conflicting versions of perl and bugzilla
Le 2019-12-02 10:49, Igor Gnatenko a écrit :
On Mon, Dec 2, 2019 at 8:58 AM Nicolas Mailhot via devel
wrote:
Le 2019-12-02 07:47, Igor Gnatenko a écrit :
> Hi Neal,
>
> On Sat, Nov 30, 2019 at 11:58 PM Neal Gompa wrote:
>> I think we need to recognize that we've done some poor optimization
>
Le 2019-12-02 10:45, Igor Gnatenko a écrit :
On Mon, Dec 2, 2019 at 8:48 AM Nicolas Mailhot via devel
wrote:
Le 2019-12-02 08:17, Igor Gnatenko a écrit :
Building communities takes time and energy and has no immediate
benefit.
But, long-term, it's the most efficient way to do things (the “
On Mon, Dec 2, 2019 at 9:13 AM Nicolas Mailhot via devel
wrote:
>
> Le 2019-12-02 08:38, Igor Gnatenko a écrit :
> > On Mon, Dec 2, 2019 at 8:28 AM Nicolas Mailhot via devel
>
> >> Having all build elements in the package repos themselves is the CORE
> >> feature that makes the “share” community d
On Mon, Dec 2, 2019 at 8:58 AM Nicolas Mailhot via devel
wrote:
>
> Le 2019-12-02 07:47, Igor Gnatenko a écrit :
> > Hi Neal,
> >
> > On Sat, Nov 30, 2019 at 11:58 PM Neal Gompa wrote:
>
> >> I think we need to recognize that we've done some poor optimization
> >> for the majority of packager wor
On Mon, Dec 2, 2019 at 8:48 AM Nicolas Mailhot via devel
wrote:
>
> Le 2019-12-02 08:17, Igor Gnatenko a écrit :
>
> > I simply can't. If somebody gets a package into repo just because he
> > wants to build foo, it is probably not very reasonable to ask them to
> > "properly" maintain it.
>
> It i
On Mon, Dec 2, 2019, 04:43 Kevin Kofler wrote:
> Igor Gnatenko wrote:
> > 1. Do we want to package multiple streams only for "leaf" software or
> > any kind of it?
> > I believe that we need both, and we do support both. However, it might
> > not look as nice as it could:
> > * Need to create mul
Le 2019-12-02 08:38, Igor Gnatenko a écrit :
On Mon, Dec 2, 2019 at 8:28 AM Nicolas Mailhot via devel
Having all build elements in the package repos themselves is the CORE
feature that makes the “share” community dimension of Fedora work.
Anyone
can take the packages and do whatever he wants w
Le 2019-12-02 07:47, Igor Gnatenko a écrit :
Hi Neal,
On Sat, Nov 30, 2019 at 11:58 PM Neal Gompa wrote:
I think we need to recognize that we've done some poor optimization
for the majority of packager workflows. Even if we consider modules,
the vast majority of components will never be modu
Le 2019-12-02 08:17, Igor Gnatenko a écrit :
I simply can't. If somebody gets a package into repo just because he
wants to build foo, it is probably not very reasonable to ask them to
"properly" maintain it.
It is very reasonable to expect anyone building in Fedora, reusing the
work of countle
On Mon, Dec 2, 2019 at 8:28 AM Nicolas Mailhot via devel
wrote:
>
> Le 2019-12-02 07:23, Igor Gnatenko a écrit :
> > On Tue, Nov 26, 2019 at 9:23 PM Nicolas Mailhot via devel
> > wrote:
> >>
> >> Le mardi 26 novembre 2019 à 16:58 +0100, Igor Gnatenko a écrit :
>
> >> > And we can't actually
> >>
Le 2019-12-02 07:23, Igor Gnatenko a écrit :
On Tue, Nov 26, 2019 at 9:23 PM Nicolas Mailhot via devel
wrote:
Le mardi 26 novembre 2019 à 16:58 +0100, Igor Gnatenko a écrit :
> And we can't actually
> have multiple versions of a package with same name (without "mangled"
> names) in a repo d
Hi Kevin,
On Mon, Dec 2, 2019 at 4:43 AM Kevin Kofler wrote:
>
> Igor Gnatenko wrote:
> > 1. Do we want to package multiple streams only for "leaf" software or
> > any kind of it?
> > I believe that we need both, and we do support both. However, it might
> > not look as nice as it could:
> > * Ne
Hi Neal,
On Sat, Nov 30, 2019 at 11:58 PM Neal Gompa wrote:
>
> On Tue, Nov 26, 2019 at 10:59 AM Igor Gnatenko
> wrote:
> >
> > Hello fellows,
> >
> > After last publication on LWN about Fedora Modularity mess, I think it
> > is time to describe the idea I was proposing internally with few other
Hey Michal,
On Sat, Nov 30, 2019 at 5:08 PM clime wrote:
>
> Hey Igor,
>
> On Tue, 26 Nov 2019 at 17:00, Igor Gnatenko
> wrote:
> >
> > Hello fellows,
> >
> > After last publication on LWN about Fedora Modularity mess, I think it
> > is time to describe the idea I was proposing internally with f
On Tue, Nov 26, 2019 at 9:23 PM Nicolas Mailhot via devel
wrote:
>
> Le mardi 26 novembre 2019 à 16:58 +0100, Igor Gnatenko a écrit :
>
> Hi, Igor
>
>
> > And we can't actually
> > have multiple versions of a package with same name (without "mangled"
> > names) in a repo due to the way how our bui
On Tue, Nov 26, 2019 at 6:35 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> As a meta-goal, we should break up "Modularity" into a number of
> separate components, some build-side, some client-side. Modularity
> suffers greatly from trying to encode everything into one document.
> This greatly raises t
On Sat, Nov 30, 2019 at 9:28 PM Kevin Fenzi wrote:
>
> On Tue, Nov 26, 2019 at 05:35:27PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > As a meta-goal, we should break up "Modularity" into a number of
> > separate components, some build-side, some client-side. Modularity
> > suffers greatly from t
Igor Gnatenko wrote:
> 1. Do we want to package multiple streams only for "leaf" software or
> any kind of it?
> I believe that we need both, and we do support both. However, it might
> not look as nice as it could:
> * Need to create multiple repos for different "streams"
> * Need to maintain epel
On Tue, Nov 26, 2019 at 10:59 AM Igor Gnatenko
wrote:
>
> Hello fellows,
>
> After last publication on LWN about Fedora Modularity mess, I think it
> is time to describe the idea I was proposing internally with few other
> folks (Adam Samalik, Brian Exelbierd) back in the RH times.
>
> Before I ac
On Tue, Nov 26, 2019 at 05:35:27PM +, Zbigniew Jędrzejewski-Szmek wrote:
> As a meta-goal, we should break up "Modularity" into a number of
> separate components, some build-side, some client-side. Modularity
> suffers greatly from trying to encode everything into one document.
> This greatly r
Hey Igor,
On Tue, 26 Nov 2019 at 17:00, Igor Gnatenko
wrote:
>
> Hello fellows,
>
> After last publication on LWN about Fedora Modularity mess, I think it
> is time to describe the idea I was proposing internally with few other
> folks (Adam Samalik, Brian Exelbierd) back in the RH times.
>
> Bef
Le mardi 26 novembre 2019 à 16:58 +0100, Igor Gnatenko a écrit :
Hi, Igor
> And we can't actually
> have multiple versions of a package with same name (without "mangled"
> names) in a repo due to the way how our buildsystem works (and not
> only buildsystem, with some caveats).
I suppose you're
As a meta-goal, we should break up "Modularity" into a number of
separate components, some build-side, some client-side. Modularity
suffers greatly from trying to encode everything into one document.
This greatly raises the complexity of the task and makes it hard to
consider alternative proposals
Hello fellows,
After last publication on LWN about Fedora Modularity mess, I think it
is time to describe the idea I was proposing internally with few other
folks (Adam Samalik, Brian Exelbierd) back in the RH times.
Before I actually go deep, I'll try to answer main questions to myself
(so that
30 matches
Mail list logo
