Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-16 Thread Michał Górny
On Thu, 16 Jun 2016 09:40:53 -0500
james  wrote:

> On 06/16/2016 10:04 AM, Michał Górny wrote:
> > On Thu, 16 Jun 2016 08:59:44 -0500
> > james  wrote:
> >  
> >> On 06/16/2016 02:51 AM, Alexander Berntsen wrote:  
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA512
> >>>
> >>> On 16/06/16 09:39, Daniel Campbell wrote:  
>  I guess what I mean is these outside developers could continue
>  hacking and/or breaking things, or whatever else, without worrying
>  about their "official" branch. We could have a standard that
>  assumes Gentoo pulls their 'master' branch and they keep other
>  stuff in 'dev', or some other model. We'll need to decide on *some*
>  branch, but putting it in writing would make things clearer for
>  prospective repo maintainers.  
> >>  
> >>> OK, then I think that it would be a good idea to have a gentoo-ci
> >>> branch, or similar, if the assumption is merely that this is where
> >>> Gentoo developers will look when evaluating your repository.
> >>>  
> >> Ok, if we go this route, here is a basic simple question. Why can't the
> >> "gentoo-ci" be a package, or group of packages that runs in a private
> >> persons own resources, regardless it is a single gentoo server or a
> >> small cluster (openstack)? That way, those gentoo-ciruns can be
> >> performed by the proxy or the author thus reducing the workload for QA
> >> or other devs.  I guess what I'm really asking is/will the gentoo-ci be
> >> packaged up for the gentoo community to use, on a small set of packages?  
> >
> > dev-util/pkgcheck is the QA tool used (you want -).
> >
> > https://github.com/gentoo/travis-repo-checks is the wrapper that is
> > used to run it in parallel. A lot of hackery, and master is outdated
> > for -. No time to fix it. The repo-mirror-ci branch is better but
> > then, I updated it recently for some local hacks.
> >
> > https://bitbucket.org/mgorny/pkgcheck-result-parser is the thingie used
> > to turn pkgcheck XML reports into pretty HTML. Also a bit hacky,
> > especially with the error & warning lists hardcoded.
> >
> > https://bitbucket.org/mgorny/repo-mirror-ci all the extra scriptery
> > used to run it all. No time to clean it up more than I already did.
> >  
> 
> EXCELLENT !  I seem to be mostly interested in orphaned, broken and 
> controversial packages these daysnot sure if that is a good thing or 
> not.
> 
> Do these ci tools work on gentoo snaps? [1]

I have no clue. And I doubt I'll be interested in testing that thing.

> [1] 
> http://arstechnica.com/information-technology/2016/06/goodbye-apt-and-yum-ubuntus-snap-apps-are-coming-to-distros-everywhere/

-- 
Best regards,
Michał Górny



pgpaVi2p9M_HX.pgp
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-16 Thread james

On 06/16/2016 10:04 AM, Michał Górny wrote:

On Thu, 16 Jun 2016 08:59:44 -0500
james  wrote:


On 06/16/2016 02:51 AM, Alexander Berntsen wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 16/06/16 09:39, Daniel Campbell wrote:

I guess what I mean is these outside developers could continue
hacking and/or breaking things, or whatever else, without worrying
about their "official" branch. We could have a standard that
assumes Gentoo pulls their 'master' branch and they keep other
stuff in 'dev', or some other model. We'll need to decide on *some*
branch, but putting it in writing would make things clearer for
prospective repo maintainers.



OK, then I think that it would be a good idea to have a gentoo-ci
branch, or similar, if the assumption is merely that this is where
Gentoo developers will look when evaluating your repository.


Ok, if we go this route, here is a basic simple question. Why can't the
"gentoo-ci" be a package, or group of packages that runs in a private
persons own resources, regardless it is a single gentoo server or a
small cluster (openstack)? That way, those gentoo-ciruns can be
performed by the proxy or the author thus reducing the workload for QA
or other devs.  I guess what I'm really asking is/will the gentoo-ci be
packaged up for the gentoo community to use, on a small set of packages?


dev-util/pkgcheck is the QA tool used (you want -).

https://github.com/gentoo/travis-repo-checks is the wrapper that is
used to run it in parallel. A lot of hackery, and master is outdated
for -. No time to fix it. The repo-mirror-ci branch is better but
then, I updated it recently for some local hacks.

https://bitbucket.org/mgorny/pkgcheck-result-parser is the thingie used
to turn pkgcheck XML reports into pretty HTML. Also a bit hacky,
especially with the error & warning lists hardcoded.

https://bitbucket.org/mgorny/repo-mirror-ci all the extra scriptery
used to run it all. No time to clean it up more than I already did.



EXCELLENT !  I seem to be mostly interested in orphaned, broken and 
controversial packages these daysnot sure if that is a good thing or 
not.


Do these ci tools work on gentoo snaps? [1]

thx,
James

[1] 
http://arstechnica.com/information-technology/2016/06/goodbye-apt-and-yum-ubuntus-snap-apps-are-coming-to-distros-everywhere/






Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-16 Thread Michał Górny
On Thu, 16 Jun 2016 08:59:44 -0500
james  wrote:

> On 06/16/2016 02:51 AM, Alexander Berntsen wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > On 16/06/16 09:39, Daniel Campbell wrote:  
> >> I guess what I mean is these outside developers could continue
> >> hacking and/or breaking things, or whatever else, without worrying
> >> about their "official" branch. We could have a standard that
> >> assumes Gentoo pulls their 'master' branch and they keep other
> >> stuff in 'dev', or some other model. We'll need to decide on *some*
> >> branch, but putting it in writing would make things clearer for
> >> prospective repo maintainers.  
> 
> > OK, then I think that it would be a good idea to have a gentoo-ci
> > branch, or similar, if the assumption is merely that this is where
> > Gentoo developers will look when evaluating your repository.
> >  
> Ok, if we go this route, here is a basic simple question. Why can't the
> "gentoo-ci" be a package, or group of packages that runs in a private
> persons own resources, regardless it is a single gentoo server or a 
> small cluster (openstack)? That way, those gentoo-ciruns can be 
> performed by the proxy or the author thus reducing the workload for QA 
> or other devs.  I guess what I'm really asking is/will the gentoo-ci be 
> packaged up for the gentoo community to use, on a small set of packages?

dev-util/pkgcheck is the QA tool used (you want -).

https://github.com/gentoo/travis-repo-checks is the wrapper that is
used to run it in parallel. A lot of hackery, and master is outdated
for -. No time to fix it. The repo-mirror-ci branch is better but
then, I updated it recently for some local hacks.

https://bitbucket.org/mgorny/pkgcheck-result-parser is the thingie used
to turn pkgcheck XML reports into pretty HTML. Also a bit hacky,
especially with the error & warning lists hardcoded.

https://bitbucket.org/mgorny/repo-mirror-ci all the extra scriptery
used to run it all. No time to clean it up more than I already did.

-- 
Best regards,
Michał Górny



pgpUmPCchLKzJ.pgp
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-16 Thread james

On 06/16/2016 02:51 AM, Alexander Berntsen wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 16/06/16 09:39, Daniel Campbell wrote:

I guess what I mean is these outside developers could continue
hacking and/or breaking things, or whatever else, without worrying
about their "official" branch. We could have a standard that
assumes Gentoo pulls their 'master' branch and they keep other
stuff in 'dev', or some other model. We'll need to decide on *some*
branch, but putting it in writing would make things clearer for
prospective repo maintainers.



OK, then I think that it would be a good idea to have a gentoo-ci
branch, or similar, if the assumption is merely that this is where
Gentoo developers will look when evaluating your repository.


Ok, if we go this route, here is a basic simple question. Why can't the
"gentoo-ci" be a package, or group of packages that runs in a private
persons own resources, regardless it is a single gentoo server or a 
small cluster (openstack)? That way, those gentoo-ciruns can be 
performed by the proxy or the author thus reducing the workload for QA 
or other devs.  I guess what I'm really asking is/will the gentoo-ci be 
packaged up for the gentoo community to use, on a small set of packages?


Is that idea too difficult at this time?
Is there even a glep, or standard or part of PMS that will allow the 
gentoo-ci solution to become a routine tool for all to use?





Alexander
berna...@gentoo.org



curiously,
James






Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-16 Thread M. J. Everitt
On 15/06/16 07:42, Andrew Savchenko wrote:
> On Wed, 15 Jun 2016 05:15:03 +0200 Michał Górny wrote:
>> On Wed, 15 Jun 2016 00:12:40 +0200
>> "Andreas K. Huettel"  wrote:
>>
>>> Am Dienstag, 14. Juni 2016, 02:32:41 schrieb Peter Stuge:
>>>
 I would personally be super happy to have my overlay hosted at Gentoo -
   
>>> So what precisely is keeping you from that?
>>>
>>> https://wiki.gentoo.org/wiki/Project:Overlays/Overlays_guide
>> Don't encourage people to create more work for me when we have GitHub!
> Github is propietary and I don't see why someone have a right to
> enforce its usage on people.
>
> If someone want to use github — go ahead, but if not — in no way
> you can force people to do that (e.g. by refusing to create on
> overlay, or review patch on bugzilla, or whatever).
>
> Best regards,
> Andrew Savchenko
+1



signature.asc
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-16 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 16/06/16 09:39, Daniel Campbell wrote:
> I guess what I mean is these outside developers could continue 
> hacking and/or breaking things, or whatever else, without worrying 
> about their "official" branch. We could have a standard that
> assumes Gentoo pulls their 'master' branch and they keep other
> stuff in 'dev', or some other model. We'll need to decide on *some*
> branch, but putting it in writing would make things clearer for
> prospective repo maintainers.
OK, then I think that it would be a good idea to have a gentoo-ci
branch, or similar, if the assumption is merely that this is where
Gentoo developers will look when evaluating your repository.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXYlpqAAoJENQqWdRUGk8B2G0P+wZ3Ol3AmhhsOFns7Jor7wJD
d9wqlLqtTeMcMEfUfYunpD02KwepN0UFN8imIqOGIHBM4IgQsvq19ejDgguh/MK3
uQxuyLWEHMhVNBRjNz6Ngm0IPx/3XaCSJPSu0RZdkCkHcOmAHisQY0Vy4NZj3MdL
JgBWSO5UA+CdOzC8t+TuyPE7+nt4fgC1sCwyPbjFMeD2A5IAtmyJ1hvW+THf0LeC
BW3tKt3SVLvbRLFV1A4kpKQJ+geG6+6t24jeqYrKkcViTaL5YSoAPNfajmYobXyE
zK7q+jN33WrwcOkUQGwWGg15D7/aGN5HzeJp6IGu6ANx+Ya+IVN/nG6ZpCdj569x
eeIKvNsFC7KNE6IV0srXQHKZbz9W7cAadX/vxyWHRxOwsYRQ5ZrxJH+gq6V5yeOf
0jHiT75xLCHkzk8jyKAFvou8YkLV4e9HnNd0R4Yub77hYUrS8kJ/XGRe2pEW9UrC
eMli1kiEdJ4rwI+E62kPpPqSpm17MGsdylFNav/2j4EW7g8l/ez+7LT1kOSY8ywW
JPSPiB53WHDDrnkn0y8Ips/sygu+8brTyu10SoNXSOHKZF2ZYUNXBOUunK3fqahb
zxrnzIAu8e5BD97+YgxSbg284lleUqkSdZP5O7DaNEpSMcEo9yOv1kLYNsD1vGH/
mGYOXf0F5wti+uGJxjoH
=bQST
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-16 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 16/06/16 09:34, Daniel Campbell wrote:
> There is overhead in choosing which repositories you want to
> include in your 'upstream'. Even with an automated tool like
> layman, there's maintenance overhead. We'd need another tool to
> assist in discoverability, too. Let's say this idea takes off and
> we start with 100-200 user repos. It's meaningless to learn that
> there are that many repositories and list them (that's what layman
> currently does). What's important is getting a list of *which
> packages* those repos have, even if it's one-by-one and cat'd to a
> file.
> 
> Even if that is written, it adds yet another facet to system 
> administration.
I'm not convinced it will be a big amount of work, and I'm doubly not
convinced most people will have *any* amount of work, as I expect most
people do not care. (I would however be pleasantly surprised to be
proven wrong.) They will start out with the Gentoo repositories, and
only venture outside if they are aspiring devs, powerusers, or have
some specific need that an overlay satisfies. If we have a useful
website (and improved CLI layman-like tool for those who have
webophobia), the complexity of assessing which overlay to use should
be exclusively derived from actual assessment, not being bogged down
in a hodgepodge of unreasonable tools. We should also have some way of
measuring popularity, and let users show appreciation for
repositories, so that there is a way to determine 'this is a top rated
repository that many people use'.

But, yes, unequivocally yes, there is an added level of system
administration for those who choose it! I just happen to think it is a
*desirable* addition for those who end up choosing it.

> Okay, and who chooses which ones get curated? Developers? The
> whole goal of this decentralization, from what I gather, is
> community. If developers are overseeing it all, it adds overhead to
> developers and doesn't really foster community control or support.
I think it is a good idea to have our developers perform reviews and
quality assurance.

> If the goal is community then it should be *community curated*, 
> which means it can exist entirely outside of Gentoo's infra and we 
> shouldn't have to care about it. Why do Gentoo devs need to curate
> it if the aim is community control? In fact, that's already
> possible right here, right now.
At first, I envision *community-assisted development* rather than our
immediate retirement and holiday in the sun. It would however be good
to aim *towards more community control*. Maybe in the future, instead
of having a KDE team we have just one person or two (volunteers like
now) who are performing a bit of review, QA, and coordination, of a
small repository. Then perhaps in a more distant future it is entirely
community driven. Stranger things have happened... But I would be
happy to see the preceding success story, even if we don't get all the
way.

> I'm not against the idea per se, but at the same time I don't see 
> why it's the responsibility of developers to make this sort of
> thing happen. It's not a trivial thing we can mark off in a
> checklist. However, there are enough tools in the Gentoo toolbox to
> make such a thing happen -- if the community wants it. And if they
> want it, they can build it. We don't do anything, to my knowledge,
> to stifle the growth of community repositories.
I think we do a poor job of fostering the growth of community
repositories, outside of making them possible in the first place. The
latter is good, of course, and kudos to everyone who's worked on it.
But it would be interesting to take it a step further and properly
facilitate these repositories.

And, again, modular repositories from our side, would make this that
much more desirable. (And modularising the Gentoo tree is obviously
our responsibility.)
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXYloNAAoJENQqWdRUGk8BMZQQAMt4qcmHlbSy7oOYVzjtP14C
j3ROKwsWUS+n9Ejx9cbCShCxLNE7HfDK7SUxmf0LFvFKxOhrmjYmVZ2t8Iu07r6O
8kK5pYlUenJtQKenMIsmMQclOFrRm/y0SX/PlDcmdwMgP+fqShy7zJ3u5JNKBwfr
vitD0/c1rLS5C/p8p+o1w6g7RYUm6UtbPn8SjfkMorMpY1moU43BX4d/PFo4FT6B
CtA5+df8Z5emUkKLDkiS/9xslVU53i1TZhycgOVbubMnyuvoJyHeB2ZWiSOtYqw7
GIUiYYmrQ6JJFf6ZNuIXV3V+zfv6nfNL5D9xvpBYg5RwMQEMUXWP8f0ca+2sE5Kx
RojMEOKQx6Y1rYHOtq9gXpsAArT0TCWmglaxCqUwrf6SKL373TEkmr8RMvvRDGBV
GFJcOsxv9OrkJTe0FYvmr8y8N93b+KTK7RhDekYuWm+rrbfebo+dcKPZmtPcYxoR
NgmhLEdllUhdwti+e2Lo+qSXBScoRBeqYmWW+lN/k02YSV/gIiumbi7d4H/HRy6n
kNbELzGpqLr/FIZRxD5Sx7ufSjEC+OlnP59OM6Uj1A6yUmuepyqlJJrmeaZ9LzGg
6/vzgrX82jjrMAishtNleftquaxpzSNQsFGB1PgZ/h2XObacuBMnOgOMV8RvsfVG
4VUp+ttdQi+DDxLQA4Bi
=zHis
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-16 Thread Daniel Campbell
On 06/16/2016 12:35 AM, Alexander Berntsen wrote:
> On 16/06/16 09:24, Daniel Campbell wrote:
>> To touch on the user repo part.. can't it be as simple as adding
>> one requirement to user repos that wish to be considered as
>> curated?
> 
>> Create a "gentoo-ci" branch or something else, and the maintainer
>> of each repo can update said branch when QA 'approves' a given
>> commit. Then others can 'subscribe' to that branch and development
>> remains unhindered by the QA process in a distributed format.
> I'm not sure what you mean by unhindered. I didn't mean for my idea to
> create any hindrance. My idea was to fork their repository, and have
> some dev(s) take the responsibility of merging from the user. Or, we
> could do what Exherbo does, just let them carry on and trust them, and
> only (perhaps temporarily) remove their repository if we find them
> guilty of some wrongdoing.
> 
> While I'm not axiomatically opposed to your idea, I think it may
> create noise if everybody makes a gentoo-ci branch, and most of them
> are close to worthless.
> 
I guess what I mean is these outside developers could continue hacking
and/or breaking things, or whatever else, without worrying about their
"official" branch. We could have a standard that assumes Gentoo pulls
their 'master' branch and they keep other stuff in 'dev', or some other
model. We'll need to decide on *some* branch, but putting it in writing
would make things clearer for prospective repo maintainers.
-- 
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: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-16 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 16/06/16 09:24, Daniel Campbell wrote:
> To touch on the user repo part.. can't it be as simple as adding
> one requirement to user repos that wish to be considered as
> curated?
> 
> Create a "gentoo-ci" branch or something else, and the maintainer
> of each repo can update said branch when QA 'approves' a given
> commit. Then others can 'subscribe' to that branch and development
> remains unhindered by the QA process in a distributed format.
I'm not sure what you mean by unhindered. I didn't mean for my idea to
create any hindrance. My idea was to fork their repository, and have
some dev(s) take the responsibility of merging from the user. Or, we
could do what Exherbo does, just let them carry on and trust them, and
only (perhaps temporarily) remove their repository if we find them
guilty of some wrongdoing.

While I'm not axiomatically opposed to your idea, I think it may
create noise if everybody makes a gentoo-ci branch, and most of them
are close to worthless.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXYla5AAoJENQqWdRUGk8BjQAP/jfWOmR3DHMSlUpYGQILCrRp
na0WUIHqWqVFirb5UaG4Jn419TXvHynT7WqeP1brL/czWiwZ/XO7IUF/Qw2Qbg29
uXtFS03V+KvnJSZNHBuY9yAsruKtv41fbRF906Erxo9KDoubJRlJdYoIazjwCA4a
TMvFcAwLhvU0eJ+kXxZHzBWO5JSH29HA9Nwikd7vSDLZEGoB1wjjzKb2eNsU60Pg
NBW7osLk7LPB+Lmqisjs/EmHJobrVCdpPl1495b/X9/I433v3Y6FE4JZQ3msclv9
aZmqAFa6nqE3Sy6bEdOJPFk7ThnS3rNU0B0hpDt4V8wG4pNRMSdW30ua3KojfcIZ
Gbk77onNR8UiJNKiwW042DgZhn6ne1+19BtMQ+C9AT+5bAlnWrTPykcf+pbNfejK
W4V8hIcFsus8Umug/uqxugTbtROyRCAZlll3eYLsi6NaWs16iJhJRGc1KOYwlnDJ
DBO6quTK1EHGbugWPERKxMdRDikum7RnQCZYXjiYOqJI+MgReArMjqihpM9teKTL
c1DUF2u8yVSxftLaClmva95wFmcbdbdWnfXVA5w1QhLeIYC+ptGUKJhV35FInTn2
Hcig2gtHZibCujBikSxsXcWigQlIzjDAtsX+lxZfa9jWwTD2b3x1ny4UQKHsA4Qi
Qd5mUTzBM/1csYZtRlue
=u0jJ
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-16 Thread Daniel Campbell
On 06/15/2016 12:22 AM, Alexander Berntsen wrote:
> On 14/06/16 08:48, Daniel Campbell wrote:
>> What sort of modularization are you talking about?
> The cheap answer is "as much as possible.
> 
>> Would we suggest something like GNOME, KDE, XFCE, Mate, Cinnamon,
>> et al getting their own overlays? dev-lang/foo getting its own
>> overlay, etc?
> Yes. Although I would not want to impose my thoughts too much in this
> regard, as I think we have a lot of capable devs, who are hopefully more
> fit for this task than I am.
> 
>> To some degree, that will simplify some people's trees and quicken
>>  emerge, but then it just pushes maintainance to a part that most
>> users don't really mess with much (repos.conf)
> I don't know what maintenance you are speaking about.

