1 |
On Fri, 22 Jun 2018 21:50:50 -0500 |
2 |
"Marty E. Plummer" <hanetzer@×××××××××.com> wrote: |
3 |
|
4 |
> So, as you may be aware I've been doing some work on moving bzip2 to an |
5 |
> autotools based build. Recently I've ran into app-crypt/mhash, which is |
6 |
> in a semi-abandoned state (talking with the maintainer on twitter atm), |
7 |
> and I was thinking it may be a good idea to set up a project for keeping |
8 |
> these semi-abandoned and really-abandoned libraries and projects up to |
9 |
> date and such. |
10 |
> |
11 |
> Basically, an upstream for packages who's upstream is either |
12 |
> uncontactable or is otherwise not accepting bug fixes and patches. So |
13 |
> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure |
14 |
> there are others in this state. |
15 |
|
16 |
It may be worth mentioning that myself and a handful of others are |
17 |
kicking around the idea of creating a "vendorised upstream", which |
18 |
essentially treats all upstreams as unmaintained, and acts as a middle |
19 |
ground between upstream and linux distributions/end users, by |
20 |
re-shipping upstreams code with fixes, in a format similar to |
21 |
upstreams, but with the mentality of a Linux Vendor. |
22 |
|
23 |
Changes to this project would of course be made under the assumption |
24 |
that upstream would one day wake up, and may be interested in adopting |
25 |
some or all of our fixes ( and for upstreams that are currently not |
26 |
actually dead, this may happen sooner than later ) |
27 |
|
28 |
Presently, this is limited in scope to vendorizing CPAN, but it may |
29 |
grow. |
30 |
|
31 |
In concept, this is of course much more work than your idea, but it has |
32 |
a few advantages, particularly with regards to integrating various |
33 |
vendors patches in a single place. |
34 |
|
35 |
But obviously, such a project is somewhat gargantuan, and getting the |
36 |
working concept off the ground is going to take a while :) |