Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Matthew Thode]

On 10/19/2016 01:00 AM, Robin H. Johnson wrote:
> One of the downsides both the git-am and cherry-pick workflows are that
> they invalidate or otherwise omit commit signatures.
> 
> git-merge on the other hand does preserve the signature as the original
> commit is intact, and the merge commit is where the signature of the
> gentoo developer is introduced.
> 
> I agree clean history is valuable, but verifiable attribution may in
> fact be more important.
> 
Yes, I don't like this aspect of any workflow that breaks history but I
personally feel that for the sake of both 'cleanliness' and ease of use
that the git am (or cherry-pick) workflow is best.  I could possibly see
the possibility of tampering with the patch could be a problem
(attribution as you say) but in the end a developer still committed it.
Authored-by and Committed-by being different fields I feel the main one
infra needs to worry about is Committed-by.

-- 
Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Local workarounds with no reported bugs

[Daniel Campbell]

On 10/17/2016 06:09 AM, Raymond Jennings wrote:
> My biggest ​opinion regarding workarounds and bugs, is that we're
> sweeping things under the rug that should at least be documented, and
> perhaps fixed...or even punted upstream if its serious enough.
> 
> Changing the status quo may require some adjustment though, but I
> suppose we could start by openly documenting a bug if we find a
> workaround that does not already have a bug number associated with it. 
> I've seen several ebuilds where workarounds are applied, but the
> workaround also has a bug number in the comment.
I'd say this falls under the scope of QA, and QA should have some sort
of "quick reference" guide to help developers out and cover situations
they've come across. At the moment, the only resource I'm aware of
(aside from the obvious devmanual and PMS) that we have is either
e-mailing qa@g.o or using repoman. repoman can't (and shouldn't) cover
_everything_, but it's hard to take rants like this seriously when
little is done to communicate to devs at large to "color in the lines".

I ran into something similar when writing the wrapper script for
media-sound/apulse. It took 3 attempts and being told "you're doing it
wrong" 2-3 times before I figured out exactly how to do it. Had it been
documented on a wiki page or something similar, it would have saved me
and others a considerable amount of time.

We need solid QA docs. The devmanual and repoman are great starts, and
answer a bunch of questions. When/if QA comes across new situations and
comes up with 'blessed' solutions, we need a way to check them out
instead of waiting for it to hit Git and be smacked with a "this is
wrong" e-mail.

Just my 2¢.

~zlg
-- 
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] Dealing with GitHub Pull Requests the easy way

[Robin H. Johnson]

One of the downsides both the git-am and cherry-pick workflows are that
they invalidate or otherwise omit commit signatures.

git-merge on the other hand does preserve the signature as the original
commit is intact, and the merge commit is where the signature of the
gentoo developer is introduced.

I agree clean history is valuable, but verifiable attribution may in
fact be more important.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: Digital signature

[gentoo-dev] Mentor request

[Kevin Simmons]

Hello gentoo-dev,

In general, I could use a mentor I can ask questions of and get answers
from. I have been a tinkerer/user only of Gentoo in the past and am now
wanting to be more involved.

I have been using the Developer Guide for assistance.

But specifically for now...
I requested to fill the maintainer role needed for the app-misc/gramps
package as I use the software for my own needs and am fairly familiar
with it. I am now the maintainer of that package. I find I can use some
guidance in getting started. For instance, there is a bug to have
gramps-4.2.4 stable (it is ~amd64 ~x86 now).

I have been running gramps-4.2.4 OK on amd64, testing various components
and reports OK

To stabilize this package for amd64 and x86 it would also need to be
verified on x86. I suppose I could do that myself by creating an x86
virtual guest and testing or I should ask for assistance via a bug to
x86@.

Also, when I run 'repoman full' from the proposed ebuild directory I get
QA issues for  RDEPEND for dev-python/pyicu, which is also ~amd64. This
dependent package (and its dependencies) would need to be stable as
well.

When it comes time to commit (repoman commit), do I need any user access
set up before I commit?

Regards,
Kevin

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Kent Fredric]

