[gentoo-dev] The state and future of the OpenRC project

[gentoo-dev] The state and future of the OpenRC project

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1593 bytes --]

Hello developers and users

The OpenRC project appears less active these days than it used to be.

There are many commits per month the last years, but the amount of
commits in 2014 per month has noticeably decreased to a crawl [1].
Alongside that, there appears to be around ~100 bugs open for OpenRC
[2] on Gentoo Bugzilla; some of which are left without a response.

This gives the impression that the development of it is slowing down.

Worth noting is that WilliamH recently had problems with his system, we
have since not seen him on IRC for almost a month; so, this can for a
part explain the last month of inactivity. Although the other months of
2014 and even 2013 to some extent show a decreasing trend.

The state and future of the OpenRC project could be of concern.

Therefore this call for general awareness; such that people that are
interested in this project can help, discuss measures to help the users
of these bugs as well as ensure the future of the OpenRC project.

Thank you in advance.


 [1]: Short log of proj/openrc history, decreasing commits in 2014.
 http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=shortlog

 [2]: Overview of bugs that involve OpenRC, most for the package itself.
 https://bugs.gentoo.org/buglist.cgi?quicksearch=openrc


Disclaimer: Just to be sure, I'm not affiliated with the OpenRC project.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] The state and future of the OpenRC project

[Daniel Campbell]

On 06/07/2014 01:19 PM, Tom Wijsman wrote:
> Hello developers and users
> 
> The OpenRC project appears less active these days than it used to be.
> 
> There are many commits per month the last years, but the amount of
> commits in 2014 per month has noticeably decreased to a crawl [1].
> Alongside that, there appears to be around ~100 bugs open for OpenRC
> [2] on Gentoo Bugzilla; some of which are left without a response.
> 
> This gives the impression that the development of it is slowing down.
> 
> Worth noting is that WilliamH recently had problems with his system, we
> have since not seen him on IRC for almost a month; so, this can for a
> part explain the last month of inactivity. Although the other months of
> 2014 and even 2013 to some extent show a decreasing trend.
> 
> The state and future of the OpenRC project could be of concern.
> 
> Therefore this call for general awareness; such that people that are
> interested in this project can help, discuss measures to help the users
> of these bugs as well as ensure the future of the OpenRC project.
> 
> Thank you in advance.
> 
> 
>  [1]: Short log of proj/openrc history, decreasing commits in 2014.
>  http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=shortlog
> 
>  [2]: Overview of bugs that involve OpenRC, most for the package itself.
>  https://bugs.gentoo.org/buglist.cgi?quicksearch=openrc
> 
> 
> Disclaimer: Just to be sure, I'm not affiliated with the OpenRC project.
> 

As someone who's been in the process of trying to become a developer and
someone who believes there should be multiple init systems, I'd like to
step forward and offer my assistance. pchrist was originally my mentor,
but unforeseen circumstances came up and he's become mostly unable to
mentor me. We discussed this and agreed that maybe I should find another
developer to mentor me. I think working on OpenRC would be a great
learning experience for me and would be a great opportunity to
contribute to Gentoo.

If you or another developer would like to take up mentoring me so I can
achieve my goal of becoming a Gentoo developer and contribute, please
reply and cc pchrist@g.o so we can coordinate things. I still have my
ebuild test file floating around as well.

I hope this doesn't come off as spammy; I'd honestly like to contribute
and keep choice alive in the init system space.

Sincerely,

Daniel Campbell

Re: [gentoo-dev] The state and future of the OpenRC project

[Anthony G. Basile]

On 06/07/14 16:35, Daniel Campbell wrote:
> On 06/07/2014 01:19 PM, Tom Wijsman wrote:
>> Hello developers and users
>>
>> The OpenRC project appears less active these days than it used to be.
>>
>> There are many commits per month the last years, but the amount of
>> commits in 2014 per month has noticeably decreased to a crawl [1].
>> Alongside that, there appears to be around ~100 bugs open for OpenRC
>> [2] on Gentoo Bugzilla; some of which are left without a response.
>>
>> This gives the impression that the development of it is slowing down.
>>
>> Worth noting is that WilliamH recently had problems with his system, we
>> have since not seen him on IRC for almost a month; so, this can for a
>> part explain the last month of inactivity. Although the other months of
>> 2014 and even 2013 to some extent show a decreasing trend.
>>
>> The state and future of the OpenRC project could be of concern.
>>
>> Therefore this call for general awareness; such that people that are
>> interested in this project can help, discuss measures to help the users
>> of these bugs as well as ensure the future of the OpenRC project.
>>
>> Thank you in advance.
>>
>>
>>   [1]: Short log of proj/openrc history, decreasing commits in 2014.
>>   http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=shortlog
>>
>>   [2]: Overview of bugs that involve OpenRC, most for the package itself.
>>   https://bugs.gentoo.org/buglist.cgi?quicksearch=openrc
>>
>>
>> Disclaimer: Just to be sure, I'm not affiliated with the OpenRC project.
>>
> As someone who's been in the process of trying to become a developer and
> someone who believes there should be multiple init systems, I'd like to
> step forward and offer my assistance. pchrist was originally my mentor,
> but unforeseen circumstances came up and he's become mostly unable to
> mentor me. We discussed this and agreed that maybe I should find another
> developer to mentor me. I think working on OpenRC would be a great
> learning experience for me and would be a great opportunity to
> contribute to Gentoo.
>
> If you or another developer would like to take up mentoring me so I can
> achieve my goal of becoming a Gentoo developer and contribute, please
> reply and cc pchrist@g.o so we can coordinate things. I still have my
> ebuild test file floating around as well.
>
> I hope this doesn't come off as spammy; I'd honestly like to contribute
> and keep choice alive in the init system space.
>
> Sincerely,
>
> Daniel Campbell
>

Related to this, I'd like to take care of sys-apps/gentoo-functions in 
WilliamH's absence.  There's a couple of items to fix and I'd like to 
get them done.  Any objections?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] The state and future of the OpenRC project

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/07/2014 04:59 PM, Anthony G. Basile wrote:

> Related to this, I'd like to take care of sys-apps/gentoo-functions in
> WilliamH's absence.  There's a couple of items to fix and I'd like to
> get them done.  Any objections?
> 

Knowing WilliamH fairly well, I'm sure he won't mind you closing bugs
for him ;-)  Please, continue the good work.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTk4Q7AAoJEKXdFCfdEflKJhMP/2c/ptkg8DF616YyCkz9EkBG
+qo8s9mfB411MUHkod2I0KmHHzNbOPRd87DIjwmZJoAJSbg/ojrJwgLlsVK5e7bK
qGIE/d2QdY3pi8Kiix1jx3sp9WVx1PXB8PnMmmEyzgzVNew7DVLI3gF7bZBCmIJA
7OscNOkGjq2MJNBH++p6fVjBpBAJVdZAr2WeFFqrIAgcS8fscC8lb1Ik/+xAeunk
i6tFb+Uv5GHeckji1SqYzWkNFqwC2okNUNFUViYJLI9DMOP3FBImPAcTl2g4ks8Z
3m+Aa3b08et3+Hnbecr5YYO+myI/cQpFnj8axzoxExg4fQ7DDQIB/kPikRTcIEQP
rCFzDrqwpUmDuq+1BjjC8ku4qokSC6WYn435KikDMGdtAVX3ViOcNjqyf7+4Jt20
mOKrm4vaSe8rLCyr3YS1iJYv2mahxF2ZIptKeyw3oT8KjXj7jW+89ruBwj71CPUN
c93cvV4A8qAAblOHMJ5M3p1Ah2Q0+DHVguKql89BKFVXSCuUaReZvYoeoestc4m1
wxb6S1KNEhPVLouyGX+zYDoNhuOfHSZN5ZWyuZZkzBqR3uIojlygG3pj5jrebuWG
ErEKhaUqYxH4SvokReU3DUR1HA1vCrx0WS5mhqcseKKGjvdOCe0dnLBHvzVQTXbE
lwVhnlTRR2COb1xHtTRN
=yT5C
-----END PGP SIGNATURE-----

Re: [gentoo-dev] The state and future of the OpenRC project

[Jeroen Roovers]

On Sat, 07 Jun 2014 15:35:04 -0500
Daniel Campbell <contact@sporkbox.us> wrote:

> >  [2]: Overview of bugs that involve OpenRC, most for the package
> > itself. https://bugs.gentoo.org/buglist.cgi?quicksearch=openrc

> I think working on OpenRC would be a great learning experience for me
> and would be a great opportunity to contribute to Gentoo.