There is overhead in choosing which repositories you want to include in
your 'upstream'. Even with an automated tool like layman, there's
maintenance overhead. We'd need another tool to assist in
discoverability, too. Let's say this idea takes off and we start with
100-200 user repos. It's meaningless to learn that there are that many
repositories and list them (that's what layman currently does). What's
important is getting a list of *which packages* those repos have, even
if it's one-by-one and cat'd to a file.

Even if that is written, it adds yet another facet to system administration.
> 
>> You can achieve mostly the same end via your own git repo at
>> /usr/local/ and pulling overlays in via either layman or git
>> submodules, for overlays that aren't already in layman.
> The repository isn't hosted by us along with everybody else's
> repository, so there is no community element. And the Gentoo tree isn't
> modular today. So I completely fail to see how that would be "mostly the
> same".
> 
>> zugaina and layman are great tools that could use a bit more
>> polish, and could be either adopted or assisted as an official part
>> of the handbook.
> That would be great.
> 
>> There's no guarantee on their quality, and if an overlay becomes
>> popular then there may be pressure put on the Gentoo tree to adopt
>> whatever the popular overlay has. This could be detrimental *or*
>> beneficial, depending on what the changes are.
> I assume that using PPAs is at your own risk, so this is not a real
> problem. Gentoo would have a curated and reviewed set of repositories,
> venturing outside of that is clearly for power users.
> 
Okay, and who chooses which ones get curated? Developers? The whole goal
of this decentralization, from what I gather, is community. If
developers are overseeing it all, it adds overhead to developers and
doesn't really foster community control or support.

If the goal is community then it should be *community curated*, which
means it can exist entirely outside of Gentoo's infra and we shouldn't
have to care about it. Why do Gentoo devs need to curate it if the aim
is community control? In fact, that's already possible right here, right
now.

I'm not against the idea per se, but at the same time I don't see why
it's the responsibility of developers to make this sort of thing happen.
It's not a trivial thing we can mark off in a checklist. However, there
are enough tools in the Gentoo toolbox to make such a thing happen -- if
the community wants it. And if they want it, they can build it. We don't
do anything, to my knowledge, to stifle the growth of community
repositories.
-- 
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: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-16 Thread Daniel Campbell
On 06/15/2016 12:37 AM, Alexander Berntsen wrote:
> You've got most things right, Rich. But a couple of comments follow.
> 
> On 15/06/16 02:25, Rich Freeman wrote:
>> 1.  Developers wouldn't have access to all the ebuilds in the
>> curated repositories.  They would only have access to the ones they
>>  contribute to.
> I'm not sure I completely agree with that as a hard rule. E.g. I think
> that having an inter-repository QA team would be valuable.
> 
>> 2.  Exherbo at least requires peer review for all commits I
>> believe. So, even if you're committing to your "own" overlay you're
>> still going to need review if your overlay is a curated one.
> Once again you are misrepresenting Exherbo. But since this thread is
> about Gentoo, I will limit my reply to Gentoo. We should not enforce
> anything on a user's repository like this. Instead, I suggest we
> maintain a fork of their repository in which we perform review.

To touch on the user repo part.. can't it be as simple as adding one
requirement to user repos that wish to be considered as curated?

Create a "gentoo-ci" branch or something else, and the maintainer of
each repo can update said branch when QA 'approves' a given commit. Then
others can 'subscribe' to that branch and development remains unhindered
by the QA process in a distributed format.

We've settled on git, and anything that replaces git in the future will
need an analog or replacement for branches, so it seems like a sound
idea to me.

Of course, pulling that off in infra and coordinating review is a
completely different issue; one that won't be solved with software.
-- 
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: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-15 Thread Michał Górny
Dnia 15 czerwca 2016 08:42:26 CEST, Andrew Savchenko  
napisał(a):
>On Wed, 15 Jun 2016 05:15:03 +0200 Michał Górny wrote:
>> On Wed, 15 Jun 2016 00:12:40 +0200
>> "Andreas K. Huettel"  wrote:
>> 
>> > Am Dienstag, 14. Juni 2016, 02:32:41 schrieb Peter Stuge:
>> > 
>> > > 
>> > > I would personally be super happy to have my overlay hosted at
>Gentoo -
>> > >   
>> > 
>> > So what precisely is keeping you from that?
>> > 
>> > https://wiki.gentoo.org/wiki/Project:Overlays/Overlays_guide
>> 
>> Don't encourage people to create more work for me when we have
>GitHub!
>
>Github is propietary and I don't see why someone have a right to
>enforce its usage on people.
>
>If someone want to use github — go ahead, but if not — in no way
>you can force people to do that (e.g. by refusing to create on
>overlay, or review patch on bugzilla, or whatever).

Congratulations, you just volunteered to join overlays and do the work!

>
>Best regards,
>Andrew Savchenko


-- 
Best regards,
Michał Górny (by phone)



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-15 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

You've got most things right, Rich. But a couple of comments follow.

On 15/06/16 02:25, Rich Freeman wrote:
> 1.  Developers wouldn't have access to all the ebuilds in the 
> curated repositories.  They would only have access to the ones they
>  contribute to.
I'm not sure I completely agree with that as a hard rule. E.g. I think
that having an inter-repository QA team would be valuable.

> 2.  Exherbo at least requires peer review for all commits I
> believe. So, even if you're committing to your "own" overlay you're
> still going to need review if your overlay is a curated one.
Once again you are misrepresenting Exherbo. But since this thread is
about Gentoo, I will limit my reply to Gentoo. We should not enforce
anything on a user's repository like this. Instead, I suggest we
maintain a fork of their repository in which we perform review.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXYQW7AAoJENQqWdRUGk8BGv4P/ieFcyRD1Be2Qqoj3/l90Vt0
3ga1EYzU1UI8nIkXXAYHChG+POMVadN73dkq/K7M/VGZbW5wAJZcCXfzC08T3rPa
5PROH8UmBnp5Y30tZiNrhI3cNyqUgV/V6E16WHAInPyQ1lOZp2csw9PZV7lu27PE
vHpjb0wmEugJNNMQrJclbMQa11PW+elI7/cgHvRCdFq3ptuaCJ6yyAkWJ+ouB4C0
8WpVelra2l+b0YwBYYXQ4A9qlkIFfa6Ptvkirk/J9Nrjjnj++8Exa1D9sayUmuQr
Iw8eTRYVUi0i1PQtTHBr6oEXMKjSdy1y1pb22O4ypflhcrj0IyhWZnIvdwDZkLzm
6abobiN79kzTgD8J45T2afcGKbtUIITldhgbS3GuxC6E1XjE6ByVswmh7MXT2cJa
l4lddH77KTdb+m0dbL6PuojTdyVKmlEyRJRr+iAEN7Fo3CSa7BE1ButdOssoNj6X
NIJLsHpGUVkGqSnar3f0lIe0hQqMdIEOSLqCkAkO6+OjA2nIbcgNAZXRHhJcGoB5
K1Nna/nCZm+GcQtlsKYvK+XyDHiLQn5QO0F6MMo5DUbxjcDR+0neKxrm12oShDFG
iGZDzcryAy7eZrycMR8o3RqEUf7vGk3Ve3eFgSMiGqQfaIp0Oogc4Meolk6ALKpG
YZ2JhKLp5efThPSaim85
=dWzl
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-15 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 14/06/16 08:48, Daniel Campbell wrote:
> What sort of modularization are you talking about?
The cheap answer is "as much as possible.

> Would we suggest something like GNOME, KDE, XFCE, Mate, Cinnamon,
> et al getting their own overlays? dev-lang/foo getting its own
> overlay, etc?
Yes. Although I would not want to impose my thoughts too much in this
regard, as I think we have a lot of capable devs, who are hopefully more
fit for this task than I am.

> To some degree, that will simplify some people's trees and quicken
>  emerge, but then it just pushes maintainance to a part that most 
> users don't really mess with much (repos.conf)
I don't know what maintenance you are speaking about.

> You can achieve mostly the same end via your own git repo at 
> /usr/local/ and pulling overlays in via either layman or git 
> submodules, for overlays that aren't already in layman.
The repository isn't hosted by us along with everybody else's
repository, so there is no community element. And the Gentoo tree isn't
modular today. So I completely fail to see how that would be "mostly the
same".

> zugaina and layman are great tools that could use a bit more
> polish, and could be either adopted or assisted as an official part
> of the handbook.
That would be great.

> There's no guarantee on their quality, and if an overlay becomes
> popular then there may be pressure put on the Gentoo tree to adopt
> whatever the popular overlay has. This could be detrimental *or*
> beneficial, depending on what the changes are.
I assume that using PPAs is at your own risk, so this is not a real
problem. Gentoo would have a curated and reviewed set of repositories,
venturing outside of that is clearly for power users.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXYQIaAAoJENQqWdRUGk8BVQQP/RmlYUCY46hslpRXC2A8W+pk
OUCF4hL16pwMqfTIMOhxGvjSJ8sGSWSrHrh27YlvW5b0T1xxmH8fL5q/b9AxnnlZ
g0cvbprunskuc0UK1b8H2vE0WFPXoTV5QmyKb3XZoXyW6BEPNYyal/uKAH8IxuQO
9y+bJa1TuAsaOEvIhDLDN8DCavwP+Wd306JrRm3dj708gDxr//i8aGg0WLEhKtof
1RAmqw/K12J2C/9rF/8isoE2UO8DEf/s19A4ghtrQj1zho4ZY4wUBZ/MNwHhboU8
TXPRXYVSI4n4N40hpdzVm6Mi+URiggLtYwwS8tZlaky1/1cLz7aG7INo1ECSaSOS
rqllFkhgOWH+Tmxkt3OaODrAV263So7RbDlpMmjl4GJxj6dpygM5yEhAoM8ARWxg
0KE1m1XkRqZeDolJ3fKjFhVOzqMSHvbJT58PzD35AbiDXc/95kdcM+dCS/BGPqSs
wSVTm7QIjsY7v5Pz6G/5kCKPi14xsTDZktSz4p/gOU53/+Tio6P+vN5ZCyFwfa43
9dkVv7QnpCJQLy8jlc07nvBB5xtEcPFe7yab/2qZdcc1LPQfRdUU8KUMzMTygNyb
1kW0aTQtKbnu2Af/JfjjVlVMN5WNBRiNVYhT430HVDRuoyShzoO6CDR+6V/AX8ze
gT+8VKGb+5gU4iUyS4sz
=wgyc
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-15 Thread Andrew Savchenko
On Wed, 15 Jun 2016 05:15:03 +0200 Michał Górny wrote:
> On Wed, 15 Jun 2016 00:12:40 +0200
> "Andreas K. Huettel"  wrote:
> 
> > Am Dienstag, 14. Juni 2016, 02:32:41 schrieb Peter Stuge:
> > 
> > > 
> > > I would personally be super happy to have my overlay hosted at Gentoo -
> > >   
> > 
> > So what precisely is keeping you from that?
> > 
> > https://wiki.gentoo.org/wiki/Project:Overlays/Overlays_guide
> 
> Don't encourage people to create more work for me when we have GitHub!

Github is propietary and I don't see why someone have a right to
enforce its usage on people.

If someone want to use github — go ahead, but if not — in no way
you can force people to do that (e.g. by refusing to create on
overlay, or review patch on bugzilla, or whatever).

Best regards,
Andrew Savchenko


pgpyGPht5mtOG.pgp
Description: PGP signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-15 Thread Tobias Klausmann
Hi! 

On Tue, 14 Jun 2016, Rich Freeman wrote:
> 1.  Developers wouldn't have access to all the ebuilds in the curated
> repositories.  They would only have access to the ones they contribute
> to.
> 1a.  You could accept a contributor into a small project and not have
> to give them access to the toolchain/etc.  Of course, they're still
> messing with curated packages so you don't want just anybody in there.
> 2.  Exherbo at least requires peer review for all commits I believe.
> So, even if you're committing to your "own" overlay you're still going
> to need review if your overlay is a curated one.
> 3.  Just as with Gentoo if something is curated you can generally
> count on it to follow QA, and if it is in a non-official overlay then
> it is anything go and it is probably not to rely too heavily on things
> like sane version numbering, deps that don't just disappear, etc.
> 4.  If somebody really does need to make a "tree-wide" change they're
> going to need access to a bazillion repos or they'll need to ask
> everybody else to commit it for them.
> 4a.  Conversely, people who probably shouldn't be making "tree-wide"
> changes won't.
> 5.  To the extent that repos contain closely-related packages you can
> probably make much more effective use of git branching and so on.  You
> would still be limited by any dependency relationships outside the
> repo.

6. Arch teams would have access to any and all repos that they do
testing on -or- AT work woulkd have to be split between testing
and doing the actual commits.

I very much would not like the second option: it's more
coordination overhead, more space for miscommunication and
increases delays from request to commit (which can be very bad in
the case of security bugs).

Just my CHF0.021 (adjusted for inflation),
Tboas

-- 
printk("NULL POINTER IDIOT\n");
linux-2.6.6/drivers/media/dvb/dvb-core/dvb_filter.c



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-14 Thread Michał Górny
On Wed, 15 Jun 2016 00:12:40 +0200
"Andreas K. Huettel"  wrote:

> Am Dienstag, 14. Juni 2016, 02:32:41 schrieb Peter Stuge:
> 
> > 
> > I would personally be super happy to have my overlay hosted at Gentoo -
> >   
> 
> So what precisely is keeping you from that?
> 
> https://wiki.gentoo.org/wiki/Project:Overlays/Overlays_guide

Don't encourage people to create more work for me when we have GitHub!

-- 
Best regards,
Michał Górny



pgpV5CRNxuNDa.pgp
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-14 Thread Rich Freeman
On Tue, Jun 14, 2016 at 6:30 PM, Ciaran McCreesh
 wrote:
> On Wed, 15 Jun 2016 00:21:45 +0200
> "Andreas K. Huettel"  wrote:
>> Am Montag, 13. Juni 2016, 09:50:15 schrieb Alexander Berntsen:
>> > > I still think you're underestimating the need for centralization.
>> > > What you call a "core/base" package is probably going to end up
>> > > being anything listed in a dependency.  That is a LOT of packages,
>> > > actually - we're not just talking about libc and zlib.
>> >
>> > It's not a lot compared to how many we have today.
>>
>> Please do me a favor and emerge @system on a fresh stage
>> installation, with USE=kde ...
>>
>> ... So,
>>
>> * does KDE go into the curated repos? or
>> * will the useflag functionality be discontinued?
>
> * Your package mangler tells you you need some packages which can
> be found in the ::kde repository if you have that flag enabled, and
> suggests you either install repository/kde or disable that USE flag so
> that it can continue.
>

Ciaran can certainly correct me if I've missed anything, but the
concept here is that the curated packages are distributed across many
repositories.  So, kde would have a repository.  It would still follow
QA/etc and have controlled access, so it wouldn't be like a typical
overlay in the Gentoo sense.

What Gentoo would currently put in a project/herd/etc would go into
its own repository under this kind of model.

So, comparing some of the features of this model vs what we do today:
1.  Developers wouldn't have access to all the ebuilds in the curated
repositories.  They would only have access to the ones they contribute
to.
1a.  You could accept a contributor into a small project and not have
to give them access to the toolchain/etc.  Of course, they're still
messing with curated packages so you don't want just anybody in there.
2.  Exherbo at least requires peer review for all commits I believe.
So, even if you're committing to your "own" overlay you're still going
to need review if your overlay is a curated one.
3.  Just as with Gentoo if something is curated you can generally
count on it to follow QA, and if it is in a non-official overlay then
it is anything go and it is probably not to rely too heavily on things
like sane version numbering, deps that don't just disappear, etc.
4.  If somebody really does need to make a "tree-wide" change they're
going to need access to a bazillion repos or they'll need to ask
everybody else to commit it for them.
4a.  Conversely, people who probably shouldn't be making "tree-wide"
changes won't.
5.  To the extent that repos contain closely-related packages you can
probably make much more effective use of git branching and so on.  You
would still be limited by any dependency relationships outside the
repo.

I think the key message here is that a distributed model isn't some
kind of panacea.  It doesn't mean that any random stranger can just
open up a repo and start contributing packages that others can build
on.  Sure, they can create a repo just as somebody can create an
overlay, but users will not be able to safely rely on these packages
and if you build all kinds of dependency relationships this way you're
building on quicksand.

Likewise, many of the benefits of having a peer-review system can be
had whether or not the repository is distributed.  Those are really
orthogonal attributes.

I think there are a lot of benefits from an Exherbo-like approach, but
I think early in this thread there was a sense that this would just
open up the bazaar and all these contributors would come out of the
woodwork.

Now, what it can give you is distributed governance.  Maybe the KDE
team achieves good Gentoo QA.  We don't know how they do it.  They
don't do it the way everybody else does it.  But, somehow they get the
job done.  So, why not let the KDE team manage their own contributors
who can operate in their sandbox without having to go through some
Gentoo-wide developer process?  I don't think this is what Exherbo
actually is doing, but it theoretically is possible.  However, it
would depend on a KDE team that does in fact maintain good QA.  The
downside to distributing governance is that you may get inconsistent
quality.  Again, I don't think this is the Exherbo model.

So, a distributed model is different, and has some pros and cons.  It
isn't a panacea.

--
Rich

-- 
Rich



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-14 Thread Ciaran McCreesh
On Wed, 15 Jun 2016 00:21:45 +0200
"Andreas K. Huettel"  wrote:
> Am Montag, 13. Juni 2016, 09:50:15 schrieb Alexander Berntsen:
> > > I still think you're underestimating the need for centralization.
> > > What you call a "core/base" package is probably going to end up
> > > being anything listed in a dependency.  That is a LOT of packages,
> > > actually - we're not just talking about libc and zlib.  
> > 
> > It's not a lot compared to how many we have today.  
> 
> Please do me a favor and emerge @system on a fresh stage
> installation, with USE=kde ...
> 
> ... So, 
> 
> * does KDE go into the curated repos? or
> * will the useflag functionality be discontinued?

* Your package mangler tells you you need some packages which can
be found in the ::kde repository if you have that flag enabled, and
suggests you either install repository/kde or disable that USE flag so
that it can continue.

-- 
Ciaran McCreesh



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-14 Thread Andreas K. Huettel
Am Montag, 13. Juni 2016, 09:50:15 schrieb Alexander Berntsen:
> 
> > I still think you're underestimating the need for centralization.
> > What you call a "core/base" package is probably going to end up
> > being anything listed in a dependency.  That is a LOT of packages,
> > actually - we're not just talking about libc and zlib.
> 
> It's not a lot compared to how many we have today.

Please do me a favor and emerge @system on a fresh stage installation, with 
USE=kde ...

... So, 

* does KDE go into the curated repos? or
* will the useflag functionality be discontinued?

-- 

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




Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-14 Thread Andreas K. Huettel
Am Dienstag, 14. Juni 2016, 02:32:41 schrieb Peter Stuge:

> 
> I would personally be super happy to have my overlay hosted at Gentoo -
> 

So what precisely is keeping you from that?

https://wiki.gentoo.org/wiki/Project:Overlays/Overlays_guide

-- 

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




Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-14 Thread james

On 06/14/2016 01:48 AM, Daniel Campbell wrote:

On 06/13/2016 11:24 PM, Alexander Berntsen wrote:

In addition to what Peter Stuge (correctly) identifies as needing to
change, there also needs to be a modularisation of Gentoo-curated
package repositories.


What sort of modularization are you talking about? Would we suggest
something like GNOME, KDE, XFCE, Mate, Cinnamon, et al getting their own
overlays? dev-lang/foo getting its own overlay, etc?

To some degree, that will simplify some people's trees and quicken
emerge, but then it just pushes maintainance to a part that most users
don't really mess with much (repos.conf)

You can achieve mostly the same end via your own git repo at /usr/local/
and pulling overlays in via either layman or git submodules, for
overlays that aren't already in layman.

zugaina and layman are great tools that could use a bit more polish, and
could be either adopted or assisted as an official part of the handbook.

The issue here is similar to the issue Ubuntu and Debian face with PPAs.
There's no guarantee on their quality, and if an overlay becomes popular
then there may be pressure put on the Gentoo tree to adopt whatever the
popular overlay has. This could be detrimental *or* beneficial,
depending on what the changes are.

tldr modularization sounds good on paper but I don't see it being
beneficial in the long run. I would be happy with the requirements to
get into layman being somewhat relaxed and/or halfway automated so users
can host anywhere they want, get listed in layman as "not vetted" but
still available, and then some sort of process or mechanism to go from
"unvetted" to "vetted", and if they're lucky, "official". It would
require less shuffling of resources, as well.



For starters, we had a thread recently on gentoo user about if there is 
a similar tool as portageq to identify a non-dev and the related 
packages they support. Listing by repo is all there is and it is scant. 
So maybe metadata.xml or overlays and such is a good start? What if a 
non-dev is primary to more that one repo? His own,  a group of friends 
and one at work? I'd suggest expanding this to folks with the proxy 
designation for now, and work out how these tools should work, before 
attempting to spread tools to a myriad of outside (no G-QA) ebuilds, 
regardless of where they are housed. CoreOS has many ebuilds too and 
it's only a matter of discovery before those CoreOS ebuilds start to 
become interesting to the gentoo communities. Ebuilds are becoming 
universally popular. Other distro folks, who can read and follow basic 
shell, can and do often use them as a roadmap to installing software.


In fact there are few tools to list packages outside the tree by 
category, scope, venue, maintainer etc etc. I'd speculate that the 
development of those tools, specific to itemization and characterization 
of ebuilds outside of the formal portage tree,
are what's really most needed (along with robust documentation). Along 
with a universal metadata.xml  effort. Universal metadata.xml  for all 
ebuilds that included  checksums/hashes/keys/etc could allow for 
packaged up download files (tar_balls, zipped, compresses etc) to be 
identified and characterized and could be auto interrogated with 
extensions to wget, git, ftp and a host of other protocols employed to 
download source files.


James





Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-14 Thread Daniel Campbell
On 06/13/2016 11:24 PM, Alexander Berntsen wrote:
> In addition to what Peter Stuge (correctly) identifies as needing to
> change, there also needs to be a modularisation of Gentoo-curated
> package repositories.
> 
What sort of modularization are you talking about? Would we suggest
something like GNOME, KDE, XFCE, Mate, Cinnamon, et al getting their own
overlays? dev-lang/foo getting its own overlay, etc?

To some degree, that will simplify some people's trees and quicken
emerge, but then it just pushes maintainance to a part that most users
don't really mess with much (repos.conf)

You can achieve mostly the same end via your own git repo at /usr/local/
and pulling overlays in via either layman or git submodules, for
overlays that aren't already in layman.

zugaina and layman are great tools that could use a bit more polish, and
could be either adopted or assisted as an official part of the handbook.

The issue here is similar to the issue Ubuntu and Debian face with PPAs.
There's no guarantee on their quality, and if an overlay becomes popular
then there may be pressure put on the Gentoo tree to adopt whatever the
popular overlay has. This could be detrimental *or* beneficial,
depending on what the changes are.

tldr modularization sounds good on paper but I don't see it being
beneficial in the long run. I would be happy with the requirements to
get into layman being somewhat relaxed and/or halfway automated so users
can host anywhere they want, get listed in layman as "not vetted" but
still available, and then some sort of process or mechanism to go from
"unvetted" to "vetted", and if they're lucky, "official". It would
require less shuffling of resources, as well.
-- 
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: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-14 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

In addition to what Peter Stuge (correctly) identifies as needing to
change, there also needs to be a modularisation of Gentoo-curated
package repositories.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXX6MTAAoJENQqWdRUGk8BnikQANsSzr8iTjcpiZUiS9sfDakI
H6iN94t9aVmkmggQl4nCKD3HrsLo+8KJ3WRrgQbCiPAZp8KCRkRqinz5tMRTb1QX
kAVHid+iEjcHeJK/XqmYkx+qWNn8A5l27gqcImZ040jY9ZAd1km9H/IQvswfd8mo
wJww7RifVJxOPg8bqvyHQJEMwFbigrAcdfDQnGzBvnJOQpChSMkl8boJlFxnLgqz
xiQzZX2DyCl3BpMrNh4BiV/wwrJAjT/HRwbVSRCaaakFmZxEgebMP0B0as40MsMy
TI+xr/+jM8o5MWL1b6FDAShrtNvuUWkk/wl6wGoz/D2EFkx7BSbwv0dFCgS7hLfc
awAcwYWGWdnJqme6FGIROKHh7NP6L1FB0LG+uvKenbsvEsf9PVX1CUtaWjqAAERJ
pFe9Jvf44is6NSdXohUOFLJKr24pXthzHdaJmrO1Ps0rH11HiYccdIBVFrXKU+Ja
mgg7ExKt2yWatWdig96NO8FHAPbyCZZ/ig7jq7VhFxxI6m1bIPpfZCyOMLK6l7Df
wizcNtMzlD1OSOtSJ/YhD+q5dzAjK2YjB3ZY6ge6uN5LC4XJqfVUeLoDmsCiPHnn
x2dAZ6UT5k7lhnGi3cuOe9uZUuGtEj+9VE7r4pd3YowNE/svpp0G4xBXZ4aHj9am
6s0ZRNij52CqzaDxhLqI
=yJ+9
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-13 Thread Peter Stuge
Consus wrote:
> This is how overlays work right now. What are suggesting to change?

Technically not a lot in terms of how packages get installed.

It's more about offering support and/or visibility for overlays.

So technically it's about hosting user repos, making the ebuilds
within easily discoverable, and simplifying their consumption.

I would personally be super happy to have my overlay hosted at Gentoo -
not because I can't host it myself - but because that would be a lovely
recognition and a great way to get more visibility and thus more help
with the packages that I've made more or less serious attempts at
packaging.

Usually they are less seriuos attemps, otherwise I would proxymaint
them, but they are good enough for me, so maybe for someone else as
well, even though they may be totally incomplete e.g. as far as USE
flags go.

(This is true for ebuilds in gentoo too, but I would never want my
name on something like that for the actual tree; I want to deliver
higher quality there, and until I have time to do so the half-assed
ebuilds stay in my overlay. They wouldn't get included anyway, and
they shouldn't.)


//Peter



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-13 Thread Consus
On 09:55 Mon 13 Jun, Alexander Berntsen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 10/06/16 17:32, Ian Stakenvicius wrote:
> > On 10/06/16 03:53 AM, Alexander Berntsen wrote:
> >> ... Their repositories would likely be amalgamations of our
> >> curated and reviewed repositories ...
> > Could you elaborate on what you mean by this?  When I read it, it 
> > sounds like you're saying people will copy ebuilds/packages from
> > the core/reviewed repositories into their own, just to have them
> > to satisfy deps or whatever..
> I expect that at least80% of users will just use the standard set of
> repositories (defined by us), and never venture outside of them. The
> other 20% however might be more adventurous, and might end up
> contributing back ebuilds.

This is how overlays work right now. What are suggesting to change?



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-13 Thread konsolebox
On Mon, Jun 13, 2016 at 2:15 AM, james  wrote:
> and start coding your dream.

I'm not that enthusiastic.  It's up to the Gentoo masters if they
would find it helpful to the community or not.

> But the proven pathways, should be left
> intact and receive further documentation, as they are working great.
> Stop blaming others or saying that the existing pathways are discouraging,

I don't think that's exactly the case, but I gave my opinion, whether
I blame or not, or whether the existing pathways are good as they are
or not, and would stand for the next coming years.

> because they are not. Go forth and code. A large ebuild base is your best
> alley. Just stop implying that other things have to change in your favor for
> your ideas to have a chance.  What currently exists is irrelevant to proving
> your ideas.

I'm merely giving ideas and joining the discussion, which is enough
for its purpose.  Proving it is another thing.

Besides with current Gentoo community philosophy, it may not be worth
it, and is unlikely to happen.  Most people doubt innovate ideas
before actually trying to help figure out how to make it work.  I've
seen a lot of discussions like this and nothing has really happened.
I'm not really expecting anything to come out out of it.  It's not
worth the risk to waste my time and effort.  And don't tell me nothing
happened because the one who made the suggestions did nothing.  The
people in control need to do their part as well.

And people always say, "This is an open-source project.  Nothing's
stopping you from proving it.  (Go ahead, take the risk.)".  Yeah
right.

If people actually take my ideas seriously, or do anything similar to
it, then I might actually decide to help (in some ways besides coding
because I'm not in the mood to take another serious project yet, and I
also don't want to take a role with responsibility, or anything that
could leave people hanging; maybe I could be an independent beta
tester, check some issues from time to time; give some suggestions
when I want to; just not anything with explicit collaboration), but
whether I help or not, I already did my part.

I've said enough for this thread, and things are not becoming
fruitful, as expected.  I'm out.

-- 
konsolebox



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-13 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 13/06/16 10:09, M. J. Everitt wrote:
> Excuse me .. and this thread emerged from deprecating the EXACT 
> thing you are suggesting!?
I don't know what you are talking about.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXXmq3AAoJENQqWdRUGk8BoWIP/0B0aOlBY+7pdYqHs9LYxs3/
xveRMG2L/Sej5364vqNsy2NDeL2VtSNzmOSnO886Uy5hl+RzM7LDdofTODlCX5Kh
FPSDdTEbwoX68boEmkEpKeUPtKabGluxuYquoovsa6WVNJXDPuamfD0CBZUgMMv7
ceT45OsB4kaA3+7BC358fbsXRv1D+z4kVKwqa5gGNAJsFaoFzMx7hcUg8buVjaBJ
UFRcjeg/B1zc0mJYMm5vjtEsDbdXJHQyFv5VaV12PfaBPmZkfffnJtEC0aC3iNCD
tAg9dnnk+fUFTY0+atUPhPJvA3FccN3yBENgDDUBciP3kvKnrEFfFIFGZpLPu1Fe
D0T4dWW7buJjWh6aLhIttZwPTs6XzVaz4R8mhjNgnXpvB8EOzCY2Sw9gLlpUhNh1
u0GqYuFHW35X/yn/HXdIcJvh8eS6oWg/awrJOOQAq7KpmhHqvO0uRm2YNRaFkzaJ
zuBj0ecQaRy7a7Zt3rEUfTR7mqAuSCjKMmDHAW1RWDYnVRyCxwluEtIpahiIyO4D
BwQyYKVUSmS89aaDB5abkKDXd4Qy5ph3yy9wV27EDaTzzPmmdrI6VAvdM61att0M
lmbrEwirut7yeefNZrnjavSsnllQDtWsE7I4ePbmtUWGoGnE52IHiK37ucgT0Fb1
6/vv1MOmzcg+7y5ys6Sp
=jL2z
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-13 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 13/06/16 09:54, M. J. Everitt wrote:
> I really think someone needs to do a bit of portageq and see what 
> the Tree *actually* contains 
> 
> Likewise .. a trek through bugzilla would also be enlightening for 
> those not familiar ...
> 
> Once you've seen those two .. perhaps you'd be a little more 
> qualified to make generalised statements about the state of 
> Gentoo.
> 
> Just sayin' ...

/dev/null is a better address for vacuous emails.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXXmpwAAoJENQqWdRUGk8BPysQAJ2bN951w8vxQwxT5oZD+Ebj
nyE+lUHSVfS3Ewne71g+x0hzkExON8Vc9zWbBhBcQj8gw7FObuMvcsxEGUk6qIZ8
WEMpL7GPHapiKER/PWGgiRy4Ji3xj/reNDvYbCo1/+LpGV9LhHE86dXgLlogYIZP
IorkShGpOL1+90Vez35Zf+wNfOJPekxFun0W3r+O4TGvWZI33ZxutSRRqX6esQFd
rW/CTOQj79aoR9G50OMYGVQ9+qW8NR57Rc9hvVfipP6W9YAGOCkkSVoubRCrfExk
wob1PnUbwzfDUYrpEKhsb02c/5AERLjVwI6VSHR4VzPnSn8AyKaz2c8o5+jeHQdu
aEtTFrXgIavykLzbr4pqJkfvwnPqdV6Vetly32GoqoSc8XBItdW4rthqpGM5nnCb
7wNYjoknUXj3UHT/V3eUiEuwQkUYKWdvp1fcYnQawssUJZvrTMCKamvzeMxjzl1g
4sjmox655fuUxl2Yl4lo1oYPgwEhjajLsTitdeuRGGqrqmQMULrWUcAgqGYw/NOM
EW8gueVpp+1DT7vplom5+BX5ibm9U7Tp5EWYty2Boh4L51oFtGo6xvYwC+emfHOj
wLAK4sOl7dNqn+33s24eXXQnSt9eMs37rrGrGX2xMduorwhKvyKOE4pxrXW+hQWU
wInti0Q/QYPkfQlAl7BM
=2GiN
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-13 Thread M. J. Everitt
On 13/06/16 09:04, Alexander Berntsen wrote:
> On 11/06/16 09:00, Michał Górny wrote:
> > If you are not going to maintain your contribution, we can't
> > guarantee it will be accepted. I'm certainly not interested in
> > having to worry about 20 more maintainer-needed packages next month
> > because someone contributed an ebuild that seemed good enough.
> This is a good point. Contributions that no devs are willing to
> maintain would not make it into the curated and reviewed repositories
> I am referring to.
>
> As an aside, perhaps we should start featuring third-party overlays
> more prominently, as this is where these ebuilds belong.

Excuse me .. and this thread emerged from deprecating the EXACT thing
you are suggesting!?



signature.asc
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-13 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/06/16 09:00, Michał Górny wrote:
> If you are not going to maintain your contribution, we can't
> guarantee it will be accepted. I'm certainly not interested in
> having to worry about 20 more maintainer-needed packages next month
> because someone contributed an ebuild that seemed good enough.
This is a good point. Contributions that no devs are willing to
maintain would not make it into the curated and reviewed repositories
I am referring to.

As an aside, perhaps we should start featuring third-party overlays
more prominently, as this is where these ebuilds belong.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXXmkOAAoJENQqWdRUGk8BXegQAOCcqOmElM35VIwC0/HoJedT
XMoB19UWurBOtTqPS2J+Fffh0if9E6ULJIIAga8Nu16W6WUaizxagxeUdccAp0W0
frI+EcxCRBUN5xqc1Wd1JCUHXm4U2rK97iJ1oQQHLoV2UvbSDrueKCEKP+/egiJk
1qFTKbRBG1q5fZl4gof/yAPHj05xuyNRD2RJ9DuK/a/srgrBO7X9LFoQG2WrgMnJ
0mtEO4zgLTxPDd+FLX8oYhNx7i6SJxZqy11bqgUpEXcDjqxBAwo1RuVuaIQaJUMt
/ycj40M+fRXoab+NDv3ZDtOhoRVu5F60DNQhoY4sSzC1tKUSc3wo2ne2Lda91ROo
Ms0tTPNGyiXtZIXARssN2vRWp3rTMcmyuMRT9/QMRR5Wcr3qJ/t79OmnVeKj0YpL
rLmRihtCCkIlo/ZvU9q5SCZ/8zAnur8h6ymDT56GnyjaMQH4zxrdINVJZf7Kp6bM
Y9XLHrv7i8RwaAKwCn8NZ4rRoNBM92smkPOQ7rcfkZNr1aTqRw0B9GaWI37cD0L5
3TF/6f3U7LTxNWeVwYuOKmBn9fyz61N6WAw2RqzRMId+xMYHUmvtEa8zYN4DFXMs
jyZ0AXtsMInHZ5xWf6RhMYcSo82OtqNVmuU7oGHLgB4/upQJdpYyRGSWv/joLZ5O
N5BnCa2rBhE50MC2UuA9
=H8nA
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-13 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/06/16 18:18, Rich Freeman wrote:
> And my understanding again for Exherbo
And it is wrong again, according to an Exherbo user I talked to.
Please get your Exherbo developer to participate directly, because I
think you are having some trouble communicating their statements.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXXmeDAAoJENQqWdRUGk8BPb4QAORn+yubgoo9BPz4/VYe2cLM
Z5JRNczsR3SzIvt+YrL6R6O9kptsNKYWvMwL67atB/UgJ8uEMY2Zi6oF6PhZQXSW
9d+k+rbyQM1CixQn553vWZRkiMWozKVXFechr5yubTxRVWq3bt84A0HFoz3Tmrh5
0WRUrTYsd9KS+6a1TZogvaxedpa+za2cB/syOAxXzqZtGZWDsiB2+fLvO+Den/wo
AmNSOsG1bKb43DfdY9WtCdvC0tfSGVyh1x2A/kVSgzFe6E67XlgTxlr0E4u/XzFP
rBVAXiuOuRes4IWKJ3oHuz+II5+6qfIgUvdu72uRL0J59+jMmXaYBIS1M9ityN8O
BfY+Y1aAutXTk+Rp0zOTzRCJH10y1c+WvkBZdhypGkV3hbxfGG5wV2GBgZlq+3xK
ecrQQUPMVUZZIm8F/64SC3UQeD79qzmr2Fz0IipPKXTnazis6vRU7B7mkb0HeOue
hheacDK929gGQNU0MZuE/ZSTS1fxcMzbp0oViS1CmQ1RzCbQB/uzl1zNdTq6hPkf
bm1Lvw6ofV6HbDBnDjO7leloIUnXx8Q+hdhbHniLFDrkcvnJR29M6hpAudWgGO+a
M0K56vjQqZI6kyAr+yjxCZT65JR8PubPfFmjUDRFFCpIlY1E2fx1/KQpoKkyLIYc
NWEdAwvtfesH8OjL+lq6
=yI5J
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-13 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/06/16 17:32, Ian Stakenvicius wrote:
> On 10/06/16 03:53 AM, Alexander Berntsen wrote:
>> ... Their repositories would likely be amalgamations of our
>> curated and reviewed repositories ...
> Could you elaborate on what you mean by this?  When I read it, it 
> sounds like you're saying people will copy ebuilds/packages from
> the core/reviewed repositories into their own, just to have them
> to satisfy deps or whatever..
I expect that at least80% of users will just use the standard set of
repositories (defined by us), and never venture outside of them. The
other 20% however might be more adventurous, and might end up
contributing back ebuilds.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXXmb1AAoJENQqWdRUGk8BXPkQAMUdunnkdLKfhsnGwxppazUV
czcQk4pgaytWGuDtiG/GoH+RJZpU1zRrsc9TQkZwh+I6iwJJ8heID50TGED4Axbw
rmSCxOTd0Ng4mRhUYDyhG/Jmjzb/ciSkItINdZ2WuBL/M8aMVeGGSTddwZayUk4W
lIpIs9MZJfJzGaCw0D2DeIX13D7nSPvWQKxAEOof/hrc8Td6sGMuCxWRr0lIpwMB
UlrkYnmyydambyXxISGFlThB2twxLfgvcl+rbQuKaDxJxO+nyPaKaWMng8R5r+tr
9jJXJuE+VHRoWe6Kb2ixP650qqWORPXmRZ6u1b7vazIbvhxF+2vmfTKuR24SQjZe
t8P01pGbnAg/kT+mYM1WvVsTsNt6FoiHiVaJHajP96paXyfKPRpgvTWpi7Keg8n9
NjL7O8bQlpJc/muMlJ18+POqL1cWZyjG0sJnJ+nEKwkoHX+6dvU/h9TJKlixWWKi
W/wo7fNhNAMvWTtCT7U4CThcIZkcDnHrFm4R19UI8gsw+ncsTRKza3fI8mtRCeXE
CCjtWN+jDlSo2DTa54MP4ccc6dGNRoIE9rhNAyFphDYfJ7HIYu0bJb80I6Po3TjI
15qEsciJpPxvvZnpG16cGVitULY3EXMpVZAXG08s3OIuwDcYKi4tXwSqSMXrJXve
/wtvIrpZmYWueGX6h8Wa
=eGhD
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-13 Thread M. J. Everitt
On 13/06/16 08:50, Alexander Berntsen wrote:
>
> > I still think you're underestimating the need for centralization.
> > What you call a "core/base" package is probably going to end up
> > being anything listed in a dependency.  That is a LOT of packages,
> > actually - we're not just talking about libc and zlib.
> It's not a lot compared to how many we have today.

I really think someone needs to do a bit of portageq and see what the
Tree *actually* contains 

Likewise .. a trek through bugzilla would also be enlightening for those
not familiar ...

Once you've seen those two .. perhaps you'd be a little more qualified
to make generalised statements about the state of Gentoo.

Just sayin' ...



signature.asc
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-13 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/06/16 12:38, Rich Freeman wrote:
> So, I was chatting with an Exherbo dev.  Their model isn't quite 
> what your earlier emails seemed to suggest (at least as I read
> it).
You should get them to reply to this thread, because...

> As I understand it the Exherbo way
Having spoken with an Exherbo developer (Ciaran, who's replied here),
and an Exherbo user, I don't think you understand "the Exherbo way".

> The impression that I got from your earlier emails is that you're 
> advocating a highly decentralized bottom-up system, where everybody
>  just publishes their packages and people borrow from each other's
>  work, and the behavior of the overall distro is fairly emergent.
I am advocating a *modular* system more so than a decentralised system.

> You suggested at one point that the need for what we call
> developers could almost go away.
I did not.

> Now you're talking about having centralized core/base packages,
> which obviously necessitates developers.  Maybe your concept is
> that the core/base packages are a very small subset of what we have
> today.
Yes! So you *do* get it.

> I still think you're underestimating the need for centralization. 
> What you call a "core/base" package is probably going to end up 
> being anything listed in a dependency.  That is a LOT of packages, 
> actually - we're not just talking about libc and zlib.
It's not a lot compared to how many we have today.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXXmW2AAoJENQqWdRUGk8BmREQAOMeQUFKLgF8sApjJB/SrbV9
eUg9PQ+vHyRXEEGEKLvOZ3+Qv92+Mt4WMz+8kHft5Aa5jghubxsSdyz6rKhizI8A
ee6tgTIPcSAE5End+6FtYMfzlseKfEcX0HDCvXewvUM/RzTFnfl3bpL5i1rXGBRF
Q7y/yM6AjljeHkaQvyKu4byhBtOWgo76Lw84jTfmcamaoTzv82w+J8aL0IChTKd6
8dKYrz6emkEuNf5oILl+0Z9e18ypusChr5xWUMsFPrEWW9/umFc0Cz7xqbLA/xx1
9nd85WJGIYwkjrAuCoxK/wo4+6hZu9QVHb1LEpBXUhYmaFRV7pxc2kjN3f7GzgYn
m+tlB/dN0Wq5+B0FeG64asngEKSdSuy3J7+o+mOvPS4Sz1JDH4mgPZ0ybaypziVG
OIMFUTwVvMaTaraKzJhI0OjKVCdBCKlEJwzBEYa2t1iyroPcdAABILkly0ZuQ6K6
BtLjqkC1TX9J+kyfLq3gqmSXujSEuaTZ5d7UTXfCUMqybTVX35P7Cpo6M4kbt3vg
QRHjLhQP0A1M++YIhX+H0UGcKsjDzQgt2dzGfc70FIJJrElG2DtEwmMqN3n5DAi7
H4OcxeGJZ1C9RqvyMMvgWO+6UcCQaJbHaFnQ1UzqeTvueNd4iP/Ma2JaMN8PRWoZ
fRCD0dZZ5XKPSlbIiT3H
=Rwas
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-13 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/06/16 11:33, Consus wrote:
> That's great, but how are you gonna prevent nodejs-like
> clusterfuck[?]
By not being nodejs. The core repos are curated and reviewed.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXXmPbAAoJENQqWdRUGk8BhOcQAJ/8FeCJ1QBbHwL3JGLaJ1SM
7MAcOtjXTjCaTBsOSLIuW0t2yNoLV3ScQM4lYk4G1s3fGOnsjJYp+Sv1sjbssIRj
gG3ABVZmc4ecqeBQfRLXi0djKGl06wtx0p14OugH42A2CccPx5BSFpzHGl8hgAxc
W/Zua6yklDdNKPaHZMtQLysJ+aApjOcAL5ehRhB96sj/lNCOfKbPrsqNsqiQdxy3
4phKorOoZUMJEc70AAIPtLpc8FSw8ZX1aHApWMEH2bQ4J3AomhPeJsjhCRBfFiHO
H33njRQ78cfsaGmRspJ8PGWI1IdGJMCT89NEOKkBRwvyKWaK0wFG+joqZ2HN1x6P
A3jSRyuyCfUDzJPJHjrNGE5mmfgWZJewPUUFaMaKtWyV5gzm9bREwDsp9RUrc6b3
rpQLRcIDkf6s08s4B9wMfrhuCXHwNZadu1Zm3v1mAWZZ9s4vxbQ+79m/ZbpPV4iK
KOVmFC8rKBCVkJMs5QaoQyf5w0nxcwND9YlnNgtw5Vo132Pl+bNNocZA9d6sk69I
QuQIp/r2cRK4QdRb81KcW2xS9TJHGzFwCnduBZ565yt542cDIUcPOi7VsrBGGR9o
1tteCDHBRJFaL5oOWr1ENRZIpdCnZIcNt8oJjfRih/FWw7Y9trxzyzJjSwEJ3zfs
jpP7bNjtMTXzQCcnug2F
=sHbe
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-12 Thread james

On 06/12/2016 01:10 AM, konsolebox wrote:

On Sat, Jun 11, 2016 at 3:00 PM, Michał Górny  wrote:

On Sat, 11 Jun 2016 11:09:39 +0800
konsolebox  wrote:


On Wed, Jun 8, 2016 at 11:53 PM, james  wrote:

The grandiose-ness you propose should only come upon graduating from proxy 
school, imho.
user-->strong-users-->proxy-->dev pathway.


Pedantic, bureaucratic, procedure-oriented, monolithic, restrictive.
Too conservative.

What matters is the contribution, and the result.  If you don't like
how a user makes a contribution, don't accept the pull request, or
don't merge his package.  Simple.  If you think that could turn out to
be just a waste of time for them, help them correct their issues; add
some documentations to enlighten them and give warnings about wrong
practices so they don't blame anyone, and so they can decide whether
they would want to contribute or not given the rules presented; but,
_don't_ make the steps mandatory.  Don't make contributions
restrictive.


You're contradicting yourself. How can improving/review of pull request
be non-mandatory, if otherwise we are to reject it? Of course, it all
depends on how you define 'mandatory'. It's not like anybody forces you
to do something, you know.


No, you just misinterpret. You can review pull requests.  You can
reject stuff, but don't reject them just because some laid-out steps
in the documentation has not been followed.  Some may not be
completely necessary.  I'm implying that these "academic" steps may
not be completely helpful at all times, and making us follow these
things only make making a contribution stiff and restrictive.

I'm mainly referring to the strict user-->strong-users-->proxy-->dev
pathway that James is encouraging, where it seems like you have to
become a proxy developer first (or maybe, prove yourself first; gain
first some trust), before you are acknowledged to be able to
contribute in a manner that Alexander Berntsen has been suggesting.


Wrong and misleading. I am proposing but one pathway. Come to find out, 
others have already started a mailing list for that (proxy) pathway. 
Furthermore, iff a fantastic programmer from Debian was to contact the 
Gentoo staff, someone of known caliber and accomplishments, and wanted 
to become a Gentoo dev, that person would be fast tracked, very similar 
to a returning gentoo dev. Tom Gall, a very accomplish ARM coder, 
recently returned for a while. He was quickly re-established as a gentoo 
dev, and is a recognized ARM innovator. He has since gone silent and 
returned to a more formal position within Arm development. I can think 
of dozens more. Those are different pathways, I have no problem with 
that fact and I'm quite happy that gentoo has multiple pathways to 
dev-status.



Skills go a long way, particularly if you are established in the FOSS 
communities. So there are multiple pathways and new ones, such as your 
can be proposed and proven up. Just go do the work and stop whining.


Then there are the multitude of ordinary coders or coder-wannabes, that 
do need the user-->strong-user-->proxy--> dev pathway, well defined
and well documented. Nothing in what I have said excludes other 
pathways. Nothing.


I did point out that /usr/local/portage on your own system, or github do 
exist and provide yet another pathway to dev status, when one can 
produce a body of work and answer those quizzes... Be bold!




These stuff imply unnecessary old-fashioned restrictions that aren't
"necessarily" helpful to security.  It doesn't help encourage users to
become active.


Wrong again. If you have such a brilliant idea, let it stand on it's own
merits, let it be a 'back door' for interlopers on your system. I have 
too many validated experiences with gentoo that cause me to keep a
conservative, trust the gentoo security devs, position  rather than to 
allow random ebuilds on my systems, be they core packages or application 
specific. But, this does not preclude you, and your pals, from building 
stuff outside the (gentoo) box and making those ebuilds available.


In fact the easiest thing for you to do is form a distro, and do things 
your way, whilst maintaining close to the portage tree function. We

already have a wonderful distro, called Pentoo, that does just that.
Things are quite wonderful between these distros.




To make it clear, I'm mostly talking about users who would want to
contribute, but doesn't necessarily take pledge on the responsibility
of maintaining a package.


There is absolutely nothing in gentoo that prevents this. But, you 
should not expect 'a rank and file blessing from the gentoo devs', 
without 'due diligence'.




And isn't that what we are mostly talking
about?  If we also talk about maintenance-ship, don't we already have
the proxy maintainer for that position?


Devs within Gentoo are on an aggressive pathway to purge codes (ebuild 
packages) that do not list an accountable dev or proxy, in 

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-12 Thread konsolebox
On Sat, Jun 11, 2016 at 10:48 PM, james  wrote:
> On 06/10/2016 10:09 PM, konsolebox wrote:
>>
>> What matters is the contribution, and the result.  If you don't like
>> how a user makes a contribution, don't accept the pull request, or
>> don't merge his package.  Simple.  If you think that could turn out to
>> be just a waste of time for them, help them correct their issues; add
>> some documentations to enlighten them and give warnings about wrong
>> practices so they don't blame anyone, and so they can decide whether
>> they would want to contribute or not given the rules presented; but,
>> _don't_ make the steps mandatory.  Don't make contributions
>> restrictive.
>
> Security is out the window with what you propose

Please elaborate why it's automatically like that.

-- 
konsolebox



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-12 Thread konsolebox
On Sat, Jun 11, 2016 at 3:00 PM, Michał Górny  wrote:
> On Sat, 11 Jun 2016 11:09:39 +0800
> konsolebox  wrote:
>
>> On Wed, Jun 8, 2016 at 11:53 PM, james  wrote:
>> > The grandiose-ness you propose should only come upon graduating from proxy 
>> > school, imho.
>> > user-->strong-users-->proxy-->dev pathway.
>>
>> Pedantic, bureaucratic, procedure-oriented, monolithic, restrictive.
>> Too conservative.
>>
>> What matters is the contribution, and the result.  If you don't like
>> how a user makes a contribution, don't accept the pull request, or
>> don't merge his package.  Simple.  If you think that could turn out to
>> be just a waste of time for them, help them correct their issues; add
>> some documentations to enlighten them and give warnings about wrong
>> practices so they don't blame anyone, and so they can decide whether
>> they would want to contribute or not given the rules presented; but,
>> _don't_ make the steps mandatory.  Don't make contributions
>> restrictive.
>
> You're contradicting yourself. How can improving/review of pull request
> be non-mandatory, if otherwise we are to reject it? Of course, it all
> depends on how you define 'mandatory'. It's not like anybody forces you
> to do something, you know.

No, you just misinterpret. You can review pull requests.  You can
reject stuff, but don't reject them just because some laid-out steps
in the documentation has not been followed.  Some may not be
completely necessary.  I'm implying that these "academic" steps may
not be completely helpful at all times, and making us follow these
things only make making a contribution stiff and restrictive.

I'm mainly referring to the strict user-->strong-users-->proxy-->dev
pathway that James is encouraging, where it seems like you have to
become a proxy developer first (or maybe, prove yourself first; gain
first some trust), before you are acknowledged to be able to
contribute in a manner that Alexander Berntsen has been suggesting.

These stuff imply unnecessary old-fashioned restrictions that aren't
"necessarily" helpful to security.  It doesn't help encourage users to
become active.

To make it clear, I'm mostly talking about users who would want to
contribute, but doesn't necessarily take pledge on the responsibility
of maintaining a package.  And isn't that what we are mostly talking
about?  If we also talk about maintenance-ship, don't we already have
the proxy maintainer for that position?

> Sure, it may seem like we expect people to fix all the tiny issues with
> pull requests but that's just a default profile we're assuming. Many of
> the people actually *want* to do that. If you don't, you can tell us
> straight ahead and we won't waste our time asking you to.
>
> I'm also unhappy when a pull request is left open for two weeks because
> we asked user to do a simple change, and he doesn't reply. I could've
> fixed it myself faster but then the user would lose his chance to do
> it. And the worst thing, I don't even know if he wants to!

There's nothing I say against that.

>> We do already allow people to send pull requests to
>> Gentoo portage's repo in Github, but it seems like they generally only
>> allow patches that fix current packages, not new features or new
>> packages.
>
> That's not true. The rules for pull requests are pretty much the same
> as for bugs.

That's great if that's really the case, but a more transparent, less
restrictive, and more dynamic system that could attract casual
contributors would be better.   Something like a web service where
their work would be officially indexed so everyone could easily find
it, not just the current developers of the current tree snapshot
they're trying to push their work to, who may reject it, if it was
intended to be pushed.  I gave the details about this in my other
e-mail.

-- 
konsolebox



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-11 Thread M. J. Everitt
On 12/06/16 04:53, james wrote:
>
> So I read this bug, but it did not illuminate an active archive, but the
> requests and subsequent problems encountered, or did i miss it? It
> looks  like the kinks are being worked out. PM having a ML is a great
> idea.
>
>
> Interesting. I found the ML @ game::
>
> http://thread.gmane.org/gmane.linux.gentoo.proxy-maint/
>
> I post a problem there but it has not shown up yet. I use
> gmane extensively, often to just passively follow a list
> Posting usually causes gmane to send me a notice.
>
> I justd subscribed to the mailing list directly, then perhaps gmane
> will grant me posting wrights access?
>
>
> I only see (2) posts in the ML, so is it active?
>
>
> James
>
>
>
If you are struggling to find/subscribe to the gentoo Mailing-lists, and
the Information/FAQ page appears to be missing information, please file
Bugs at bugs.gentoo.org, so that these matters get picked up, tracked
and addressed.

james, you may find this page:
https://www.gentoo.org/get-involved/mailing-lists/instructions.html helpful.

 Thanks.



signature.asc
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-11 Thread Kristian Fiskerstrand
On 06/12/2016 04:57 AM, Kristian Fiskerstrand wrote:
> On 06/12/2016 05:53 AM, james wrote:


> 
>> I only see (2) posts in the ML, so is it active?
> 
> It is a new ML, but it is active to the extent that you should expect to
> see discussion on it
> 

To elaborate on this, there were posts on it before gmane picked it up
as well

-- 
Kristian Fiskerstrand
OpenPGP certificate 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: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-11 Thread Kristian Fiskerstrand
On 06/12/2016 05:53 AM, james wrote:
> On 06/11/2016 08:29 PM, Kristian Fiskerstrand wrote:
>> On 06/12/2016 04:20 AM, james wrote:
>>>
>>> Is there an archive to this wonderful list? I cannot seem to find the
>>> archive?
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=581370
>>
> 
> So I read this bug, but it did not illuminate an active archive, but the
> requests and subsequent problems encountered, or did i miss it? It looks
>  like the kinks are being worked out. PM having a ML is a great idea.
> 

Archive isn't working yet, it results in 500 as per comment 11
> 
> http://thread.gmane.org/gmane.linux.gentoo.proxy-maint/
> 
> I post a problem there but it has not shown up yet. I use
> gmane extensively, often to just passively follow a list
> Posting usually causes gmane to send me a notice.
> 
> I justd subscribed to the mailing list directly, then perhaps gmane will
> grant me posting wrights access?

The ML requires subscription ex ante to post, similar to most other
gentoo hosted MLs


> I only see (2) posts in the ML, so is it active?

It is a new ML, but it is active to the extent that you should expect to
see discussion on it

-- 
Kristian Fiskerstrand
OpenPGP certificate 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: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-11 Thread james

On 06/11/2016 08:29 PM, Kristian Fiskerstrand wrote:

On 06/12/2016 04:20 AM, james wrote:


Is there an archive to this wonderful list? I cannot seem to find the
archive?


https://bugs.gentoo.org/show_bug.cgi?id=581370



So I read this bug, but it did not illuminate an active archive, but the
requests and subsequent problems encountered, or did i miss it? It looks 
 like the kinks are being worked out. PM having a ML is a great idea.



Interesting. I found the ML @ game::

http://thread.gmane.org/gmane.linux.gentoo.proxy-maint/

I post a problem there but it has not shown up yet. I use
gmane extensively, often to just passively follow a list
Posting usually causes gmane to send me a notice.

I justd subscribed to the mailing list directly, then perhaps gmane will 
grant me posting wrights access?



I only see (2) posts in the ML, so is it active?


James





Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-11 Thread james

On 06/11/2016 05:52 PM, waltd...@waltdnes.org wrote:

On Sat, Jun 11, 2016 at 10:58:35PM +0200, Kristian Fiskerstrand wrote

On 06/11/2016 10:53 PM, Daniel Campbell wrote:

On 06/11/2016 07:48 AM, james wrote:

[snip]

Good/Bad idea, posting proxy-maintainer questions to gentoo-user?
(recall irc does not work for me). Also, it might just spur on other
users to create/maintain a few packages in their own area of interest.


There is also a gentoo-proxy-ma...@lists.gentoo.org list for these
kinds of questions that is likely more appropriate


Archive?

I did find (2) entries in gmane::

http://news.gmane.org/gmane.linux.gentoo.proxy-maint

surely, I'll be adding to this list



   And also gentoo-devhelp



Huh. I did now see this one on the comprehensive list. Is there an 
archive? I did find this on gmane, but this list seems mostly inactive.

Pretty sparse over the last year.

Thanks for the resource listings.

James




Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-11 Thread Kristian Fiskerstrand
On 06/12/2016 04:20 AM, james wrote:
> 
> Is there an archive to this wonderful list? I cannot seem to find the
> archive?

https://bugs.gentoo.org/show_bug.cgi?id=581370

-- 
Kristian Fiskerstrand
OpenPGP certificate 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: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-11 Thread james

On 06/11/2016 03:59 PM, Daniel Campbell wrote:

On 06/11/2016 01:58 PM, Kristian Fiskerstrand wrote:

On 06/11/2016 10:53 PM, Daniel Campbell wrote:

On 06/11/2016 07:48 AM, james wrote:



There is also a gentoo-proxy-ma...@lists.gentoo.org list for these kinds
of questions that is likely more appropriate



Ah, yes. I had forgotten about that list. That does seem like the best
place for that. My apologies.


Great. That sounds perfect. I never saw that mail list.

Perhaps this list needs to be listed::
here:
https://www.gentoo.org/get-involved/mailing-lists/all-lists.html

and maybe here:

https://www.gentoo.org/get-involved/mailing-lists/

Is there an archive to this wonderful list? I cannot seem to find the
archive?

THANKS!
James




Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-11 Thread waltdnes
On Sat, Jun 11, 2016 at 10:58:35PM +0200, Kristian Fiskerstrand wrote
> On 06/11/2016 10:53 PM, Daniel Campbell wrote:
> > On 06/11/2016 07:48 AM, james wrote:
> >> [snip]
> >>
> >> Good/Bad idea, posting proxy-maintainer questions to gentoo-user?
> >> (recall irc does not work for me). Also, it might just spur on other
> >> users to create/maintain a few packages in their own area of interest.
> 
> There is also a gentoo-proxy-ma...@lists.gentoo.org list for these
> kinds of questions that is likely more appropriate

  And also gentoo-devhelp

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-11 Thread Daniel Campbell
On 06/11/2016 01:58 PM, Kristian Fiskerstrand wrote:
> On 06/11/2016 10:53 PM, Daniel Campbell wrote:
>> On 06/11/2016 07:48 AM, james wrote:
>>> [snip]
>>>
>>> Good/Bad idea, posting proxy-maintainer questions to gentoo-user?
>>> (recall irc does not work for me). Also, it might just spur on other
>>> users to create/maintain a few packages in their own area of interest.
> 
> There is also a gentoo-proxy-ma...@lists.gentoo.org list for these kinds
> of questions that is likely more appropriate
> 
Ah, yes. I had forgotten about that list. That does seem like the best
place for that. My apologies.

-- 
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: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-11 Thread Kristian Fiskerstrand
On 06/11/2016 10:53 PM, Daniel Campbell wrote:
> On 06/11/2016 07:48 AM, james wrote:
>> [snip]
>>
>> Good/Bad idea, posting proxy-maintainer questions to gentoo-user?
>> (recall irc does not work for me). Also, it might just spur on other
>> users to create/maintain a few packages in their own area of interest.

There is also a gentoo-proxy-ma...@lists.gentoo.org list for these kinds
of questions that is likely more appropriate

-- 
Kristian Fiskerstrand
OpenPGP certificate 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: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-11 Thread Daniel Campbell
On 06/11/2016 07:48 AM, james wrote:
> [snip]
> 
> Good/Bad idea, posting proxy-maintainer questions to gentoo-user?
> (recall irc does not work for me). Also, it might just spur on other
> users to create/maintain a few packages in their own area of interest.

Anyone is welcome to post to either gentoo-user _or_ gentoo-dev. Ebuild
questions are likely more appropriate on gentoo-dev, but if we're
talking about a high volume of e-mail, it may suit gentoo-user more
since that's the target audience. You'd get a better idea of consensus
over there, as there are some devs who aren't subscribed to gentoo-user.
It wouldn't be fair for us to form consensus for a mailing list we
aren't on. Granted, some of us also hang out on -user. I'm not one of
them, but I think your idea to discuss ebuilds and things over a mailing
list is good. We already have an avenue for that in the forums and IRC,
so the mailing list couldn't hurt.

The only issue is you'd want to make sure you're getting quality answers
from people who know what they're doing. There are many ways to write an
ebuild, but a great majority of them are inefficient or not up to
Gentoo's standards.

That said, the idea has merit. Are there others who would rather not use
the fora or IRC?
-- 
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: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-11 Thread james

On 06/10/2016 10:09 PM, konsolebox wrote:

On Wed, Jun 8, 2016 at 11:53 PM, james  wrote:

The grandiose-ness you propose should only come upon graduating from proxy 
school, imho.
user-->strong-users-->proxy-->dev pathway.


Pedantic, bureaucratic, procedure-oriented, monolithic, restrictive.
Too conservative.


Funny, this seems like a warm complement, not a criticism or deficiency.



What matters is the contribution, and the result.  If you don't like
how a user makes a contribution, don't accept the pull request, or
don't merge his package.  Simple.  If you think that could turn out to
be just a waste of time for them, help them correct their issues; add
some documentations to enlighten them and give warnings about wrong
practices so they don't blame anyone, and so they can decide whether
they would want to contribute or not given the rules presented; but,
_don't_ make the steps mandatory.  Don't make contributions
restrictive.


Security is out the window with what you propose, so you will only 
attract a subset of folks to your beliefs, imho.




We do already allow people to send pull requests to
Gentoo portage's repo in Github, but it seems like they generally only
allow patches that fix current packages, not new features or new
packages.


Yes, do mostly to a lack for formal documentation on howto do those 
things, imho.


You miss the point. Your way is but one pathway. Go forth and create it,
alone or with a dev, as you do not need help. Me, I'm a simpler, sort of 
a monkey-see monkey-do type of hack. I like to read and find formalized 
documentation, augmented with examples, of great comfort and confidence. 
It keeps the trains rolling along the same track, in a very productive 
manner.



That's the very reason why I didn't like becoming a dev.  The system
is too conservative and old-school for me.  I avoid projects where
collaboration is mandatory.  I prefer contributing to a project with
open and loosely knit arrangements, and a dynamic system.  Rankings,
team bonding mean nothing.


You are confusing issues. There is a multitude of folks I've encountered 
over the years that are gentoo-lone-wolves, most have an extraordinary 
levels of competence and do not require interaction with gentoo proper. 
Many like the solace, so there is nothing precluding you from utopic 
gentoo. You are all ready there, aren't you?


/usr/local/portage + github mastery and you do not need the community, 
right?


I do appreciate your input and all the other input. I'm just looking for 
a different pathway, where I can read, and find answers, at my own pace. 
A formal set of documents does provide the gentoo devs/council control 
over what folks learn along the way to dev status and prevents the same 
questions from being asked, over and over and over again. Ad-hoc forums, 
such as irc-proxy and mail-reflectors have poor QA attributes over time, 
imho. QA in those mediums is labor intensive.

Those sorts of mediums are great for unique and non-standard needs.
Documents are king for routine and basic questions that are often seen,
evidence by the myriad of howto's, FAQ's and such documents in existence.


So my conclusion is to just post proxy centric questions, to gentoo-user
and all other questions along the pathway from user==>dev. If docs are 
parsed out and formalized/standardize from the archive, then that would 
be a good thing. If not, I guess folks can use their own filters to 
search out random answers to the (50-500) common questions along that 
pathway.


Good/Bad idea, posting proxy-maintainer questions to gentoo-user?
(recall irc does not work for me). Also, it might just spur on other 
users to create/maintain a few packages in their own area of interest.



konsolebox


James




Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-11 Thread Daniel Campbell
On 06/10/2016 09:05 AM, Alec Ten Harmsel wrote:
> On Fri, Jun 10, 2016 at 04:20:06PM +0100, M. J. Everitt wrote:
>> (2) any user can edit wiki pages not governed by Projects. Even Project
>> pages I'm sure could be updated by means of patches submitted to the
>> appropriate team, with some basic follow-up to ensure action.
> 
> Only users with a wiki account. The gentoo wiki/handbook et. al. are
> great, but I personally really do not like editing wikis in general.
> When I see a clarification or improvement that I could make in gentoo's
> docs, I remember that I'd have to:
> 
> * get a wiki account
> * use a dumb web editor and (probably) HTML to make a change instead of vim

I edit the wiki every now and then, and use a great extension for
Firefox called "It's All Text" which allows you to use any program to
edit the text in  elements. It makes editing much better for
me. I'm not sure if Chromium has anything equivalent, but it's something.

> * get it approved somehow
> 
> All my enthusiasm vanishes at that point. If gentoo's wiki/docs were,
> say, a bunch of markdown files in a git repo somewhere, I would be much
> more willing to clone the repo, make a change, and send in a patch. A
> wiki and handbook could be auto-generated from this, of course. From an
> infra standpoint, this is also simpler than maintaining a wiki.
> 
>> (3) until some enthusiastic sponsors come forward to host/maintain these
>> systems, I don't think its fair to overburden the already stretched
>> Infra guys (no offence, guys! you're doin a great job).
> 
> Agree. Gentoo is fantastic.
> 
> Alec
> 


-- 
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: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-11 Thread Ashish Gupta
Presently, the way to make contributions as outlined in [1] is to create
a bugzilla ticket and attach the patch to that ticket. But there is no
community involvement really for this.

A possible model for increasing user-collaboration and promoting user activity:

>From User's POV:
  - Do emerge --sync and get the tree (Obvious)
  - Make changes, fix/add ebuilds in /usr/portage
  - Do emerge --please-take-my-tree-to-community-review

What will emerge --please-take-my-tree-to-community-review do?
  - Generate a suitable patch between the user's local tree and the
official tree
  - Trigger pybugz[2] (or similar..) to create a new Bugzilla
ticketwith as much information
as possible. For example, it can be automatically guessed whether
the changes
are about fixing an existing ebuild or adds a new ebuild.
===
  - In addition to the emails that are sent by bugzilla to the
developers or groups
responsible, a new email would be sent to
nice-users-that-will-help-me-review-my-code at gentoo.org for
community review.
This will help the user fix issues (The user might range from
complete novice to
almost-developer) according to feedback he or she recieves from other users.
Other users can also run the new ebuilds easily (will promote
sharing user contributions).
  - Once enough people have used the new contributions, the changes
have more chances
of being merged into the official tree.
===

The bugzilla ticket can be suitably updated by the contributor. The
best part is that
the user doesn't need any git expertise and can focus on the task at
hand. This will
also help promote user discussion and the feedback-improve cycle for
user contributions.
IMHO, once it is extremely easy for the users to make contributions, they will
have less mental barriers to become contributors. The discussion on
the ML (or IRC),
will also help in deduplication/enhancement as some existing user(s)
might have already made
similar changes to the same ebuilds but didn't consider sharing them earlier.

As far as the execution is concerned, one possibility is to have a USE flag:
So if portage was installed with USE="dev-mode", all the above
features would be enabled
and dependencies like pybugz (or others) will be pulled in.
Who ever sets this USE flag should also have the possibility of adding
his or her email address
to the contributors ML through the terminal so that they can start
participating asap.

I'm not sure if this satisfies or handles all/any of the features that bernalex
had in mind but I think it would be a big step forward in user contributions and
making them feel that they are a part of the Gentoo community and that
their work
/contributions are deemed important. It might also make potential
Gentoo devs feel
that it is not *that* difficult to become an official developer as
they are already
contributing as a user.

PS - Not directly related, but the same model can most probably be used to help
 users in suggesting would-be-good-to-have features and receiving
feedback on that
 from other users, out of which some might actually take the bold step of
 building it and sending it back to the requesting user.

All criticism is welcome.

[1]: https://wiki.gentoo.org/wiki/Submitting_ebuilds
[2]: https://github.com/williamh/pybugz/ (Package is www-client/pybugz)

Regards,
Ashish Gupta



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-11 Thread Michał Górny
On Sat, 11 Jun 2016 11:09:39 +0800
konsolebox  wrote:

> On Wed, Jun 8, 2016 at 11:53 PM, james  wrote:
> > The grandiose-ness you propose should only come upon graduating from proxy 
> > school, imho.
> > user-->strong-users-->proxy-->dev pathway.  
> 
> Pedantic, bureaucratic, procedure-oriented, monolithic, restrictive.
> Too conservative.
> 
> What matters is the contribution, and the result.  If you don't like
> how a user makes a contribution, don't accept the pull request, or
> don't merge his package.  Simple.  If you think that could turn out to
> be just a waste of time for them, help them correct their issues; add
> some documentations to enlighten them and give warnings about wrong
> practices so they don't blame anyone, and so they can decide whether
> they would want to contribute or not given the rules presented; but,
> _don't_ make the steps mandatory.  Don't make contributions
> restrictive.

You're contradicting yourself. How can improving/review of pull request
be non-mandatory, if otherwise we are to reject it? Of course, it all
depends on how you define 'mandatory'. It's not like anybody forces you
to do something, you know.

Sure, it may seem like we expect people to fix all the tiny issues with
pull requests but that's just a default profile we're assuming. Many of
the people actually *want* to do that. If you don't, you can tell us
straight ahead and we won't waste our time asking you to.

I'm also unhappy when a pull request is left open for two weeks because
we asked user to do a simple change, and he doesn't reply. I could've
fixed it myself faster but then the user would lose his chance to do
it. And the worst thing, I don't even know if he wants to!

> We do already allow people to send pull requests to
> Gentoo portage's repo in Github, but it seems like they generally only
> allow patches that fix current packages, not new features or new
> packages.

That's not true. The rules for pull requests are pretty much the same
as for bugs.

If a fix or enhancement makes sense, the maintainer can approve it or
not. Don't expect that people are going to agree with you, or consider
your contribution more correct just because you provided a patch
or a pull request. And don't expect the developer to take long-term
responsibility for changes he doesn't understand, use or approve.

As for new packages, the rules are simple -- someone has to maintain
them. Gentoo is not the kind of zero-maintenance distro where an ebuild
written once is good forever. With the very limited manpower Gentoo
has, don't expect people to just take some random package you use
and maintain it for you if they don't even have any clue what it does.

If you are not going to maintain your contribution, we can't guarantee
it will be accepted. I'm certainly not interested in having to worry
about 20 more maintainer-needed packages next month because someone
contributed an ebuild that seemed good enough.

In this case, less is better than more. A really bad thing is to
provide something new just to have it removed (or became useless)
in a month or so.

-- 
Best regards,
Michał Górny



pgpKi2xKv6zjw.pgp
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread konsolebox
On Wed, Jun 8, 2016 at 9:16 PM, Alexander Berntsen  wrote:
> It would be wise of us to create a novel way of involving users from
> the ashes of Sunrise.
>
> Here is my suggestion: It would be fruitful to encourage every single
> Gentoo user to have their own repository. And this repository should
> be publicly available.
>
> This way we can merge useful things from people, and they can submit
> pull-requests if they have useful things that are not in the tree.
> Before merging anything to the main tree, ebuilds should of course be
> carefully reviewed. Users could also review each other's ebuilds to
> ensure better quality ebuilds.
>
> This could lead to a future where the Gentoo tree is largely
> superseded. Every user would just have their own repository, where
> they could pick and choose packages from other users. The Gentoo tree
> would just focus on a high-quality repository of the basic/core things
> that everybody needs. Gentoo devs would spend most of their time
> maintaining curated small and useful repositories.
>
>
> While there is some work to be done to facilitate my suggestion, it
> should be a lot less work than Sunrise was. What we need short-term is
> simply documentation where we encourage users to have their own
> repositories that are available online. Next up would be setting
> Portage up to expect a user repository from the get go. The initial
> personal tree could be fork of the Gentoo tree with a remote 'gentoo'
> that they can pull from (emerge could do this automatically). This
> way, users who do not care at all, can just use Gentoo like they do
> today.
>
> The final step is the most difficult (but then again we might never
> get so far). It is two-fold. First we make the core/base repository.
> Then we identify important subsets that can be logically separated
> into repositories, and do this.
>
> Parallel to all this, we should work on tooling. It is unreasonable to
> expect people to be git experts to be effective. The workflows for
> managing user repositories doesn't need the full power of git anyway.
> It would also be good to offer hosting insofar as possible to a set of
> curated repositories we consider to be of high quality.
>
>
> In the end, Gentoo might make a gigantic leap into the future with a
> truly modular distribution. If anyone wants to look at distros that
> get this more right than Gentoo, have a look at e.g. NixOS and Exherbo.
>
> What are your thoughts?

Here's mine:

Make the layman system more open (or have a version of layman that has
more scope e.g. open-layman), but add tags to differentiate stable,
official, or trusted overlays to those which aren't: outdated,
under-provision, etc.  We have to have an open web-based registration
system where users can easily sign-up for their own overlay name which
would be mapped to a supported repository service, like Github.  The
system would time and time check for each repository for activity, and
check for updates.  It would then update the database for packages
which are provided by the overlay.  Note that it doesn't have to
always do repoman-like checks (or maybe it doesn't really have to),
but it could just do it when a user asks for a request, which could be
enqueued, and done only once in every update.

With an open system, users would be encouraged to contribute since
even if their works would not be accepted to be merged into the
official repo, it would still be available to the public for anyone to
use - where people could also easily find it.

Everything about security should already be obvious.  You can warn
users, mask user overlays by default, etc.  If we want, we can have a
comment and upvote system for every package in every overlay where
each is only dynamically created in the database if an upvote,
downvote, or comment is made.

If we are also concerned about overlay names that should only be used
officially, we should warn users that if possible, they should only
use unique names, and avoid common names, and tell them that we could
take their names for official use if we want to, granting their name
is arguably not unique.

Transfer of a package to an official repository:

If an official dev chooses to pull a package from a user overlay,
automatically it should mean that he or another dev would take place
in maintaining that package.  This would prevent the issue of
unmaintained packages, and dependencies among user overlays.

Now some people might question this since it might just drive people
to become normal contributors, and not official, but I think it's more
helpful to the system than not, since it adds more activity, and a lot
of users don't intend to become an official dev anyway.  Besides,
people can still become an official dev on later time if they would
want to, or they can be persuaded to become one.

---
konsolebox



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Rich Freeman
On Fri, Jun 10, 2016 at 12:16 PM, james  wrote:
> On 06/10/2016 08:00 AM, Ciaran McCreesh wrote:
>>
>>
>> The Exherbo model is not "packages are all over the place and there is
>> no coordination whatsoever". The model is "packages that lots of people
>> use are in a small number of core repositories and are carefully dealt
>> with to avoid breakages,
>
> Kinda like the @system + selected profile package list?
>

I suspect it would be more like all core dependencies and common
packages.  So, think KDE, Gnome, X11, python, perl, etc.  We're not
just talking @system.

Basically any package that any average person is reasonably likely to
be familiar with.

There is a very long tail of stuff that would be outside of the
official repos, but you wouldn't care about 99% of it, which is why it
would be outside the official repos.

And my understanding again for Exherbo is that they use code review in
all official repos, so even if you're the only maintainer of a package
and it is in your own git repo, you're still going to put your commits
through code review before you commit them to your own repo.  It isn't
like the Gentoo overlay model where they're all anything-goes.

-- 
Rich



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread james

On 06/10/2016 10:20 AM, M. J. Everitt wrote:

On 10/06/16 17:16, james wrote:


And this effort needs a documentation collection to support users,
post installation to their target (ideal stage-4?) collection of
packages; many of which they maintain themselves even if a strong-user
or dev
helps them assimilate those final packages. Then they can use stage-4
snapshots for periodic backups on complete systems. or for quick
installs of new systems. (that would super-charge my cluster dev work)!


It just seems to me that we have all of that now, but it is::
1) not organized
2) needs documentation so folks do not have to use irc to ask the same
questions over and over and over again (gentoo wiki is maturing in
this direction too, imho.
3) needs (desires) gentoo managed repos, not github

For now, we can use github for users. A glep or 2 can solved 1 and
(2), well I was politely turned down, so suggestions on documentation
to achieve this? Data-mining of emails and irc could easily provide
the first-draft of the docs for need (2).



James


(2) any user can edit wiki pages not governed by Projects. Even Project
pages I'm sure could be updated by means of patches submitted to the
appropriate team, with some basic follow-up to ensure action.


Yes, exactly my point on this and similar threads. If the focus was 
placed on item (2), item (1) evaporates and github or /usr/local/portage
solves (3). Gentoo managed SaaS is not necessary but highly desirable 
after (2) is solved. The 'grandness of these aforementioned musings' are 
irrelevant-noise and not necessary. If (2) is solved (door number 2 you 
are a winner!), the utopia, graciousness and nirvana all arrive, for 
free (or little effort).


DOCUMENTATION
to lift the masses, is what is truly needed at Project:Gentoo and is a 
red-herring at Gentoo, particularly among many of the devs. It is 
free-will choice, but it is akin to the lowest common denominator of 
public education (gentoo-style). Great resources, well organized allow

for and encourage 'self-study'. Add incentives, like 'strong-user,
repos, proxy, and dev, statues to the reward matrix and folks will
follow the docs. Young kids (HS and college) need and want jobs. 
Providing a pathway to deep linux education (which is what gentoo really 
is) is the the honey to grow our ranks. Old farts (like me) will
naturally gravitate to Gentoo, if (2) is solved. The better the docs and 
modules, the stronger the magnetism.


For a more introspective survey, ask ordinary gentoo users how they
use GIT/github in there daily routine. It's a practical-skills desert 
among rodinary-gentoo users, imho.




(3) until some enthusiastic sponsors come forward to host/maintain these
systems, I don't think its fair to overburden the already stretched
Infra guys (no offence, guys! you're doin a great job).


Agreed. As I stated, solve (2) and all the grandiose schema are totally 
in reach. (3) is a trivial effort and can be multiplicative in pathways, 
*after (2) is solved*. Just look at Arch Linux.  We are moving in that 
direction, if not mostly akin to a herd of cats.



MJE



Thanks for your insight, MJE.

Great appreciation to all the gentoo devs past and present.
James




Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Alec Ten Harmsel
On Fri, Jun 10, 2016 at 04:20:06PM +0100, M. J. Everitt wrote:
> (2) any user can edit wiki pages not governed by Projects. Even Project
> pages I'm sure could be updated by means of patches submitted to the
> appropriate team, with some basic follow-up to ensure action.

Only users with a wiki account. The gentoo wiki/handbook et. al. are
great, but I personally really do not like editing wikis in general.
When I see a clarification or improvement that I could make in gentoo's
docs, I remember that I'd have to:

* get a wiki account
* use a dumb web editor and (probably) HTML to make a change instead of vim
* get it approved somehow

All my enthusiasm vanishes at that point. If gentoo's wiki/docs were,
say, a bunch of markdown files in a git repo somewhere, I would be much
more willing to clone the repo, make a change, and send in a patch. A
wiki and handbook could be auto-generated from this, of course. From an
infra standpoint, this is also simpler than maintaining a wiki.

> (3) until some enthusiastic sponsors come forward to host/maintain these
> systems, I don't think its fair to overburden the already stretched
> Infra guys (no offence, guys! you're doin a great job).

Agree. Gentoo is fantastic.

Alec



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Ian Stakenvicius
On 10/06/16 03:53 AM, Alexander Berntsen wrote:
> ... Their repositories
> would likely be amalgamations of our curated and reviewed
> repositories ...

Could you elaborate on what you mean by this?  When I read it, it
sounds like you're saying people will copy ebuilds/packages from the
core/reviewed repositories into their own, just to have them to
satisfy deps or whatever..

If that's what you mean, then I think many of the comments mentioned
earlier still apply.  I forsee that we'd end up with the type of mess
that binary distros (used to?) have, where the third-party repos
contain various copies of potentially out-of-date and out-of-sync core
packages to satisfy the unique packages they actually want to provide.



signature.asc
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Dirkjan Ochtman
On Fri, Jun 10, 2016 at 3:06 PM, Ciaran McCreesh
 wrote:
> How do you know? What is your experience in the area of coordinating
> work across repos in a Gentoo-style distribution?

I don't have much experience with ebuilds, but I have plenty of
experience with software components distributed across git submodules,
and larger distributed systems distributed across a bunch of
components developed separately.

Cheers,

Dirkjan



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread M. J. Everitt
On 10/06/16 17:16, james wrote:
> 
> And this effort needs a documentation collection to support users,
> post installation to their target (ideal stage-4?) collection of
> packages; many of which they maintain themselves even if a strong-user
> or dev
> helps them assimilate those final packages. Then they can use stage-4
> snapshots for periodic backups on complete systems. or for quick
> installs of new systems. (that would super-charge my cluster dev work)!
>
>
> It just seems to me that we have all of that now, but it is::
> 1) not organized
> 2) needs documentation so folks do not have to use irc to ask the same
> questions over and over and over again (gentoo wiki is maturing in
> this direction too, imho.
> 3) needs (desires) gentoo managed repos, not github
>
> For now, we can use github for users. A glep or 2 can solved 1 and
> (2), well I was politely turned down, so suggestions on documentation
> to achieve this? Data-mining of emails and irc could easily provide
> the first-draft of the docs for need (2).
>
>
>
> James
>
(2) any user can edit wiki pages not governed by Projects. Even Project
pages I'm sure could be updated by means of patches submitted to the
appropriate team, with some basic follow-up to ensure action.

(3) until some enthusiastic sponsors come forward to host/maintain these
systems, I don't think its fair to overburden the already stretched
Infra guys (no offence, guys! you're doin a great job).

MJE



signature.asc
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread james

On 06/10/2016 08:00 AM, Ciaran McCreesh wrote:

On Thu, 9 Jun 2016 06:20:38 -0400
Rich Freeman  wrote:

On 08/06/16 16:53, Rich Freeman wrote:

Do you propose that you can have cross-repo dependencies?

Sure. This works well in Exherbo using Paludis. We could do it
right now if we wanted to.


If so that creates a lot of potential issues, even if you do it
the NixOS way.

You should tell Exherbo and NixOS about all these issues that they
should be having but aren't having.



Perhaps you could explain how they actually prevent the issues I
brought up?  Since you didn't actually quote them I'll do so:

Suppose you have 10 packages, and they each depend on zlib from a
different repository?


They don't. Packages do not depend upon "zlib from repository x". They
depend upon "zlib".

The Exherbo model is not "packages are all over the place and there is
no coordination whatsoever". The model is "packages that lots of people
use are in a small number of core repositories and are carefully dealt
with to avoid breakages,


Kinda like the @system + selected profile package list?



but packages that have small numbers of users
are in personal repositories which everyone can see".


Yes. Right now I use my '/usr/local/portage' for dozens of packages.
Maybe a hybrid of /usr/local/portage (being primary) and the public
repo, when things are ready to share, or to get help on a personal
package ebuild, by making it publically available?



 Libraries and
packages that start to be used by many people get moved to one of the
central repositories; one way to tell that this needs to be done is
when it looks like the issues you think could happen actually start to
happen.


And this effort needs a documentation collection to support users, post 
installation to their target (ideal stage-4?) collection of packages; 
many of which they maintain themselves even if a strong-user or dev

helps them assimilate those final packages. Then they can use stage-4
snapshots for periodic backups on complete systems. or for quick 
installs of new systems. (that would super-charge my cluster dev work)!



It just seems to me that we have all of that now, but it is::
1) not organized
2) needs documentation so folks do not have to use irc to ask the same 
questions over and over and over again (gentoo wiki is maturing in this 
direction too, imho.

3) needs (desires) gentoo managed repos, not github

For now, we can use github for users. A glep or 2 can solved 1 and
(2), well I was politely turned down, so suggestions on documentation
to achieve this? Data-mining of emails and irc could easily provide
the first-draft of the docs for need (2).



James



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Ciaran McCreesh
On Thu, 9 Jun 2016 14:25:08 +0200
Dirkjan Ochtman  wrote:
> I would tend to agree with those who have written that coordinating
> work across repos is kind of a pain.

How do you know? What is your experience in the area of coordinating
work across repos in a Gentoo-style distribution?

-- 
Ciaran McCreesh



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Ciaran McCreesh
On Thu, 9 Jun 2016 06:20:38 -0400
Rich Freeman  wrote:
> > On 08/06/16 16:53, Rich Freeman wrote:  
> >> Do you propose that you can have cross-repo dependencies?  
> > Sure. This works well in Exherbo using Paludis. We could do it
> > right now if we wanted to.
> >  
> >> If so that creates a lot of potential issues, even if you do it
> >> the NixOS way.  
> > You should tell Exherbo and NixOS about all these issues that they
> > should be having but aren't having.
> >  
> 
> Perhaps you could explain how they actually prevent the issues I
> brought up?  Since you didn't actually quote them I'll do so:
> 
> Suppose you have 10 packages, and they each depend on zlib from a
> different repository?

They don't. Packages do not depend upon "zlib from repository x". They
depend upon "zlib".

The Exherbo model is not "packages are all over the place and there is
no coordination whatsoever". The model is "packages that lots of people
use are in a small number of core repositories and are carefully dealt
with to avoid breakages, but packages that have small numbers of users
are in personal repositories which everyone can see". Libraries and
packages that start to be used by many people get moved to one of the
central repositories; one way to tell that this needs to be done is
when it looks like the issues you think could happen actually start to
happen.

-- 
Ciaran McCreesh



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Rich Freeman
On Fri, Jun 10, 2016 at 3:45 AM, Alexander Berntsen  wrote:
>
> On 09/06/16 22:15, Michał Górny wrote:
>> Didn't you just contradict yourself? First you tell that everyone
>> should have their own public repo... then you tell that we should
>> merge stuff from those repos. So are you targeting split-repo
>> model, or central repo model, or...?
> Everyone should have their own public repository, yes. I want people
> to be able to grow their own Gentoo as they please. But I'm not
> suggesting we up and away with our developers and expertise. instead,
> we should maintain core/base packages, and curated and reviewed
> small-ish repositories that we feature and recommend using. As such,
> I'm not suggesting anything that major here. Just encouraging users to
> put all their stuff public and get more involved with writing and
> reviewing ebuilds, and, further on, us becoming a bit more modular.

So, I was chatting with an Exherbo dev.  Their model isn't quite what
your earlier emails seemed to suggest (at least as I read it).

The impression that I got from your earlier emails is that you're
advocating a highly decentralized bottom-up system, where everybody
just publishes their packages and people borrow from each other's
work, and the behavior of the overall distro is fairly emergent.  You
suggested at one point that the need for what we call developers could
almost go away.  Now you're talking about having centralized core/base
packages, which obviously necessitates developers.  Maybe your concept
is that the core/base packages are a very small subset of what we have
today.

I still think you're underestimating the need for centralization.
What you call a "core/base" package is probably going to end up being
anything listed in a dependency.  That is a LOT of packages, actually
- we're not just talking about libc and zlib.  You can't have those
packages just randomly disappearing or having inconsistent versioning.

As I understand it the Exherbo way is to have many different
repositories, but just about anything used as a dependency and most
important packages are in officially-blessed repositories.  All
packages in the blessed repositories go through code review in gerrit.
So, maybe every maintainer has their own private git repo, but they
don't publish effective changes in their own repos without going
through central code review.  That is actually MORE centralized in a
sense than Gentoo's overlay system.  The overall distro isn't emergent
from a lot of random devs doing their own thing.

There are some pros and cons to that sort of approach that I can think
of offhand.  Security is an obvious pro - people only have access to
modify the packages they actually maintain.  It probably also means
that you can more readily make repositories official since their
ability to do dumb stuff is limited.  However, there are cons with
regard to collaboration.  If somebody needs to make a distro-wide
change they would need to get all the repo owners to apply the changes
to their own repos - they can't just have at the main tree with a
script (not entirely a bad thing, I'll admit).  Co-maintainership is
also a potential challenge, since you now need repos that multiple
people can access, and doing that on an individual package basis could
get messy (it would work well for defined teams).

Don't get me wrong - such a model has its advantages and we should
talk about them.  Just don't think that it magically gets rid of the
need for central coordination.

The NixOS approach has the potential to be more organic, but I'd think
that it would tend to lead to the zlib problem I brought up.  I'll
post a separate reply to that to clarify the issue.

-- 
Rich



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Consus
On 09:53 Fri 10 Jun, Alexander Berntsen wrote:
> > So forgive me for being blind .. but we were talking about going 
> > -away- from central, curated repositories, and now we've come full 
> > circle to the situation we have now with overlays, mostly
> > controlled in some way by gentoo .. so, do tell me .. what's the
> > difference?!
> Some things. For users, the main difference is that their repositories
> are central and can be grown in a modular manner. Their repositories
> would likely be amalgamations of our curated and reviewed
> repositories, and some more obscure ones from specific areas they are
> interested in. This is very similar to what we have today, save for
> the public user repositories. A central index, as pointed out by Zac,
> would ideally be Accompanying the public repositories. Via this hub,
> users could review each other's ebuilds, and so on.

That's great, but how are you gonna prevent nodejs-like clusterfuck
(happened not so long ago: some guy just removed his packaged and
suddenly everything was broken)? Or any other kind of
screw-you-guys-im-doing-it-my-way behavior? We already have a lot of
issues (like nobody gives a damn about broken packages for weeks) due to
lack of manpower. In my opinion, we need more people with commit access,
not a bunch of standalone repos managed by some random dudes.

> For our central repositories, the main difference would be having more
> repositories, to ensure that we are as modular as possible, so that
> users can more easily e.g. pick and choose external repositories
> instead of what we suggest and recommend, or completely get rid of
> components they don't need or want.

Splitting one giant repo in a bunch of smaller ones (like
haskell-overlay for example) is actually a good idea.



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/06/16 09:39, M. J. Everitt wrote:
> So forgive me for being blind .. but we were talking about going 
> -away- from central, curated repositories, and now we've come full 
> circle to the situation we have now with overlays, mostly
> controlled in some way by gentoo .. so, do tell me .. what's the
> difference?!
Some things. For users, the main difference is that their repositories
are central and can be grown in a modular manner. Their repositories
would likely be amalgamations of our curated and reviewed
repositories, and some more obscure ones from specific areas they are
interested in. This is very similar to what we have today, save for
the public user repositories. A central index, as pointed out by Zac,
would ideally be Accompanying the public repositories. Via this hub,
users could review each other's ebuilds, and so on.

For our central repositories, the main difference would be having more
repositories, to ensure that we are as modular as possible, so that
users can more easily e.g. pick and choose external repositories
instead of what we suggest and recommend, or completely get rid of
components they don't need or want.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWnHfAAoJENQqWdRUGk8BkeUQAMwcuz+0VKvJEXIz6lDu/d9U
CqUNdfVEDUIw2KznogOht0NOkAEGOA6431nbfnf7or5V/AGubVcOVICImex5yNhR
IMp4W2KFor5DKOGyBCDvEjBDFJdbFPNsZsYeJ+KKnaIKhQEaWvMAqk0UFrZKuh3G
a1aDGjvdPdqySdfBEeSqTPSQcUKhegTtxQu0q4WrVbyAz5d74SYyqsJGzeYz9v2d
NPuswwJ22s1QavhjppDa55lp6lO1THaJyYnMkDPJ9qavjXMDkr7h0MD0VstiqedO
HRW5O6Za7bv43aStiy5lC7wO+XBwDPjFOpMRNPynXzy4dA8OrnQZQThykTFYXPu1
k7NKHQQNrnXgNSjcvEYirvcjJDanARMUSMn2BCC7lM2Iy30B7IemDdnnT0TkfhG1
ipnPN0N+Vcmp8xJfOftEjsypVyXzuIv7dA1Ck6egqTdkcsKitSS4RAM7nT049FM9
pYTlGUs/6p/Jbl355CPK+Wfi8PuOCcPOaEI7XeAawXbfKBIIi2/U7mDCDV8NWy+N
b+hBRssNx8MBmJeb1UnbqxezDJlUP/ahinbrCg+BOvJZHgrS3fMJymu/lJ6HMZfD
ULVqXl40ZFdNaL4ZMeJxVWRfX+gUunSzJPYzLR9kLaJfzrfWdIG5zxGsSpwDg291
A4PKup/1kjtqXawOyFC0
=MaxA
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/06/16 22:15, Michał Górny wrote:
> Didn't you just contradict yourself? First you tell that everyone 
> should have their own public repo... then you tell that we should 
> merge stuff from those repos. So are you targeting split-repo
> model, or central repo model, or...?
Everyone should have their own public repository, yes. I want people
to be able to grow their own Gentoo as they please. But I'm not
suggesting we up and away with our developers and expertise. instead,
we should maintain core/base packages, and curated and reviewed
small-ish repositories that we feature and recommend using. As such,
I'm not suggesting anything that major here. Just encouraging users to
put all their stuff public and get more involved with writing and
reviewing ebuilds, and, further on, us becoming a bit more modular.

> Does that mean that using Gentoo would involve spending hours on 
> figuring out which repository supplies a package that happens to be
>  quite up-to-date, build and not have huge security issues?
That's where the mentioned curated and reviewed repositories featured
by us come in.

> So... are we doing split repos, or now forking Gentoo and expecting
>  things to magically work when people attempt to merge a dozen 
> outdated forks of Gentoo?
We're not doing anything -- we're just having a discussion. I'm not
sure about what you mean by merging outdated forks though.

> NixOS doesn't work. It's a huge pile of hacks that create more 
> problems than they solve.
There are quite a lot of people that would disagree vehemently with
you, but I can't really address your issues because you are
effectively just saying "NixOS sucks lol". Do you have the same
concerns with Guix SD? Could you perhaps elaborate on what your
concerns actually are?

> Exherbo is special. You can talk about everyone having their own 
> repository when you have to deal with around 10 users who also 
> happen to be developers. It doesn't scale to Gentoo.
I find this unfounded and about as useful as your "argument" against
NixOS. Exherbo has one single contribution hub with a common review
system for all repositories. I see no reason this shouldn't scale.

> I don't really see how this is relevant to Sunrise.
I didn't mean to say that it was -- I just think we should involve
users, which Sunrise did.

> You have no real technical suggestions, or even a clear vision. I 
> have no clue how your idea is going to work, or if it's even a
> single idea.
The email was primarily meant to generate discussion, to see what kind
of ideas people have in this direction. But I think there are a few
more concrete things in here, and I hope there will be more of those.
If you have more questions or ideas, then perhaps my answers will help
elucidate the "vision", as it were.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWm/7AAoJENQqWdRUGk8B37EP/34BGpWb0tF/QHC/9+o7k4EZ
1vbbmeRwIq8nm1A7NI9DzXvI3modlU/luIqSI0zp8aC/p2mM4Ace2evC2rmSr3Ux
qeuoSR1L2SbH3/RtnrCi8xw+dZaI9xfMrnGC9+IeeaavKWuxgG0IrKrqHDBbhNzA
0qQZdBS4hf7uWNyU2KdcEPjnQMabsCzNFw6LcSQ9XfTfIdFBohLtdDxux1isfbC0
eYvm+VmZv4ICIlHxZKpgLLXVtzgIU4hW2Lwp9Sqo1i4mRJu7oquETibG3vBfasr9
1vPTE1mGecEykGthuVfzGMwAd2E4uZV2Q8X1RndoLOubKIi4sLWY+olzwbF4XQQR
V6XpsFQ4iVwSDphFuRP9hGpl/ePvM6Fujb81D4WThe4+IJ/jo72MKGWnW/+KMUhi
Sh6ApdeDjsiEyyI226ArPAJPrKBUvGlVke6kwb5gDFiGc+bwtsntrnzfheVnp3+N
deLRPiIEH9sePDUDhuT7kxPPCpUAdzieueoS0JjLN7AD2Lqb5xAUV3bzLikLDkJs
m7BYjE+ky/JA6AmEg3uwWnzWW6yNNqpB4uZXZ3VWuHf8KyS69Czrq+oKv7PpR9O3
cn7pCJ8mq2EN7toZXtRiOOHBHXe63Cbb0vcbsDTZQBiSX20pbaSUzofElMZIyKPE
35rKL/DG2RJB5jdsrtPu
=fyiM
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread M. J. Everitt
On 10/06/16 08:33, Alexander Berntsen wrote:
> On 09/06/16 12:28, Igor Savlook wrote:
> > Ok how coordinate? Example: I install packageA in exherbo from
> > repository1 and packageA denend on packageB on repository2. Now
> > packageB removed from repository2 and exherbo crash on install
> > package or on rebuild world (epic fail). Exherbo user need wait
> > when return packageB or create new repository for this package.
> This (as I understand what you're writing) doesn't happen. That's kind
> of the point of curated and reviewed repositories.
So forgive me for being blind .. but we were talking about going -away-
from central, curated repositories, and now we've come full circle to
the situation we have now with overlays, mostly controlled in some way
by gentoo .. so, do tell me .. what's the difference?!



signature.asc
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/06/16 12:28, Igor Savlook wrote:
> Ok how coordinate? Example: I install packageA in exherbo from 
> repository1 and packageA denend on packageB on repository2. Now 
> packageB removed from repository2 and exherbo crash on install 
> package or on rebuild world (epic fail). Exherbo user need wait
> when return packageB or create new repository for this package.
This (as I understand what you're writing) doesn't happen. That's kind
of the point of curated and reviewed repositories.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWm09AAoJENQqWdRUGk8ByZUP/03WUj+WlpHpiH3urM8n6oVn
YHIwSEZQamdsHaubP9e/Ivb3A4i0s/1yjQX1p1I/8WU9jbIXmfSSz0rRrTvYn0lu
kL64WuCNVwVxon9UaO6P0554mbfQHePosmS4ZAsAXo9veQRF3SxZMe7kRwBYQk3s
Req7kPawHq7qn7ltbnwGzKWk2xkYTmKwrnrUrCMkwMCB1r6w9AnzjDhBB/I6jWXk
cW4dHAxss0ryfAc95NTiNU3KOQU1d+PAe+C8naIv+ZFi74mbmvpqzIjgTHdgixFw
mVWEQsyq0JPeE1mprVK/g74365WQbO/ZV1bKYUvVT7xIGVqI2oP1XYWM4KSn6WFK
LhAbGm/l4bM+i04jMK/PgayNX/esIHTacydYv3FwFpLRkGiFe2h8ylKxe82q17w+
Y6MF8nwJjjYBDURizhQJF6tR0oyRG37E2c57eN810NCqeaDXgVNEsLug4W5ivrWo
4bRQoWMEEHxBnJNR+k9P2qKndOz09FciU+Y5jiTFNBRRfzhxtF38mRwfwS3nVV5s
4Px2kQgAKai40hhQcf74lts3Ku8YLKgyoqE+t1G9KLp3MrABLzwQXpWQaZL/iFg3
VxmF/BZde16sESGojqsFli3w9Sq3Bnm2CVLcew3cwetrszHqCHzEFxSDOj3G3cK5
RSoGIsuCCHIDCVy+xFbF
=zTKA
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/06/16 12:20, Rich Freeman wrote:
> Perhaps you could explain how they actually prevent the issues I 
> brought up?
You should probably ask the Exherbo developers, not me.
> 
> Suppose you have 10 packages, and they each depend on zlib from a 
> different repository?  If they collide, that is one problem to 
> solve. If they don't collide then you have 10 copies of zlib now, 
> and good luck making sure they're all secure, and of course now 
> you're multiplying the number of "shared" objects you keep in RAM.
I don't understand why this would happen. Perhaps I was not clear
enough.

If we support a central repository with core/base features, and curate
some useful repositories (with code review), the users would likely
mostly have programs from the curated repositories, and zlib from the
core/base repository. If they are using unreviewed things not
officially reviewed and supported by us, they would be on their own,
just like expert powerusers are today.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWmz7AAoJENQqWdRUGk8BWJUQANvSzJ70cog6ybFBIhVf/+bn
FX9BYpH6rPkkr1Ve9+XGJviq3d1hOh8TAwBt+Qx3YkmRu6h4fVyXO1sPaqf+gs03
bvyvKHez2JT+KyJ1a2Mj61ojy7RYOaVOn2cSGQasD39yPfl+57qJbIDLzGTK8a1D
Upo+MrKuxSFm31JM4XsQJ0BtYl7SysVJW+5ztdOcRgDvg+pGae1U9Hwep3yEaRiV
zuxuALrPtvUdAB8j71dSawf80j0DSh1VP3mfZeqmj7ghvTfUbi/RzOpmf6qZpFLo
3vc4pMiSh0PB7bjgffPRDnTdgu/ecm2Coms8n3OlMDCQ0rihkLmd+P0OibyfQKmu
fH1+2PYcXRE6cs5ogiuWs845KZ6FNUxbNwCHBfRm4N3x/59NPXmXSWBUcYSdFFss
WDoBf2A08J2As0OEJv1DV2+Qn0hM6GjtOv/fhMoO+58rP8cKvFhfPMezSNPf8SFO
NQGbAW4TzotwHbBREoQcJtl+lOa4+U/Tv80H0RlSyOwaINI6hf/YjLd3Xukwftk6
Sti+vPiZIj7esvJmE0XvfPI8XHUWkFmojTyZuTIPyjYQbNU1psEt7KnQ+2+oahbc
qcPq4FfNQ7QO65q5nyzQjTgPj0Hqy2X/xCoZLtcxMKEfqObWGR38Z2+Coqsil7tD
Q9NWG94PTpAq3G+oG6tn
=246a
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Michał Górny
On Wed, 8 Jun 2016 15:16:57 +0200
Alexander Berntsen  wrote:

> It would be wise of us to create a novel way of involving users from
> the ashes of Sunrise.
> 
> Here is my suggestion: It would be fruitful to encourage every single
> Gentoo user to have their own repository. And this repository should
> be publicly available.
> 
> This way we can merge useful things from people, and they can submit
> pull-requests if they have useful things that are not in the tree.
> Before merging anything to the main tree, ebuilds should of course be
> carefully reviewed. Users could also review each other's ebuilds to
> ensure better quality ebuilds.

Didn't you just contradict yourself? First you tell that everyone
should have their own public repo... then you tell that we should merge
stuff from those repos. So are you targeting split-repo model, or
central repo model, or...?

> This could lead to a future where the Gentoo tree is largely
> superseded. Every user would just have their own repository, where
> they could pick and choose packages from other users. The Gentoo tree
> would just focus on a high-quality repository of the basic/core things
> that everybody needs. Gentoo devs would spend most of their time
> maintaining curated small and useful repositories.

Does that mean that using Gentoo would involve spending hours on
figuring out which repository supplies a package that happens to be
quite up-to-date, build and not have huge security issues? I know it's
Gentoo style but we so far focused on making Gentoo painful with a lot
of useless choices on USE flag level.

> While there is some work to be done to facilitate my suggestion, it
> should be a lot less work than Sunrise was. What we need short-term is
> simply documentation where we encourage users to have their own
> repositories that are available online. Next up would be setting
> Portage up to expect a user repository from the get go. The initial
> personal tree could be fork of the Gentoo tree with a remote 'gentoo'
> that they can pull from (emerge could do this automatically). This
> way, users who do not care at all, can just use Gentoo like they do
> today.

So... are we doing split repos, or now forking Gentoo and expecting
things to magically work when people attempt to merge a dozen outdated
forks of Gentoo?

> The final step is the most difficult (but then again we might never
> get so far). It is two-fold. First we make the core/base repository.
> Then we identify important subsets that can be logically separated
> into repositories, and do this.
> 
> Parallel to all this, we should work on tooling. It is unreasonable to
> expect people to be git experts to be effective. The workflows for
> managing user repositories doesn't need the full power of git anyway.
> It would also be good to offer hosting insofar as possible to a set of
> curated repositories we consider to be of high quality.
> 
> 
> In the end, Gentoo might make a gigantic leap into the future with a
> truly modular distribution. If anyone wants to look at distros that
> get this more right than Gentoo, have a look at e.g. NixOS and Exherbo.

NixOS doesn't work. It's a huge pile of hacks that create more problems
than they solve.

Exherbo is special. You can talk about everyone having their own
repository when you have to deal with around 10 users who also happen
to be developers. It doesn't scale to Gentoo.

> What are your thoughts?

I don't really see how this is relevant to Sunrise. Sunrise failed for
a few reasons, and one of them was that the pseudo-distributed model
that it attempted to establish didn't work. You are moving
in the opposite direction than most of the Sunrise contributors.

You have no real technical suggestions, or even a clear vision. I have
no clue how your idea is going to work, or if it's even a single idea.

-- 
Best regards,
Michał Górny



pgp4FdG0juBRI.pgp
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Dirkjan Ochtman
On Thu, Jun 9, 2016 at 12:22 PM, Alexander Berntsen  wrote:
> If you mean that we should go with what is currently popular, then
> that would be Microsoft Windows, Mac OS X, and to a lesser degree
> Ubuntu. But I'm not sure what that mental exercise affords us. I am
> more concerned with how we can make Gentoo better, and how we can grow
> and evolve as a distro. I don't think Gentoo as it exists today will
> continue to be a success in 2025. From a user POV I already think that
> Gentoo is likely not the best distro choice for me. But instead of
> immediately abandoning ship like other developers have, I want Gentoo
> to improve.

If you think Exherbo is better for you, then you should probably
use/work on Exherbo instead.

I would tend to agree with those who have written that coordinating
work across repos is kind of a pain. The way we're currently setup,
with a largish active "core" repository and lots of little satellites
seems to work pretty well. We should always invest in ways to make it
easier to contribute work, and to become a dev, and I would not be
opposed to integrating layman/repositories.xml a bit more, but I don't
think your stated goal of totally decentralizing our ebuild tree will
make Gentoo better.

Cheers,

Dirkjan



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Rich Freeman
On Thu, Jun 9, 2016 at 6:22 AM, Alexander Berntsen  wrote:
>
> On 09/06/16 12:14, Johannes Huber wrote:
>> This statement is not feeded with numbers. Distrowatch tells
>> something else.
> I don't know what "feeded" means. Distrowatch is useless for anything
> but figuring out what distros are popular among people who actually
> still use distrowatch.
>

It isn't even useful for that.  It is only useful for figuring out
which distros that advertise themselves in USER_AGENT strings are
popular among people who actually still use distrowatch.

Gentoo doesn't tend to be big on self-promotion, so we probably don't
get a lot of credit for the traffic we do generate.

Here is my user agent right now:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/51.0.2704.63 Safari/537.36

Good luck figuring out what distro I'm on from that...

-- 
Rich



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Igor Savlook

On 06/09/2016 12:38 PM, Alexander Berntsen wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/06/16 16:53, Consus wrote:

How all those people are expected to coordinate their work?

I don't want to control this. That's up to them. It works well in
Exherbo and NixOS. But I agree that tooling to support it would be
useful.

- --
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTkuAAoJENQqWdRUGk8BGo0P/1Zu0ql2hEjeyLa4PAZcpSZX
Bkync3nf328qXZtghIR1BM/oBXc44LLV4bPctCAKCzvOTuf7O6u7GvEyqeRjqXHz
EK2V85/XsujiwUFwucb064IUxvg3xhuJvJorOt8PlgVu1JrER6ZgQao5cGo7DU6/
UDSsGBC09MjSnm7QJOmygMVYRETR/3WrG5P8fAAlS6YBYsn+3MLQFES/BH1TEVCk
YpF97XCtpFf+m/ryfXYgaf3PKX+yd5NrIv+jjLjAjudzgUOy6DzDrMXZqLcYVS2m
HtqnnENKsPBXRpq3M34BrCSeD3JWyS5n3VLHuwDTl4oGCiRKSA34d7qotiAWjlDe
r9+8kQv3kt0nlqBJ7gI6vIqm9QPEEkhPYQbbTf3pQlDVtPnrgdouFKrWlTNJTg0+
XbyDKZos2bz3Y7/HH3u2Ptz7YdE5Lv0TlE3p+nenBxjCCn58KzPCdo3aaASWpaUQ
cgazEBqipLp93W4imxDs+bXWVFDXSDb1zSB0Vr/J9R3eOo9bNHRGGsgGzpGUMwju
RB6vMAmTA/1WaNy2FBLpgPPToLyekun2mUYnLPIL+rJxrPHDWYltp0BNQDs8rWaT
kxVCjZHv8q7UynuTnLZaklXtKvB5Yb8gx2oxV9gzTr/JFEyogxvHYdI+0XM71uHH
x4KZKm2K77AzK8aNkb1N
=0cnT
-END PGP SIGNATURE-

Ok how coordinate? Example: I install packageA in exherbo from 
repository1 and packageA denend on packageB on repository2. Now packageB 
removed from repository2 and exherbo crash on install package or on 
rebuild world (epic fail).
Exherbo user need wait when return packageB or create new repository for 
this package.




Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/06/16 12:14, Johannes Huber wrote:
> This statement is not feeded with numbers. Distrowatch tells 
> something else.
I don't know what "feeded" means. Distrowatch is useless for anything
but figuring out what distros are popular among people who actually
still use distrowatch.

> Overcomplex mess. This doesn't work on distro level. User have 
> already decided which are the successful distros. Those with a 
> central main repo.
It works well in quite a few distros.

If you mean that we should go with what is currently popular, then
that would be Microsoft Windows, Mac OS X, and to a lesser degree
Ubuntu. But I'm not sure what that mental exercise affords us. I am
more concerned with how we can make Gentoo better, and how we can grow
and evolve as a distro. I don't think Gentoo as it exists today will
continue to be a success in 2025. From a user POV I already think that
Gentoo is likely not the best distro choice for me. But instead of
immediately abandoning ship like other developers have, I want Gentoo
to improve.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWUNUAAoJENQqWdRUGk8BQNkP/2pBzcimg9m5K2hQrKizxtf3
x7OFIW1lGt17e2ZjKFfwnQwB73Ek4WosjXociReMHo/B//CxtnQbeg0QYbp0uXi+
Je3eZsp89xzWgHzJo2mNMBR4IJ7I6vH+8V+9VF74AKuLGza5WaXenfBvq4c/uPoC
1XrRSCfhJPmmkuONokoHng/0LXMJtpS8ySDA2yDyh+nNVLEnGsUHWXdceRuNPpG1
mv/z1b/ElKSNkWnKUJfxFnY8EgDecxKo+1qRechJX3cjCKWSrxciahx0K0JNrur3
86T3c0WkEG3iODYt7b/VMdAVQ2LTUCU6NQEKsbOr14uyK3w9CFUlgouabWI/fna8
drDbGX2r6QyLeMdVa1seGrGqIHvGwPg8usYHS8yCTyBhvHGGtx5ONuJg1Qb8FZdr
65uSGtur/Ar3XipoCxbgr1IkfQH2w2b+OmJBaqnezbOB3u/mTrFASwhU3FJnVhz/
VIwmQTHQ6H3cl0MZRmgscrnlLMT4nhkJygEZVikVtUOR2bUchXeQEgd1uW3IEbx9
MGVKsnA5AaNj03UgAHjdcJKsP9lFlDYskbPtet1hTXepB9Q9q8xl6UGCadjLhHpd
jM5tMYa9Tz/wkypmsfM9OEIC7vheKQxTZYe0zY0zlhJ241jZmvekNLb2dIF80Lue
kLnLtr8skyMaQh2wXDLs
=E/QI
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Rich Freeman
On Thu, Jun 9, 2016 at 5:41 AM, Alexander Berntsen  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 08/06/16 16:53, Rich Freeman wrote:
>> Do you propose that you can have cross-repo dependencies?
> Sure. This works well in Exherbo using Paludis. We could do it right now
> if we wanted to.
>
>> If so that creates a lot of potential issues, even if you do it
>> the NixOS way.
> You should tell Exherbo and NixOS about all these issues that they
> should be having but aren't having.
>

Perhaps you could explain how they actually prevent the issues I
brought up?  Since you didn't actually quote them I'll do so:

Suppose you have 10 packages, and they each depend on zlib from a
different repository?  If they collide, that is one problem to solve.
If they don't collide then you have 10 copies of zlib now, and good
luck making sure they're all secure, and of course now you're
multiplying the number of "shared" objects you keep in RAM.

How is this prevented in your proposal?  Do we just accept that the
typical user might have multiple copies of a library installed, with
no guarantees that they're free of security issues?

Keep in mind that this isn't the sort of issue that might be obvious
to an end user.  The average windows user probably has 14 versions of
many common DLLs installed all from random sources and probably has a
bunch of random ones with security issues (including zlib).  The
software all works, because the versions don't collide and the user
doesn't realize that they are wasting RAM and are vulnerable.  So, it
would be pretty easy to say that the windows approach "just works."

Maybe they have found some way to prevent issues like these, but the
conversation would move forward if this were actually explained,
rather than just dismissing concerns.

-- 
Rich



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Johannes Huber
Am Mittwoch 08 Juni 2016, 15:16:57 schrieb Alexander Berntsen:
> In the end, Gentoo might make a gigantic leap into the future with a
> truly modular distribution. If anyone wants to look at distros that
> get this more right than Gentoo, have a look at e.g. NixOS and Exherbo.

This statement is not feeded with numbers. Distrowatch tells something else.

> What are your thoughts?

Overcomplex mess. This doesn't work on distro level. User have already decided 
which are the successful distros. Those with a central main repo. 




Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread M. J. Everitt
On 09/06/16 10:58, Alexander Berntsen wrote:
> On 09/06/16 11:55, Daniel Campbell wrote:
> > According to Enigmail, it expired April 19th.
> I suggest you refresh your keys. My signing subkey was signed April
> 20th and expires in 2017.
>
Indeed, cache error, thanks. All square now.

MJE




signature.asc
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/06/16 11:55, Daniel Campbell wrote:
> According to Enigmail, it expired April 19th.
I suggest you refresh your keys. My signing subkey was signed April
20th and expires in 2017.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWT20AAoJENQqWdRUGk8BWtIQALacIfky93hrYbBjcpGm15G4
LgVbG88B0V+DSJtw1e25wIXFb86Su1a2GEL1rdCl8zp79kvMDny+cheupu+JlFwv
szSM8fbyLE3NmFTj8pJkwSRmsvqVtWuXzyUk8bnfpoT+4SwYvf9bGMDf1FOFFGb9
q+Bfc0eMEiPi1krrSB9tp9yD5h7+CbN6l3x6uAS2yVqrclFosKh4YI1c2rfKZSBD
YGvcE2WqTjEUB00wZQbiYvdm3WtFeP1MFOsbd6kAb2Gfhl3l1hxKKtGbk0XTUlEq
XoDf9D0jDzAAXSMxsa7KMuhGGGTapcU4+ZAhxKL9Cl4Yh3qbim30W1kIOHVu/2fR
oWyB6WBc5lHStzRFGlg5UhFD2jyHxNpo4+VO57xoMn/dShbcyRPf41ZlsymGqH2h
/PI70+LXrALSrLMeZJ0178I7lRahPF2tcmh5ujXOWj++Y2qjVFRaeH1gAAh330Ye
ZgIcB1dZOUf79TJwmM+vNheUH6ix9pVoX2A8UC1ZGKJFD3w89mvM3+lR2kBysIp+
XdfFt/N3oTGttVKnPDqvXfAA8Ce/WUH7CpPH63oBJRxOhPsmJApen2j1heJ8ynjz
WFDXfpstxkCp1f6dNp+KGnfUms8DRPQx0plTYx/s4v7QcirGaVKQxi/0xJ/ysfsn
6fBFVtrLIEUGQ2Ly0PL2
=aAbh
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Daniel Campbell
On 06/09/2016 02:53 AM, M. J. Everitt wrote:
> On 09/06/16 10:48, Alexander Berntsen wrote:
>> On 09/06/16 11:45, M. J. Everitt wrote:
>> > Btw, your key is showing up as expired, Alex.
>> It doesn't expire until next year.
>>
>>
> 
> I'll blame it on Enigmail, but this is the information I'm seeing:
> 
> "EXPIRED KEY Good signature from "Alexander Berntsen 
> Key ID: 0x705073B5 / Signed on: 09/06/16 10:48"
It's his signing subkey that's expired: 0x541A4F01

According to Enigmail, it expired April 19th.

-- 
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: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread M. J. Everitt
On 09/06/16 10:48, Alexander Berntsen wrote:
> On 09/06/16 11:45, M. J. Everitt wrote:
> > Btw, your key is showing up as expired, Alex.
> It doesn't expire until next year.
>
>

I'll blame it on Enigmail, but this is the information I'm seeing:

"EXPIRED KEY Good signature from "Alexander Berntsen 
Key ID: 0x705073B5 / Signed on: 09/06/16 10:48"


signature.asc
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/06/16 11:45, M. J. Everitt wrote:
> Btw, your key is showing up as expired, Alex.
It doesn't expire until next year.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTtdAAoJENQqWdRUGk8Bl9cQALN5ngYXFjHv4sU9VZiOzMlI
9ysiZhCDWdBJuyJlxIejYo/wMnDiKZZJextwEKEAmyd5hEjmgv0pIcWCgPAyoc8y
tsr2ztcuFYdG1TqlZ8XcPc0KmeJMXXECkrI+m20+i+Rx/bu4OnKnNf0i95EJ3s44
MfGRQuBGwPzABOuR33A1JvIdyvQ2Qlv3orpqI8va9OW48jNiLmRjpiD0Rg90bjMk
Ew9nZOkG5ADAMPboURCyN0Y2cLMBbISgdWsy4gUzNDFdgvf2btIwWO8g9Seb7JB5
be0oFJ9J43rL2MQ1QMdOkeIoOSltJhoEEGxGVVWtnQtuS+SGWuU2j+Lwq56jJTNN
qqIM8H12tuEmltQ446tdLIlC0ObV2q0mnVKi079JDN/NwqH26gCiq601MFncv5Md
GUTu45YwuhhxfckAdVZKXjytzPXTtBmnKXkr6hLFUWE84OOjjMs1G/YTuRFm2yF8
btH8M8SG0XxQndEretqM85nZEsDfxrDo1uL5Z+4B4HWrMudOGV9+WzAywLddhnjh
+2F4YKWxiiANEn5saeHoLA90ossDc7QYzTwg9PDQUxGPvWVNViUyNEIXll0wExH2
N+xCWgAk9DpGG78C59diK6MCHdt75bn0PHeYizgA+xVlTuG96kFi7LjO7e7vrywS
tzhpcDzD/o7ufDh0kaHr
=vE+S
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/06/16 01:08, Andreas K. Huettel wrote:
> Sigh. Every 2 years somebody else comes up with the same silly
> idea.
I stopped reading your email after this sentence.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTq/AAoJENQqWdRUGk8BlpYP/3dt+jPnIFwW0WKoqLLDzQNr
l8qWQZZ3IYzuBV0AUtkDY+Skit7L/mbFOkNNYpwPKeDzfD3YL0G9ajdtC0HLP5Ii
WfplFd62qBB5A3xaw5sCL3Dta2SB6I9mRiLA0E1WfxoM1sq5vxgQXYIdacWPV1/d
QrSPvUqjQN//cRjWFWAASzQpMp4VwQ6fpKOsDqDdIrk7bHwPGitRVUTghZKjXKfW
rNyktONBjKf1Gt7eD7Wuog4sWFm3f02olBKbr5GTIkxWYAF5Q7jmLCuyvqIQYtcp
E1sUiHA+48+lRS+iTCdPuAMmXfeNE3T6pUKAZO6Cv77bSwmzQzQ98+uImZyfbFi7
CLQGOxsJz6p24GGI66Qfgbe2trBUMxM8ozBtrdtg+3Pl8CZqE87Lfhr+CK6rWB66
DzZojr1JIQy/YVjC1m/xo/97Uc4DcXp7BDjliCH6PkdjEsS8ySnqr1X/4eJ+3iRm
8GXWD2vL/sBkGTMg2ZP6yw3CHEmmi7N0lU/O0qPq3BTM9RVffZjxaRc39ysoj0QU
Rfur4Y8ObAqx2UV/RoRMSd+U4uWPaB1Km/mVRFMeRCLDq5L7ZKp692qwFCX8dBZy
9sVfGlIaoI1IMIdSgL2Nx8nxq3jfmDr/m7Q2HllWPpEodrdiwCns4/azf2jIpupg
p8gTq794oVzQw1O/2RDn
=gDDu
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread M. J. Everitt
On 09/06/16 10:37, Alexander Berntsen wrote:
> On 08/06/16 16:39, Zac Medico wrote:
> > The first obstacle that comes to my mind is how to discover the
> > packages. There needs to be a central index of repositories which
> > includes searchable metadata for all of the packages provided by
> > those repositories. It will be something like gpo.zugaina.org, with
> > the ability to download the whole database, and update the local
> > copy incrementally.
> This falls under the tooling side of things, and I agree that it is
> very useful.
>
We should be thinking about bringing the gpo.zugaina.org under the
Gentoo umbrella .. it -is- a *very* useful resource, and should belong
with the main sites, perhaps with a refactorage of the 'overlays.g.o' site?!

Btw, your key is showing up as expired, Alex.





signature.asc
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/06/16 18:15, Peter Stuge wrote:
> Do NOT - I repeat NOT - tie "user repos" to GitHub Inc.
If I were in charge or to be involved, I would not even dream about
tying users to a proprietary SaaS. That would be highly unethical in
my view.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTqSAAoJENQqWdRUGk8Bm24P/j3H/32R5MPk0namYpXdBPU7
aqiCLMoQGMNDHLSXlN7e4UfseE5HdwDIyeZmdUGPeCB6cRI3b0K5I0nmOVQJiuND
rvrX86h+gBGbzbQFKNP19TYq5qMusfJylUvidOBkstz0fTQrIIcOioAJ5AYlhcFB
2ypdlZdqCQm2IvjjCdRMOiMEAMl4TfNEhIiic5yvCCe9U6gsOyUhjIGSu8Ul3Fru
IFl8M8D+9S4eOARIVC0ciutUJQBrqVdxAytA3x04qdxRRuCGr8DcPG8EYVvRK3Vw
ozydEBNJtZIkhiJpB0Kqw6e2I5yJpmjfJ0c6boLNGAxCP5IboE11D2QzGq6o+iNf
IxHyAhldKfxF2ZOLKBfivuwgAHG12oJzMHaTgGMuq0nMSW9M5tINvV5ftw3UqVMj
0pS3Hx2styOhZjuH9qtrlCZsD5fbJt4sma+fkOP3uCBgYY6Y2KEZ8vIXMkgTro5H
qFzRNTbbQkp/P8s9Vz3JO5vk1HeMImy4oypFbJ1fyzqim0pK0CvxNi9hgqTTe2Sb
elBaYd3u0vbw42OGbqNuH7ciiNN248dFUc0XME4S4S6ETHdT2e1rraT+gjTJ5UQT
ca4lkfS4ApRDCSptgAkeQ+RKtsaM2aWJgSwFTW1HXBcr7r+BCQYHTAWRjOZ9MGR9
/c9M5xEZHSxiKxpMfRif
=Ie70
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/06/16 17:53, james wrote:
>> DEAL?
No thanks.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTpTAAoJENQqWdRUGk8BPAsQAM1vjeh7AzBx8yVGHcZ0U+vJ
RNoIDrF05PLGAVTqbtMniVNv/jcAwaAk1S2WZGpqaUHnQpWgo+1/Pc9p3HEg6UGf
/tq7uSihJk3dwimSjowzzC9JOu+sJT5d3yc0NPdypxgbuJ0DcPQLXVCCEC/dg1Oi
Anol5S7FR0C6bZFQtQ241MnpEe7pwZT8xEGzhHYC+PaL4bWk5pNcNzArP3VEEhP6
q40tMWsESueulxalagxb3vAb+/Ngi2Y06Jzx213ge9uA4d0Q6Hk0uv7EbTGPmHZ5
RVaf96MFcuyqU9SwjOLhaoz84uYnPaCTPRDT5eTomK2Ls5U1Xghkm8bSrH2hwbeU
EGngSDy+Bf2kPGV1VXCvB7yBrIbPzolDcAkDl51kfJKPtE4IlQb5wJP991Vm8h4n
0cOS5LX+BGvOED2UKLWq8Mr1nf/nQFCmLss4+MFE69/9UenC1LqQmCIT4o809d1C
WLHJLk1+qHNVNTdeOW0Af6hcZ04F8Bci+ALCShhMEiQ8ioTFFdWaFdGpNUsDb7qw
Yx4D78TEggV4qxHUrl/zvKKw6x1zvbzoberBcvzVErV7CPKGtUzRHH/oPmX09drh
8C0sVYVROdVMOGfe5zgEefV9UDdkDqQHxwi9JeOgzQI/PoL3jAYJiwENIGNdG2jv
MGN1PSZvXyzuiCOrtxQ4
=RA10
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/06/16 16:53, Rich Freeman wrote:
> Do you propose that you can have cross-repo dependencies?
Sure. This works well in Exherbo using Paludis. We could do it right now
if we wanted to.

> If so that creates a lot of potential issues, even if you do it
> the NixOS way.
You should tell Exherbo and NixOS about all these issues that they
should be having but aren't having.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTnZAAoJENQqWdRUGk8BGoAQAMmRKgmeRFN1wSfNIF7JUAqu
H23vd/MR1IJ5s3IPwzgo0zJTpHMJFatyCCJnYqNKcse+lS13w584gWI2ukLLh7iW
zgeN8ngXcQ0U07Bn1fdO6PXGWHEL9+bUm2QKuGOIIDxdkhMlb/uJz3sDK4+uaqqE
nBBxwUJT2YofBmALqt0l5VJeJBhV1HkRhfC/pBoKM1rvAjWTsiKH98xQC4TQ6Qr5
bV/cNDvSn8sw3kqNOHNJ9EulcRg0mycJAAdVrrlUTlHWB4r1YlWfBC8bT86cxJ+7
DeDE8rSyAY2MJ4s5TV00KzJqgTv/16C9xoZEiIfXjYe7MKuh5EWGbJZGp/rlMPis
B2g2bjSGxdaWWSJBS597KfuPqTqnsfekxvccQCSXaXBhDa1mXIPNW5jDwRQgOsd3
P88GDzF2SZyT9CzSipgf9m5olhg0kA5YFT+RbkvP98ZpYrVzmuO/lXkxyQIUQGxm
C/zGrPbnydaJFYIlE051dKjvdCdRU9HAoRFV6/8AWTio7aOILGWjTJx/nGrkUHdh
pmyDrMP/lnlDJwyS/kyoou2hw8v0w7dh3ges12VF4GqxlLF6hbBE7areXjVKyX+X
VhRKEm0cBVp3KSEv5jRpa4w7qzqnttXHVf7r4Q0T9/Ic01n/oP0p+UIrymScQ2JH
SpmugNyiZCPv2uM70IBz
=GcTt
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/06/16 16:53, Consus wrote:
> How all those people are expected to coordinate their work?
I don't want to control this. That's up to them. It works well in
Exherbo and NixOS. But I agree that tooling to support it would be
useful.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTkuAAoJENQqWdRUGk8BGo0P/1Zu0ql2hEjeyLa4PAZcpSZX
Bkync3nf328qXZtghIR1BM/oBXc44LLV4bPctCAKCzvOTuf7O6u7GvEyqeRjqXHz
EK2V85/XsujiwUFwucb064IUxvg3xhuJvJorOt8PlgVu1JrER6ZgQao5cGo7DU6/
UDSsGBC09MjSnm7QJOmygMVYRETR/3WrG5P8fAAlS6YBYsn+3MLQFES/BH1TEVCk
YpF97XCtpFf+m/ryfXYgaf3PKX+yd5NrIv+jjLjAjudzgUOy6DzDrMXZqLcYVS2m
HtqnnENKsPBXRpq3M34BrCSeD3JWyS5n3VLHuwDTl4oGCiRKSA34d7qotiAWjlDe
r9+8kQv3kt0nlqBJ7gI6vIqm9QPEEkhPYQbbTf3pQlDVtPnrgdouFKrWlTNJTg0+
XbyDKZos2bz3Y7/HH3u2Ptz7YdE5Lv0TlE3p+nenBxjCCn58KzPCdo3aaASWpaUQ
cgazEBqipLp93W4imxDs+bXWVFDXSDb1zSB0Vr/J9R3eOo9bNHRGGsgGzpGUMwju
RB6vMAmTA/1WaNy2FBLpgPPToLyekun2mUYnLPIL+rJxrPHDWYltp0BNQDs8rWaT
kxVCjZHv8q7UynuTnLZaklXtKvB5Yb8gx2oxV9gzTr/JFEyogxvHYdI+0XM71uHH
x4KZKm2K77AzK8aNkb1N
=0cnT
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/06/16 16:39, Zac Medico wrote:
> The first obstacle that comes to my mind is how to discover the 
> packages. There needs to be a central index of repositories which 
> includes searchable metadata for all of the packages provided by
> those repositories. It will be something like gpo.zugaina.org, with
> the ability to download the whole database, and update the local
> copy incrementally.
This falls under the tooling side of things, and I agree that it is
very useful.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTjxAAoJENQqWdRUGk8BuEcP/iE76kp8HAqusjifU3h41IO6
z7EX6oNmkCTIUye/BqsiiaGQKoJazD2GzBUTrsAHtVuLib/ILea0Bu/K3wl8kOw2
T+2sDhmBKMabFmbtVnwgySsW1ZeQOj6518BELjfrYBSywC/TIU4706e6r3uzkrFi
xjVA+7EPcBz7NuyV6osh3yDB7mtsRgZTS5Pa3RWK7r6zwQedgcb1ExU+5qeDMrPw
aCzGM1EhdyGEJkrBdinJd6OsUo9MCUxf+Tt2Ndq6hy9wT3fz745x5xhHFpzhpoeC
Tq+Qm6/E+gLVAOu5Qd+33NHhPtEPQxCJ6lP0fhqavvOOCY3Sq13wdOKBxspXi0SI
sGgkQMbZxaDB99VhEEOWKxcb5kJif4FTxD4b30UpZwFWhKUrrXjPZ0/o7rPQWvt9
1me//ppEvgDd/1DkCA1H2EpbHHFclsW3R3I4QyGj2PyGhtGJ7WwLeUjHG+O5D1Nl
No49ASFKV9KPBUU5OqbvTn3EO7AIVQnK6nqxp5vCqEGmJUi4+ldYV5y34OxTudnQ
vZ3vE0+CwB42IAR23Hx7PdHv68l8vRigsaedcSV6UbraOnv2U3jxBAa2rPrpE5Ht
j/E+lD+wfS6f3l8qn5+jb3dKiTRK/6RmaMzETcy9ZOWc8SmwCspPOvu4mDVHoVFX
6/kewlpe4qcce/SXbAle
=UZKB
-END PGP SIGNATURE-



Re: CoC (Was: Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project))

2016-06-09 Thread Daniel Campbell
On 06/08/2016 11:21 PM, Andrew Savchenko wrote:
> Hi!
> 
> On Wed, 8 Jun 2016 22:07:06 -0700 Daniel Campbell wrote:
> 
>> There are some of us against GitHub and/or other commercial outfits, so
>> that's not a problem. We offer some mirrors on GitHub, and some devs
>> host things on there, but it's nothing officially endorsed or otherwise
>> required by Gentoo.
>>
>> In fact I recently deleted my repos and account over the Code of Conduct
>> fiasco, but that's a whole 'nother topic. :P
> 
> Do you mean github's Code of Conduct? Looks like I missed some
> change there.
> 
> Best regards,
> Andrew Savchenko
> 
Yeah. It's unrelated to this thread, but GitHub's adopted the 'Open Code
of Conduct' by the TODO group or whatever. They had claimed it was
solely for their own projects, but there was some drama that came up
where they deleted peoples' repos, issues, and/or comments over that
same CoC. Often, it was enforced due to political or personal leanings
on sensitive subjects that didn't relate to the code at hand.

It may be better to discuss this over IRC or in private e-mail. The tldr
of it is they'd enforced their CoC despite it being nowhere in their
official Terms of Service. For some, that is a problem.

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


CoC (Was: Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project))

2016-06-09 Thread Andrew Savchenko
Hi!

On Wed, 8 Jun 2016 22:07:06 -0700 Daniel Campbell wrote:

> There are some of us against GitHub and/or other commercial outfits, so
> that's not a problem. We offer some mirrors on GitHub, and some devs
> host things on there, but it's nothing officially endorsed or otherwise
> required by Gentoo.
> 
> In fact I recently deleted my repos and account over the Code of Conduct
> fiasco, but that's a whole 'nother topic. :P

Do you mean github's Code of Conduct? Looks like I missed some
change there.

Best regards,
Andrew Savchenko


pgpFCFhHwO6O4.pgp
Description: PGP signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-08 Thread Sam Jorna
On 09/06/16 15:31, NP-Hardass wrote:
> On 06/09/2016 01:03 AM, Daniel Campbell wrote:
> [...]
>> Proxy-maint team: do you guys feel that your project and/or process are
>> a suitable starting point to becoming a proper Gentoo developer?
> As with everything, it depends on the individual.  One can certainly cut
> their teeth and learn/contribute a lot through proxy maint, but at the
> same time, they could just do the bare minimum to keep their package
> updated.  The idea behind the project is to facility user contributions.
>  Part of that includes ensuring proper QA and writing good, well formed
> ebuilds.  This certainly provides the opportunity to get an individual
> moving toward developership, but obviously, once again, depends on the
> individual.

I'd also like to expand on this a little further to point out that we
have recently enacted a policy to help track/list what a given
contributor actually contributes to through the use of bugs[0,1] which
could be beneficial to someone's application to the recruiters. Note
that this isn't intended as a replacement for the recruitment process.


That being said, there are still a lot of bugs and PR's to be done, so
we would welcome any new members wishing to help facilitate user
contributions!


[0] https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Managing_Requests
[1]
https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Maintainer_Bugs_and_Maintainership_Requests

Cheers;
-- 
Sam Jorna (wraeth) 
GnuPG Key: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-08 Thread NP-Hardass
On 06/09/2016 01:03 AM, Daniel Campbell wrote:
[...]
> Proxy-maint team: do you guys feel that your project and/or process are
> a suitable starting point to becoming a proper Gentoo developer?
As with everything, it depends on the individual.  One can certainly cut
their teeth and learn/contribute a lot through proxy maint, but at the
same time, they could just do the bare minimum to keep their package
updated.  The idea behind the project is to facility user contributions.
 Part of that includes ensuring proper QA and writing good, well formed
ebuilds.  This certainly provides the opportunity to get an individual
moving toward developership, but obviously, once again, depends on the
individual.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-08 Thread Daniel Campbell
On 06/08/2016 10:54 AM, james wrote:
> On 06/08/2016 11:27 AM, Nathan Zachary wrote:
>>
>>> GitHub Inc. is successful because they host a central location with
>>> "all the code on the Internet"; convenient for consumers and
>>> producers alike. Of course it is a fallacy, but it's convenient
>>> when it works.
>>>
>>> Ensure that Gentoo accomplishes the same for Gentoo.
>>>
>>> Do NOT - I repeat NOT - tie "user repos" to GitHub Inc., please do
>>> not even bother working on a prototype there (looking at you James),
>>> because if it is good enough it will stick, and as the social
>>> contract rightfully states, it's important to remain independent,
>>> so that Gentoo and Gentoo only can decide what it will offer.
> 
> OK, put me on the spot (actually good) I'm no fan of github, for a
> variety of reason. 'bait and switch' in the mantra of modern business.
> I just assumed we are stuck with github.
> 
> As an older hack, I more of the C/unix/files type of mindset, not
> diffing everything. Still the diff centric semantics are useful
> 
>>> This is a wonderful idea which would benefit the community
>>> tremendously. I wish I had time to implement all of it immediately.
>>>
>>>
>>> Kind regards
>>>
>>> //Peter
>>>
>> I agree with the idea of NOT using GitHub.  Though it is a great
>> resource, I second the idea that Gentoo should offer the repository
>> space in order to stay separate.
>>
>> Cheers,
>> Nathan Zachary
> 
> I actually strongly agree with gentoo rolling it's own on the
> development site/tools.  What we are missing is a distributed file
> system and the ability to cluster resources on top of a distributed
> file system for this central gentoo system. OrangeFS does look promising
> for the dfs. Any number of sys-cluster codes are maturing so that
> a system can span resources transparently to the user. From what I'm
> learning, if you can go from running gentoo on a server or workstation
> to buidling up a dfs on a small gentoo cluster, then you are at the
> dev-status-level, imho.
> 
> 
> Actually (Peter and Zachary) I'm all in on the non-github approach, if
> that pathway is defined by gentoo-devs on the team. I do believe in the
> cook-book approach before 'gets their wings' with gentoo, being
> old-school.   Besides it's always nice to look at docuemnts, if you have
> not use a particular 'set of tricks' in a while
> 
> ymmv. So, I can take it either way, but building something
> gentoo-centric, without github, is very appealing too.
> 
> 
> 
> James
> 
> 
There are some of us against GitHub and/or other commercial outfits, so
that's not a problem. We offer some mirrors on GitHub, and some devs
host things on there, but it's nothing officially endorsed or otherwise
required by Gentoo.

In fact I recently deleted my repos and account over the Code of Conduct
fiasco, but that's a whole 'nother topic. :P

-- 
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: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-08 Thread Daniel Campbell
On 06/08/2016 08:53 AM, james wrote:
> On 06/08/2016 08:16 AM, Alexander Berntsen wrote:
> Friends,
> 
> It would be wise of us to create a novel way of involving users from
> the ashes of Sunrise.
> 
> Here is my suggestion: It would be fruitful to encourage every single
> Gentoo user to have their own repository. And this repository should
> be publicly available.
> 
>> Folks can already do this on their own with github. Are you suggesting
>> individual githubs, under the 'gentoo umbrella'?
> 
> 
> This way we can merge useful things from people, and they can submit
> pull-requests if they have useful things that are not in the tree.
> Before merging anything to the main tree, ebuilds should of course be
> carefully reviewed. Users could also review each other's ebuilds to
> ensure better quality ebuilds.
> 
>> In fact, users of gentoo learning to review ebuilds (from other users)
>> is a good idea, particularly more in the 'application' or 'area of
>> interest' as opposed core or gentoo-centric packages.
> 
> 
> This could lead to a future where the Gentoo tree is largely
> superseded. Every user would just have their own repository, where
> they could pick and choose packages from other users. The Gentoo tree
> would just focus on a high-quality repository of the basic/core things
> that everybody needs. Gentoo devs would spend most of their time
> maintaining curated small and useful repositories.
> 
>> Sorry, I'm not buying into the 'utopia' scheme. The current gentoo::
>> user-->proxy-->dev pathway needs to become stronger. I your proposal as
>> complimenting that pathway, like this:: user-->strong_user-->proxy
>> However, if/when utopia is achieved, sure I'll guzzle the koolaid.
> 
> 
> While there is some work to be done to facilitate my suggestion, it
> should be a lot less work than Sunrise was. What we need short-term is
> simply documentation where we encourage users to have their own
> repositories that are available online. Next up would be setting
> Portage up to expect a user repository from the get go. The initial
> personal tree could be fork of the Gentoo tree with a remote 'gentoo'
> that they can pull from (emerge could do this automatically). This
> way, users who do not care at all, can just use Gentoo like they do
> today.
> 
>> Too much power too quickly. I'd suggest a user, with an area of interest
>> that is under-served as to their package needs (java, clusters, science,
>> etc) creates said github repo and starts cracking at packages. The
>> grandiose-ness you propose should only come upon graduating from proxy
>> school, imho. A dev actually can now get their own repo, via github, or
>> a group of devs can work out of the same repo, as self-defined as to
>> what works best.
> 
> 
> 
> The final step is the most difficult (but then again we might never
> get so far). It is two-fold. First we make the core/base repository.
> Then we identify important subsets that can be logically separated
> into repositories, and do this.
> 
>> Actually a different project, imho. Focus on strong-user-->proxy-->dev.
> 
> 
> Parallel to all this, we should work on tooling. It is unreasonable to
> expect people to be git experts to be effective. The workflows for
> managing user repositories doesn't need the full power of git anyway.
> It would also be good to offer hosting insofar as possible to a set of
> curated repositories we consider to be of high quality.
> 
>> Now you have just joined my chorus. Gentooers, are pretty much 'flung
>> against the git-wall'. There is a gentoo way, but nobody of sufficient
>> knowledge depth cares to create such tools and docs. It's not easy.
>> Examples == {null set}.
> 
>> Some have been revising the devManual, just to bring it current with all
>> the  changes. That is a challenging effort, because, the dev-manual is
>> where the dev community must agree.  There needs to be a proxy manual
>> and development materials (I personally hate IRC as it is often ADD-noise).
> 
>> Proper docs take a while to develop and even more effort to maintain.
> 
> In the end, Gentoo might make a gigantic leap into the future with a
> truly modular distribution. If anyone wants to look at distros that
> get this more right than Gentoo, have a look at e.g. NixOS and Exherbo.
> 
> 
>> If you agree with loosing the more grandiose ideas (for now) from above,
>> I'll work with you as a test-grunt on developing documents and pathway
>> training, on a modular basis following  the
>> user-->strong-users-->proxy-->dev pathway.
> 
>> I guess to sum it up, WE, work together via emails (create first draft
>> docs from emails), set up a github account, learn the necessary
>> specifics of  github-gentoo-kungfu, create manuals (several revisions of
>> these new docs) and such so I can successfully graduate (pass the ebuild
>> and postmortemproxy quizes) and become a candidate for dev status,
>> without ever using IRC.
> 
>> Note:: does not imply that I will apply for dev-status, or any

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-08 Thread Sam Jorna
On 09/06/16 09:08, Andreas K. Huettel wrote:
> 
>> This could lead to a future where the Gentoo tree is largely
>> superseded. Every user would just have their own repository, where
>> they could pick and choose packages from other users. The Gentoo tree
>> would just focus on a high-quality repository of the basic/core things
>> that everybody needs. Gentoo devs would spend most of their time
>> maintaining curated small and useful repositories.
> 
> [...]
> 
>> The final step is the most difficult (but then again we might never
>> get so far). It is two-fold. First we make the core/base repository.
>> Then we identify important subsets that can be logically separated
>> into repositories, and do this.
> 
> 
> Sigh. Every 2 years somebody else comes up with the same silly idea.
> 
> 1) Who defines what everybody needs?
> 2) How do you enforce security and/or qa requirements on the rest?
> 3) Will you allow non-core dependencies? What guarantees are made there?
> 4) How do you make sure that different split-out repos actually work together?
> 5) "logically separated subsets" means either "loss of functionality" or 
> "impossible to do"
> 
> Independent of how many magic tools you whip up this will be a significant 
> step down in functionality and quality, and a big step towards a big 
> unmanageable steaming pile of cr...