On Tue, 18 Oct 2016 21:45:05 -0500
Matthew Thode  wrote:

>  Does pram allow you to pass options to git
> am (signedoffby for instance)?

It doesn't presently allow arbitrary arguments, and it would probably be wise
to avoid need for such arguments and prefer convention over configuration, 
given what this is.

--signoff is already a default:

https://metacpan.org/source/MONSIEURP/Gentoo-App-Pram-0.003000/lib/Gentoo/App/Pram.pm#L71



pgpseI3abq5cg.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Matthew Thode]

I've been using the curl into git am method for a while now, it's nice
to see it's not just me :D  Does pram allow you to pass options to git
am (signedoffby for instance)?

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Michael Orlitzky]

On 10/18/2016 08:03 PM, Benda Xu wrote:
> 
> This will be an important reference. Please consider adding it into the
> wiki after we reach a wider consensus on how to merge pull request on
> github.


It's been there for a long time:

https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Pull_requests_from_developers_and_users

(that's the way I prefer to merge pull requests, too).

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Benda Xu]

Hi Patrice,

Patrice Clement  writes:

> [...]

Very enjoyable write-up.  I completely agree with you.

This will be an important reference. Please consider adding it into the
wiki after we reach a wider consensus on how to merge pull request on
github.

Benda


signature.asc
Description: PGP signature

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Peter Stuge]

Patrice Clement wrote:
> We should strive for keeping a clean and linear history.

I agree with you.


> Cherry-picking is not my go-to solution as far as I'm concerned.
> It requires a bit of setup and is clearly tedious: you must know
> in advance the full SHA-1 of commit(s) you want to cherry-pick.

git cherry-pick master..pr1234 # picks all commits on pr1234 not on master

This is essentially a "manual" rebase of pr1234 onto master.

Demo time. Preparations:

$ git config --global alias.la 'log --oneline --graph --decorate --all'
$ export PAGER=cat


Assume the following repo:
$ git la
* ccbc288 (HEAD, master) d
* d33a95b b
| * 3e5b52e (pr1234) c
| * 6491f93 b2
|/  
* 2dfcb95 a
$ 

git cherry-pick master..pr1234 would apply b2 and c onto master:

$ git cherry-pick master..pr1234
[master 305532b] b2
 1 file changed, 1 insertion(+)
 create mode 100644 b2
[master d18f1ac] c
 1 file changed, 1 insertion(+)
 create mode 100644 c
$ git la
* d18f1ac (HEAD, master) c
* 305532b b2
* ccbc288 d
* d33a95b b
| * 3e5b52e (pr1234) c
| * 6491f93 b2
|/  
* 2dfcb95 a
$ 

If the pr1234 branch has some value once b2 and c are in master then
this is a good way to do it, the main drawback IMO that it leaves a
repetitive and redundant pr1234 branch behind.


Another way would be to simply rebase the pr1234 branch. Disclaimer: I
don't know GitHub processes and assumptions, so rebase might suck for this.

If noone cares about the PR branches once they have been merged/closed
(I got that impression from your mail) then rebase may be a good choice.

$ git la
* ccbc288 (HEAD, master) d
* d33a95b b
| * 3e5b52e (pr1234) c
| * 6491f93 b2
|/  
* 2dfcb95 a
$ git rebase master pr1234
First, rewinding head to replay your work on top of it...
Applying: b2
Applying: c
$ git la
* 92417d4 (HEAD, pr1234) c
* 385ca8c b2
* ccbc288 (master) d
* d33a95b b
* 2dfcb95 a
$ 

At this point, pr1234 can be fast-forward merged into master:

$ git checkout master
Switched to branch 'master'
$ git merge --ff-only pr1234
Updating ccbc288..0565e44
Fast-forward
 b2 | 1 +
 c  | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 b2
 create mode 100644 c
$ git la
* 0565e44 (HEAD, pr1234, master) c
* 0dbfdf8 b2
* ccbc288 d
* d33a95b b
* 2dfcb95 a
$ 


