Re: MBI (Playground 2.0)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 1, 2019 at 6:59 AM Nicolas Mailhot
<nicolas.mailhot@xxxxxxxxxxx> wrote:
>
> Le jeudi 31 janvier 2019 à 19:52 -0500, Neal Gompa a écrit :
> > On Thu, Jan 31, 2019 at 6:58 PM Stephen John Smoogen <smooge@xxxxxxxxx
> > > wrote:
> > > On Thu, 31 Jan 2019 at 07:28, Igor Gnatenko <
> > > ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote:
> > > > Problem №1: Build-only packages
> > > >
> > > > Rawhide gating makes this much more complicated because builds
> > > > appear in buildroot slower, updating group of packages would need
> > > > side tags and it’s just painful to work with.
> > > >
> > > > https://pagure.io/fesco/issue/2068
> > > >
> > > > And, after all, those packages shouldn’t be shipped to users.
> > >
> > > My main problem with this is the above. Yes Joe Desktop User isn't
> > > going to see/need that package.. but we have a LOT of packagers who
> > > take our stuff and rebuild it for themselves for various reasons. I
> > > find it hard to put together the proposal which is supposed to make
> > > developing/packaging easier with making developing/packaging harder.
> > > Whether you want it to or not, this comes across as "If you want to
> > > use Go or Rust, you will need our special set of tools which we keep
> > > hidden."
> > >
> >
> > This is actually something I really don't like either. But the Fedora
> > leadership has pushed very hard on the concept of having packages that
> > aren't available to "normies", and require special tooling to be able
> > to leverage (that for various reasons, I can't even use as a third
> > party packager!).
>
> If MBI is about hiding build packages I don't see the point and I'm not
> interested.
>

MBI isn't about that. That's what modularity is (partly) about.

> What I *am* interested in is being able to import in one go the
> hundred(s) of srpms involved in building the complex highly modularized
> stuff package projects output nowadays, without the two months of review
> getting each spec audited separately would entail.
>
> Our main infra and main administrative processes just don't scale.
>

Indeed. Those were ideas that we put into the proposal of things we
want to improve.


-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux