[gentoo-dev] RFI: A better workflow for github pull requests

2015-09-12 Thread Michał Górny
Hello, everyone.

The current workflow for handling github pull requests is at least
suboptimal. Handling pull requests takes a fair effort from the few
developers contributing there, and the progress is often stalled by
package maintainers which are either unresponsive or not registered on
github at all. That's why I'd like to get your ideas on how we could
improve the workflow.



Current workflow


Let's summarize the current workflow first. Right now, there's a few
Gentoo developers who actively monitor pull requests on gentoo/gentoo
repository. Those developers review incoming pull requests and help
submitters get their contributions in shape. Some of those developers
also try to 'CC' (@-mention) package maintainers to get their attention
on the pull request.

Sadly, @-mentioning sucks for a few reasons:

1. Many of the Gentoo developers have different nicknames on GitHub.
Some developers don't even set their real names which makes them even
harder to find.

2. Teams can be created only by repository 'owners' (which pretty much
is equivalent of Infra). Which practically means I'm the only person
migrating teams (projects, herds) to GitHub.

3. GitHub notifications are not very reliable. Some developers get only
some of them via mail, some don't. And some simply don't care.

4. Some developers openly refuse to work with contributors via GitHub.
Proxying them manually is not really productive.



Potential solution: bi-dir github <=> bugzilla integration
==

My current idea would be pretty much that:

1. a new dedicated Gentoo bug would be automatically created for every
pull request on github,

2. all comments from github would be automatically copied to bugzie.
All bugzie comments would be automatically copied to github,

3. resolving the bug would automatically close the relevant pull
request.

This way, all pull requests can be assigned to package maintainers in
Bugzilla without having to resort to GitHub user or team names. All
involved parties would get more reliable Bugzilla notification mails.
They could choose to either use the provided URLs to discuss the pull
request on GitHub, or discuss it directly on Bugzilla, whichever is
more convenient to them.

The additional Bugzilla load should be manageable, though we may want
to employ some kind of rate limiting in case someone though it'd funny
to spam our bugzilla via spamming github.

Problems:

- handling line comments (probably a Bugzie comment with quoted code
  snippet),

- handling comment edits and removals,

- some people will get double mail for each comment,

- extra bugs for existing issues (we shouldn't really try to reuse
  existing bugs for this).



What are your thoughts? Any other proposals?


-- 
Best regards,
Michał Górny



pgpQinyBTVInU.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] RFI: A better workflow for github pull requests

2015-09-12 Thread Andreas K. Huettel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Samstag, 12. September 2015, 21:12:25 schrieb Michał Górny:

> Potential solution: bi-dir github <=> bugzilla integration
> ==

The general idea is nice and neat.

> - handling comment edits and removals,

Just discourage it. Strongly discourage it. We should treat PRs like bugs 
anyway, with a permanent history.

> - extra bugs for existing issues (we shouldn't really try to reuse
>   existing bugs for this).

Why not provide a way to hook a PR into an existing bug? After all this sounds 
like normal procedure (bug exists, fix is prepared, ...)

- - How should assignment / wrangling be handled in case a bug is newly 
generated from Github?

- - Who's going to do the integration work? :P

- - What do our BZ admins say about it?

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJV9KF+XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5EKgP/0VwMcmIP9usi+T3Q2/790np
zpB9JTCJN3N47+wQPpooK5yAA9eXA2+tzykzv13cAQr216/c2k6cNAqy+I/P2/Ap
QY8xiA0XGSXZmm/zHlYyn9BVzwtbbg9f3dJvWNYbwuZ1YfvqBmjSbu9cP7aU7EnZ
sfkQdxO9cfieU5omnDIstky4TVA8qhys3Z43iTA+qnnR5IWnBgF21uSPjr7CQJUI
KHCfdkR6rSrlZBvjjdW06WnwW6skR6F5iXlEWRHH1uViXVt+Oz8h0rhtk9GJR2k8
ePyQDQWADTON4HBPhRzKuaj7bHBDoVKXqJ/sHPQnIHhz1bxf12RJqzp7HJM20F8I
PPQaYMmgBqE94P2GEY7nXVjV6RdL1NKw2BmR9qqaip6WjpRQITuD7HnQScTjRW9+
yphGxlgD0f7bysAz86NnW9eYpekR0WF3uwamBOTx7jaPH4ZWdJcE/w8qPmfJEXnS
5RDAlWUC4Imwc9LuMcbAtUapg0XZodFtCdDJEyTynsJKNOAoIMGIwbVROzYZJ1o/
0w+S7zAhzFmhHCoX3fLwf24vTWhcOKh432P2r8cd/mDrqdEK9S5T1uJWMRZQ46fY
d6eBzJinMtELokeaHDop4knsaCtJEVvETfshCySlvJjK3lbVJB5KgRaZI/5tS1V/
wWreJGHxZCqoiHLb5Zwi
=RvsI
-END PGP SIGNATURE-



Re: [gentoo-dev] RFI: A better workflow for github pull requests

2015-09-12 Thread Hanno Böck
On Sat, 12 Sep 2015 21:12:25 +0200
Michał Górny  wrote:

> 1. Many of the Gentoo developers have different nicknames on GitHub.
> Some developers don't even set their real names which makes them even
> harder to find.

This isn't directly related to your proposal, but may I jump in here:
Wouldn't it be in general valuable to track the connection gentoo dev
handle <-> github handle in a machine readable and generic way?

