Re: [gentoo-dev] Re: Referencing bug reports in git
On 08/12/2015 08:38 PM, Matt Turner wrote: On Wed, Aug 12, 2015 at 3:40 AM, hasufell hasuf...@gentoo.org wrote: So, I've just tried to count the ++ for different ideas and even if I missed one or two or misread someone's opinion, I think the result is pretty clear: reference the bug only in the summary: 1 don't make any of this mandatory: 1 Gentoo-Bug: 123 or similar short form: 9 Gentoo-Bug: url or similar long form: 2-3 I'm in favor of Gentoo-Bug: url in case we're voting. May be Bug-Gentoo should be used instead. It's to use the same header name format as Debian in their patches (Bug-Debian). -- Best regards, Dmitry signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
On 08/11/2015 10:12 AM, Michał Górny wrote: Dnia 2015-08-11, o godz. 09:56:55 Dmitry Yu Okunev dyoku...@ut.mephi.ru napisał(a): On 08/11/2015 12:06 AM, Michał Górny wrote: 3. Too many text, hard to read. Some bugs may refer to a dozen of URLs. And how is a dozen numbers better? Less text, more readable. How is: Bug: 123451, 453445, 344334, 343444 more readable than: Bug: https://bugs.gentoo.org/123451 Bug: https://bugs.gentoo.org/453445 Bug: https://bugs.gentoo.org/344334 Bug: https://bugs.gentoo.org/343444 Readability is a matter of formatting, not contents. 1. One line and 35 chars are certainly more readable than four lines and 140 chars. Character counts are completely irrelevant to readability. Visual space is. And in this case, exhibit A (also known as wall of digits) is more likely to get people confused. I think it's just individual preference. No sense to argue this. Just everybody should consider that there exists another position on this question. However I want to add an other argument: 1a. It's easier to parse the Bug: header is there only bug IDs (without URLs). What if there are different bug trackers involved? We sometimes note upstream bugs, other distro bugs, pull requests... For example Gentoo may use Gentoo-Bug:/Bug-Gentoo: as I mentioned. Debian uses Bug-Debian: for Debian ITS references and Bug: for upstream bugreport references in their patches (debian/patches/*), IIRC. And is there any guarantee that URL format won't be changed in future (that everybody won't be have to rewrite their parsers). I mean not near future, but any long future. I doubt it can change *without* changing the bug tracker software. And then, old IDs will no longer be relevant. Why? Just migrate with saved IDs. In fact, since the URLs are Bugzilla-specific it will allow us to ensure better compatibility if we start numbering bugs from 1 again. IMHO, it's a really bad idea to do not migrate previous data to the new ITS. There's URL and there's URI. Even if URL is no longer valid, it will still be a valid URI. It will still allow us to uniquely identify the bug report. Only if you will use Bugzilla or some workarounds to imitate Bugzilla. It's a lock-in. 2. Strings are read from left to right (at least in English), thus having most important information last on the line is not convenient. This is not literature. Keys usually precede values, and namespaces precede namespaced identifiers. A commit-comment is not a source code. It's an ordinary text (like literature). Literature is a long continuous text which you read left-to-right, and usually without going back. This is short text which you read randomly, possibly going back and forth, and scanning for specific details. Well, ok. But personally I have a habit to read such text left-to-right. It requires split seconds to recognize this lines similarity but it requires. Anyway as I said, I will see much more garbage while looking on the whole text if you will use URLs instead of pure IDs. As far as I'm aware, URLs are supported much more widely than Gentoo-specific bug numbers. They are uniform and unique by definition. The tools using bug numbers can be easily expanded to extract them from URLs. I don't really see forking cgit to support Gentoo bug numbers, or asking github to provide special rules for our commits. We should not adjust our ecosystem for closed and proprietary solutions like github. URLs are not github invention. Localized bug numbers are local Gentoo non-sense. So should we adjust it to ignore the rest of the world and expect everyone to create custom hackery just to be able to see a bug report? You can use header Gentoo-Bug: (instead of Bug:) and explain in documentation ways to parse that. So you're suggesting it's better to invent a custom format and tell people how to handle it, rather than use a commonly-supported format? What you mean with the custom format? I suggest to use comment as a comment, but not as a documentation about How to reach Gentoo ITS in every comment. I can agree with another argument: There should be a possibility to define an upstream bug which format in turn can be simply unified only by URLs. And it may became harder to read when neighboring headlines are formatted different ways (one header — pure IDs, another one — URLs). But _IMHO_, it doesn't outweigh disadvantages of this approach (with URLs for reference on Gentoo bug). -- Best regards, Dmitry. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
Hello. I'm not a gentoo-dev, so sorry if I shouldn't express my thoughts with my lame English here. Please tell me if it's so. On 08/11/2015 12:06 AM, Michał Górny wrote: 3. Too many text, hard to read. Some bugs may refer to a dozen of URLs. And how is a dozen numbers better? Less text, more readable. How is: Bug: 123451, 453445, 344334, 343444 more readable than: Bug: https://bugs.gentoo.org/123451 Bug: https://bugs.gentoo.org/453445 Bug: https://bugs.gentoo.org/344334 Bug: https://bugs.gentoo.org/343444 Readability is a matter of formatting, not contents. 1. One line and 35 chars are certainly more readable than four lines and 140 chars. Character counts are completely irrelevant to readability. Visual space is. And in this case, exhibit A (also known as wall of digits) is more likely to get people confused. I think it's just individual preference. No sense to argue this. Just everybody should consider that there exists another position on this question. However I want to add an other argument: 1a. It's easier to parse the Bug: header is there only bug IDs (without URLs). And is there any guarantee that URL format won't be changed in future (that everybody won't be have to rewrite their parsers). I mean not near future, but any long future. 2. Strings are read from left to right (at least in English), thus having most important information last on the line is not convenient. This is not literature. Keys usually precede values, and namespaces precede namespaced identifiers. A commit-comment is not a source code. It's an ordinary text (like literature). 3. A lot of duplicated and useless information consumes time and space, irritating people. Well, maybe I'm very special then because I can *instantly* notice that the four quoted lines are almost identical and differ only by bug numbers. Yes. But as for me this duplicated text adds a lot of garbage to the total text of a comment. It's harder to fast look over it. You were right — Visual space does matter. And Andrew said useless information — I agree. 4. Think about people using special accessibility devices like speech-to-text engine or Braille terminal. It will be pain for them to read all this notorious URLs. And we have at least one developer relying upon such devices. And that's the first valid argument. Though I would doubt that accessibility software handles random numbers better than URLs. Unless you consider retyping one of the six numbers you just heard easier than triggering some kind of URL activation feature. I remember that William Hubbs asked me to remove one very simple ASCII-arted scheme (that explains how the code works) from a patch, because it's very inconvenient to listen that stuff using speech-to-text engines. May be somebody should just ask him for his opinion on this question? I think it's more convenient to listen pure bug IDs rather than a lot of full URLs. What is a corner case? Why not defining clicking on the link in the git log as a corner case? As far as I'm aware, URLs are supported much more widely than Gentoo-specific bug numbers. They are uniform and unique by definition. The tools using bug numbers can be easily expanded to extract them from URLs. I don't really see forking cgit to support Gentoo bug numbers, or asking github to provide special rules for our commits. We should not adjust our ecosystem for closed and proprietary solutions like github. URLs are not github invention. Localized bug numbers are local Gentoo non-sense. So should we adjust it to ignore the rest of the world and expect everyone to create custom hackery just to be able to see a bug report? You can use header Gentoo-Bug: (instead of Bug:) and explain in documentation ways to parse that. -- Best regards, Dmitry. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] A question to Russian Gentoo Developers Community about import software substitution
08.05.2015 23:05, Vadim A. Misbakh-Soloviov пишет: I had been trying to push the idea of creating an united FOSS community to solve problems of the higher school of the Russian Federation. But such initiatives faded due to absence of support of top executives… And now (according to e.g. [1]) it won't be a problem, IMHO. It would. Just because of the fact, that top executives (in Education Dept, in regional ministerys and so on) is that kind of clerks, that WOULDN'T accept anything if it is impossible to get (read as steal) some money in personal. The link [1] shows that the _can_ get money in personal. And I'd prefer make a distribution for the higher shool based on Gentoo Linux. I'd also prefer, but it is not that possible as you imagine. There is such thing as certification in Federal Security Service (FSB) and so on. 1. It's not a big problem. We can certify a release of our Gentoo based distribution. It's just need a money to pay to laboratories. Plus big universities (like my) have enough social ties to fast push such things through Russian bureaucracy machines, IMO. And we can return the spent money the same way as ALT Linux (by selling tech support coupons). 2. The Federal Service for Technical and Export Control (ФСТЭК) and Federal Security Service (ФСБ) certificates required only to process big systems with personal data (ФЗ-152). For the rest systems (like ordinal desktop) it's not required at all. So here's the Question: Does anybody interested in creating a consortium to send an application to the Ministry of Communications? I'm partially interested to mentally maintain that, but I have to free time to activelly do anything in personal (but, probably, will be fine in a group). I just offer to unite efforts. You don't need to free an additional time. We just need to find common problems and solve it together as a project for Ministry of Communications. Other good people will connect to us and meanwhile the support of the ministry will stimulate the top executives. Specifically, I'm interested in making a distribution for the higher school of Russian Federation. But, as I said, I doubt in success of that operation. But... Let the Force be with us... There was a lot of doubtable (but good) projects in my life. However few of them successfully started and completed. I think we _must_ try if we believe in FOSS. Sorry for this pathos :) P.S. I'd not use politic-related phrases (like import software substitution) in international communities at all and here in particular. Sorry for that. I was thinking that it's better to make subject more concrete. Best regards, Dmitry.
[gentoo-dev] A question to Russian Gentoo Developers Community about import software substitution
Hello. I'm not a Gentoo Developer and sorry if I shouldn't write such messages here. If it's really so then I'll consider this in the future and it will not happen again. The question is only for Russian Gentoo Developers subcommunity. I had been trying to push the idea of creating an united FOSS community to solve problems of the higher school of the Russian Federation. But such initiatives faded due to absence of support of top executives… And now (according to e.g. [1]) it won't be a problem, IMHO. And I'd prefer make a distribution for the higher shool based on Gentoo Linux. So here's the Question: Does anybody interested in creating a consortium to send an application to the Ministry of Communications? [1] http://www.opennet.ru/opennews/art.shtml?num=42189 Best regards, Dmirty. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: openrc service script dependency checker
Hello, everybody! I'm the author of discussed patches and let me put my 2¢. I want to clarify some things and explain my position… Right away sorry for my English skills. Also I wrote the patches year ago and may remember something incorrectly. 1. The Later Loop Detector There are really two approaches which can complement each other. But personally I as the author recommend only the early loop detector (below - ELD) to be approved into the upstream. This is due to next facts: - I'm not sure in correctness of the later loop detector (below — LLD). - LLD can be easily replaced in most of cases by modifying 2 lines in the ELD. So it's just an extra code. However I can imagine few situations where ELD will be unable to handle a loop situation, while the LLD will be able to. Nevertheless even if this situations really exists, they should appears only in quite exotic conditions (like read-only dependencies cache file). Some time is required to make tests in order to verify this aspect, which can be done if somebody here thinks that this is really important. So I recommend to discuss only the ELD. 2. The Early Loop Detector, summary As Andrew Savchenko already mentioned the algorithm is represented in PDF-presentation [1], and ELD works while building dep tree cache. [1] https://github.com/xaionaro/documentation/blob/master/openrc/earlyloopdetector/early-loop-detection.pdf Actually ELD is not only a detector but also a solver, so it can be considered as two separate components: - Loop detector (below — Detector). It detects a dependency loop chains. - Loop solver (below — Solver). Analyzes different variants of loops solutions and solves them (if possible). I think almost everybody here agree that Detector is really required in OpenRC. It's quite definitely that sysadmin should be able to see any error situation on his/her machine. So let's talk only about the Solver. And I think the Solver should be enabled by default. But I even don't hope that somebody will support this position in this mail-list and IMHO it's quite useless to argue on this issue. But I'm very sure that the Solver should be saved at least as an option. 3. Using ELD Solver as an option Sorry if I remember something wrong. I need time I don't have right now to recheck and refresh my memory. But IIRC currently without the Solver, OpenRC in parallel: - Hangs with timeout (and can hang multiple times, as it was in may case with ~60 services the same time). - Just doesn't run all looped services. So any extra use dependency can break startup of great lot of services. As it already happened on Debian. Here's a quote from Gentoo Handbook [2]: The *use* settings informs the init system that this script uses functionality offered by the selected script, but does not directly depend on it. A good example would be *use logger* or *use dns*. If those services are available, they will be put in good use, but if you do not have a logger or DNS server the services will still work. If the services exist, then they are started before the script that *use*'s them. [2] https://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=2chap=4#doc_chap3 Moreover the system boot can be delayed for few minutes or even for few hours (as in my case, IIRC). Almost anyone tells me that the Solver is even not an option for OpenRC. But I disagree. It has heuristic algorithm to minimize the detriment. If you boot looping system without the Solver the detriment will be much more significant. For example network and sshd wouldn't start due to one extra use dependency and system will boot a long time. IIRC, in case of Debian the whole system is not running (inc. mounting, network and so on) due to extra use dependencies only. I can understand that you don't care about Debian and I'm prepared to the unfortunate fact that we will have to maintain extra patch for OpenRC package in Debian. So returning to Gentoo. Let's just compare behavior in loop situation with the Solver and without. Without the Solver (sorry for repeating this): - System will hang until timeout will be reached and so for each loop. - All looping services won't start. Likely enough, system will be unreachable. With the Solver: - System won't hang, of course. - Some low-cost dependency will be removed and likely all looping services will start. Also what sysadmin should do to make the Solver harm him/her. He should: - Enable the Solver manually in /etc/rc.conf (if it's not enabled by default). - Use need instead of use and use instead of need (or something like this). - Create the loop situation. - Ignore warnings and reboot. I can imagine this only if this is done willfully. I very need this option in Debian and I'd prefer to use it on Gentoo. So I recommend to save the Solver at least as an option. 4. Few comments My opinion is the less automatic adjustment we do the better. Don't enable the option. :) On 12/04/2014 04:59 PM, Rich Freeman wrote: I
Re: [gentoo-dev] rfc: openrc service script dependency checker
One more ¢… On 12/04/2014 08:37 PM, Christopher Head wrote: On December 4, 2014 8:12:58 AM PST, Andrew Savchenko birc...@gentoo.org wrote: Yes. But booting as much services as possible is even more preferable, especially when box is remote. Are you sure booting most, but not all, services in a loop is always better than booting none of them at all? What if I have an insecure dæmon listening on TCP, I need it running, but I want to ensure only local processes can connect to it? Obviously, I would make it “need iptables”, assuming the dæmon doesn’t have its own bind address config knob. What if now, by some accident, iptables ends up in a loop (maybe not even a loop including $insecure_service, but some other loop entirely), and it’s the randomly chosen victim? Is it still good to boot as many services as possible? I think not. I would make it “need iptables” Firstly, the loop solver doesn't remove need dependencies [1]. There will be no problem. [1] https://github.com/xaionaro/documentation/blob/master/openrc/earlyloopdetector/early-loop-detection.pdf But there are few ways to bypass such problems. For example: - Don't enable the option in this case. You should understand consequences of enabling any non-default option. Also for example sysadmin shouldn't setup public sshd with pass test on root. Here's the same. It's just required to understand what are you doing. - Use network namespaces for insecure processes without ability to setup the bind address. And use iptables to redirect to the real listening port (in the namespace). Best regards, Dmitry. signature.asc Description: OpenPGP digital signature