You can start fixing bugs immediately. You can check out the sources,
write patches and attach the patches to the bug reports. Then all it
takes is someone else to review/commit the patches.


     jer

Re: [gentoo-dev] The state and future of the OpenRC project

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/06/14 23:08, Jeroen Roovers wrote:
> You can start fixing bugs immediately. You can check out the
> sources, write patches and attach the patches to the bug reports.
> Then all it takes is someone else to review/commit the patches.
Hacking an init system is different to hacking e.g. desktop or Web
programs. Unless Daniel happens to be a seasoned veteran init system
hacker, having a mentor will be a significant boost.

It would be cool if some of the OpenRC hackers had the time to set up
a developer's wiki or similar, where they share their workflow and
similar. When last I hacked on OpenRC there was nothing like this, and
not many people had time to help me (William was quite helpful
though), so I was left blindly poking things and trying to figure out
things myself. This is a somewhat demotivating process.

P.S.
we should likely do this for other Gentoo projects as well; for
instance Portage.
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlOTttgACgkQRtClrXBQc7UZegD+MlEko0JVgT6GQS10btBZIXaN
M3UBtvcXoEffNFm9Ry0BAJz8b/o/nxa3JCibHk4B3E2+hxKUhjVZA1ocBROGiF5c
=PgD7
-----END PGP SIGNATURE-----

Re: [gentoo-dev] The state and future of the OpenRC project

[Jeroen Roovers]

On Sun, 08 Jun 2014 03:05:28 +0200
Alexander Berntsen <bernalex@gentoo.org> wrote:

> On 07/06/14 23:08, Jeroen Roovers wrote:
> > You can start fixing bugs immediately. You can check out the
> > sources, write patches and attach the patches to the bug reports.
> > Then all it takes is someone else to review/commit the patches.

> Hacking an init system is different to hacking e.g. desktop or Web
> programs.

Exactly nobody suggested that.

That said, starting with OpenRC probably doesn't give you the easiest
learning curve for getting "into" Gentoo.

> Unless Daniel happens to be a seasoned veteran init system
> hacker, having a mentor will be a significant boost.

Lots of people post patches all the time. Whether they're good patches
is up for review, and the lack of mentoring doesn't stop thousands of
others from proposing patches on bugzilla on a very regular basis.


      jer

Re: [gentoo-dev] The state and future of the OpenRC project

[hasufell]

Jeroen Roovers:
> On Sun, 08 Jun 2014 03:05:28 +0200
> Alexander Berntsen <bernalex@gentoo.org> wrote:
> 
>> On 07/06/14 23:08, Jeroen Roovers wrote:
>>> You can start fixing bugs immediately. You can check out the
>>> sources, write patches and attach the patches to the bug reports.
>>> Then all it takes is someone else to review/commit the patches.
> 
>> Hacking an init system is different to hacking e.g. desktop or Web
>> programs.
> 
> Exactly nobody suggested that.
> 
> That said, starting with OpenRC probably doesn't give you the easiest
> learning curve for getting "into" Gentoo.
> 
>> Unless Daniel happens to be a seasoned veteran init system
>> hacker, having a mentor will be a significant boost.
> 
> Lots of people post patches all the time. Whether they're good patches
> is up for review, and the lack of mentoring doesn't stop thousands of
> others from proposing patches on bugzilla on a very regular basis.
> 
> 

The amount of contributors (with real patches and real ebuilds) is
constantly decreasing, because our workflow is horrible. I hope you
don't actually think that bugzilla is an appropriate review platform.

The situation with lack of mentors is more than a small problem. It's a
problem for a lot of gentoo internal projects as well where people start
at positions they don't understand, because there is no one who did
mentor them in that specific area.

Re: [gentoo-dev] The state and future of the OpenRC project

[Jeroen Roovers]

On Sun, 08 Jun 2014 14:41:04 +0000
hasufell <hasufell@gentoo.org> wrote:

> The amount of contributors (with real patches and real ebuilds) is
> constantly decreasing,

As evidenced where exactly?

> because our workflow is horrible. I hope you
> don't actually think that bugzilla is an appropriate review platform.

A poor workman ...

> The situation with lack of mentors is more than a small problem.

If you need mentoring to write patches for OpenRC then you should
probably focus on lesser goals for the time being.

> It's a problem for a lot of gentoo internal projects as well where people
> start at positions they don't understand, because there is no one who
> did mentor them in that specific area.

We're drifting far from the topic and firmly onto hasufell's pet
peeve territory here. Sharks!


Kind regards,
     jer

Re: [gentoo-dev] The state and future of the OpenRC project

[hasufell]

Jeroen Roovers:
> On Sun, 08 Jun 2014 14:41:04 +0000
> hasufell <hasufell@gentoo.org> wrote:
> 
>> The amount of contributors (with real patches and real ebuilds) is
>> constantly decreasing,
> 
> As evidenced where exactly?
> 

I am not sure if that is a joke. You can pretty much ask most major
gentoo projects. The ones where I was involved more deeply definitely
suffer from that problem, including sunrise and games team. Science team
gave up importing major ebuilds to the tree and just let users manage
them on github, because that workflow sucks less.

People are increasingly using their own overlays, because they don't
want to bother with our collaboration walls.

That's reality.

>> because our workflow is horrible. I hope you
>> don't actually think that bugzilla is an appropriate review platform.
> 
> A poor workman ...
> 

Work smart, not hard.

>> The situation with lack of mentors is more than a small problem.
> 
> If you need mentoring to write patches for OpenRC then you should
> probably focus on lesser goals for the time being.
> 

That's a common attitude in opensource, but still wrong and does not
improve collaboration. Especially when we are talking about our own
community.

"Figure it out yourself or get lost!"?

Re: [gentoo-dev] The state and future of the OpenRC project

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

On 08/06/14 18:06, hasufell wrote:
> I am not sure if that is a joke. You can pretty much ask most major
> gentoo projects. The ones where I was involved more deeply definitely
> suffer from that problem, including sunrise and games team. Science team
> gave up importing major ebuilds to the tree and just let users manage
> them on github, because that workflow sucks less.

I disagree with that point.  If you are referring to sage (or
other larger science projects), then they stay in the overlay
because people feel it is not worth the effort to fix the QA
issues which in turn would be necessary before moving them to the
main tree.

From what I can tell it has nothing to do with bugzilla
vs. github.  For me personally bugzilla + a git tree (which is
the situation we have for overlays anyway) is fine.

Cheers,
Thomas

-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 601 bytes --]

Re: [gentoo-dev] The state and future of the OpenRC project

[hasufell]

Thomas Kahle:
> then they stay in the overlay
> because people feel it is not worth the effort to fix the QA
> issues which in turn would be necessary before moving them to the
> main tree.
> 

Probably because no one mentored them on how to fix these QA issues.
Otherwise... if that's attitude, then that's just sad and has to be
fixed by those who run that overlay (review, contribution guidelines).

And I still think that the top 1 reason people run an overlay is because
it's easier than contributing directly.
A lot of overlay maintainers I tried to convince on getting more
involved even said that.

Even sunrise workflow has proven too slow and cumbersome... look at the
commit history, it's constantly decreasing.

Sure, reasons may vary, but there is not much positive to say about
current gentoo workflow.

Re: [gentoo-dev] The state and future of the OpenRC project

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

On Mon, 09 Jun 2014 21:45:26 +0000
hasufell <hasufell@gentoo.org> wrote:

> Probably because no one mentored them on how to fix these QA issues.
> Otherwise... if that's attitude, then that's just sad and has to be
> fixed by those who run that overlay (review, contribution guidelines).
> 
> And I still think that the top 1 reason people run an overlay is
> because it's easier than contributing directly.
> A lot of overlay maintainers I tried to convince on getting more
> involved even said that.
> 
> Even sunrise workflow has proven too slow and cumbersome... look at
> the commit history, it's constantly decreasing.
> 
> Sure, reasons may vary, but there is not much positive to say about
> current gentoo workflow.

We are setting up https://github.com/gentoo/proxy-maintainers to deal
with some of these problems; if sunrise continues to decrease activity,
I suspect this repository has a chance to become its successor.

Travis integration is used to cover QA issues, see
https://travis-ci.org/gentoo/proxy-maintainers which runs repoman on
the overlay for each commit; therefore, QA issues don't go unnoticed.

To improve the workflow further; we use app-portage/overlint to catch
differences between that repository and the Portage tree, after which
there is room for even much more automation; thus more time reviewing.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] The state and future of the OpenRC project

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