Should / could we add that as an ldap attribute or something?

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpoomRUUh5oh.pgp
Description: OpenPGP digital signature


[gentoo-dev] What is the status of phone/tablet support?

2015-09-12 Thread Richard Yao
I asked in #gentoo-embedded on freenode, but I would like to pose this question
to a wider auidence through the list.

What is the status of phone/tablet support? In specific, I am curious about:

* Modern hardware options (especially those without a hardware keyboard)
* Status of F/OSS drivers
* Xorg touch support (multitouch, virtual keyboards, etcetera)
* Desktop environments designed for multitouch in portage
* Graphical applications (e.g. dialer, calendar, web browser, email client)
* Reliable filesystem options for flash storage in small memory environments.

I know that the KDE project has Plasma Mobile, which gives us both a desktop
environment and many key graphical applications. However, I am not sure if much
has been done to support it in Gentoo's packaging and I would like to hear about
this:

http://www.youtube.com/watch?v=auuQA0Q8qpM

I realize that it is difficult to convey the sort of information that one wants
on an open ended topic such as this, so I will try to lead by example by talking
about filesystem options. First off, Linaro has some good summary:

https://wiki.linaro.org/Flash%20memory

Their summary consists entirely of log-based filesystems and CoW filesystems. It
omits in-place filesystems such as ext4 and XFS. In-place filesystems really
should not be appropriate for a phone or tablet because they are not designed to
gracefully recover from unclean unmounts caused by kernel panics or power loss
(e.g. dead battery, battery removal), although Android uses ext4 anyway.

A notable exception from Linaro's list that I happen to maintain in the tree is
the ZFSOnLinux driver. ZFS has many attributes that are desireable for phones,
such as easy backup through incremental send/recv (easy on bandwidth and battery
life), the ability to detect corrupt data (flash is not perfect), LZ4
compression (better throughput/latencies and less flash is need to store the
amount data) and ARC for a better cache hit rate when your working set exceeds
the amount of memory you have for cache (always true on phones).

ZFSOnLinux is currently behind other CoW filesystems in support for
phones/tablets. Upstream is gradually improving this and it should become a
competitive option in the future. The main areas that pose problems are:

1. Efficient use of minimal memory.

1a. Long held objects in SLABs cripple reclaim efficiency by preventing mostly
empty slabs from being reclaimed. On Solaris, some of the caches implement a
move callback that allows for compaction, but Linux's SLAB implementation does
not provide the option, ZoL's SLAB implementation does not implement it and it
is not clear if it is possible to defragment the things on Linux that use it
without modifications to the Linux kernel. Thankfully, nearly all of the memory
used by SLABs is in the ZIO buffers, which will be replaced with page-based
scatter-gather lists in the next release. That will go a long way to mitigating
this.

1b. mmap() double caches between the ARC and the page cache. This has been done
in OSv's ZFS driver and can be done in the ZFSOnLinux driver. It is currently
blocked on 1a as it does not make sense to implement sooner, but it will be
definitely be done.

2. 32-bit support (not an issue on 64-bit ARMv8 hardware, but ARMv8 is rare)

2a. Linux's kernel virtual memory allocator is crippled because the kernel
enters an infinite loop when it runs out of address space set aside for kernel
virtual memory. This is not a problem on 64-bit system swhere the amount set
aside exceeds the amount any single image system in existence currently has, but
it is a major problem on 32-bit. There is the further problem of a global
spinlock being used and certain accoutning functions iterating a linked list of
all virtual memory allocaitons, but this secondary has been mitigated mostly
through SLAB allocation. The main use of kernel virtual memory is to
avoid external fragmentation issues that come from allocting large buffers,
especially the SLABs that are used to minimize the number of kernel virtual
memory allocations that are done. The next release will implement scatter-gather
lists that should bypass this on the ZIO bufers while the other consumers either
have already been moved to kernel virtual memory or should be moved.

2b. There is no upstream test coverage on 32-bit and there are open issues
involving 32-bit runtime failures. The project has gradually fixed 32-bit
issues, but more work needs to be done here to make 32-bit as reliable as
64-bit. This will likely come after the solution to 2a makes 32-bit feasible
enough to subject it to regular testing.

3. Tweaks for flash storage.

3a. We will gain discard support from the Illumos community in the next release,
but the behavior of the hardware when discard is translated into the native
command needs to be studied. On SATA, discard is mapped to ATA TRIM. The design
of ATA TRIM is broken before SATA 3.1 where TRIM is an unqueued command that
introduces arbitrary lags. Consequently, 

Re: [gentoo-dev] symlinks in the tree

2015-09-12 Thread Andreas K. Huettel
Am Samstag, 12. September 2015, 15:12:08 schrieb Justin Lecher (jlec):
> Hi,
> 
> I would like to discuss the pro and cons of usage of symlinks in the
> tree, which are possible now as we aren't bound to CVS anymore
> 

Please please just ban them completely. 

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/




Re: [gentoo-dev] symlinks in the tree

2015-09-12 Thread Michał Górny
Dnia 2015-09-12, o godz. 15:30:45
"Justin Lecher (jlec)"  napisał(a):

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 12/09/15 15:19, hasufell wrote:
> > +1 for banning symlinks
> > 
> 
> mrueg just mentioned a very crucial point. There are filesystem which
> don't support symlinks and would break everything.

Just to be clear, I don't see that as being a problem.

