| 1 |
On Wed, Jun 8, 2011 at 7:17 AM, Duncan <1i5t5.duncan@×××.net> wrote: |
| 2 |
> He didn't say he was going to defy council, rather, that he simply |
| 3 |
> wouldn't be removing ebuilds /at/ /all/ until either the changelog is auto- |
| 4 |
> generated (making the case moot) or the council changes policy. |
| 5 |
> |
| 6 |
> That means they'll either fall to someone else to do, or will simply |
| 7 |
> remain there, but either way, it's quite different from directly defying |
| 8 |
> the council decision. |
| 9 |
> |
| 10 |
|
| 11 |
As long as all versions in the tree compile cleanly and are free from |
| 12 |
security issues, I don't see any issue with keeping older ebuilds |
| 13 |
around. If anything I think that some packages are too quick to |
| 14 |
remove ~arch versions. I run stable but accept the odd ~arch package. |
| 15 |
When I do accept a ~arch package I only accept one version of it with |
| 16 |
the goal of going stable once whatever drove me to accept ~arch gets |
| 17 |
there. When the ~arch package disappears I just have to re-evaluate |
| 18 |
my new options and try again, and sometimes it feels like I never end |
| 19 |
up in stable. (I do realize that a few types of packages will |
| 20 |
probably never be stable by their nature, and that is fine.) |
| 21 |
|
| 22 |
If old versions become QA issues then we already have processes to |
| 23 |
deal with that. It is the duty of maintainers to deal with such |
| 24 |
problems. |
| 25 |
|
| 26 |
In any case, the rule is simple - if you remove an ebuild you have to |
| 27 |
include a note in the Changelog. That could change, or it might not, |
| 28 |
or perhaps it will become automated, but either way it is the rule |
| 29 |
right now. |
| 30 |
|
| 31 |
One thing I will say is that I appreciate the civility in this thread |
| 32 |
so far. I think everybody on both sides of the issue realizes that |
| 33 |
this is contentious, and I think everybody would be open to a better |
| 34 |
solution. |
| 35 |
|
| 36 |
Rich |
Archives