On 09.06.2014 23:45, hasufell wrote:
> Thomas Kahle:
>> then they stay in the overlay
>> because people feel it is not worth the effort to fix the QA
>> issues which in turn would be necessary before moving them to the
>> main tree.
>>
> 
> Probably because no one mentored them on how to fix these QA issues.
> Otherwise... if that's attitude, then that's just sad and has to be
> fixed by those who run that overlay (review, contribution guidelines).

I was mentored on the QA issues and have come to 'this attitude'
myself.  Take sci-mathematics/singular: Upstream is genuinely not
interested in supporting distriutions or their petty QA unless
you can prove them that there is a problem that massively hurts
them.  Fixing compatibility with user specified LDFLAGS?  They'll
laugh at you.  Their attitude is a result of years and years of
struggling with too little manpower themselves.  They can hardly
keep up with scientific developments.

My personal attitude: It is just not worth the effort to rewrite
their build systems for the ~10 users out there.  I have better
things to do with my time and I think that these packages can
live forever in the overlay and that is completely OK this way.

> And I still think that the top 1 reason people run an overlay is because
> it's easier than contributing directly.
> A lot of overlay maintainers I tried to convince on getting more
> involved even said that.

I think that's a different point.  I've also met people who just
don't want to become developers because their "it's not worth my
time" boundary is on the other side of the quizzes.  So one could
say yes, contributing to overlays is convenient enough to never
do quizzes.  The arguments I have heard are not about bugzilla
workflow.  They are: I don't get that much more from being a full
dev, so I don't bother taking the quizzes.

> Even sunrise workflow has proven too slow and cumbersome... look at the
> commit history, it's constantly decreasing.

I don't know sunrise.

> Sure, reasons may vary, but there is not much positive to say about
> current gentoo workflow.

Here's a positive thing: There are many ways to contribute, even
without taking lenghty quizzes :)

Cheers,
Thoams


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] The state and future of the OpenRC project

[Rich Freeman]

On Tue, Jun 10, 2014 at 4:57 AM, Thomas Kahle <tomka@gentoo.org> wrote:
>
> My personal attitude: It is just not worth the effort to rewrite
> their build systems for the ~10 users out there.  I have better
> things to do with my time and I think that these packages can
> live forever in the overlay and that is completely OK this way.

I think this is a fairly common issue, actually.  Many ebuilds live
out in overlays (if they're lucky) or just in bugzilla (if not) simply
because they have QA issues that nobody wants to deal with.  I've seen
ebuilds in bugzilla that get bumped as regularly as anything in the
tree.

QA can be a double-edged sword.  Sometimes it can turn a good ebuild
into a great one.  At other times it can result in a fair-to-good
ebuild leaving the tree entirely.

I don't see overlays as a problem though.  The main issue I've seen
with them is when people make changes to the tree that requires
updating reverse dependencies they don't update overlays, and users
using overlays can end up being in a broken state for a time.
Obviously we can never control whether overlays get updated, but we
could require tree-wide updates like this to get announced, instead of
just having a tracking bug that only notifies maintainers of impacted
packages/etc.  That would be more noise though, and likely
bikeshedding that those making the changes want to avoid.  Or we can
just accept that those using overlays will have them break from time
to time.

Rich

Re: [gentoo-dev] The state and future of the OpenRC project

[Peter Stuge]

Rich Freeman wrote:
> likely bikeshedding
..
> Or we can just accept that those using overlays will have them
> break from time to time.

Maybe there's an in-between. It's very reasonable to ask from an
overlay maintainer that they run overlint now and then. If overlint
can be taught to report whenever something breaks, I think that might
be good enough.

Anyone not bothering to run overlint (like me) knows what they are
getting themselves into.


//Peter

Re: [gentoo-dev] The state and future of the OpenRC project

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]

On Tue, 10 Jun 2014 10:57:32 +0200
Thomas Kahle <tomka@gentoo.org> wrote:

> I was mentored on the QA issues and have come to 'this attitude'
> myself.  Take sci-mathematics/singular: Upstream is genuinely not
> interested in supporting distriutions or their petty QA unless
> you can prove them that there is a problem that massively hurts
> them.  Fixing compatibility with user specified LDFLAGS?  They'll
> laugh at you.  Their attitude is a result of years and years of
> struggling with too little manpower themselves.  They can hardly
> keep up with scientific developments.
> 
> My personal attitude: It is just not worth the effort to rewrite
> their build systems for the ~10 users out there.  I have better
> things to do with my time and I think that these packages can
> live forever in the overlay and that is completely OK this way.

Yeah, it behaves like a trade-off in manpower; the type of QA brought
up here is an enhancement, where it would be nice if someone could make
the *FLAGS, CC, LD, ... supported but definitely not a requirement.

This is not a reason to keep it in an overlay (or block stabilization).

> I think that's a different point.  I've also met people who just
> don't want to become developers because their "it's not worth my
> time" boundary is on the other side of the quizzes.  So one could
> say yes, contributing to overlays is convenient enough to never
> do quizzes.  The arguments I have heard are not about bugzilla
> workflow.  They are: I don't get that much more from being a full
> dev, so I don't bother taking the quizzes.

Yes; becoming a full Gentoo Developer can help to go across certain
restrictions, as well as can become more handy if you do work all over
the place in the Portage tree. Other than that I think there is a lot
you can get accomplished as an user; that is, if there is enough
manpower to make those accomplishments of the users have an effect:

https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs

> Here's a positive thing: There are many ways to contribute, even
> without taking lenghty quizzes :)

Indeed, here is a lengthy summary that is probably not complete:

https://wiki.gentoo.org/wiki/Contributing_to_Gentoo

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] The state and future of the OpenRC project

[Christopher Schwan]

[-- Attachment #1: Type: text/plain, Size: 2818 bytes --]

On Monday 09 June 2014 21:45:26 hasufell wrote:
> Probably because no one mentored them on how to fix these QA issues.
> Otherwise... if that's attitude, then that's just sad and has to be
> fixed by those who run that overlay (review, contribution guidelines).
> 
> And I still think that the top 1 reason people run an overlay is because
> it's easier than contributing directly.
> A lot of overlay maintainers I tried to convince on getting more
> involved even said that.
> 
> Even sunrise workflow has proven too slow and cumbersome... look at the
> commit history, it's constantly decreasing.
> 
> Sure, reasons may vary, but there is not much positive to say about
> current gentoo workflow.

Since I was mentioned here - I am one of sage overlay[1] developers - it is 
maybe worth sharing my point of view as someone that is not a Gentoo 
developer. The recent discussion[2] with hasufell on our overlay might also be 
interesting.

I have to agree that indeed it is easier to contribute to an overlay, in my 
case because of

   a) git and
   b) github.

As far as I am up-to-date the main Gentoo repository is still managed by cvs, 
right? Thats something I really would not like to work with. Not because cvs 
is inferior to git (I hope no one feels offended) but because now I am so used 
to and pleased with the workflow that comes with git that I can not even think 
of changing that.

What I really love about github (and I don't think that similar platform 
differ much here) is the fact that it allows me to comment on /everything/. I 
can comment on commits that maybe lack something, which could then result in a 
new Issue; a user could be faster than I and create a pull request that fixes 
this problem. Maybe there is another mistake which I tell him there so he 
adjusts his commit and I finally accept it. Sometimes, after some months I 
wonder why we decided about some things the way we did and I can look it up in 
the Issue. There is the _complete_ discussion with direct references to the 
code and all people involved.

If there is a lession that I learned here, than that centralizing 
communications and development in one place was beneficial for us. Whether 
this also applies to the Gentoo project - well, I don't know. Right now there 
are several mailing lists, IRC channels and the Bugzilla so in comparison to 
our little overlay it is quite decentralized. Adding another way, e.g. via 
github, could complicate the situation but it will defintely get the project 
more user contributions (if that is needed).

In any case, I believe that the migration to git would be a huge step forward 
and it would attract at least one pontential new developer ;). Any update on 
this?

[1] https://github.com/cschwan/sage-on-gentoo
[2] https://github.com/cschwan/sage-on-gentoo/issues/294

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] The state and future of the OpenRC project

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

For what it's worth, I strongly oppose using GitHub or any other SaaSS
that is not licensed using AGPL or under similar terms.

My suggestion is Phabricator, which additionally beats GitHub on
functionality by having proper code review support. I will however not
oppose any momentum for a different self-hosted free software solution.
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlOW4PgACgkQRtClrXBQc7U7JQD+Lg9mKq+Y/pW9bSUDAxLkTxSP
9D2E18qGh9Ce/ZBQAXMA/RiqRN9QGtqIPGBVah3ZOXa8zV4FBP0CVqSZhNECZ6JB
=mTUU
-----END PGP SIGNATURE-----