> You may or may not know about it but a PR can be fetched as a git
> am-compatible patch.
..
> https://github.com/gentoo/gentoo/pull/1234.patch

Didn't know - that's pretty handy!


> $ cd /home/patrice/gentoo
> $ pram 1234

Nice work! I might have made a git pr alias instead, but pram seems
way more flexible than that would be.


Finally, while I do agree with you, the one and only reason IMO to
live with merge commits is that they implicitly preserve the branching
point. For source code that can be useful, but for ebuilds less so.


//Peter

Re: [gentoo-dev] Re: Local workarounds with no reported bugs

[Michał Górny]

On Tue, 18 Oct 2016 21:09:44 +0200
Patrick Lauer  wrote:

> On 10/17/16 09:23, Michał Górny wrote:
> > Hello, everyone.
> > 
> > I'd like to point out a major problem in Gentoo: there's a fair number
> > of developers who add various local workarounds to problems they meet
> > and don't bother to report a bug. Worst than that, this applies not
> > only for upstream problems but also to Gentoo eclass/ebuild-related
> > issues.
> > 
> > 
> > Example: udev people had problems with MULTILIB_WRAPPED_HEADERS
> > in the past. Instead of contacting me  
> ... bus factor of 1, that's not a good strategy in general.

s/me/anyone on multilib team/. Does that make you happy? But yes, I
should add a big fat warning to the docs.

-- 
Best regards,
Michał Górny



pgpK_5CvxdOc0.pgp
Description: OpenPGP digital signature

[gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Patrice Clement]

Hello fellow Gentoo developers and subscribers of the gentoo-dev mailing list,

I've been wanting to write this email for a while but for some reason never got
round to doing it due to lack of motivation and time. 

I will be discussing many topics in this email revolving around git
essentially. I first want to go over some basic concepts about git and GitHub
and why we should be doing things differently if we want to avoid cluttering up
our repository with useless stuff.

* Background

As you know, a little while ago we've migrated the main tree to git, the
revision control tool which needs no introduction. A few months after the
migration, our repository was mirrored over to GitHub to give the project a bit
more exposure to what some developers refers to as "the GitHub generation". The
response from the community was extordinary and as a result, a massive number
of Pull Requests came our way. We soon then started to lend ourselves to the
duty of PR triaging and merging, and started to make what's called in the git
world "merge commits". Understanding merge commits requires understanding how
GitHub considers a contribution. 

When a contributor sends a PR via GitHub, he will essentially be making a
different branch, start working on it and eventually file it. For those of you
familiar with git or who've already filed PRs on GitHub, this is old news.
However, there's a number of different way to deal with PRs on the receiving
end (us) in order to keep a sane log history (graph actually).

When we first started working with git, and GitHub, the tendency was to rely on
merge commits to merge contributions back into the main repo. In my opinion,
this was, and still is, a bad idea. What's so special about merge commits? 

* A short walk through merge commits

As you may know, merging one branch into another often results in creating a
new commit. This commit is called a "merge commit" in git jargon. Let's pick
for instance cf4cce36684de5e449ec60bde3421fa0e27bac74. I'm not trying to put
the blame on a particular developer, we've all used merge commits at one point
or another and I was one of the first! In the log graph, this commit is
displayed as such:

$ git log --graph --oneline master
[snip]
* | |   cf4cce3 Merge remote-tracking branch 'github/pr/1845'
|\ \ \
| * | | abf61de net-im/ejabberd: require https://github.com/gentoo/gentoo/pull/1234.patch

Once fetched, using your favourite web crawler, the patch can be directly
applied via the git am command onto HEAD of the repository you're dealing with.
There's this common idiom for fetching AND applying at patch all at once:

$ curl https://github.com/gentoo/gentoo/pull/1234.patch | git am

* This is where I'm meant to sell you my solution

Ultimately, I've decided to write a tool to leverage this way of fetching PRs
and merging them. The tool is called Gentoo-App-Pram and is available in the
tree:

# emerge Gentoo-App-Pram

It is written in Perl, works fairly well and has been used by a fair (growing?)
number of developers so far. The tool is CLI-based so you will need to feel at
home with the command line.

