[gentoo-dev] Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings
Tom Wijsman posted on Wed, 13 Aug 2014 10:38:45 +0200 as excerpted: >> I don't recall a policy mandating that descriptions can't end with '.'. >> I asked our QA lead about it and was told that he didn't recall that we >> have an official policy about it either. Also, the devmanual never >> mentions any such requirement. > > It has been a common belief to drop '.' among some from what I've seen. [Observational/skippable.] FWIW, I've been watching this debate with some amusement, as I follow Language Log, which has a continuing serious covering the generational/ regional differences in period/full-stop interpretation. The first in the series and my favorite, due to the cartoon illustrating the issue (Nov. 2012): http://languagelog.ldc.upenn.edu/nll/?p=4304 Two newer installations of the series (Nov 2013 and Aug 1, 2014, respectively): http://languagelog.ldc.upenn.edu/nll/?p=8667 http://languagelog.ldc.upenn.edu/nll/?p=13723 It can be a big deal for some. Quoting from the first comment on the first article (and noting that what we call a "period" US-English is a "full stop" in UK-English): Obviously, a period is a full stop, but, in short text messages, I feel like it almost SAYS full stop, with all the attendant emphasis of that phrase. "Best movie ever" is one thing, but "Best. Movie. Ever." is quite another. Back to gentoo and the current "Much ado about nothing". Someone's irritated with the periods/full-stops following short descriptions, because to him it's disruptive, almost as if an exclamation point (which I /would/ find disruptive) was used, such that for him a repoman check is warranted. But to many others, it's trivial, certainly nothing worth bothering with a repoman check and hundreds of individual fixes with concurrent changelog entries. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] minimalistic emerge
Tom Wijsman: > On Sat, 9 Aug 2014 18:10:51 +0100 > Ciaran McCreesh wrote: > >> On Sat, 09 Aug 2014 11:12:46 -0400 >> Chris Reffett wrote: >>> Then write it. Portage's source is available to anyone. >> >> It's quicker to start from scratch than to try to add things to >> Portage's source... > > But do we want to be quicker? If you want a lot of input, Portage... > How is your private PM project going? I heard you want to write a PM from scratch in C++.
Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings )
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 12 Aug 2014 10:04:58 -0400 Ian Stakenvicius wrote: > I'm wondering what everyone thinks of having a --nonag option to > repoman and shoving some of the more trivial/style-related repoman > 'warnings' into a 'nag' level warning? What is the point of a repoman 'warning' if it doesn't nag anymore? > IIRC at least one of the QA team members is so tired of the warnings > that they want to make every single one of them errors; the --nonag > option would allow those warnings to remain in repoman (ie to help > guide new dev's or non-dev's using repoman on their local repos) but > since they don't relate to actual technical breakage they can just be > turned off during QA runs, etc. For all I know the QA team tries to get rid of them where we can with the resources available; we're not necessarily tired of seeing them, but what is the point in having such repoman 'warning' if maintainers as a whole don't pursue the same goal as the QA team is trying to do here? These repoman warnings don't block commits; so, they're not problematic in terms of being able to do your workflow. There has been talk by Patrick to turn some of the warnings into errors, but that doesn't imply that the QA team or community necessarily thinks in the same way. So, I don't think that's something to worry about; especially with the increased awareness after the DESCRIPTION.punctuation happening. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJT6yY7AAoJEPWZc8roOL/Q9YcH/1uQ4yxS19X/EKb0x3RZWK5M Yk3HRJoFidD1q0mcVhqmYs8ZU+y6kppE3yHw0hpPMt3yEzym9ObB+EFl8C4841cr 3wlyY4hLNjn+hHvgiZMi3c2+OTiKZB02z7sZ/gRb5Q0oWWINZn7buWGvI0Y2iuk/ URKjn73yPsg4EisPDrfpX8NdHqSZP5MV1/EFibU0zmd97L0O/mcB/UvTOMQYegyL NEE9hLPcrU9BTl4KYsRCDhqssKu7RFsMtbuzHHrswmSMUtPtUcjeVt5EFTjYt+0k lzDEGREh9kYd87vapeUmShTZXJcK8TnwDDwh2qbNcc+M8fgOoqTbR1rmOiIjFwA= =cFld -END PGP SIGNATURE-
Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings
On Mon, 11 Aug 2014 20:48:20 -0500 William Hubbs wrote: > On Sun, Aug 10, 2014 at 03:22:11PM +0300, Sergei Trofimovich wrote: > > Hello World! > > > > TL;DR: > > This evening I plan to mangle ~3000 ebuilds in the main tree > > by dropping trailing '.' in all 'DESCRIPTION=' fields (except > > "etc." case) > > > > Long story: > > > > As you may know newest portage release 2.2.11 > > got a minor (but chatty) QA warning: > > DESCRIPTION ends with a '.' character > > Why is this a QA warning in the first place? It isn't or shouldn't be; in the future, it would be nice if this type passes by QA / Council before being acked into the Portage tree code. Looking at the commit, the ack / commit has completely bypassed QA; we also were not involved on the related bug, thus we were unaware of it. > I don't recall a policy mandating that descriptions can't end with > '.'. I asked our QA lead about it and was told that he didn't recall > that we have an official policy about it either. Also, the devmanual > never mentions any such requirement. It has been a common belief to drop '.' among some from what I've seen. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] minimalistic emerge
On Fri, 08 Aug 2014 23:04:40 +0200 Johannes Huber wrote: > /me is thinking: > Your caps lock key is broken and about the content: man portage || > use linux from scratch Caps lock highlighting is a common practice. Why do you tell him to read a manual or use a distribution that both lack the requested feature? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] minimalistic emerge
On Sat, 9 Aug 2014 18:10:51 +0100 Ciaran McCreesh wrote: > On Sat, 09 Aug 2014 11:12:46 -0400 > Chris Reffett wrote: > > Then write it. Portage's source is available to anyone. > > It's quicker to start from scratch than to try to add things to > Portage's source... But do we want to be quicker? If you want a lot of input, Portage... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] minimalistic emerge
On Fri, 8 Aug 2014 15:32:37 +0200 Jeroen Roovers wrote: > Nice capitalisation! Speaking of which, where is the US$ 1,000,000 > (ONE MILLION UNITED STATES DOLLARS) you promised in your last e-mail? Nice placement of the space behind the dollar sign! No money for you. > Don't bother to file bug reports if you think a fully up to date > system is not for you. Where do we state to have a fully up-to-date system before filing a bug? This in particular becomes interesting to do when the bug keeps you from updating your system; or even further, rendering it non bootable. We need to fix things such that people have a working system that they can bring up-to-date; not the other way around, as that is pointless. Automatic updates is a goal to pursue; well, at least if you want everyone to have a fully up-to-date bootable system that can update. > > Is there any option in emerge to pull MINIMUM packages to > > get the result - install the application you need, leaving > > everything else AS IS untouched and stable? > > RTFM. Why do you point to a manual which does not document such feature? > > If no such USE flag, what about stabilize > > gentoo with STABILIZED flag implementation in make.conf? > > Next time, please bother the gentoo-user@ mailing list. No. The gentoo-user@ ML can't do anything about a missing feature. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[OT] Re: [gentoo-dev] minimalistic emerge
On Sat, 9 Aug 2014 19:25:56 +0400 Igor wrote: > In my experience - hacking into 96 system with a 0 door is much > harder than in 2014. In most cases unless you're an expert on 96 > software which is difficult nowadays due to human memory. Why does one need to be an expert? How about known and/or implemented exploits? > To really break in you need to reproduce server environment as close > as possible or/and have a clear understanding how this particular > software works. Try to assemble a 96 system on modern hardware or > assemble it as they were back in 96, not all sources are online any > longer, that is a hard job. 2014 systems are much easier to assemble > and get a peek to the sources is a trifle. Why reproduce the environment? Is the sources' availability the only factor? > As Linux software is open-source it's often easier to break in Linux > than in Windows systems. The open source is only theoretically safer. > Many belive that because the code is open - it's reviewed and checked > and the number of critical bugs is low. But the reality is that there > is usually no time to review code. Many modern software is very > complex with millions lines and it's not realistic to check or > understand how it works before you use it in your project. Tell me > how many libraries that you use right now are reviewed by you > personally? Not many. And that is a door that is NEVER going to be > closed. There are bugs, rest assured, if you pull any soft right now > and spend time you will find them. If you have an expertise on cross > platforms - you will find even more as developers used to focus on > one platform the birth platform. Can you back up that open source is theoretically safer / harder / ...? It depends on how you look at the source code and binaries; having either doesn't necessarily make it easier or harder to accomplish, especially if you want to find run-time behavior to exploit. You could scan through the source code looking for known errors or so; however, the same is possible to do with the machine code. Both can be done manually or automatically; whether it gets tedious to find, depends on what it is exactly that you are trying to find and how you find it. > If you compare the number of bugs you find in 1996 software and in > 2014 > - the numbers would approximately be the same. That reads like a wild guess due to too much assumptions / conditionals. > Usually 1996 system is patched or protected against known issues and > you have to deal with "unknown" which in case of 1996 is much harder. This also reads like a wild guess; words ending in -ly like "usually" indicate that you're not sure about it and how much of it really is as such, a more believable statement would read like "...% of the systems in 1996 are ... [reference to research]". > Another weak link with open source is software developers. Many of > them spend a lot of time on their software not always getting a fair > monetary reward. So if you a very shrewd and have resources - you go > to developers and offer them money to introduce a subtle bug into the > main tree. After the software is adopted then you have open doors in > EVERY "updated" linux on the planet. > > Personally I belive Heart Bleed bug is one of such. You can never > proof if the bug is artificial or not - how? > > The same true for Microsoft soft. You can basically go to a ntkernel > developer offer him 500 000$ if have them and he would add a bug and > explain you how to use it and you're everywhere :-) but this is > usually the government's methods. They used to keep them secret. Have you considered steady high incomes and the aftermath? With a steady high income and a high level job as Microsoft kernel developer, 500 000$ and the aftermath of consequences loses traction. You might be able to convince that single kernel developer; however, that developer still has to slip this by the rest of the kernel development team as well as quality assurance processes and measures. Getting by the static and dynamic analyzers as well as other run-time measures they have to their availability for awareness is harder than without it; apart from it, there's are also human code reviews and QA. The story gets somewhat different when people don't end up using them, or not spend an equivalent effort; like for example with Heart Bleed. Think about some random unrelated pieces of open source libraries; did that get run through analyzers and include run-time measures, have code reviews like kernels would have and extended QA procedures? https://i.imgflip.com/b3mx0.jpg -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On Wed, 30 Jul 2014 13:48:37 +0200 Luis Ressel wrote: > I think I'd rather go with the original workflow. Okay, perhaps > package.masking - is a bit uncommon and clutters package.mask, but > it's not all *that* bad and it eases the workflow. Depends on whose workflow you are referring to; it doesn't affect the maintainer, but the clutter can be a pain if you attempt to keep the p.mask size low. Having package.mask as a directory would be a solution to this; however, there's not much other need for it to be a directory. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