Re: [gentoo-dev] The state and future of the OpenRC project

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]

Hello,

On Mon, 09 Jun 2014 21:45:26 +0000 hasufell wrote:
> Thomas Kahle:
> > then they stay in the overlay
> > because people feel it is not worth the effort to fix the QA
> > issues which in turn would be necessary before moving them to the
> > main tree.
> > 
> 
> Probably because no one mentored them on how to fix these QA issues.
> Otherwise... if that's attitude, then that's just sad and has to be
> fixed by those who run that overlay (review, contribution guidelines).
> 
> And I still think that the top 1 reason people run an overlay is because
> it's easier than contributing directly.
> A lot of overlay maintainers I tried to convince on getting more
> involved even said that.

As for my own overlay, most of packages there are just either
bugfixes already in bugzilla and pending there (often for years) or
extra packages nobody cares to add despite bugs. I don't want to
blame anyone, project is understuffed and people are overburdened.
But even for those became Gentoo devs it is not so easy to fix
other people's packages due to quite strict and complicated rules
about touching other people's stuff.

So the problem is not in overlays being easier, but in overlays
being often the only way to have required or fixed packages.

Another issue is that CVS is outdated if not retarded compared to
Git. CVS was great 15 years ago, but today Git is far more
productive for distributed collaborative development. Probably the
most terrible issues are how CVS manages directories, renames; and
branches support is really weird.

I don't know why CVS is still used for Gentoo main repository,
probably some infrastructure elements depends deeply on its
internals, because I see of no other reason why Git is still not
used despite efforts ongoing for last several years.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] The state and future of the OpenRC project

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/06/14 17:45, Andrew Savchenko wrote:
> I don't know why CVS is still used for Gentoo main repository, 
> probably some infrastructure elements depends deeply on its 
> internals, because I see of no other reason why Git is still not 
> used despite efforts ongoing for last several years.
Infra can probably speak for themselves, but Portage with its history
is crazy big, and git is not great with crazy big projects. What you
commonly do in those situations is obviously make it more modular and
have several repositories. My guess is this process of figuring out
how to git efficiently isn't progressing too rapidly.
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlOXKPsACgkQRtClrXBQc7Vp5wD+Ib697vg0VF2WRi//CZfaQ1Id
cWMnkGSio22Vxv4NhdcBAIvGImYta4Ajkg/CXsHHPTBVsZNAMtPXubMYSec2ExQB
=g9ID
-----END PGP SIGNATURE-----

Re: [gentoo-dev] The state and future of the OpenRC project

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

On Tue, 10 Jun 2014 17:49:15 +0200 Alexander Berntsen wrote:
> On 10/06/14 17:45, Andrew Savchenko wrote:
> > I don't know why CVS is still used for Gentoo main repository, 
> > probably some infrastructure elements depends deeply on its 
> > internals, because I see of no other reason why Git is still not 
> > used despite efforts ongoing for last several years.
> Infra can probably speak for themselves, but Portage with its history
> is crazy big, and git is not great with crazy big projects.

Why are you saying that git is inefficient with large projects? It
was developed with efficiency in mind in the first place. And
kernel guys will likely disagree with "git is not great with crazy
big projects" statement. And with git kernel bisection and other
complicated (in terms or data manipulation) operations are quite
fast even on old hardware.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] The state and future of the OpenRC project

[Rich Freeman]

On Tue, Jun 10, 2014 at 12:45 PM, Andrew Savchenko <bircoph@gmail.com> wrote:
>
> Why are you saying that git is inefficient with large projects? It
> was developed with efficiency in mind in the first place. And
> kernel guys will likely disagree with "git is not great with crazy
> big projects" statement.

The kernel tree that "everybody" uses has only a single committer -
Linus.  That is definitely a potential challenge that we may run into
migrating gentoo-x86 - we have many committers and a fairly high
commit rate.

With Linux you have a million separate git repos and everybody
cascades their changes up, which get merged into bigger and bigger
patch sets.  So, Linus might get a set of updates to merge from the
video driver maintainer and it might contain 400 bundled commits, but
it isn't like the 400 committers have direct access to Linus's tree.
They all commit to their own trees and cascade up to the next level
via email.

We already have a working method of migrating the entire portage
history to git.  However, the infra tools/etc are all built around git
and only a few people have access to update them.  The git repository
needs to make it out to the mirrors/etc.

There are also a bunch of process-related details to work out.  Does
everybody try to rebase onto master, or do we have lots of merges?
What happens if you do rebase onto master and then when you go to push
it isn't a fast-forward any longer because somebody else pushed first?

But, for the most part we just need to get the back-end re-written to
work with a git repo.  Actually migrating the tree itself to git is
largely a solved problem.

Rich

[gentoo-dev] Re: The state and future of the OpenRC project

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]

On Tue, 10 Jun 2014 13:09:26 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Tue, Jun 10, 2014 at 12:45 PM, Andrew Savchenko <bircoph@gmail.com> wrote:
> >
> > Why are you saying that git is inefficient with large projects? It
> > was developed with efficiency in mind in the first place. And
> > kernel guys will likely disagree with "git is not great with crazy
> > big projects" statement.
> 
> The kernel tree that "everybody" uses has only a single committer -
> Linus.  That is definitely a potential challenge that we may run into
> migrating gentoo-x86 - we have many committers and a fairly high
> commit rate.
> 
> With Linux you have a million separate git repos and everybody
> cascades their changes up, which get merged into bigger and bigger
> patch sets.  So, Linus might get a set of updates to merge from the
> video driver maintainer and it might contain 400 bundled commits, but
> it isn't like the 400 committers have direct access to Linus's tree.
> They all commit to their own trees and cascade up to the next level
> via email.
> 
> We already have a working method of migrating the entire portage
> history to git.  However, the infra tools/etc are all built around git
> and only a few people have access to update them.  The git repository
> needs to make it out to the mirrors/etc.
> 
> There are also a bunch of process-related details to work out.  Does
> everybody try to rebase onto master, or do we have lots of merges?
> What happens if you do rebase onto master and then when you go to push
> it isn't a fast-forward any longer because somebody else pushed first?
> 
> But, for the most part we just need to get the back-end re-written to
> work with a git repo.  Actually migrating the tree itself to git is
> largely a solved problem.

Weren't we also waiting for some gpg signing stuff to land?


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 475 bytes --]

Re: [gentoo-dev] Re: The state and future of the OpenRC project

[Patrick Lauer]

On 06/11/2014 12:10 PM, Ryan Hill wrote:
>> But, for the most part we just need to get the back-end re-written to
>> work with a git repo.  Actually migrating the tree itself to git is
>> largely a solved problem.
> 
> Weren't we also waiting for some gpg signing stuff to land?
> 

That's completely orthogonal (but would be convenient to have as a
built-in, which git since ~1.8 does)

Since people can't even decide on a key policy in under 5 years I doubt
signing is important enough ...

Now git has some/all of the needed features, and people wait on a future
potential git migration instead of figuring out the important bits now
(a good part of that is defined in GLEP 63, but there's no action apart
from work on gentoo-keys.I don't have motivation to try pusing this
again this year ...)

Re: [gentoo-dev] Re: The state and future of the OpenRC project

[Rich Freeman]

On Wed, Jun 11, 2014 at 12:17 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> Now git has some/all of the needed features, and people wait on a future
> potential git migration instead of figuring out the important bits now
> (a good part of that is defined in GLEP 63, but there's no action apart
> from work on gentoo-keys.I don't have motivation to try pusing this
> again this year ...)

Well, the folks doing the git migration are basically waiting for the
infra pieces to be done.

A challenge here is that nobody has time, and sometimes the argument
gets made that there is no sense doing A because you can't use it
without B.  The reality is that we need A, B, C, D, E to cut over, and
none of them are useful on their own, so if everybody makes this
argument we take no action.

The actual migration and git tools should be fine now.

Rich

[gentoo-dev] Re: The state and future of the OpenRC project

[Duncan]

Ryan Hill posted on Tue, 10 Jun 2014 22:10:07 -0600 as excerpted:

[On switching the gentoo tree to git.]
> Weren't we also waiting for some gpg signing stuff to land?

At one point, yes, but AFAIK, that was actually resolved some time ago
(a year, two?) now.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] The state and future of the OpenRC project

[hasufell]

