Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer
El mié, 26-07-2017 a las 13:46 +, Lucas Ramage escribió: > I am not yet an official developer but I am interested in assisting in > maintaining this. > Then, please take a look on: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers In summary, you will need to open a bug asking proxy-maint to set you as maintainer and, for fixing bugs, usually sending github PR is the preferred method Thanks
Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow
On 07/26/2017 07:20 PM, Rich Freeman wrote: > I was thinking that it would make far more sense to use "Bug" for > Gentoo bugs, and use something like "Reference" or "Remote-Bug" for > non-Gentoo bugs. 99% of the time commits will reference a Gentoo bug. I like the idea of Reference for URL specification . This can be used as a general property for other relevant discussion points as well, and indeed frees up Bug to be used for Gentoo with numeric identifiers only. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow
On śro, 2017-07-26 at 19:05 +0200, Kristian Fiskerstrand wrote: > On 07/25/2017 02:28 PM, Michael Palimaka wrote: > > Does a bug # really need to always be in the summary line? It can eat > > valuable characters and tags which are pretty popular are equally valid IMO. > > I would prefer the summary to be informative without having bug ID at > all. Summary should describe the change ,not only "fixes XXX", the bug > reference belongs in body (tags) > I guess I didn't say it verbosely but this obviously should be the case. The bug no is just a cherry at the top. Of course if you can't spare 6 characters, you don't have to put it there. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow
On śro, 2017-07-26 at 19:17 +0200, Kristian Fiskerstrand wrote: > On 07/25/2017 10:05 AM, Michał Górny wrote: > > ** Fixes: https://bugs.gentoo.org/NN;; — > > to indicate a fixed bug, > > At this point fixes is overloading > > ** Fixes: commit-id (commit message) — to indicate fixing a > > previous commit > > This use should be forbidden. ...because? But sure, you don't like it, let's remove it. Not that anyone will actually prefer the things from the GLEP over anything else. > > ** Bug: https://bugs.gentoo.org/NN;; — to > > reference a bug, > > See other comments in thread wrt Gentoo-Bug. > > > ** Closes: https://github.com/gentoo/gentoo/pull/ > ki>; — to automatically close a GitHub pull request, > > Is this a generic tag for any pull request of any platform? No. As I've told multiple times already, there are *no* generic tags. It just happens to be used by some random platforms. Some others use e.g. 'Fixes' which you forbade. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow
On 07/27/2017 03:52 PM, Michał Górny wrote: > On śro, 2017-07-26 at 19:17 +0200, Kristian Fiskerstrand wrote: >> On 07/25/2017 10:05 AM, Michał Górny wrote: >>> ** Fixes: https://bugs.gentoo.org/NN;; — >>> to indicate a fixed bug, >> >> At this point fixes is overloading >>> ** Fixes: commit-id (commit message) — to indicate fixing a >>> previous commit >> >> This use should be forbidden. > > ...because? But sure, you don't like it, let's remove it. Not that > anyone will actually prefer the things from the GLEP over anything else. > Because it overloads the tag for multiple meanings and as such should be different tags, we already have a tag that specifies the bug (namely Bug, presuming we use Reference: for URL specification of relevant upstream information or other discussions) >>> ** Bug: https://bugs.gentoo.org/NN;; — to >>> reference a bug, >> >> See other comments in thread wrt Gentoo-Bug. >> >>> ** Closes: https://github.com/gentoo/gentoo/pull/>> ki>; — to automatically close a GitHub pull request, >> >> Is this a generic tag for any pull request of any platform? > > No. As I've told multiple times already, there are *no* generic tags. It > just happens to be used by some random platforms. Some others use e.g. > 'Fixes' which you forbade. > Isn't that the point of having a GLEP to begin with? Trying to standardize the use of e.g the tags so that it has a consistent meaning and can be useful? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow
On czw, 2017-07-27 at 15:54 +0200, Kristian Fiskerstrand wrote: > On 07/27/2017 03:52 PM, Michał Górny wrote: > > On śro, 2017-07-26 at 19:17 +0200, Kristian Fiskerstrand wrote: > > > On 07/25/2017 10:05 AM, Michał Górny wrote: > > > > ** Fixes: https://bugs.gentoo.org/NN;;; > > > > — > > > > to indicate a fixed bug, > > > > > > At this point fixes is overloading > > > > ** Fixes: commit-id (commit message) — to indicate fixing a > > > > previous commit > > > > > > This use should be forbidden. > > > > ...because? But sure, you don't like it, let's remove it. Not that > > anyone will actually prefer the things from the GLEP over anything else. > > > > Because it overloads the tag for multiple meanings and as such should be > different tags, we already have a tag that specifies the bug (namely > Bug, presuming we use Reference: for URL specification of relevant > upstream information or other discussions) > > > > > ** Bug: https://bugs.gentoo.org/NN;;; — > > > > to > > > > reference a bug, > > > > > > See other comments in thread wrt Gentoo-Bug. > > > > > > > ** Closes: https://github.com/gentoo/gentoo/pull/ > > > ki>; — to automatically close a GitHub pull request, > > > > > > Is this a generic tag for any pull request of any platform? > > > > No. As I've told multiple times already, there are *no* generic tags. It > > just happens to be used by some random platforms. Some others use e.g. > > 'Fixes' which you forbade. > > > > Isn't that the point of having a GLEP to begin with? Trying to > standardize the use of e.g the tags so that it has a consistent meaning > and can be useful? > Tags are mentioned merely for convenience, and as examples. If you want to request GitHub support to add support for special Gentoo tags you've just invented, be my guest. But don't bother forwarding their reply to me because I know their answer. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow
On 07/27/2017 03:58 PM, Michał Górny wrote: > ** Closes: https://github.com/gentoo/gentoo/pull/ ki>; — to automatically close a GitHub pull request, Is this a generic tag for any pull request of any platform? >>> No. As I've told multiple times already, there are *no* generic tags. It >>> just happens to be used by some random platforms. Some others use e.g. >>> 'Fixes' which you forbade. >>> >> Isn't that the point of having a GLEP to begin with? Trying to >> standardize the use of e.g the tags so that it has a consistent meaning >> and can be useful? >> > Tags are mentioned merely for convenience, and as examples. If you want > to request GitHub support to add support for special Gentoo tags you've > just invented, be my guest. But don't bother forwarding their reply to > me because I know their answer. Right, so github automatically closes pull requests when encountering Closes, that doesn't indicate that Closes can't be used for other platforms to do similar things, or closing things manually if provided through other channels. The current wording indicates it is only for Github use "to automatically close a GitHub pull request," -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow
On czw, 2017-07-27 at 16:08 +0200, Kristian Fiskerstrand wrote: > On 07/27/2017 03:58 PM, Michał Górny wrote: > > > > > > ** Closes: > > > > > > https://github.com/gentoo/gentoo/pull/ > > > > > ki>; — to automatically close a GitHub pull request, > > > > > > > > > > Is this a generic tag for any pull request of any platform? > > > > > > > > No. As I've told multiple times already, there are *no* generic tags. It > > > > just happens to be used by some random platforms. Some others use e.g. > > > > 'Fixes' which you forbade. > > > > > > > > > > Isn't that the point of having a GLEP to begin with? Trying to > > > standardize the use of e.g the tags so that it has a consistent meaning > > > and can be useful? > > > > > > > Tags are mentioned merely for convenience, and as examples. If you want > > to request GitHub support to add support for special Gentoo tags you've > > just invented, be my guest. But don't bother forwarding their reply to > > me because I know their answer. > > Right, so github automatically closes pull requests when encountering > Closes, that doesn't indicate that Closes can't be used for other > platforms to do similar things, or closing things manually if provided > through other channels. The current wording indicates it is only for > Github use "to automatically close a GitHub pull request," ...which is the only purpose it's being used for right now, and I seriously doubt there will be any other use in the near future. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow
On 07/27/2017 04:11 PM, Michał Górny wrote: >> Right, so github automatically closes pull requests when encountering >> Closes, that doesn't indicate that Closes can't be used for other >> platforms to do similar things, or closing things manually if provided >> through other channels. The current wording indicates it is only for >> Github use "to automatically close a GitHub pull request," > ...which is the only purpose it's being used for right now, and I > seriously doubt there will be any other use in the near future. That doesn't mean we shouldn't prepare for it in our specification, why shouldn't I be able to use it for closing a pull request provided through bitbucket or a git request-pull from my private gitolite? There is absolutely no reason to mention github in the GLEP versus making it a generic tag for closing a pull request. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow
Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted: > ==Motivation== > Although the main Gentoo repository is using git for two years already, > developers still lack official documentation on how to use git > consistently. Most of the developers learn spoken standards from others > and follow them. This eventually brings consistency to some extent but > is suboptimal. Furthermore, it results in users having to learn things > the hard way instead of having proper documentation to follow. Just a couple grammar fixes: First sentence: s/repository is using git/repository has been using git/ Second: s/Most of the developers/Most developers/ -- 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
[gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow
Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted: > ==Specification== > ===Branching model=== > The main branch of the Gentoo repository is the master > branch. All Gentoo developers push their work straight to the master > branch, provided that the commits meet the minimal quality standards. > The master branch is also used straight for continous user repository > deployment. s/continous/continuous/ > Since multiple developers work on master concurrently, they may be > required to rebase multiple times before being able to push. Developers > are requested not to use workflows that could prevent others from > pushing, e.g. pushing single commits frequently instead of staging them > and using a single push. This is unclear as to which of the two behaviors is encouraged vs. discouraged. Maybe just add an an explicit "(encouraged)" and "(discouraged)" by each as appropriate? > Developers can use additional branches to facilitate review and testing > of long-term projects of larger scale. However, since git fetches all > branches by default, they should be used scarcely. For smaller projects, > local branches or repository forks are preferred. Nit-picking/quibble: "Can" vs. "may": While "can" is perfectly appropriate as used here in informal settings, "may" is more formal (with "can" reserved for whether it's technically possible, not at issue here or it wouldn't need mentioned, while "may" indicates it's approved/recommended, there's a child's game, "Mother may I", that I recall reinforcing this when I was young). Since this is intended as a GLEP it's arguably quite formal and "may" /may/ be more appropriate, thus my mention of the issue altho either should be well understood and "can" would be entirely appropriate if the context isn't considered quite that formal. Entirely a judgment call. > Unless stated otherwise, the rules set by this specification apply to > the master branch only. The development branches can use relaxed rules. Can/may... There may be other uses I won't mention but if you decide it's worth changing at all, a search and evaluate usage may be worth it. > Rewriting history (i.e. force pushes) of the master branch is forbidden. -- 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
[gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow
Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted: > ===Splitting commits=== > Git commits are lightweight, and the developers are encouraged to split > their commits to improve readability and the ability of reverting > specific sub-changes. When choosing how to split the commits, the > developers should consider the following three rules: > # Use atomic commits — one commit per logical change. > # Split commits at logical unit (package, eclass, profile…) boundaries. > # Avoid creating commits that are 'broken' — e.g. are incomplete, have > uninstallable packages. (Without commenting on the technical specifics, particularly in the examples, only nitpicking grammar here...) Two instances of "the developers": Should be "the developer" (singular), or "developers" (plural, no "the"), your choice. Note that in the first usage, if the singular "the developer" is chosen, the following "are" and "their" will need changed to singular as well. (Of course then there's the question of his/her or a controversial usage of singular "their" to remain gender neutral, so plural "developers" may be best there, nicely avoiding the secondary controversy. FWIW, the appropriateness of singular they/their to avoid gender specificity is a current topic of debate in linguistic circles, but is "languagelog approved" at least, citing usage by respected authors going back over a century, and seems to be on the way toward wider acceptance. YMMV, but it's easy enough to avoid the entire question here, with consistent plural usage.) > It is technically impossible to always respect all of the three rules, s/all of the three rules,/all three rules/ (Note omission of the comma too.) > so developers have to balance between them at their own discretion. Side > changes that are implied by other change (e.g. revbump due to some > change) should be included in the first commit requiring them. Commits > should be ordered to avoid breakage, and follow logical ordering > whenever possible. > > Examples: > * When doing a version bump, it is usually not reasonable to split every > necessary logical change into separate commit since the interim commits s/into separate commit/into separate commits/ ... but that's still slightly uncomfortable due to ambiguous plurality agreement. Maybe... "into its own commit" > would correspond to a broken package. However, if the package has a live > ebuild, it ''might'' be reasonable to perform split logical changes on > the live ebuild, then create a release as another logical step. > * When doing one or more changes that require a revision bump, bump the > revision in the commit including the first change. Split the changes > into multiple logical commits without further revision bumps — since > they are going to be pushed in a single push, the user will not be > exposed to interim state. > * When adding a new version of a package that should be masked, you can > include the {{Path|package.mask}} edit in the commit adding it. > Alternatively, you can add the mask in a split commit ''preceding'' the > bump. > * When doing a minor change to a large number of packages, it is > reasonable to do so in a single commit. However, when doing a major > change (e.g. a version bump), it is better to split commits on package > boundaries. -- 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] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Mon, Jul 24, 2017 at 4:22 PM, Sergei Trofimovich wrote: > TL;DR;TL;DR: > [...] Here's a data point you may, or may not, find relevant. in 16 years of using Gentoo exclusively, the only one time I used stable on one machine for about 2 years it ended up being much more of a pain than unstable. Actually, I can't say I have anything to complain about unstable. On my critical machines I snapshot the system subvolume before I update. I can't remember the last time I had to roll back. I'm sure most will disagree with me but since you're indirectly asking for my opinion here it is: I think people working on stable are wasting their time. But who am I to stop them...
[gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow
Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted: > ===Commit messages=== [...] > Historically, Gentoo has been using a few tags starting with X- > . However, this practice was abandoned once it has been pointed > out that git does not enforce any standard set of tags, and therefore > indicating non-standard tags is meaningless. Thanks for this historical note. I hadn't noticed, but if I had, I might have found the usage and then abandonment confusing, and this clears it up. =:^) > Gentoo developers are still frequently using Gentoo-Bug tag, s/developers are still frequently using/developers still frequently use/ The (past and continuing) tense that you're (apparently) trying to use, while common in other languages, isn't one English treats separately. > sometimes followed by Gentoo-Bug-URL. Using both > simultaneously is meaningless (they are redundant), and using the former > has no advantages over using the classic #nn form in the > summary or the body. -- 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] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Thu, Jul 27, 2017 at 7:12 PM, Denis Dupeyron wrote: > > Here's a data point you may, or may not, find relevant. in 16 years of using > Gentoo exclusively, the only one time I used stable on one machine for about > 2 years it ended up being much more of a pain than unstable. Actually, I > can't say I have anything to complain about unstable. When in the last 16 years was this 2 year period of running stable? The general state of QA has varied quite a bit over that time. Judging by the open bugs anybody running unstable systemd has been going through a bit of pain in the last week as various scripts/etc are updated to handle the change in install location. Now, it could have been masked initially, but that is really no different except it is a different set of guinea pigs. If unstable never breaks chances are we aren't actually using it for its intended purpose, not that we should be deliberately breaking things. -- Rich
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Thu, Jul 27, 2017 at 6:41 PM, Rich Freeman wrote: > > When in the last 16 years was this 2 year period of running stable? > The general state of QA has varied quite a bit over that time. > I would say 3 or 4 years ago, roughly. > running unstable systemd has been Running unstable doesn't mean being stupid. > If unstable never breaks chances are we aren't actually using it for its > intended purpose, not that we > should be deliberately breaking things. There's this idea that unstable should break. But the initial idea was that unstable is what should be sent straight to stable, barring the occasional mistake. Unstable was never meant for ebuilds in development and very much in flux because of that. That's what package masks are for.
[gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow
Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted: > ==Backwards Compatibility== > Most of the new policy will apply to the commits following its approval. > Backwards compatibility is not relevant there. s/Backwards/Backward/ (both header and body) "Backwards" is a regionalism I too have problems with (as a native USian with time in the former Crown colony Kenya and exposure to various European and Asian as well as widely dispersed USian usage. According to the wictionary entry, "backward" is strictly speaking the adjective in British English, "backwards" the adverb, while in the US, the usage is more flexible/regional and may be reversed. But (when I catch myself) I always try to use "backward", because the addition of the terminating "s" adds no meaning and has come to sound like "hick-speak" to my ear. Regardless, in this instance "backward" is used as an adjective, so the stricter "backward" should sound find to the British ear, while being at least flexibly tolerated to the American ear even if their particular region reverses it. (Besides, "backwards compatibility" sounds... like something my car lacked when I was trying to teach someone to drive, after they jammed the transmission in reverse while going forward. Hmm... Maybe I favor the -s form as adverb more than I thought. =:^) > One particular point that affects commits retroactively is the OpenPGP > signing. However, it has been an obligatory requirement enforced by the > infrastructure since the git switch. Therefore, all the git history > conforms to that. -- 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