Once emerged, cd into your Gentoo git repo and type `pram' followed by the PR
number you wish to merge:

$ cd /home/patrice/gentoo
$ pram 1234

pram will then fetch the PR as a patch and display it to you in your
favourite $EDITOR. At this point, you can make any change to the PR i.e.
editing commit message(s), changing code in-line, etc. 

pram also leverages the "Closes:" header. This header is recognised by GitHub,
and Larry the Cow, and will automatically close a PR when parsing it in the
body of a commit message. So for instance, the following header will
automatically close PR 1234: "Closes: 
https://github.com/gentoo/gentoo/pull/1234";.
You don't need to manually add it as pram will do this for you.

After saving and getting out of $EDITOR, pram will ask you whether the PR needs
merging by asking a yes/no question. "y" will launch git am and merge the
patch whereas "n" will abort the operation and clean it up.

That's pretty much it. Make sure to read the man page since there are other
options available (pram --man).

pram wouldn't have been possible without Kent Fredric's help. He's assisted me
in releasing the package on CPAN and contributed a few patches. Kudos to him!

To wrap up:
- Please stop making merge commits. This strategy is not useful in the case of
  Gentoo and does more harm than good.
- Cherry-pick or git-am external contributions such as PRs.
- Better yet, use Gentoo-App-Pram. :-)

If you want to contribute to Gentoo-App-Pram, send me a PR on GitHub at
https://github.com/monsieurp/Gentoo-App-Pram or file a bug report at
https://bugs.gentoo.org and assign it to me.

Comments and suggestions welcome.

Cheers,

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] x11-misc/bumblebee and x11-misc/virtualgl up for grabs

[NP-Hardass]

On 10/18/2016 03:32 PM, Pacho Ramos wrote:
> I don't have much interest on this packages anymore and, also, my local
> setup has not the ability to check their functionality, hence, feel
> free to grab them
> 
> Thanks
> 

I'll take this if no one else wants it.  Happy to take a co-maintainer
if someone else wants that.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Package up for grabs: games-strategy/freeorion

[NP-Hardass]

On 10/16/2016 03:15 PM, Thomas Kahle wrote:
> Hi,
> 
> games-strategy/freeorion is a space empire and galactic conquest
> game inspired by Master of Orion (though not a clone):
> http://www.freeorion.org
> 
> I cannot maintain it anymore, the main reason being that I don't
> have a gentoo machine with a screen attached to it at the moment.
> 
> FreeOrion has a dedicated community (also in Gentoo) that does
> research on bugs and is generally helpful.  Upstream is also
> helpful and produces patches quickly.  They use github.
> 
> Open tasks are:
> 
> - remove games.eclass and EAPI=6 bump: I've done some work in
>   this direction, but I'm not finished.
> 
> - bump to 0.4.6: https://bugs.gentoo.org/show_bug.cgi?id=596680
> 
> The bump is the only open bug.  Please just take it or e-mail me
> (or both) if you are interested.
> 
> Cheers,
> Thomas
> 
> 

I'll take this if no one else wants it.  Happy to take a co-maintainer
if someone else wants that.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] x11-misc/bumblebee and x11-misc/virtualgl up for grabs

[Pacho Ramos]

I don't have much interest on this packages anymore and, also, my local
setup has not the ability to check their functionality, hence, feel
free to grab them

Thanks

[gentoo-dev] Re: Local workarounds with no reported bugs

[Patrick Lauer]

On 10/17/16 09:23, Michał Górny wrote:
> Hello, everyone.
> 
> I'd like to point out a major problem in Gentoo: there's a fair number
> of developers who add various local workarounds to problems they meet
> and don't bother to report a bug. Worst than that, this applies not
> only for upstream problems but also to Gentoo eclass/ebuild-related
> issues.
> 
> 
> Example: udev people had problems with MULTILIB_WRAPPED_HEADERS
> in the past. Instead of contacting me
... bus factor of 1, that's not a good strategy in general.

> (which would result in helpful
> explanation how to do things properly), they abused bash to disable
> the check function implicitly in the ebuilds.


> Nobody bothered to inform me of the issue there.
Well, you didn't ask ;)

 Instead, I had to
> notice it looking at the udev ebuilds accidentally. Furthermore, in
> most of the ebuilds the workaround was no longer necessary but nobody
> bothered to check that.
> 
> 
> Example 2: Coacher had problem with git-r3 not trying fallback URIs
> when earlier URI was https and https wasn't supported in git. So he
> reordered URIs to have https last. With tiny explanation in some random
> commit message.
> 
> So we have a problem that affects around a half of git-r3 packages
> (using quick grep, results inaccurate), however minor it is. Worse, it
> affects the policy of preferring https and causes some people to reject
> the policy silently. And nobody gives a damn to report it!
> 
> 
> Therefore, I'd like to request establishing an official policy against
> workarounds with no associated bug reports.
That's too fuzzy to make a policy. Feels good, everyone agrees with the
idea, but where's the limit? When is it a required fix, when it is just
a workaround? What needs to be upstreamed, and what can't be upstreamed?

> 
> Your thoughts?
> 
I like the general idea of ... like ... improving ... things, but you
should be more precise and try to avoid creating situations with a bus
factor of one.

Re: [gentoo-dev] grub-2 configuration

[Joakim Tjernlund]

On Tue, 2016-10-18 at 12:45 -0400, Tom H wrote:
> On Tue, Oct 11, 2016 at 10:54 AM, M. J. Everitt  wrote:
> > 
> > On 11/10/16 15:42, Tom H wrote:
> > > 
> > > 
> > > You can use exactly the same text in 40_grub that you'd use in
> > > grub.cfg and have the latter generated.
> > 
> > That's a useful tit-bit .. thanks!
> 
> You're welcome.
> 
> I doubt that the grub developers intended 40_custom to be the only
> "/etc/grub.d/" file to be executed but it's practical for generating a
> simple grub.cfg. This is what I use in a Debian VM:
> 

We still use grub-1 and I really like the automatic generation of new grub
menu entries using genkernel --bootloader=grub, does this work with grub2 as 
well?

 Jocke

Re: [gentoo-dev] grub-2 configuration

[Tom H]

On Tue, Oct 11, 2016 at 10:54 AM, M. J. Everitt  wrote:
> On 11/10/16 15:42, Tom H wrote:
>>
>> You can use exactly the same text in 40_grub that you'd use in
>> grub.cfg and have the latter generated.
>
> That's a useful tit-bit .. thanks!

You're welcome.

I doubt that the grub developers intended 40_custom to be the only
"/etc/grub.d/" file to be executed but it's practical for generating a
simple grub.cfg. This is what I use in a Debian VM:

#!/bin/sh

cat <

Re: [gentoo-dev] Package file name requirement for binary ebuilds

[Ciaran McCreesh]

On Mon, 17 Oct 2016 16:43:40 -0400
"William L. Thomson Jr."  wrote:
> No its a PMS requirement as you said not visual as I was saying...

PMS doesn't cover multiple repository stuff in much detail. We didn't
want to mandate Portage's historical weird overlay behaviour, so it
doesn't really specify anything at all.

-- 
Ciaran McCreesh

Re: [gentoo-dev] [PATCH] metadata: add vcs tag

[Gilles Dartiguelongue]

Le mercredi 12 octobre 2016 à 09:44 -0700, Robin H. Johnson a écrit :
> 
> [...]
> @@ -52,6 +52,8 @@
>  
>  
>     module|cpe|cran|ctan|freecode|freshmeat|gentoo|github|gitlab|gitoriou
> s|google-
> code|launchpad|pear|pecl|pypi|rubyforge|rubygems|sourceforge|sourcefo
> rge-jp|vim) #REQUIRED>
> +
> +

I am probably nitpicking here but if you expect this element to contain
a valid URL, then maybe using #CDATA makes more sense ?

-- 
Gilles Dartiguelongue 
Gentoo

signature.asc
Description: This is a digitally signed message part