1 |
On Sun, Aug 5, 2018 at 12:45 PM, Richard Yao <ryao@g.o> wrote: |
2 |
|
3 |
> |
4 |
> |
5 |
> On Jun 23, 2018, at 6:59 AM, Alec Warner <antarus@g.o> wrote: |
6 |
> |
7 |
> |
8 |
> |
9 |
> On Sat, Jun 23, 2018 at 3:30 AM, Marty E. Plummer <hanetzer@×××××××××.com> |
10 |
> wrote: |
11 |
> |
12 |
>> On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote: |
13 |
>> > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E. |
14 |
>> > Plummer napisał: |
15 |
>> > > So, as you may be aware I've been doing some work on moving bzip2 to |
16 |
>> an |
17 |
>> > > autotools based build. Recently I've ran into app-crypt/mhash, which |
18 |
>> is |
19 |
>> > > in a semi-abandoned state (talking with the maintainer on twitter |
20 |
>> atm), |
21 |
>> > > and I was thinking it may be a good idea to set up a project for |
22 |
>> keeping |
23 |
>> > > these semi-abandoned and really-abandoned libraries and projects up to |
24 |
>> > > date and such. |
25 |
>> > > |
26 |
>> > > Basically, an upstream for packages who's upstream is either |
27 |
>> > > uncontactable or is otherwise not accepting bug fixes and patches. So |
28 |
>> > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm |
29 |
>> sure |
30 |
>> > > there are others in this state. |
31 |
>> > > |
32 |
>> > |
33 |
>> > So in order to fix problem of semi-abandoned packages, you're creating |
34 |
>> > an indirect herd-like entity that will soon be semi-abandoned itself |
35 |
>> > because people will be dumping random packages into it and afterwards |
36 |
>> > nobody will claim responsibility for them. |
37 |
>> > |
38 |
>> > -- |
39 |
>> > Best regards, |
40 |
>> > Michał Górny |
41 |
>> |
42 |
>> No, I mean for packages which are important enough in gentoo to warrant |
43 |
>> such treatment. For instance, every email I've tried for bzip2's |
44 |
>> upstream bounced or recieved no reply. That, I assume, is important |
45 |
>> enough to actually maintain and improve. Any other library which may be |
46 |
>> as important which are as inactive would be added. |
47 |
>> |
48 |
>> |
49 |
> I suspect this might be better done in the Linux foundation itself as they |
50 |
> have staffing for core components that everyone is using. |
51 |
> |
52 |
> This would put decision making power into the hands of bureaucrats. I |
53 |
> would rather it remain in a community of volunteers. |
54 |
> |
55 |
|
56 |
Meh, it doesn't hurt to ask there about interest (they certainly fund |
57 |
development of other components.) Its not like they have to accept, or that |
58 |
declining somehow inhibits this development. |
59 |
|
60 |
Part of my frustration is that seemingly "anything open source related can |
61 |
be held in Gentoo" and I'm somewhat against that as I feel it dilutes the |
62 |
Gentoo mission. We are here to make a distribution, not maintain random |
63 |
libraries. If you want to do that feel free; but I don't see a need for |
64 |
that work to be associated with Gentoo. |
65 |
|
66 |
|
67 |
> |
68 |
> I consider upstream development efforts by Gentoo developers to be |
69 |
> beneficial to Gentoo. Nothing makes fixing an issue in Gentoo at upstream a |
70 |
> priority quite like it affecting a key upstream developer in his day to day |
71 |
> life. |
72 |
> |
73 |
|
74 |
> |
75 |
> Also, the Linux Foundation is not embarking on such a project and we |
76 |
> clearly have someone willing to try, so I say that we should go for it. |
77 |
> Having people that wish to take a more active role in upstream development |
78 |
> would not make us any worse off. It is their time to volunteer, so it is |
79 |
> not like they will volunteer it for something else if we discourage them. |
80 |
> |