Re: [gentoo-portage-dev] Constraint-Based Dependency Solver: initial results

2019-10-08 Thread Zac Medico
On 8/30/19 7:34 AM, michael.lienha...@laposte.net wrote:
>  - install the configuration computed by my solver (I am still unsure that 
> emerge --nodeps would be flexible enough, and maybe I will have to implement 
> my own planner)

One problem with emerge --nodeps is that it does not resolve file
collisions in cases where two packages block each other. Normally, such
collisions are resolved by removing the files from the contents of the
installed package (the installed package is ultimately unmerged in order
to solve the blocker), but with --nodeps the blockers are simply
discarded and emerge treats all file collisions as fatal.

Another problem is that --nodeps eliminates the dependency information
that's needed for scheduling parallel builds with emerge --jobs.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] Constraint-Based Dependency Solver: initial results

2019-10-08 Thread Michael Orlitzky
On 8/30/19 10:34 AM, michael.lienha...@laposte.net wrote:
> 
> All comments/suggestions are welcomed.
> 

Since no one else has said it yet (?), I think this approach is really
cool and I'm glad someone is working on it.

Modeling difficult computations as abstract optimization problems is a
"hobby" of mine, and I think it will pay off if we can abstract away a
big ugly part of the PM and try to swap it out for something more
principled.



Re: [gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it?

2019-10-08 Thread Alec Warner
On Tue, Oct 8, 2019 at 4:57 AM Michael Palimaka 
wrote:

> On 10/8/19 7:21 AM, Andreas K. Huettel wrote:
> > In any case, since many people *do* rely on it, maybe we should declare
> it
> > official? [+]
> >
> > And, if that's OK with both of you, move it onto infra hardware?
> >
> > Happy to sponsor both for the next council meeting agenda.
> >
> >
> > [+] At some point the one remaining whiner doesnt count anymore.
> >
>
> In the past, infra has been understandably hesitant to take on new
> services due to staffing issues.
>
> Additionally, I understand that the current infra design does not easily
> allow granular access control, preventing non-infra members from easily
> performing maintenance on individual services.
>
> Has this situation changed? I doubt infra want to take responsibility
> for the bot, and I don't fancy the hassle of trying to find people to
> poke things on my behalf.
>

Things have not changed. We don't need to run the bot, we just need some
clearer contact info for it IMHO.

I don't think the reliability of the bot is really that different from
official infra services, but it was unclear who owned it and so there was
confusion; and I think the confusion is the key thing we are looking to
resolve here.

-A


Re: [gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it?

2019-10-08 Thread Rich Freeman
On Tue, Oct 8, 2019 at 7:57 AM Michael Palimaka  wrote:
>
> On 10/8/19 7:21 AM, Andreas K. Huettel wrote:
> > In any case, since many people *do* rely on it, maybe we should declare it
> > official? [+]
> >
> > And, if that's OK with both of you, move it onto infra hardware?
> >
> > Happy to sponsor both for the next council meeting agenda.
> >
> >
> > [+] At some point the one remaining whiner doesnt count anymore.
> >
>
> In the past, infra has been understandably hesitant to take on new
> services due to staffing issues.
>
> Additionally, I understand that the current infra design does not easily
> allow granular access control, preventing non-infra members from easily
> performing maintenance on individual services.
>
> Has this situation changed? I doubt infra want to take responsibility
> for the bot, and I don't fancy the hassle of trying to find people to
> poke things on my behalf.
>

IMO we should have a few tiers:

1.  Absolutely core stuff that infra has to run (authentication, LDAP,
maybe some services, etc).
2.  Community-run stuff that is FOSS, with public config tracking
(minus passwords/etc), and reasonably good docs.
3.  Community-run stuff that is the wild west.

IMO having a service catalog that includes all of this stuff is
beneficial, with clear indications as to which tier each thing is in
and who to contact with issues.

Depending on #1-2 shouldn't really be a problem.  #3 can be a
playground for experimentation but shouldn't be something we really
depend on for core workflow.  To mitigate the risk of #2 we could have
exercises to clone services following docs/etc.  If anything #2 has
the potential to be more reliable than #1 if it gets enough attention
(though there is no reason our internal services couldn't also be made
easy-to-replicate).

I think the issue here is that we don't really have any standards for
#2, but it is clear that this particular bot is intended to meet those
requirements but doesn't quite do so today.

I think this is a compromise that could help us focus our infra
resources where they're needed most, with some separation of concerns.
Ideally we should also make it possible via single-sign-on
technologies to leverage infra's authentication services for stuff in
tier 2, and maybe tier 3.  Biggest risk is phishing if somebody spoofs
a sign-on page.

-- 
Rich



[gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it?

2019-10-08 Thread Michael Palimaka

On 10/8/19 7:21 AM, Andreas K. Huettel wrote:

In any case, since many people *do* rely on it, maybe we should declare it
official? [+]

And, if that's OK with both of you, move it onto infra hardware?

Happy to sponsor both for the next council meeting agenda.


[+] At some point the one remaining whiner doesnt count anymore.



In the past, infra has been understandably hesitant to take on new 
services due to staffing issues.


Additionally, I understand that the current infra design does not easily 
allow granular access control, preventing non-infra members from easily 
performing maintenance on individual services.


Has this situation changed? I doubt infra want to take responsibility 
for the bot, and I don't fancy the hassle of trying to find people to 
poke things on my behalf.




[gentoo-dev] Re: [gentoo-dev-announce] Gentoo CI news: pkgcheck is now running truly parallel

2019-10-08 Thread Benda Xu
Michał Górny  writes:

> Just a quick note: thanks to hard work of radhermit, the newest release
> of pkgcheck features internal parallelization of checks.  While it's not
> perfect and there's still room for improvement (I mean, it could run
> even faster!), it's a major step forward.
>
> This means that I've finally retired that ugly hack that split
> categories into multiple groups and ran them in parallel.  This means
> that CI is no longer bound by the longest category (hello, media-libs/)
> and can utilize all 32 cores instead of ~14.
>
> This also means that if you're planning to run tree-wide scans with
> pkgcheck, you no longer have to employ huge hacks to make them faster. 
> You just run it normally!  In your face, repoman!
>
> Once again, thanks to radhermit.  His work on pkgcheck is astonishing,
> and it's becoming a great tool for developers.

A big round of applause to radhermit for the better QA tool!

Thank you to all who contributed.

Benda


signature.asc
Description: PGP signature