I would expect Gentoo development to occur on systems which support
symlinks properly. For user systems, I would expect rsync mirrors to
replace symlinks with duplicated files.

That said, I have the same stance for symlinks as I have for
'if [[ ${PV} ==  ]]' blocks in ebuilds -- I don't like them but I
can live with them.

-- 
Best regards,
Michał Górny



pgpUc3xUtZP5v.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] RFI: A better workflow for github pull requests

2015-09-12 Thread W. Trevor King
On Sat, Sep 12, 2015 at 10:11:27PM +0200, hasufell wrote:
> We should probably auto-attach the patch from the pull request. This
> can easily be done with link-rewriting, e.g.:
> https://github.com/gentoo/gentoo/pull/83 to
> https://github.com/gentoo/gentoo/pull/83.patch
> yields a nice downloadable patch.

Why not [1]:

  $ GITHUB_REMOTE=origin  # adjust this to match whatever you call GitHub's 
gentoo/gentoo
  $ git config --add remote.$GITHUB_REMOTE.fetch 
+refs/pull/*/head:refs/remotes/$GITHUB_REMOTE/pr/*

That will let you fetch the remote branch (e.g. origin/pr/83 assuming
‘origin’ is your GitHub remote).  That seems easier than copy/pasting
around commits and messing with ‘git am’ and other things that will
change the committer, which will in turn invalidate any commit
signatures (the patch seems to drop those anyway).

Cheers,
Trevor

[1]: https://gist.github.com/piscisaureus/3342247

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFI: A better workflow for github pull requests

2015-09-12 Thread hasufell
On 09/12/2015 09:12 PM, Michał Górny wrote:
> 
> Potential solution: bi-dir github <=> bugzilla integration
> ==
> 
> My current idea would be pretty much that:
> 
> 1. a new dedicated Gentoo bug would be automatically created for every
> pull request on github,
> 
> 2. all comments from github would be automatically copied to bugzie.
> All bugzie comments would be automatically copied to github,
> 
> 3. resolving the bug would automatically close the relevant pull
> request.
> 
> This way, all pull requests can be assigned to package maintainers in
> Bugzilla without having to resort to GitHub user or team names. All
> involved parties would get more reliable Bugzilla notification mails.
> They could choose to either use the provided URLs to discuss the pull
> request on GitHub, or discuss it directly on Bugzilla, whichever is
> more convenient to them.
> 
> The additional Bugzilla load should be manageable, though we may want
> to employ some kind of rate limiting in case someone though it'd funny
> to spam our bugzilla via spamming github.
> 
> Problems:
> 
> - handling line comments (probably a Bugzie comment with quoted code
>   snippet),
> 
> - handling comment edits and removals,
> 
> - some people will get double mail for each comment,
> 
> - extra bugs for existing issues (we shouldn't really try to reuse
>   existing bugs for this).
> 
> 
> 
> What are your thoughts? Any other proposals?
> 
> 

We should probably auto-attach the patch from the pull request. This can
easily be done with link-rewriting, e.g.:
https://github.com/gentoo/gentoo/pull/83 to
https://github.com/gentoo/gentoo/pull/83.patch
yields a nice downloadable patch.

Or was that already part of your plan?



Re: [gentoo-dev] RFI: A better workflow for github pull requests

2015-09-12 Thread Andreas K. Huettel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Samstag, 12. September 2015, 23:31:11 schrieb W. Trevor King:

> Right, thanks.  In that case, I think you'll need a hook to push a new
> patch whenever the GitHub branch is updated, rebased, etc.  That could
> make for a lot of Bugzilla spam, because folks tend to cycle less
> formally in GitHub branches than they do with list-based (and similar)
> workflows.

Possible, but so far the number of github pull request events hasn't exploded 
yet. (The new Git repo has already 5200 commits, but the pull request counter 
is only at 86 so far.) 

Of the currently open 18 PR's most have 1-2 comments, only two more than 10 
comments.

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJV9KBkXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5op4P/0aFwahQE//PqWK54JXToLld
ro3k9sW7WJ0WO06S7PGceelIgKCeMwtqn8ajLvRfw8Ahbwqk6b4LSRFr1dtOoKaF
sNsnl4mecdazvQcXA03YHELL2R+Iso8tewWm3JexrhjCZ54mg3vJw+QearU91z3Y
1EfVD/jEBnpnTKropdV2G4c5Z5D9zEzwv/NaAeNF6S3FGXd57xsf4WyX2zRJWYib
a2GHAXsmHSj3W8S1FJ8VvtzpqEIH66XMnKRGc17YbqUxAhVoLc134zPigp6s70pQ
srEO3kvG/LrRTOULzZwZ2cC3Df0g750CFPn+8x05d7ec6qo/XgTtT4u3LiVJYmkl
sRg88J2dENEPxjrx8COfL1CaE3sZI/3KywNhabRMw3G8qQYq8WrA5OIypM/FLS7o
Ie30aUx9FYz8GLR0P+31uFrS1S07kA2LKiL7uCXsdcsVcwFtiO2Q+kEci6Yxq89h
UFo9IPjpemFS2Omd32YAN09eRDwjdWZF0J/S8kUJfNjLeM+pT2myU90jPJ9hRuXD
YRoI3TLF7CIqOnuBZoYrFQUA8trnno36JdSTLzR/7N/ZzEDLuoN/nhR95wVqH4p7
rW8sQT+PgG/aMESfL8ZROpzTj2EGrtzfiNay+HYBv4Lf5dFTwaGg8mXjGgrbzDsX
nOg+rrjo9H2xUG4xp5A1
=JSlT
-END PGP SIGNATURE-



Re: [gentoo-dev] RFI: A better workflow for github pull requests

2015-09-12 Thread hasufell
On 09/12/2015 11:07 PM, W. Trevor King wrote:
> On Sat, Sep 12, 2015 at 10:11:27PM +0200, hasufell wrote:
>> We should probably auto-attach the patch from the pull request. This
>> can easily be done with link-rewriting, e.g.:
>> https://github.com/gentoo/gentoo/pull/83 to
>> https://github.com/gentoo/gentoo/pull/83.patch
>> yields a nice downloadable patch.
> 
> Why not [1]:
> 
>   $ GITHUB_REMOTE=origin  # adjust this to match whatever you call GitHub's 
> gentoo/gentoo
>   $ git config --add remote.$GITHUB_REMOTE.fetch 
> +refs/pull/*/head:refs/remotes/$GITHUB_REMOTE/pr/*
> 
> That will let you fetch the remote branch (e.g. origin/pr/83 assuming
> ‘origin’ is your GitHub remote).  That seems easier than copy/pasting
> around commits and messing with ‘git am’ and other things that will
> change the committer, which will in turn invalidate any commit
> signatures (the patch seems to drop those anyway).
> 

Because that is not a valid bug report. Patches must be attached to
bugzilla.




Re: [gentoo-dev] RFI: A better workflow for github pull requests

2015-09-12 Thread W. Trevor King
On Sat, Sep 12, 2015 at 11:15:14PM +0200, hasufell wrote:
> Because that is not a valid bug report. Patches must be attached to
> bugzilla.

Right, thanks.  In that case, I think you'll need a hook to push a new
patch whenever the GitHub branch is updated, rebased, etc.  That could
make for a lot of Bugzilla spam, because folks tend to cycle less
formally in GitHub branches than they do with list-based (and similar)
workflows.  For example, if I submit a patch series to a mailing list,
I'll wait a week before pushing v2 with a bunch of typo fixes, etc.
But if I submit a patch series via a GitHub PR, I'll push fixes for
those sort of things immediately.  I'm skeptical that you'll be able
to retrain frequent GitHub users to pace their pushes, so hopefully
this has a technical solution.  Maybe iterate over open PRs every week
and push changed patches to Bugzilla?  That avoids too much spam, but
it means that comments via GitHub and Bugzilla may be talking about
different versions of the branch (which seems like it would cause
trouble ;).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFI: A better workflow for github pull requests

2015-09-12 Thread W. Trevor King
On Sun, Sep 13, 2015 at 01:30:44PM +1200, Kent Fredric wrote:
> If the patch is automatedly filed against bugzilla, people will
> assume viewing that patch tells them all they need to know.
> 
> But the reality is somebody may rebase/amend/repush to the
> publicised branch location before any developer reviews the patch in
> bugzilla, and so by the time somebody reviews the patch, it is
> already wrong.

This is what I was trying to get at [1].  And I still think some sort
of rate-limited posting of updated patches is the best way to handle
it.  Git remotes are more complete (signatures and committer info) and
as current as you like while you're actively reviewing [2], and I
expect the point of the attached patch is to provide an archival
reference that folks can refer to after GitHub (or whoever's hosting
the remote) closes down.  In that case, having the attached patch
occasionally lag by a week (or whatever) is not going to be a big
deal.

Cheers,
Trevor

[1]: http://thread.gmane.org/gmane.linux.gentoo.devel/97329/focus=97333
 Message-ID: <20150912213111.gb14...@odin.tremily.us>
[2]: http://thread.gmane.org/gmane.linux.gentoo.devel/97329/focus=97333
 Message-ID: <20150912210734.ga14...@odin.tremily.us>

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] symlinks in the tree

2015-09-12 Thread NP-Hardass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In my wine-a-holics overlay, I used symlinks.  I found that
occassionally, git would act up and replace the symlink with the linked
file when committing.  I never found out how or why, but for this
reason alone, I highly recommend against it.

Regarding the comment about regular and live versions, I'd also
recommend against this for the simple reason that sometimes something
changes upstream before a release comes out, and it adds an additional
complication of worrying about edits to the live version changing a
versioned ebuild.

- --NP-Hardass

On Sat, 12 Sep 2015 15:12:08 +0200
"Justin Lecher (jlec)"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi,
> 
> I would like to discuss the pro and cons of usage of symlinks in the
> tree, which are possible now as we aren't bound to CVS anymore
> 
> We have quite a number of ebuilds already in the tree defining
> functionality for both, regular version and live versions. These are
> typical candidates. Same for different package versions with the same
> ebuild.
> 
> What is your opinion on making heavy use of symlinks here?
> 
> Personally I would ban symlinks and duplicated code. One ebuild for
> one version. And in case you like to propagate changes over several
> ebuilds, just use tools like meld.
> 
> A drawback is that tools like sed break symlinks and write back a
> plain files.
> 
> And last, we have potential breakages if people don't give enough care
> when doing stabilizations and removal of version.
> 
> nevertheless, we would slim the tree and reduce work when changing
> things like HOMEPAGE.
> 
> So please discuss this matter.
> 
> Justin
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0
> 
> iQJ8BAEBCgBmBQJV9CSoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
> OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiIZ0P/0q6jSuGZzZ4lDiu87GIYMiC
> ndRzHsR/OGT9paB01pkoQogOt9+AMKdNd434n2to+HbuNf7Le5cWP7MBAdD/ydzV
> H+5zE98Mu9h8IXTRvuxv6eTSRPFsnnDPuMAS+28D7WwDBcmOhl4we/hRyfq0+JFw
> s5XojNlrk7YZLynZs8SHcgqq5CbaKbjLMsVSTnVXKeA1NcaB0lPFjI0JraCqW4xS
> BgIA2MrrR5XM2imvmBInanwJZ+VOVvHD1jxTlfUQeF7qJusTY5fTnVncvnIo72Fh
> E2Rz/+vrWFe+CvQV63IpgbtC2oYP5OMidnfZSQynRbGsK9w3rm25cXOlyXjLA98O
> sv/wNHvVk3+SIvIviN3yDjOOG5q1zeW33UtZfz5iKu3E7dUGw6B2a/qjC9m9lIQH
> GGDu7csYnW8aSLiEJPGsJsduTqw/+G5p8DWMGuHss6xu6DyZKJPRxgd4VlDkLIiE
> ZCgoHCGhQX3LDEOlzh7+j01A1AOO4SfTZqqDch8f6jiLYmx0dw4Rcz6Lth+cAzn+
> fjTdq8A1P5umV8NiwGZtx8GtPoEWRpEV0zuhZHWXjvFSIxpn2TBUi+pETo421wXH
> 9QDQD5Q/9Wf/Wckyb86+OEhwBGoPXib2sF1BOTWONXHECvQ5xuqXy2Ux34HJHbou
> Que3NfC4OiQKXSJv1jae
> =K93a
> -END PGP SIGNATURE-
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV9PKMAAoJEBzZQR2yrxj7498P/3ITnQ3Ji8MaPGbv3AWK52SN
hccXU3Bjyq7I/A+1H/ZYzmBRtLkANczeCcqOBQTIr2p7s3lFfnvRVAfrpyRsmo1s
ix9Pmf/9ixDZ+dHUxliARiYNZHWNtisxCF5ehmo8+q/F5efLslrjKNf81X9xDpaL
Haz5ywWUfVRXWZwWjgc5dSLfqauPYZSE9B3NzOgjKnRT9OeYT/5dMHf6rgkPi2jT
O2NeYI2zKL93hspxM4ot1QBhlmKAw2ArjDMoV5UkjpvKa/4FKXu8h34dgwZH0AYJ
2WlIMXREUt1iR+FYQ+hUEzOsEO7HgSlz7wfn0Z7SJUFObhXTzIlMLjm5wbVbjsVx
rzz/XEXJlU8OFjy5h2MfoFWn0I46ysgFtie7OaRl/Rq3jqLg6irLAmwgiqJbLgCa
qcwUt3EhbWqSr5NlHdxCHfjnOwYsTrd+cX0FEhMNW2pFO8oBXa4Xz+x4PiZAz07M
RyRftQucd2JbY+TE2nS51HzJYN8157ZkPJ1SnNN38Nftd0oD0XJ9UmeYhO45Gc6W
wRpX75af1dUhgs3nh6CpnYCXuWe8Aa08vf2WWTpw72QdcurI3cSrYcjScDXbF4Yw
hthsaaP+rwDCFacFdY24Rglg01Q45mWq23mylVwnmMUtG3qvE0Nhu3ZIBtqx+j5O
gsujfaXNV5U/jsnCWDMf
=8n1u
-END PGP SIGNATURE-


Re: [gentoo-dev] RFI: A better workflow for github pull requests

2015-09-12 Thread Kent Fredric
On 13 September 2015 at 09:15, hasufell  wrote:
> Because that is not a valid bug report. Patches must be attached to
> bugzilla.


I would recommend against attaching the pull in patch form against
bugzilla. It might lead to unintentionally misleading consequences.

If the patch is automatedly filed against bugzilla, people will assume
viewing that patch tells them all they need to know.

But the reality is somebody may rebase/amend/repush to the publicised
branch location before any developer reviews the patch in bugzilla,
and so by the time somebody reviews the patch, it is already wrong.

And as it is common for there to be a "get feedback, amend the pull,
get feedback, amend the pull" loop in existing real-world git
workflows, it should be assumed that is going to happen frequently.

It would also be better for there to be some way to specify a
repository remote and a ref-spec, not having github-intrinsic
behaviours. ( Because people may have personally hosted git repos they
want feedback on  if they have a github aversion, and we must not
*require* github to interact with the development workflow )

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL



[gentoo-dev] Re: www-client/chromium gtk3 support

2015-09-12 Thread Duncan
Rich Freeman posted on Sat, 12 Sep 2015 06:48:13 -0400 as excerpted:

> On Sat, Sep 12, 2015 at 6:00 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>>
>> Just bite the bullet and create entire USE flag families such that an
>> ebuild can choose the flag appropriate to how it actually uses it. 
>> AFAIK this would need EAPI help, for reasons given below, but it should
>> be doable.
>>
>> gui
>> gui-gtk
>> gui-gtk-2
>> gui-gtk-3
>> gui-qt
>> gui-qt-4
>> gui-qt-5
> 
> I'm going to have to read the rest of your email about 14 times to fully
> grok it,

LOL.  I started with a paragraph describing each setting, and very 
quickly decided /that/ wasn't going to work!  I was "in a maze of twisty 
passages, all different!"[1]  So I tried the matrix/table.  That was bad 
enough, but at least with the table, I could cover all possibilities 
systematically without losing track of where I was.

Luckily, the logic can be written once and used by many.  Additionally, 
once setup, ordinary ebuild maintainers won't have to worry about the 
logic matrix, they'll simply setup the vars describing the candidates, 
call the function, get a result, and act on it.  To ordinary ebuild 
maintainers it can be as effectively black-box as a call to any EAPI/PM 
supplied function is, today.

> but one thing that strikes me about this approach, and perhaps
> mine as well, is that this assumes that USE=-gui should imply USE="-gtk
> -qt" or similar.
> 
> What if qt or gtk is used for more than just the GUI.  What if the
> console version of the program still uses other functions in these
> toolkits besides window decoration/etc?

You're expanding my realm of possibilities here, thanks! =:^)

Good point, particularly since qt5 is modularized with the specific 
intent of making it useful for CLI-only as well.  Except that no, the 
proposal does /not/ necessarily assume USE=-gui means USE=-qt and -gtk as 
well.  While my example had nothing suggesting CLI, keep in mind that 
these are effectively hierarchy flags, with gui-* used as the example.  

This was a (possibly abridged, there's other GUI toolkits...) example of 
the use and logic of the gui-* flags, but use of other flags and flag-
families in the same ebuild would certainly be possible.  Presumably one 
such flag (and perhaps eventually flag-family, if called for) could be 
cli-qt-5.

Meanwhile, keep in mind that as described, the ebuild would set the 
candidates, then call a function which would return the selected 
candidates to build.  But that doesn't prevent the ebuild from using 
further logic with other flags, etc.

So taking your example, the ebuild would do the whole gui-* flag family 
thing as I described, get the results for that, and could then either do 
another family setup and get more results, or could throw in more 
conventional flags.  And one such flag, possibly individual at first, 
wold be cli-qt-5, controlling this option separately.  If later there 
were enough such flags to make a cli-* family, existing ebuilds using cli-
qt-5 would continue to use that individual flag, while revision-bumps or 
new versions could start using the cli-* family, setting it up using UH-* 
variables and calling the function again, getting a CLI result which 
could be used, just as they got a GUI result to use.

---
[1] https://en.wikipedia.org/wiki/Colossal_Cave_Adventure

-- 
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] www-client/chromium gtk3 support

2015-09-12 Thread Rich Freeman
On Sat, Sep 12, 2015 at 12:55 AM, Raymond Jennings  wrote:
> On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman  wrote:
>>
>> On Fri, Sep 11, 2015 at 5:03 AM, Daniel Campbell  wrote:
>> >
>> > I like the general 'gtk' flag we generally use to choose *which*
>> > toolkit, and local USE flags for specific versions, if they are
>> > supported. But in that case, the general gtk flag should be
>> > interpreted as the latest version supported, so users don't come
>> > across weirdly behaving packages that default to gtk2 (unless that
>> > version is the most stable).
>> >
>> >...
>> >
>> > For starters, versioned USE flags more than likely don't belong in
>> > make.conf's USE variable and shouldn't be global.
>
> Personally i disagree with this.
>
> Versioned use flags for widely used dependencies (like a windowing toolkit)
> IMO qualify as global USE flags because they have a common effect across
> many packages.

He wasn't suggesting that they have different meanings for different
packages.  By saying that they shouldn't be global he meant that users
should not typically be manipulating them at a global level, such as
in make.conf.

Back in the day it was common to stick flags like these in make.conf
or in profiles, since if you didn't packages wouldn't build GUIs and
such.  That was before USE defaults and it caused a lot of headaches
when multiple versions of toolkits started coming along and setting
these flags started causing harm.

But, the way we use the terms local/global USE flags is confusing.
They can mean that a flag has a package-specific vs global meaning, or
the terms can mean that it is recommended that the flag be enabled at
the package.use level vs at the make.conf level.  To be fair to you,
until very recently the first meaning was the most common.  People are
talking more about the second meaning of late because of problems that
happen when people try to tweak fairly detailed settings like gtk3 at
the global level.

>
>> I'd be tempted to even say to not have gtk3 but instead call the flag
>> chromium-gtk3 or whatever so that it becomes very difficult to put in
>> the global config.  However, that goes against our general principle
>> of letting the user break their system and keep the pieces if they
>> think they know what they're doing.  If somebody WANTS to test out a
>> gtk3-only system or whatever they should have the freedom to do so,
>> understanding that testing sometimes uncovers problems.
>
> I actually also think that there should be a single USE flag for building on
> gtk3, called gtk3.  calling it "(packagename)-gtk3" is a bit redundant, and
> also flies in the face of having a single global flag with a coherent
> purpose.
>

The only reason for doing it the other way would be to make it harder
for users to shoot themselves in the foot by setting these flags in
make.conf.  They'd have to put 50 flags in make.conf and not just one.
However, in general Gentoo operates under the principle that while we
should avoid surprising the user, we shouldn't actually make it hard
for the user to override our decisions when they feel it is best.

-- 
Rich



Re: [gentoo-dev] Re: www-client/chromium gtk3 support

2015-09-12 Thread Rich Freeman
On Sat, Sep 12, 2015 at 6:00 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Just bite the bullet and create entire USE flag families such that an
> ebuild can choose the flag appropriate to how it actually uses it.  AFAIK
> this would need EAPI help, for reasons given below, but it should be
> doable.
>
> gui
> gui-gtk
> gui-gtk-2
> gui-gtk-3
> gui-qt
> gui-qt-4
> gui-qt-5

I'm going to have to read the rest of your email about 14 times to
fully grok it, but one thing that strikes me about this approach, and
perhaps mine as well, is that this assumes that USE=-gui should imply
USE="-gtk -qt" or similar.

What if qt or gtk is used for more than just the GUI.  What if the
console version of the program still uses other functions in these
toolkits besides window decoration/etc?

Granted, I suspect that in such a case turning off any of this stuff
is probably not build-time-configurable.  If you want the console-only
version you'd just pass the appropriate command line option (like
deluge's --ui option).

However, it is conceivable that you could design a build system so
that the GUI requires qt and libfoo, spell check requires qt only, and
you could build the program with GUI support, spell check support, or
neither.  If you built with USE="-gui spellcheck" then you'd want qt
enabled but libfoo disabled.  That is obviously a highly contrived
example and perhaps we don't need to worry about this scenario.
However, it does illustrate the general danger of making USE flags a
strict hierarchy.  A hierarchy like qt/qt4 is probably fairly safe,
but when you generalize to gui/qt/qt4 you're making the assumption
that qt is only used for guis.

But I do like the concept, well, conceptually.

-- 
Rich



Re: [gentoo-dev] symlinks in the tree

2015-09-12 Thread Patrice Clement
Saturday 12 Sep 2015 15:30:45, Justin Lecher (jlec) wrote :
> On 12/09/15 15:19, hasufell wrote:
> > +1 for banning symlinks
> > 
> 
> mrueg just mentioned a very crucial point. There are filesystem which
> don't support symlinks and would break everything.
> 
> 
+1 too

A functionality that causes a maintenance burden should be avoided. It's just
common sense.

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


signature.asc
Description: PGP signature


Re: [gentoo-dev] symlinks in the tree

2015-09-12 Thread Ulrich Mueller
> On Sat, 12 Sep 2015, Justin Lecher (jlec) wrote:

> I would like to discuss the pro and cons of usage of symlinks in the
> tree, which are possible now as we aren't bound to CVS anymore

> We have quite a number of ebuilds already in the tree defining
> functionality for both, regular version and live versions. These are
> typical candidates. Same for different package versions with the
> same ebuild.

> [...]

> nevertheless, we would slim the tree and reduce work when changing
> things like HOMEPAGE.

IIUC git will only store one copy of duplicate files, so using
symlinks won't save any space in the repository.

Also I suspect that symlinks would soon cause a mess when package
versions are stabilised.

Ulrich


pgp1WXtcM9j9K.pgp
Description: PGP signature


Re: [gentoo-dev] USE="gui"

2015-09-12 Thread hasufell
On 09/12/2015 01:52 AM, Daniel Campbell wrote:
> On 09/11/2015 01:34 PM, hasufell wrote:
>> I already use IUSE=gui and will keep doing that.
> 
>> USE flags in gentoo are the best and the worst thing at the same
>> time. They are also mostly the main reason people don't like
>> gentoo, because USE flags are (for todays situation) pretty much
>> not an appropriate pattern to reflect real-world configuration. To
>> be more precise... USE flags are first-class citizens and there is
>> only one layer of them. There's not configuration
>> pattern/abstraction behind them. If you wonder what I am talking
>> about, have a look at NixOS. The reason we lack proper declarative
>> configuration is also the reason we had to introduce this ugliness
>> called REQUIRED_USE. Instead of saying "gui.gtk" we say 
>> "REQUIRED_USE="gui? ( || (  gtk ... ) )". And it will get worse. I 
>> wonder when people start realizing that.
> 
> 
> So are you suggesting maybe we come up with namespaced USE flags? That
> would be interesting.
> 

I'm not sure we can do that without breaking gentoo. At least, it would
be a _huge_ EAPI change.

It would require a lot of PM work, would break our configuration format
(if you want to do it properly) and probably have other side effects for
running systems.

And if you have followed NixOS development... you know that you can
screw this up as well, because consistency is even more important if you
really want declarative configuration. And I'm not sure there is enough
interest in consistency in gentoo. People seem to be fine with micro
managing USE flags in order to achieve a particular configuration state
which can break arbitrarily on any update.



[gentoo-dev] symlinks in the tree

2015-09-12 Thread Justin Lecher (jlec)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I would like to discuss the pro and cons of usage of symlinks in the
tree, which are possible now as we aren't bound to CVS anymore

We have quite a number of ebuilds already in the tree defining
functionality for both, regular version and live versions. These are
typical candidates. Same for different package versions with the same
ebuild.

What is your opinion on making heavy use of symlinks here?

Personally I would ban symlinks and duplicated code. One ebuild for
one version. And in case you like to propagate changes over several
ebuilds, just use tools like meld.

A drawback is that tools like sed break symlinks and write back a
plain files.

And last, we have potential breakages if people don't give enough care
when doing stabilizations and removal of version.

nevertheless, we would slim the tree and reduce work when changing
things like HOMEPAGE.

So please discuss this matter.

Justin
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0

iQJ8BAEBCgBmBQJV9CSoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiIZ0P/0q6jSuGZzZ4lDiu87GIYMiC
ndRzHsR/OGT9paB01pkoQogOt9+AMKdNd434n2to+HbuNf7Le5cWP7MBAdD/ydzV
H+5zE98Mu9h8IXTRvuxv6eTSRPFsnnDPuMAS+28D7WwDBcmOhl4we/hRyfq0+JFw
s5XojNlrk7YZLynZs8SHcgqq5CbaKbjLMsVSTnVXKeA1NcaB0lPFjI0JraCqW4xS
BgIA2MrrR5XM2imvmBInanwJZ+VOVvHD1jxTlfUQeF7qJusTY5fTnVncvnIo72Fh
E2Rz/+vrWFe+CvQV63IpgbtC2oYP5OMidnfZSQynRbGsK9w3rm25cXOlyXjLA98O
sv/wNHvVk3+SIvIviN3yDjOOG5q1zeW33UtZfz5iKu3E7dUGw6B2a/qjC9m9lIQH
GGDu7csYnW8aSLiEJPGsJsduTqw/+G5p8DWMGuHss6xu6DyZKJPRxgd4VlDkLIiE
ZCgoHCGhQX3LDEOlzh7+j01A1AOO4SfTZqqDch8f6jiLYmx0dw4Rcz6Lth+cAzn+
fjTdq8A1P5umV8NiwGZtx8GtPoEWRpEV0zuhZHWXjvFSIxpn2TBUi+pETo421wXH
9QDQD5Q/9Wf/Wckyb86+OEhwBGoPXib2sF1BOTWONXHECvQ5xuqXy2Ux34HJHbou
Que3NfC4OiQKXSJv1jae
=K93a
-END PGP SIGNATURE-



Re: [gentoo-dev] symlinks in the tree

2015-09-12 Thread hasufell
+1 for banning symlinks



Re: [gentoo-dev] symlinks in the tree

2015-09-12 Thread Justin Lecher (jlec)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/09/15 15:19, hasufell wrote:
> +1 for banning symlinks
> 

mrueg just mentioned a very crucial point. There are filesystem which
don't support symlinks and would break everything.


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0

iQJ8BAEBCgBmBQJV9CkFXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmi1ZoP/RwfCG1w0Rz9NcMx+ZSI2BaU
sQ5AJnvGK44G3v+H7gCz5GtdHUVkFcKzZ0o6FPQnBeSO4B2Ja42d4Sl/L5Hp+K11
h3lMzqZ8t4d2g+d5Vdu4dSt2doPwH0hPQmSZJ3mUUtTZphacxo3iAL1oYZ6c6FKw
thU4Cd52VLVuYIzekFP3pqW5g2iAyOKP/Z2+icJ8ljF9Y1NgdHjqDkKHLZ7U0cHt
RmCj0K6xctIH+nJ5PEIo2z5EvJqMb7f9B8ijkCGAZFu8mWI0BBma+OSnPvF6zjtF
e1X6IP7B7j2q57oRCHpnSG19T1wDnfJZaqZD+wpUb4EV6ITme8E3JT/4OG4OJF/0
W7/dJHYNkEAbgWoDjagsEQNuqda3BbOyv6IoXze0CUlTkGwW8wOVDUhPPnTBF8JL
Yf9WEbbECT4sRSi8ZdaUd+8M0b1gnazPBdRHCndxn530mxdicHZ6Ereup7fhRUPx
OoqvRNHJhQPX5UazbBhw/YyFq7Y1G5dg1kvZFuv50Uohmy4D1plE1dyPg0hdFwRB
UewKUl5j6CA2VKUTBFsdSBMhu/KRG/Bv4ThO7vTKhqITTwAoUXpTmLO1T7FoadIe
0DohHo3lMg2B45f0aRq8rMcgGFv8LGa5hYAzy11uU07CVHAWxfIGkMUFUvwVo3cO
PsyI27ZZVfrE38MflVgs
=4NpN
-END PGP SIGNATURE-



Re: [gentoo-dev] symlinks in the tree

2015-09-12 Thread Kristian Fiskerstrand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/12/2015 03:12 PM, Justin Lecher (jlec) wrote:
> Hi,
> 
> I would like to discuss the pro and cons of usage of symlinks in
> the tree, which are possible now as we aren't bound to CVS anymore
> 
> We have quite a number of ebuilds already in the tree defining 
> functionality for both, regular version and live versions. These
> are typical candidates. Same for different package versions with
> the same ebuild.
> 
> What is your opinion on making heavy use of symlinks here?

I'm not in favor of it, I see an increase in maintenance complexity in
particular with regards to stabilization and version cleanup without
any obvious benefit. If the argument is the duplicate ebuild info
after a copy is too much, there are likely too many versions for that
package around.

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJV9CjnAAoJECULev7WN52FbNsH/jeN9wN257cu9rk/tDMEKrXB
JLizxjTQSSXQAPGR262bQ8T8vL40vW4rxYDUdEfO+l/tA88iqA7gIUN5RIULclBG
7bJt2OBD6nX+ySwavklU+kT/sCTX9xhKz6FyPMNREhR97utTPuhAefgyuDhFS1+T
M+RkMmtrEya34FK0K4jg2s9S67FE1HEhe60AHCYILKpDqBR6/ESkd3jCgSDOwl51
rdQ5QqlX0eblmXossWbA34SbWA2u8yr7cMAYP6Y/wUCLI0MkDoNDbC7d4lOpJ6pe
PLxLC4vPOmIJC1vRri1R5aiKeHywE80/KcfraMBAhHzgPgJ8QjHlpuIgbblBets=
=5jWI
-END PGP SIGNATURE-