Andrew Savchenko:
> On Tue, 10 Jun 2014 17:49:15 +0200 Alexander Berntsen wrote:
>> On 10/06/14 17:45, Andrew Savchenko wrote:
>>> I don't know why CVS is still used for Gentoo main repository, 
>>> probably some infrastructure elements depends deeply on its 
>>> internals, because I see of no other reason why Git is still not 
>>> used despite efforts ongoing for last several years.
>> Infra can probably speak for themselves, but Portage with its history
>> is crazy big, and git is not great with crazy big projects.
> 
> Why are you saying that git is inefficient with large projects? It
> was developed with efficiency in mind in the first place. And
> kernel guys will likely disagree with "git is not great with crazy
> big projects" statement. And with git kernel bisection and other
> complicated (in terms or data manipulation) operations are quite
> fast even on old hardware.
> 
> Best regards,
> Andrew Savchenko
> 

interesting read:
http://thread.gmane.org/gmane.comp.version-control.git/189776

Does any1 know what fb currently uses or if any of these issues have
been resolved?

Re: [gentoo-dev] The state and future of the OpenRC project

[Sergei Trofimovich]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

On Tue, 10 Jun 2014 19:58:36 +0000
hasufell <hasufell@gentoo.org> wrote:

> Andrew Savchenko:
> > On Tue, 10 Jun 2014 17:49:15 +0200 Alexander Berntsen wrote:
> >> On 10/06/14 17:45, Andrew Savchenko wrote:
> >>> I don't know why CVS is still used for Gentoo main repository, 
> >>> probably some infrastructure elements depends deeply on its 
> >>> internals, because I see of no other reason why Git is still not 
> >>> used despite efforts ongoing for last several years.
> >> Infra can probably speak for themselves, but Portage with its history
> >> is crazy big, and git is not great with crazy big projects.
> > 
> > Why are you saying that git is inefficient with large projects? It
> > was developed with efficiency in mind in the first place. And
> > kernel guys will likely disagree with "git is not great with crazy
> > big projects" statement. And with git kernel bisection and other
> > complicated (in terms or data manipulation) operations are quite
> > fast even on old hardware.
> > 
> > Best regards,
> > Andrew Savchenko
> > 
> 
> interesting read:
> http://thread.gmane.org/gmane.comp.version-control.git/189776
> 
> Does any1 know what fb currently uses or if any of these issues have
> been resolved?
> 

Mercurial + custom plugins: https://www.youtube.com/watch?v=Dlguc63cRXg

-- 

  Sergei

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] The state and future of the OpenRC project

[Rich Freeman]

On Tue, Jun 10, 2014 at 3:58 PM, hasufell <hasufell@gentoo.org> wrote:
>
> interesting read:
> http://thread.gmane.org/gmane.comp.version-control.git/189776
>
> Does any1 know what fb currently uses or if any of these issues have
> been resolved?
>

Not sure, but I did a git status on the actual gentoo-x86 converted
repository (all commits) and it took about 30s.  It has about 130k
files in it, and I suspect that the number of files matters a good
deal.  Git status should need to compare the working tree (a directory
tree) against the index (which is a flat file I think) against the
head (which is a tree full of tree files).  The index should perform
very well as the number of files grow, but the tree and head should
become much harder to traverse as the number of subdirectories grow
(assuming the filesystem design requires seeks to navigate to
subdirectories but not to read the contents of a directory).

Our tree isn't all that deep.  I'd think the pathological case for git
would be a repository in which there is a single file 1.5M subdirs
deep.  That would require 1.5M trees in the repository to store for a
single file, or 1.5M filesystem readdirs to traverse the working tree.

If your repository were flat I'd think that git would perform
reasonably well, though it would still have to compare all those
hashes to find out what changed (but how long can it take a CPU to
compare 1.5M pre-computed hashes?).

Rich

Re: [gentoo-dev] The state and future of the OpenRC project

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/06/14 18:45, Andrew Savchenko wrote:
> Why are you saying that git is inefficient with large projects?
Because it is.

> It was developed with efficiency in mind in the first place.
Not for big projects.

> And kernel guys will likely disagree with "git is not great with 
> crazy big projects" statement
Not the last time I chatted to any of them, nor the last time I saw
Linus say anything about this.

> And with git kernel bisection and other complicated (in terms or 
> data manipulation) operations are quite fast even on old hardware.
The Linux repository is nowhere near Portage-big. Rich mentions one of
the reasons. Another is that for Linux, they very carefully decided to
throw away history to make migration easier. I don't think we're about
to throw away history for Portage.

See also the Facebook link Julian posted. As Sergei linked, Facebook
"solved" this by not using git.


Personally I tend to believe that if git can't handle your project,
you are doing something wrong in terms of modularity. But in the "real
world", that's not always amendable.
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlOYUrAACgkQRtClrXBQc7XyoQD6AhPbhXqL4D7chnYnNF28+wGK
oy+7MuNwiSgeQRCZk2EBAImLz2m2lEeMLrnGqUR+EKiROo+yWQhWPZ8tqCmB0kPO
=PYpt
-----END PGP SIGNATURE-----

[gentoo-dev] The infinite git migration

[Patrick Lauer]

On 06/10/2014 11:45 PM, Andrew Savchenko wrote:
[lots of whining removed ;) ]
> 
> I don't know why CVS is still used for Gentoo main repository,
> probably some infrastructure elements depends deeply on its
> internals, because I see of no other reason why Git is still not
> used despite efforts ongoing for last several years.
> 

One part of it: Manpower. Few people have worked on the git migration,
and those are often busy with more important things (like work, life,
other gentoo issues)

Another part: Git wasn't ready.
The first migration attempt failed after consuming nearly 100GB of RAM!
When it did work it took obscene amounts of time, and the result was
unusably large (e.g. initial checkout would take 16GB RAM on the server,
thus not allowing a few hundred devs to do checkouts the same day).
The current state is almost usable, but it is still obscenely slow (e.g.
initial clone taking ~10 CPU-minutes just to figure out what to do), but
we can just throw more hardware at it.
(10 minutes @ 3.6Ghz, so on my notebook it'll take about 4h to just
clone the friggin repository. Too awesome!)

Another part: Few people thought about the difficult problems in the
migration. For example the rsync mirrors, which will still be used - the
scripts that generate those will need to be changed, tested, and then
replaced if a migration ever happens.

If you fix all those you may have a chance, but with the current
performance pessimization I don't see git as viable for nontrivial
repositories. Seriously, I won't wait a few hours for it to clone, even
CVS is faster than that!

So get busy, figure out how to help, then your complaints will not be in
vain :)

Have fun,

Patrick

Re: [gentoo-dev] The infinite git migration

[Rich Freeman]

On Tue, Jun 10, 2014 at 6:59 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> The first migration attempt failed after consuming nearly 100GB of RAM!
> When it did work it took obscene amounts of time, and the result was
> unusably large (e.g. initial checkout would take 16GB RAM on the server,
> thus not allowing a few hundred devs to do checkouts the same day).

Well, effort required to do the migration isn't too big of a deal
since it is a one-time event.  As long as it can be done correctly, it
is good enough.  Ferringb was routinely crunching it in something like
an hour at the end of last year, granted on a system with an obscene
number of cores.

> The current state is almost usable, but it is still obscenely slow (e.g.
> initial clone taking ~10 CPU-minutes just to figure out what to do), but
> we can just throw more hardware at it.
> (10 minutes @ 3.6Ghz, so on my notebook it'll take about 4h to just
> clone the friggin repository. Too awesome!)

Hmm, can't say I've tried it on a variety of systems but I never had
trouble cloning it.  You are cloning from a bundle right, and not just
hitting the server for the whole tree, right?  The thought is to have
a hook that will block anybody from actually doing a full clone from
the server.  Instead users would clone from a bundle (either full or
with shallow history) and then do pulls from the server vs that.  The
bundle would just be distributed on the mirrors.

>
> Another part: Few people thought about the difficult problems in the
> migration. For example the rsync mirrors, which will still be used - the
> scripts that generate those will need to be changed, tested, and then
> replaced if a migration ever happens.

Well, I wouldn't say that few have thought about it.  The bigger issue
is that I don't think any of the existing code is published anywhere,
so it is a bit hard to contribute to it.  If that isn't the case I'm
happy to be corrected.

But, yes, that is the bigger block right now.

Rich

Re: [gentoo-dev] The infinite git migration

[Duy Nguyen]

On Wed, Jun 11, 2014 at 5:59 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> Another part: Git wasn't ready.
> The first migration attempt failed after consuming nearly 100GB of RAM!
> When it did work it took obscene amounts of time, and the result was
> unusably large (e.g. initial checkout would take 16GB RAM on the server,
> thus not allowing a few hundred devs to do checkouts the same day).
> The current state is almost usable, but it is still obscenely slow (e.g.
> initial clone taking ~10 CPU-minutes just to figure out what to do), but
> we can just throw more hardware at it.
> (10 minutes @ 3.6Ghz, so on my notebook it'll take about 4h to just
> clone the friggin repository. Too awesome!)

