| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Enrico Weigelt wrote: |
| 5 |
> The gentoo devs currently do much of the upstream's work. |
| 6 |
> Fixing bugs or even adding new stuff which does not directly have to |
| 7 |
> do w/ gentoo should be done exlusively by the upstream. |
| 8 |
> |
| 9 |
|
| 10 |
Not true at all. |
| 11 |
|
| 12 |
We (as developers) won't be able to avoid helping upstream (it is |
| 13 |
actually in our social contract). For example, we have dealt with |
| 14 |
packages inside our herd where we are able to reproduce and detect a bug |
| 15 |
before upstream does; or even found a "better" way of doing something, |
| 16 |
and upstream (lucky for us) has always been happy of receiving our |
| 17 |
suggestions/fixes , included even patches. |
| 18 |
|
| 19 |
I personally think there is nothing wrong with this, i see it actually |
| 20 |
as one of the goal of gentoo. |
| 21 |
|
| 22 |
> |
| 23 |
> For an oss-qm + gentoo connection I imagine the following workflow: |
| 24 |
> (should also work w/ other distros this way) |
| 25 |
> |
| 26 |
> * gentoo user files an bug -> gets assigned to the devs. |
| 27 |
> * dev inspects the bug whether its gentoo-specific or general |
| 28 |
> @ general: |
| 29 |
> * dev pushes the bug to oss-qm (files a bug there), |
| 30 |
> * oss-qm tries to solve this bug and releases a new hotfix |
| 31 |
> * the gentoo dev then takes in the hotfix and gives the |
| 32 |
> patched package into the QM cycle. |
| 33 |
> |
| 34 |
> @ gentoo: |
| 35 |
> * works as currently |
| 36 |
> |
| 37 |
> As for the suggested user contribution: |
| 38 |
> |
| 39 |
> The users willing to contribute simply join the oss-qm team and do |
| 40 |
> their works there. This at least would cope evrything that's not |
| 41 |
> gentoo specific. What remains to gentoo would be just the contents |
| 42 |
> of the ebuild file (ie. useflags and dependencies okay, etc). |
| 43 |
> |
| 44 |
|
| 45 |
I fail to see a border line between what you call 'gentoo specific' |
| 46 |
problems, and upstream problems. Really, it is not _that_ simple. |
| 47 |
|
| 48 |
Also, i don't see how this might be an alternative to my current proposal. |
| 49 |
|
| 50 |
|
| 51 |
- -- |
| 52 |
|
| 53 |
|
| 54 |
Luis F. Araujo "araujo at gentoo.org" |
| 55 |
Gentoo Linux |
| 56 |
|
| 57 |
|
| 58 |
-----BEGIN PGP SIGNATURE----- |
| 59 |
Version: GnuPG v1.4.4 (GNU/Linux) |
| 60 |
|
| 61 |
iD8DBQFEykgrdZ42PGEF17URAhleAKDgRx+zMNomW+UUUbg3dCvJmHdtggCbB25s |
| 62 |
hGHkKFzMQmA6q9tMIaz3IhU= |
| 63 |
=y4MH |
| 64 |
-----END PGP SIGNATURE----- |
| 65 |
-- |
| 66 |
gentoo-dev@g.o mailing list |
Archives