Even excepting the significant technical issues such as dependencies and
security issues, even something as simple as versioning, if interpreted
differently between users, could prove difficult to overcome.

Not to mention SLOTting...

-- 
Sam Jorna (wraeth) 
GnuPG Key: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-08 Thread M. J. Everitt
On 09/06/16 00:08, Andreas K. Huettel wrote:
>
> > This could lead to a future where the Gentoo tree is largely
> > superseded. Every user would just have their own repository, where
> > they could pick and choose packages from other users. The Gentoo tree
> > would just focus on a high-quality repository of the basic/core things
> > that everybody needs. Gentoo devs would spend most of their time
> > maintaining curated small and useful repositories.
>
> [...]
>
> > The final step is the most difficult (but then again we might never
> > get so far). It is two-fold. First we make the core/base repository.
> > Then we identify important subsets that can be logically separated
> > into repositories, and do this.
>
>
> Sigh. Every 2 years somebody else comes up with the same silly idea.
>
> 1) Who defines what everybody needs?
> 2) How do you enforce security and/or qa requirements on the rest?
> 3) Will you allow non-core dependencies? What guarantees are made there?
> 4) How do you make sure that different split-out repos actually work
> together?
> 5) "logically separated subsets" means either "loss of functionality" or
> "impossible to do"
>
> Independent of how many magic tools you whip up this will be a
> significant
> step down in functionality and quality, and a big step towards a big
> unmanageable steaming pile of cr...
>
>