Since v1.9.0 we can clone from a shallow repository. We can host two
repos on the server: a full repo and a shallow one, containing history
of only last year. Most of the time spent in initial clone is to
verify the history. Shorter history would shorten that time. But you
need to try out to see how long it actually is. I'm not sure if that
16GB includes cloning, or just plain checkout. If the latter, Git has
a problem.
-- 
Duy

Re: [gentoo-dev] The infinite git migration

[Greg Turner]

On Tue, Jun 10, 2014 at 5:48 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> Since v1.9.0 we can clone from a shallow repository.

Wow, awesome!  Thank you, git developers, you rock (and sorry I'm too
lazy to tell you in your own mailing list :) )!

Re: [gentoo-dev] The infinite git migration

[Sergey Popov]

[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]

11.06.2014 04:48, Duy Nguyen пишет:
> On Wed, Jun 11, 2014 at 5:59 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>> Another part: Git wasn't ready.
>> The first migration attempt failed after consuming nearly 100GB of RAM!
>> When it did work it took obscene amounts of time, and the result was
>> unusably large (e.g. initial checkout would take 16GB RAM on the server,
>> thus not allowing a few hundred devs to do checkouts the same day).
>> The current state is almost usable, but it is still obscenely slow (e.g.
>> initial clone taking ~10 CPU-minutes just to figure out what to do), but
>> we can just throw more hardware at it.
>> (10 minutes @ 3.6Ghz, so on my notebook it'll take about 4h to just
>> clone the friggin repository. Too awesome!)
> 
> Since v1.9.0 we can clone from a shallow repository. We can host two
> repos on the server: a full repo and a shallow one, containing history
> of only last year. Most of the time spent in initial clone is to
> verify the history. Shorter history would shorten that time. But you
> need to try out to see how long it actually is. I'm not sure if that
> 16GB includes cloning, or just plain checkout. If the latter, Git has
> a problem.
> 

Not sure if you can commit into that shallow repo(IIRC, you can not). I
thought shallow clones is more suitable for users that want some state
but do not want the whole history.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] The infinite git migration

[Duy Nguyen]

On Wed, Jun 11, 2014 at 4:38 PM, Sergey Popov <pinkbyte@gentoo.org> wrote:
> 11.06.2014 04:48, Duy Nguyen пишет:
>> On Wed, Jun 11, 2014 at 5:59 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>>> Another part: Git wasn't ready.
>>> The first migration attempt failed after consuming nearly 100GB of RAM!
>>> When it did work it took obscene amounts of time, and the result was
>>> unusably large (e.g. initial checkout would take 16GB RAM on the server,
>>> thus not allowing a few hundred devs to do checkouts the same day).
>>> The current state is almost usable, but it is still obscenely slow (e.g.
>>> initial clone taking ~10 CPU-minutes just to figure out what to do), but
>>> we can just throw more hardware at it.
>>> (10 minutes @ 3.6Ghz, so on my notebook it'll take about 4h to just
>>> clone the friggin repository. Too awesome!)
>>
>> Since v1.9.0 we can clone from a shallow repository. We can host two
>> repos on the server: a full repo and a shallow one, containing history
>> of only last year. Most of the time spent in initial clone is to
>> verify the history. Shorter history would shorten that time. But you
>> need to try out to see how long it actually is. I'm not sure if that
>> 16GB includes cloning, or just plain checkout. If the latter, Git has
>> a problem.
>>
>
> Not sure if you can commit into that shallow repo(IIRC, you can not).

Not before v1.9.0. Since 1.9, shallow repos are no different than full
ones. You can fetch from a shallow repo, to a shallow repo, as well as
push from/to a shallow repo.
-- 
Duy

Re: [gentoo-dev] The infinite git migration

[Alex Xu]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

On 10/06/14 06:59 PM, Patrick Lauer wrote:
> [snip]

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

> The current state is almost usable, but it is still obscenely slow
> (e.g. initial clone taking ~10 CPU-minutes just to figure out what to
> do), but we can just throw more hardware at it.

https://bugs.gentoo.org/show_bug.cgi?id=333685:
> git 2.0 has pack-bitmap apparently :)
so once infra lands that that's basically the end of the major blockers
afaik

On 10/06/14 06:59 PM, Patrick Lauer wrote:
> Another part: Few people thought about the difficult problems in the
> migration. For example the rsync mirrors, which will still be used - the
> scripts that generate those will need to be changed, tested, and then
> replaced if a migration ever happens.

https://bugs.gentoo.org/show_bug.cgi?id=333701:
> What comment #2 should have said: "This bug is so low priority to the
> overall initiative that there shouldn't be anyone considering it a
> blocker, show me the git repo then we can talk" :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] The infinite git migration

[Rich Freeman]

On Wed, Jun 11, 2014 at 8:54 AM, Alex Xu <alex_y_xu@yahoo.ca> wrote:
>
> https://bugs.gentoo.org/show_bug.cgi?id=333701:
>> What comment #2 should have said: "This bug is so low priority to the
>> overall initiative that there shouldn't be anyone considering it a
>> blocker, show me the git repo then we can talk" :)
>

We have a git repo now.  We can generate one at any time.  We still
don't have infra tools.

I don't know if the repo is published anywhere, but there are plenty
of bundles on dev.gentoo.org:/space/git-work/

If the infra backend scripts are actually published somewhere where an
outside contributor can work on them and somebody is willing to do so,
I'd be more than happy to push a bundle to github, or post it
somewhere to download.

If people don't want to work on them, fine.  This is a volunteer
effort.  However, there really isn't any aspect of the git migration
that isn't worth working on.  If everybody is just going to sit around
until everybody else does their part of the task, then we might as
well give up now.  :)

So, I find stuff like comment #2 unhelpful, but at the same time
nobody is really obligated to help out here.  I just think that the
infra components are certainly worth working on.

Rich

Re: [gentoo-dev] The infinite git migration

[Rich Freeman]

On Wed, Jun 11, 2014 at 10:34 AM, Rich Freeman <rich0@gentoo.org> wrote:
> We have a git repo now.  We can generate one at any time.  We still
> don't have infra tools.
>
> I don't know if the repo is published anywhere, but there are plenty
> of bundles on dev.gentoo.org:/space/git-work/

So, if anybody does want to play around with Gentoo in git:
https://github.com/rich0/gentoo-gitmig-2014-02-21.git

This is just a snapshot from Feb.

As a side note, it took about 10min to push to github, then git sat
around waiting to terminate for 7min more before the remote side
dropped the connection.  At that point it appeared to have failed, but
a few hours later everything was there.  I'm sure the admins over at
github are cursing my name.

We need to get all the migration utility code published as well.  My
validation scripts are on github, with instructions on the wiki.

Rich

Re: [gentoo-dev] The state and future etc. etc.

[Patrick Lauer]

On 06/10/2014 03:52 AM, Thomas Kahle wrote:
> On 08/06/14 18:06, hasufell wrote:
>> I am not sure if that is a joke. You can pretty much ask most major
>> gentoo projects. The ones where I was involved more deeply definitely
>> suffer from that problem, including sunrise and games team. Science team
>> gave up importing major ebuilds to the tree and just let users manage
>> them on github, because that workflow sucks less.
> 
> I disagree with that point.  If you are referring to sage (or
> other larger science projects), then they stay in the overlay
> because people feel it is not worth the effort to fix the QA
> issues which in turn would be necessary before moving them to the
> main tree.

I've interacted with the nice people of the sage overlay - in that case
it's just the sheer amount of ebuilds, and no one on the gentoo side
with the time/motivation to take care of it. (I think I might have
borrowed a few of their ebuilds in the past)

QA issues are just an easy way to say "they be users, not us smart
devs", and that's just silly. If that were an issue you could start
fixing their ebuilds now, and once they are in good shape start
importing them. As no one has done that I'd say it's not a "QA" problem.
> 
> From what I can tell it has nothing to do with bugzilla
> vs. github.  For me personally bugzilla + a git tree (which is
> the situation we have for overlays anyway) is fine.

Ah, the old git turkey.

Personally I find github amazingly hard to figure out, usually I just
click around randomly in the webUI until something happens.

Migrating ebuilds is a lot of work, independent of VCS.

