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