| 1 |
On Sun, Jun 29, 2014 at 7:36 AM, hasufell <hasufell@g.o> wrote: |
| 2 |
> If something is that fragile that you want to add it to the tree masked, |
| 3 |
> maybe it isn't even ready for it yet. |
| 4 |
> Fun-stuff, alpha-software and other broken things have a good place in |
| 5 |
> overlays. |
| 6 |
|
| 7 |
How is not putting it in the tree at all better than putting it into |
| 8 |
the tree in a masked state? |
| 9 |
|
| 10 |
In neither case will ~arch users be testing it. |
| 11 |
|
| 12 |
I think the right approach depends on the situation. If you're taking |
| 13 |
about something where you have 47 packages that need |
| 14 |
coordination/testing/etc then an overlay makes sense. If you're |
| 15 |
talking about an isolated package, then creating an overlay for it |
| 16 |
seems like overkill. |
| 17 |
|
| 18 |
If the only one testing it is the maintainer then it probably |
| 19 |
shouldn't go in the tree. However, if the maintainer is working with |
| 20 |
others to actually test the package, then a short-term mask is |
| 21 |
probably fine. |
| 22 |
|
| 23 |
As I said earlier, though, it only makes sense if you're actually |
| 24 |
going to TEST the package. Adding it, masking it, and walking away |
| 25 |
for six months doesn't make sense. |
| 26 |
|
| 27 |
If a package is being masked because a dependency is being masked, |
| 28 |
that would be something worth noting in the Changelog. I also have no |
| 29 |
issues with requiring a bug reference. The purpose of the Changelog |
| 30 |
is to communicate, so we should be doing that. |
| 31 |
|
| 32 |
Rich |
Archives