And if you want the git migration to happen, well, uhm, do something
about it. The only work that happened on it this year was me trying to
reproduce the last attempts to figure out where things are, a few people
like robbat2 providing data, and a few people like ferringb doing
minimal fixes to the existing migration scripts.

And I'm not even interested in using git!

Have fun,

Patrick

[gentoo-dev] Re: The state and future of the OpenRC project

[Michael Palimaka]

On 06/09/2014 12:41 AM, hasufell wrote:
> The amount of contributors (with real patches and real ebuilds) is
> constantly decreasing, because our workflow is horrible. I hope you
> don't actually think that bugzilla is an appropriate review platform.
The problem is finding improvements that everyone is happy with.
Gerrit is a no-go as Infra has expressed previously they do not want to
touch Java. I set up a public Review Board instance against gentoo-x86 a
while back but that saw zero instance.

In the KDE and Qt teams we've seen much improved rates of user
contribution since maintaining a mirror on GitHub, but excessive use may
cause a problem in relation to our social contract (and many people just
plain don't like GitHub).

Perhaps we could consider GitLab?

Re: [gentoo-dev] Re: The state and future of the OpenRC project

[Alexey Shvetsov]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

В письме от 9 июня 2014 01:36:49 пользователь Michael Palimaka написал:
> On 06/09/2014 12:41 AM, hasufell wrote:
> > The amount of contributors (with real patches and real ebuilds) is
> > constantly decreasing, because our workflow is horrible. I hope you
> > don't actually think that bugzilla is an appropriate review platform.
> 
> The problem is finding improvements that everyone is happy with.
> Gerrit is a no-go as Infra has expressed previously they do not want to
> touch Java. I set up a public Review Board instance against gentoo-x86 a
> while back but that saw zero instance.
> 
> In the KDE and Qt teams we've seen much improved rates of user
> contribution since maintaining a mirror on GitHub, but excessive use may
> cause a problem in relation to our social contract (and many people just
> plain don't like GitHub).
> 
> Perhaps we could consider GitLab?

Yep. Its better to have gitlab || gerrit || ReviewBoard 
Personaly i have only expirience with gerrit

However this will depend on migration of gentoo-x86 to git

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov, PhD
Department of Molecular and Radiation Biophysics
FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Leningrad region, Gatchina, Russia
mailto:alexxyum@gmail.com
mailto:alexxy@omrb.pnpi.spb.ru
mailto:alexxy@gentoo.org

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: The state and future of the OpenRC project

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/06/14 18:38, Alexey Shvetsov wrote:
>> Perhaps we could consider GitLab?
> 
> Yep. Its better to have gitlab || gerrit || ReviewBoard Personaly
> i have only expirience with gerrit
> 
> However this will depend on migration of gentoo-x86 to git
I really like Phabricator so far. It does not rely on a specific VCS
as far as I know. I have only used it with git though.
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlOUm1wACgkQRtClrXBQc7VOdQD/T+MqXoRDIClRCjMcX9AqWzTK
RoCxgZ13bf2nrLiIzvIA/2RU3aidtgU1Gg3RyBg75nSGWnGm0VnNSTkZ+nBM7pSI
=Wbly
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: The state and future of the OpenRC project

[heroxbd]

[-- Attachment #1: Type: text/plain, Size: 269 bytes --]

Alexey Shvetsov <alexxy@gentoo.org> writes:

> However this will depend on migration of gentoo-x86 to git

Well, we can start evaluating gitlab for git overlays and gentoo hosted
projects, such as (back to topic :) OpenRC.

Is the infra team interested in this option?

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: [gentoo-dev] Re: The state and future of the OpenRC project

[William Hubbs]

All,

I attempted to post an update a bit earlier, but I haven't seen it yet, 
so I thought I would try again.

Thanks to Daniel Robbins of funtoo, I am about to getGentoo installed on 
another box, so I will be able to take the lead on OpenRC again. He 
assisted me on Skype today with getting into setup on the box and 
setting the boot order so I can boot from a cd rom.

Also, he volunteered to work with me as a co-maintainer of OpenRC.

I should have the new box installed sometime tomorrow or Wednesday, then 
I will be around for a few days, then sometime on or after 18 June, I 
have a medical issue that I need to take care of. Once that is done, I 
should be back in the saddle so to speak.

You don't need to be a gentoo developer to work on OpenRC, that work is 
happening on the #openrc irc channel. Also, the primary OpenRC 
repository is http://github.com/openrc/openrc, feel free to fork that 
and submit pull requests. Once I am fully back up and running, I am 
planning on opening a mailing list for OpenRC.

Thanks for your patience,

William

Re: [gentoo-dev] Re: The state and future of the OpenRC project

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

Michael Palimaka <kensington@gentoo.org> writes:

> Perhaps we could consider GitLab?

+1 on that. I have deployed it recently at work and it seems to perform
well.  *Really* easy to use.  Easy to deploy as well.  It's written in
Ruby, *not Java*.  It's possible to have a basic integartion with
external issue trackers.  It also has an LDAP auth.


+1 on docs.

We should focus on forcing people who were involved into OpenRC to
document what they know.  I could do some contributions to OpenRC, but I
don't have time for reverse engineering.  I have developed some
experimental Plytmouth plugin to OpenRC, but it was really time
consuming to guess what does what...

We cannot let OpenRC die.  It cannot happen that systemd and upstart are
the only init systems.


-- 
Amadeusz Żołnowski

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: [gentoo-dev] Re: The state and future of the OpenRC project

[Rich Freeman]

On Mon, Jun 9, 2014 at 4:57 AM, Amadeusz Żołnowski <aidecoe@gentoo.org> wrote:
>
> We should focus on forcing people who were involved into OpenRC to
> document what they know.

Uh, you can't force anybody to do anything, and most of them are no
longer around.  You can always encourage or ask nicely.  You can also
set a policy of no further commits accepted without accompanying
documentation, but that could just as easily result in fewer commits
and not more documentation.

And this is why half of FOSS isn't well-documented.  Often the docs
aren't written by the same people who wrote the code.

Rich

Re: [gentoo-dev] Re: The state and future of the OpenRC project

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

Rich Freeman <rich0@gentoo.org> writes:

> Uh, you can't force anybody to do anything, and most of them are no
> longer around.  You can always encourage or ask nicely.

Yes, I meant that: forcing by asking nicely. :-)


> You can also set a policy of no further commits accepted without
> accompanying documentation, but that could just as easily result in
> fewer commits and not more documentation.

Yup, that's right, unfortunately.


-- 
Amadeusz Żołnowski

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: [gentoo-dev] The state and future of the OpenRC project

[heroxbd]

[-- Attachment #1: Type: text/plain, Size: 234 bytes --]

Alexander Berntsen <bernalex@gentoo.org> writes:

> It would be cool if some of the OpenRC hackers had the time to set up
> a developer's wiki or similar, where they share their workflow and
> similar. 

Nice idea, on my list.

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: [gentoo-dev] The state and future of the OpenRC project

[William Hubbs]

All,

just a quick update.

I now have a box set up for installing gentoo on it so I will be able to 
take the lead on OpenRC again.

I will have that up and running, probably tomorrow, then I also have a 
medical situation I have to take care of in a couple of weeks.

I will continue to be intermittently around for a few weeks, but that 
should all be taken care of soon.

If you want to help out, the #openrc irc channel is the place to go; 
that is where most things are done. You do not have to be a gentoo 
developer to contribute to OpenRC.

Daniel Robbins assisted me today with tweaking the bios of the box I 
plan to put Gentoo on so that I can boot it from a cdrom. Also he 
alerted me to this thread, so that is why I wanted to post this update.

He will also be becoming a co-maintainer of OpenRC, so you will see 
commits from him in the tree soon.

Once I am fully up and running again, I plan to open a ml for OpenRC 
development.

Thanks for your patience,

William



On 6/7/2014 4:08 PM, Jeroen Roovers wrote:
> On Sat, 07 Jun 2014 15:35:04 -0500
> Daniel Campbell <contact@sporkbox.us> wrote:
>
>>>   [2]: Overview of bugs that involve OpenRC, most for the package
>>> itself. https://bugs.gentoo.org/buglist.cgi?quicksearch=openrc
>> I think working on OpenRC would be a great learning experience for me
>> and would be a great opportunity to contribute to Gentoo.
> You can start fixing bugs immediately. You can check out the sources,
> write patches and attach the patches to the bug reports. Then all it
> takes is someone else to review/commit the patches.
>
>
>       jer
>

[gentoo-dev] Re: The state and future of the OpenRC project

[Duncan]

William Hubbs posted on Mon, 09 Jun 2014 22:14:34 -0500 as excerpted:

> Daniel Robbins assisted me today with tweaking the bios of the box I
> plan to put Gentoo on so that I can boot it from a cdrom. Also he
> alerted me to this thread, so that is why I wanted to post this update.
> 
> He will also be becoming a co-maintainer of OpenRC, so you will see
> commits from him in the tree soon.

Very positive development.  =:^)  A bus-factor of one isn't a good thing, 
particularly for something as critical as an init-manager.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] The state and future of the OpenRC project

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

On Sat, 7 Jun 2014 23:08:15 +0200 Jeroen Roovers wrote:
> On Sat, 07 Jun 2014 15:35:04 -0500
> Daniel Campbell <contact@sporkbox.us> wrote:
> 
> > >  [2]: Overview of bugs that involve OpenRC, most for the package
> > > itself. https://bugs.gentoo.org/buglist.cgi?quicksearch=openrc
> 
> > I think working on OpenRC would be a great learning experience for me
> > and would be a great opportunity to contribute to Gentoo.
> 
> You can start fixing bugs immediately. You can check out the sources,
> write patches and attach the patches to the bug reports. Then all it
> takes is someone else to review/commit the patches.

And who will review patches made? There are already six push
requests pending on OpenRC github for a long time:
https://github.com/OpenRC/openrc/pulls
And some of them are fixing long-standing severe bugs such as
https://bugs.gentoo.org/show_bug.cgi?id=391945 is fixed by:
https://github.com/OpenRC/openrc/pull/12
https://github.com/OpenRC/openrc/pull/13
We tested these patches on our infra and they work fine. Though
without upstream accepting/reviewing these changes for a long time
all enthusiasm dies slowly...

I understand that all devs have issues of their own to handle and I
don't want to blame anyone due to a lack of time. I just want to
point out that lack of contributions is only one side of a problem.
Another one is that someone with proper authority should take care
of such contributions.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] The state and future of the OpenRC project