+2


signature.asc
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-08 Thread Andreas K. Huettel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

> 
> This could lead to a future where the Gentoo tree is largely
> superseded. Every user would just have their own repository, where
> they could pick and choose packages from other users. The Gentoo tree
> would just focus on a high-quality repository of the basic/core things
> that everybody needs. Gentoo devs would spend most of their time
> maintaining curated small and useful repositories.
> 
[...]
> 
> The final step is the most difficult (but then again we might never
> get so far). It is two-fold. First we make the core/base repository.
> Then we identify important subsets that can be logically separated
> into repositories, and do this.
> 

Sigh. Every 2 years somebody else comes up with the same silly idea.

1) Who defines what everybody needs?
2) How do you enforce security and/or qa requirements on the rest?
3) Will you allow non-core dependencies? What guarantees are made there?
4) How do you make sure that different split-out repos actually work together?
5) "logically separated subsets" means either "loss of functionality" or 
"impossible to do"

Independent of how many magic tools you whip up this will be a significant 
step down in functionality and quality, and a big step towards a big 
unmanageable steaming pile of cr...

- -- 

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXWKVmXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkxRgP/1gOFT/J2dozw5yFVgjLTpRl
dv2uQ1jYZSI6OFRj+0GWwNJEeOtw3mGddEgE59ut3zPVXXmdCgwsAo34A6rgxFsU
zJuXBDinj/P6Zq+3Wp3bOmZuDNWZyKh27OC0tJ+w/dj1WALZhQVnz22b0/dmtrHT
g3NX63BYni7nkJawrIf6f3pBmRjs0EPKuBvcyezEvv7ejLvtg7yKlfK02P8W2qJL
iXBDVlQFu8IvAGFQVYD8ZyvNv/8oEebYJlepPjSj+TQ0tLvrBtNzxZOldKdwnGX8
/VvH2ooCfTL8R//16Fbaor5haI7f3WhqAWtuvVSyF7zWmWFnE/EOaLJNU610XYgN
SEX3uuRjC3fo2aPmtqjt73C9Gmc0L8WU5/Vac4LWu/8VzPtDn9YNC3dU8VQeymlZ
RqiVsmVR13isx7RwEvdakq4p+JVcn4N7ujMnxf0U5w6M+pY8kfBrLMK+6EoCAbDg
RGpu6JlVrXKWlVMoH0Cw41hJB7d1LzUEV06PTajPHo2/akfgTaY0StEGZh+srlyW
doTSImk7MlS/QixkkwmWa3vGZFMJ1FbAxgDpzQSgJa9u7FmKuNZWFlLMjOS2QmTG
hQlF3Z4kSaSF0TAtpz/JsmXFi3pTIs1AP1t2AtuBAaW0H7yo6OPmJJ9CdobxDdqp
NA1qExtuFYWuF9mKVjbs
=c6wy
-END PGP SIGNATURE-



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-08 Thread james

