Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
Dnia 2015-04-13, o godz. 17:28:23 Gordon Pettey napisał(a): > On Mon, Apr 13, 2015 at 7:59 AM, Erik Mackdanz wrote: > > > William Hubbs writes: > > "git request-pull" simply formats an email template to tell someone how > > > they may pull from you, but Github makes no attempt to process such a > > message or turn it into a Github pull request. > > > > A pull is a pull is a pull. Please don't conflate Git and GitHub. > > > > Any Github presence of the tree will result in Github issues being > > submitted and Github pull requests coming across. We'd have to be > > prepared to chain that into our existing processes or have someone > > dedicated to closing every issue/pull request with "Use bugzie". > > > Then turn off the issue tracker. Joe Random can't submit GitHub > issues if the repository admin hasn't enabled them. How about we turn off this mailing list? It certainly wastes more of my time than the github pull requests, and unlike them doesn't benefit Gentoo as can be seen by this post. -- Best regards, Michał Górny pgpzSbOijUATI.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
On Mon, Apr 13, 2015 at 7:59 AM, Erik Mackdanz wrote: > William Hubbs writes: "git request-pull" simply formats an email template to tell someone how > they may pull from you, but Github makes no attempt to process such a > message or turn it into a Github pull request. > A pull is a pull is a pull. Please don't conflate Git and GitHub. > Any Github presence of the tree will result in Github issues being > submitted and Github pull requests coming across. We'd have to be > prepared to chain that into our existing processes or have someone > dedicated to closing every issue/pull request with "Use bugzie". Then turn off the issue tracker. Joe Random can't submit GitHub issues if the repository admin hasn't enabled them.
Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
William Hubbs writes: > The only thing locked to their platform really is the web ui or their > api. Even pull requests really aren't, because git has the > "git request-pull" command. Not true. Github pull requests are for pulling from other Github repos/branches only, and they store unique metadata (e.g. comments, issues) outside of the repo. It is truly a lock-in feature. "git request-pull" simply formats an email template to tell someone how they may pull from you, but Github makes no attempt to process such a message or turn it into a Github pull request. Any Github presence of the tree will result in Github issues being submitted and Github pull requests coming across. We'd have to be prepared to chain that into our existing processes or have someone dedicated to closing every issue/pull request with "Use bugzie". -- Erik Mackdanz
Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
On Sun, Apr 12, 2015 at 06:49:24PM +0200, Peter Stuge wrote: > William Hubbs wrote: > > It may take some work, but I do not think we could reach a point > > where nothing could be changed. > > > > Remember that, unlike cvs, every git clone, by default, has all of the > > history of the repository, so all we would have to do is find another > > place to host the repository and push it there. > > I think that's too simplistic. Proprietary systems are a slippery > slope. And the problem with GitHub Inc. in particular isn't their > technology at all, but their processes and the mindset they promote, > because the processes and mindset are locked to their platform. The only thing locked to their platform really is the web ui or their api. Even pull requests really aren't, because git has the "git request-pull" command. William signature.asc Description: Digital signature
Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
Dnia 2015-04-12, o godz. 01:47:43 Andrew Savchenko 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 pgpPRKPinoogG.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
William Hubbs wrote: > It may take some work, but I do not think we could reach a point > where nothing could be changed. > > Remember that, unlike cvs, every git clone, by default, has all of the > history of the repository, so all we would have to do is find another > place to host the repository and push it there. I think that's too simplistic. Proprietary systems are a slippery slope. And the problem with GitHub Inc. in particular isn't their technology at all, but their processes and the mindset they promote, because the processes and mindset are locked to their platform. It sounds silly but it *is* a problem. //Peter pgpmfbMunugXh.pgp Description: PGP signature
Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
On Sun, Apr 12, 2015 at 05:54:36PM +0300, Andrew Savchenko wrote: > Right now there is no hard dependency on github or travis, of > course. But present pathway worries me: with current pace at some > point we _will_ depend on travis or github too much. Then they may > change their terms of service or license argeement, or just shut > down the whole service (as Google recently shut down Google Code). > And then we will be in a great trouble. And then it may be too late > to change anything. I want to avoid this, that's all. It may take some work, but I do not think we could reach a point where nothing could be changed. Remember that, unlike cvs, every git clone, by default, has all of the history of the repository, so all we would have to do is find another place to host the repository and push it there. > What we should really do is to develop our own QA tools or use > existing free ones on our own infrastructure, thus that Gentoo > development may continue to be independent and unbiased. This is more likely once the main Gentoo ebuild repository is migrated to git. > Please understand that I'm grateful for all people improving > Gentoo, including Michał, for their hard work. But we should not > solely rely on third-party proprietary solutions (travis is a > github lock-in) because of convenience. wrt travis-ci, why not contribute code to it so that isn't a github lock-in? Have you checked to see if the authors are opposed to that kind of contribution? I think all of these extra solutions are coming up because folks are frustrated with the current status of our main portage tree not being under git. > Best regards, > Andrew Savchenko William signature.asc Description: Digital signature
Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
On Sat, 11 Apr 2015 21:57:13 -0500 Gordon Pettey wrote: > On Sat, Apr 11, 2015 at 5:47 PM, Andrew Savchenko > wrote: > > > 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. > > > > Looks pretty open to me... https://github.com/travis-ci/travis-ci > Replacement may be non-trivial purely due to the large number > of components involved, but closed and proprietary are a bit > extreme. Problem is not in replacement only. Travis is a GitHub lock-in: https://github.com/travis-ci/travis-ci README.markdown Without GitHub Travis is useless, as it can't be used with any other solution. And GitHub itself is closed. Do you aware of any local Travis setup out there? There are none to my knowledge. Best regards, Andrew Savchenko pgpqeOw7z1r9G.pgp Description: PGP signature
Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
Andrew Savchenko wrote: > we should not solely rely on third-party proprietary solutions > (travis is a github lock-in) because of convenience. We must not. //Peter pgp10MsxnxXNc.pgp Description: PGP signature
Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
On Sun, 12 Apr 2015 03:03:18 + (UTC) Jorge Manuel B. S. Vicetto wrote: > > 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. > > Our infra has no dependency over travis. The only thing we've done infra > side about this is to create the alias travis-ci and an ml[1] > (gentoo-automated-testing) where we plan to send the output of several > automated tools so that interested parties can check the status and "fix" > any issues. > > [1] - https://archives.gentoo.org/gentoo-automated-testing/ > > > 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. > > I fail to see how by adding yourself to the alias, joining the ml or > checking the archives, you are breaking in any way the Social Contract - > but every developer is free to choose whether to use this tool or not. Right now there is no hard dependency on github or travis, of course. But present pathway worries me: with current pace at some point we _will_ depend on travis or github too much. Then they may change their terms of service or license argeement, or just shut down the whole service (as Google recently shut down Google Code). And then we will be in a great trouble. And then it may be too late to change anything. I want to avoid this, that's all. What we should really do is to develop our own QA tools or use existing free ones on our own infrastructure, thus that Gentoo development may continue to be independent and unbiased. Please understand that I'm grateful for all people improving Gentoo, including Michał, for their hard work. But we should not solely rely on third-party proprietary solutions (travis is a github lock-in) because of convenience. Best regards, Andrew Savchenko pgpm7H50waV8O.pgp Description: PGP signature
Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
On Sun, 12 Apr 2015, Andrew Savchenko wrote: 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. 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. If travis will become essential for Gentoo development, it may undermine development freedom and Gentoo social contract, which states: "Gentoo will never depend upon a piece of software or metadata unless it conforms to the GNU General Public License, the GNU Lesser General Public License, the Creative Commons - Attribution/Share Alike or some other license approved by the Open Source Initiative (OSI)." I've seen no one suggest the use of travis is or will be mandatory. What Michał has done is setup the environment to help identify tree breakage. I want to thank him for working on a tool to improve the quality of Gentoo. 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. Our infra has no dependency over travis. The only thing we've done infra side about this is to create the alias travis-ci and an ml[1] (gentoo-automated-testing) where we plan to send the output of several automated tools so that interested parties can check the status and "fix" any issues. [1] - https://archives.gentoo.org/gentoo-automated-testing/ 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. I fail to see how by adding yourself to the alias, joining the ml or checking the archives, you are breaking in any way the Social Contract - but every developer is free to choose whether to use this tool or not. If some other free tool (preferably deployed on Gentoo infrastructure) will be used for this task, I'll sign-up right away. If you care about this topic, you should talk to the QA team and developers that have showed an interest in automated testing. Just the other day Magnus sent an email to this ml about a project his working on. Best regards, Andrew Savchenko Regards, Jorge Manuel B. S. Vicetto
Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
On Sat, Apr 11, 2015 at 5:47 PM, Andrew Savchenko wrote: > 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. > Looks pretty open to me... https://github.com/travis-ci/travis-ci Replacement may be non-trivial purely due to the large number of components involved, but closed and proprietary are a bit extreme.
Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
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. If travis will become essential for Gentoo development, it may undermine development freedom and Gentoo social contract, which states: "Gentoo will never depend upon a piece of software or metadata unless it conforms to the GNU General Public License, the GNU Lesser General Public License, the Creative Commons - Attribution/Share Alike or some other license approved by the Open Source Initiative (OSI)." 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. Best regards, Andrew Savchenko pgpS3UHLBxZFF.pgp Description: PGP signature
[gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
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. [1]:https://travis-ci.org/gentoo/gentoo-portage-rsync-mirror [2]:https://bugs.gentoo.org/show_bug.cgi?id=broken-depgraph -- Best regards, Michał Górny pgppRiQY8LP4d.pgp Description: OpenPGP digital signature