[Jeroen Roovers]

On Tue, 10 Jun 2014 21:39:30 +0400
Andrew Savchenko <bircoph@gmail.com> wrote:

> On Sat, 7 Jun 2014 23:08:15 +0200 Jeroen Roovers wrote:
> > On Sat, 07 Jun 2014 15:35:04 -0500
> > Daniel Campbell <contact@sporkbox.us> wrote:
> > 
> > > >  [2]: Overview of bugs that involve OpenRC, most for the package
> > > > itself. https://bugs.gentoo.org/buglist.cgi?quicksearch=openrc
> > 
> > > I think working on OpenRC would be a great learning experience
> > > for me and would be a great opportunity to contribute to Gentoo.
> > 
> > You can start fixing bugs immediately. You can check out the
> > sources, write patches and attach the patches to the bug reports.
> > Then all it takes is someone else to review/commit the patches.
> 
> And who will review patches made?

Let's recap.

Post 1: OpenRC needs help
Post 2: I can write patches but I need help.
I     : You can write patches right now (or you can't).
You   : See Post 1.

Full circle. Now let's go back to derailing this thread further with
more posts about $better_tool. It's where things happen.


      jer

Re: [gentoo-dev] The state and future of the OpenRC project

[Patrick Lauer]

On 06/11/2014 01:39 AM, Andrew Savchenko wrote:
> On Sat, 7 Jun 2014 23:08:15 +0200 Jeroen Roovers wrote:
>> On Sat, 07 Jun 2014 15:35:04 -0500
>> Daniel Campbell <contact@sporkbox.us> wrote:
>>
>>>>  [2]: Overview of bugs that involve OpenRC, most for the package
>>>> itself. https://bugs.gentoo.org/buglist.cgi?quicksearch=openrc
>>
>>> I think working on OpenRC would be a great learning experience for me
>>> and would be a great opportunity to contribute to Gentoo.
>>
>> You can start fixing bugs immediately. You can check out the sources,
>> write patches and attach the patches to the bug reports. Then all it
>> takes is someone else to review/commit the patches.
> 
> And who will review patches made? There are already six push
> requests pending on OpenRC github for a long time:
> https://github.com/OpenRC/openrc/pulls
> And some of them are fixing long-standing severe bugs such as
> https://bugs.gentoo.org/show_bug.cgi?id=391945 is fixed by:
> https://github.com/OpenRC/openrc/pull/12
> https://github.com/OpenRC/openrc/pull/13
> We tested these patches on our infra and they work fine. Though
> without upstream accepting/reviewing these changes for a long time
> all enthusiasm dies slowly...

Some people like me don't github, so if it's not a bugreport on bugs.g.o
it'll just be ignored.

Duplicating stuff like that is still a bad idea ... (I have no idea why
some people are so eager to have multiple writable clones of repositories)
> 
> I understand that all devs have issues of their own to handle and I
> don't want to blame anyone due to a lack of time. I just want to
> point out that lack of contributions is only one side of a problem.
> Another one is that someone with proper authority should take care
> of such contributions.
As long as they are in the right place

[gentoo-dev] Re: The state and future of the OpenRC project

[Duncan]

Tom Wijsman posted on Sat, 07 Jun 2014 20:19:20 +0200 as excerpted:

> The OpenRC project appears less active these days than it used to be.
> 
> There are many commits per month the last years, but the amount of
> commits in 2014 per month has noticeably decreased to a crawl [1].
> Alongside that, there appears to be around ~100 bugs open for OpenRC [2]
> on Gentoo Bugzilla; some of which are left without a response.
> 
> This gives the impression that the development of it is slowing down.
> 
> Worth noting is that WilliamH recently had problems with his system, we
> have since not seen him on IRC for almost a month; so, this can for a
> part explain the last month of inactivity.
> 
>  [1]: Short log of proj/openrc history, decreasing commits in 2014.
>  http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=shortlog
> 
>  [2]: Overview of bugs that involve OpenRC, most for the package itself.
>  https://bugs.gentoo.org/buglist.cgi?quicksearch=openrc

Also worth noting.

For several years I was one of the few users (where gentoo devs count as 
users too) running live-git openrc-9999 and reporting issues, a 
significant number of which were fixed before they made it into a release 
at all.  Filter bugs on ALL sys-apps/openrc-9999 and take a look[a], 
there's others reporting issues early on, but since 2010, all but two of 
the bugs are mine, the two being the latest bug, filed and fixed in mid-
January, and one from 2013 that's actually a feature-request to duplicate 
git-log functionality in a changelog that was RESOLVED/WORKSFORME.

But I recently took the plunge and switched to systemd.  Given the bug 
history, that very likely means there is now almost almost *NO* one doing 
pre-release testing and bug-filing on live-git openrc-9999!  For openrc 
users and supporters[b] that could/should be quite an alarming danger 
sign!

For gentoo users/admins that are reasonably good in shell but don't 
really do C/C++ or even perl/python/etc, because so much of openrc is 
effectively shell scripts this is a rare opportunity to actually read 
code and very possibly contribute real patches, not just report bugs that 
otherwise there's limited opportunity to actually participate in fixing! 
=:^)

The biggest problem from my perspective as an openrc tester was (as 
bernalex already mentioned in a more general context) lack of 
documentation on the openrc-specific commands/shell-vars
called/used from what is otherwise effectively shell code.

Some of the vars are/were documented as part of the runscript (8) manpage, 
but for the commands, generally symlinks to the (single executable, multi-
call) executable itself, the only documentation I could find is that 
available from their help option, which is slightly inconvenient to get 
since these executables are considered openrc internals and are thus not 
exposed from the standard $PATH var.  I had filed a couple bugs [c,d] on 
this too but recently closed the commands bug [c] with a note that I'm on 
systemd now and thus couldn't really test documentation anyway, but that 
the bug could be reopened if anyone else was interested.  Williamh closed/
fixed the vars bug [d] back in January, but I didn't really look too 
closely to see how well the new documentation works as I switched not 
long after.

So anyway, "position open" for live-git openrc tester.  And should 
someone familiar enough with the openrc-internal commands to document 
them wish to do so, it would surely help anyone volunteering for that 
open position. =:^)

---
[a] 
https://bugs.gentoo.org/buglist.cgi?cmdtype=runnamed&namedcmd=openrc-9999

[b] While I'm no longer a user (except technically on one old system that 
I don't keep current) I still consider myself a supporter.

[c] Commands bug: https://bugs.gentoo.org/show_bug.cgi?id=489356
sys-apps/openrc many helper command symlinks undocumented

[d] Vars bug: https://bugs.gentoo.org/show_bug.cgi?id=489344
sys-apps/openrc RC_* vars undocumented in runscript (8)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman