Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[Michał Górny]

Dnia 2015-04-12, o godz. 01:47:43
Andrew Savchenko <bircoph@g.o> napisał(a):

> On Thu, 9 Apr 2015 00:23:29 +0200 Michał Górny wrote:
> > Hello, developers.
> >
> > We have added a new mail alias travis-ci@g.o and set up travis-ci [1]
> > to send notifications on status change there. Please seriously consider
> > adding yourself to the alias, and contributing to the quality
> > of Gentoo.
> >
> > The mail load is low -- travis will only send notices when the state
> > changes from 'good' to 'bad', and the other way around. However, you
> > will need to manually grep the logs provided by travis for occurences
> > of 'FATAL'.
> >
> > Please remember that keeping the repository in a broken state is
> > inconvenient both for users and other developers. In particular
> > the issues include:
> >
> > 1. dependency resolution errors blocking @world upgrades,
> >
> > 2. Portage unnecessarily switching packages to ~arch (and therefore
> >    reducing quality of stable systems),
> >
> > 3. repoman refusing to commit irrelevant changes to packages.
> >
> > Therefore, whenever possible please try to fix the issues ASAP.
> >
> > However, if you are not the person directly responsible for
> > the dependency graph breakage, please *reliably* inform him
> > about the revert/change you're doing. Failing to do has already
> > resulted in developers repeating their mistakes because of
> > misinformation.
> >
> > Preferably, always file a bug in such a case and make it block
> > the 'broken-depgraph' tracker [2]. When assigning/CC-ing to the bug,
> > please make sure to include both the maintainers of the broken package,
> > and the maintainers of the dependency as necessary.
>
> While I must admit that travis is a quite convenient tool (thought
> it has its limitations), I'd like to raise related software freedom
> concern.
>
> Travis itself is a closed, proprietary and non-trivial-to-replace
> solution. [...]

Wrong. Actually, it's trivial. Even better, deploying pcheck
on Gentoo-hosted service is likely easier than on Ubuntu container used
by travis (though it was quite a nice pkgcore learning experience).

The only reason I used travis-ci is because they are giving their
hardware for free. If someone gave me hardware on sane terms, I can
move it elsewhere. Though right now I see no point in wasting Gentoo
money on dedicated hardware when the tasks can be offloaded to
travis-ci.

> If travis will change their terms of service in future and our
> workflow/infra will depends on these checks, whole development
> process may be hampered.
>
> So developers should think twice before depending their workflow on
> this solution. I'm refusing to sign up to the list which in my
> opinion indirectly violates Gentoo social contract.
>
> If some other free tool (preferably deployed on Gentoo
> infrastructure) will be used for this task, I'll sign-up right away.

You can run repoman/pcheck on your hardware too, you know. You don't
have to have a dedicated remote service to do that.

That said, I have bigger plans™ if someone gives me some hardware to
handle them. Let's call it 'big Gentoo repository mirror'. The idea is
that a script would process repositories.xml, maintain checkouts of all
repositories (fetch, sync, remove as necessary), generate md5-cache
and provide the resulting repo for syncing via git & rsync. It wouldn't
hurt to run travis on all repos there as well.

In other words, something like our git mirror, though on dedicated
hardware and for all repositories :).

-- 
Best regards,
Michał Górny