| 1 |
On Tue, Mar 6, 2018 at 5:22 PM, Matt Turner <mattst88@g.o> wrote: |
| 2 |
|
| 3 |
> On Tue, Mar 6, 2018 at 1:35 PM, Rich Freeman <rich0@g.o> wrote: |
| 4 |
> > On Tue, Mar 6, 2018 at 4:17 PM, Andreas K. Huettel <dilfridge@g.o> |
| 5 |
> wrote: |
| 6 |
> >> |
| 7 |
> >> Is it worth the effort? Yes, see below. |
| 8 |
> >> Is it a high priority task? No. |
| 9 |
> >> |
| 10 |
> > |
| 11 |
> > It sounds like all that has been done is to log a tracker and create |
| 12 |
> > some bugs. That is hardly a major burden on anybody. If it nudges |
| 13 |
> > people to bump the EAPI when they're doing other work so much the |
| 14 |
> > better, but there doesn't seem to be a drop-dead date yet. |
| 15 |
> > |
| 16 |
> > If devs don't want to think about EAPI cleanup they don't have to right |
| 17 |
> now. |
| 18 |
> |
| 19 |
> No, not true. Look at the blocking bugs. We're asking arch teams to |
| 20 |
> retest and restabilize ebuilds whose only difference is the EAPI bump. |
| 21 |
> |
| 22 |
> |
| 23 |
Ultimate the arch teams are supposed to test the ebuild (that it works), so |
| 24 |
when we change the EAPI of the ebuild re-testing is required. |
| 25 |
If we only cared about the ebuild (that it worked or not) we could use |
| 26 |
automation to cut down on the humans involved in this work. |
| 27 |
|
| 28 |
-A |
Archives