Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer

[Pacho Ramos]

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] Re: [RFC pre-GLEP] Gentoo Git Workflow

[Daniel Campbell]

On 07/26/2017 10:05 AM, 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)
> 
+1. I tend to add bug numbers in my summary, but it makes it very
challenging to put something meaningful into the remaining characters.
We already put 'category/pkg:' or 'dir/file:' for a prefix. Adding 6 or
7 characters to that already considerable deficit cuts ~15% of git's
recommended 50 characters, or 10% of our proposed 70.

Pushing this out to a tag -- and standardizing it -- will only improve
maintenance and speed up our onboarding process.


"Bug: xx" isn't my favorite since it requires tooling to actually
visit said bug (and doesn't clarify which bug platform to reference),
but a URL uses more bytes and infra may change. It's a tough choice, but
if we can find something that fits enough use cases, tooling shouldn't
be too difficult to write to make up for it. I already use a `bgo`
keyworded shortcut in Pale Moon to make bug searching faster; adding
another to navigate straight to a bug wouldn't be much trouble.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Kristian Fiskerstrand]

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

[Michał Górny]

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

[Kristian Fiskerstrand]

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

[Michał Górny]

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

[Michał Górny]

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

[Kristian Fiskerstrand]

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Michał Górny]

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

[Kristian Fiskerstrand]

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

[gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow

[Duncan]

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?

[Rich Freeman]

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?

[Denis Dupeyron]

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

[Duncan]

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

[gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow

[Duncan]

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

[Duncan]

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

[Duncan]

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?

[Denis Dupeyron]

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...