| 1 |
Greg KH: |
| 2 |
> On Mon, Jun 30, 2014 at 04:15:55PM +0200, Jeroen Roovers wrote: |
| 3 |
>> On Mon, 30 Jun 2014 09:25:27 -0400 |
| 4 |
>> Rich Freeman <rich0@g.o> wrote: |
| 5 |
>> |
| 6 |
>>> Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED |
| 7 |
>>> AT ALL. The maintainer knows that they compile, and that is it. |
| 8 |
>> |
| 9 |
>> Developers who "HAVEN'T [...] TESTED AT ALL" and still commit their |
| 10 |
>> changes to the tree should immediately hand in their toys and leave |
| 11 |
>> the project. |
| 12 |
> |
| 13 |
> What toys? Were we given some when we became developers? If I had some |
| 14 |
> I'd send mine back in, but as I don't, I'll keep committing stable |
| 15 |
> kernel ebuilds that I never test as no one seems to be complaining... |
| 16 |
> |
| 17 |
> greg "never make absolute statements" k-h |
| 18 |
> |
| 19 |
|
| 20 |
Depends on what you mean with testing. Just renaming ebuilds like |
| 21 |
foo-1.2.ebuild -> foo-1.3.ebuild and letting the community figure out if |
| 22 |
that even makes sense (e.g. the ebuild dies in src_prepare, because a |
| 23 |
patch fails or is missing) is a bit rough, although it may work if you |
| 24 |
know the underlying package very well. |
| 25 |
|
| 26 |
If you are talking about actually testing and running the software then |
| 27 |
that's a different story and definitely not within our scope when |
| 28 |
committing to ~arch. |
| 29 |
|
| 30 |
That said, I think it's a reasonable minimum to at least check if an |
| 31 |
ebuild emerges on my current machine with my current setup before |
| 32 |
committing to ~arch. If even that fails, what's the point of committing |
| 33 |
the ebuild? |
Archives