On 06/08/2016 11:27 AM, Nathan Zachary wrote:



GitHub Inc. is successful because they host a central location with
"all the code on the Internet"; convenient for consumers and
producers alike. Of course it is a fallacy, but it's convenient
when it works.

Ensure that Gentoo accomplishes the same for Gentoo.

Do NOT - I repeat NOT - tie "user repos" to GitHub Inc., please do
not even bother working on a prototype there (looking at you James),
because if it is good enough it will stick, and as the social
contract rightfully states, it's important to remain independent,
so that Gentoo and Gentoo only can decide what it will offer.


OK, put me on the spot (actually good) I'm no fan of github, for a 
variety of reason. 'bait and switch' in the mantra of modern business.

I just assumed we are stuck with github.

As an older hack, I more of the C/unix/files type of mindset, not 
diffing everything. Still the diff centric semantics are useful



This is a wonderful idea which would benefit the community
tremendously. I wish I had time to implement all of it immediately.


Kind regards

//Peter


I agree with the idea of NOT using GitHub.  Though it is a great
resource, I second the idea that Gentoo should offer the repository
space in order to stay separate.

Cheers,
Nathan Zachary


I actually strongly agree with gentoo rolling it's own on the 
development site/tools.  What we are missing is a distributed file

system and the ability to cluster resources on top of a distributed
file system for this central gentoo system. OrangeFS does look promising
for the dfs. Any number of sys-cluster codes are maturing so that
a system can span resources transparently to the user. From what I'm 
learning, if you can go from running gentoo on a server or workstation
to buidling up a dfs on a small gentoo cluster, then you are at the 
dev-status-level, imho.



Actually (Peter and Zachary) I'm all in on the non-github approach, if 
that pathway is defined by gentoo-devs on the team. I do believe in the
cook-book approach before 'gets their wings' with gentoo, being 
old-school.   Besides it's always nice to look at docuemnts, if you have 
not use a particular 'set of tricks' in a while


ymmv. So, I can take it either way, but building something 
gentoo-centric, without github, is very appealing too.




James




  1   2   >