| 1 |
On Thu, 18 Aug 2011 11:57:01 +0200 |
| 2 |
Diego Elio Pettenò <flameeyes@g.o> wrote: |
| 3 |
|
| 4 |
> Il giorno gio, 18/08/2011 alle 11.15 +0200, Thomas Sachau ha scritto: |
| 5 |
> > |
| 6 |
> > The argument about dropped tarballs, once the ebuilds gets removed |
| 7 |
> > might weight a bit more, but you |
| 8 |
> > cannot depend on other upstream keeping their tarballs around |
| 9 |
> > forever, so i see no requirement for |
| 10 |
> > us preserving only specific tarballs (those created by our devs), |
| 11 |
> > while upstream tarballs could |
| 12 |
> > already be gone and are not preserved, once the ebuild for it is |
| 13 |
> > gone. |
| 14 |
> |
| 15 |
> _Most_ upstream projects keep tarballs available of all historic |
| 16 |
> releases; okay maybe not _all_ projects, but most, especially those |
| 17 |
> using services such as SourceForge, Google Code, RubyForge, |
| 18 |
> Rubygems, ... |
| 19 |
> |
| 20 |
> For _our_ projects, snapshots, or packages, let's try to apply a sane |
| 21 |
> policy. And that starts by not arguing that we shouldn't be doing so |
| 22 |
> because others might not be doing so themselves. |
| 23 |
|
| 24 |
I'd say do it like that: |
| 25 |
|
| 26 |
1) for our projects -- keep all historical releases (be a good |
| 27 |
upstream), |
| 28 |
|
| 29 |
2) for snapshots -- keep them as long as they're used (considering that |
| 30 |
a snapshot could be recreated at any point), |
| 31 |
|
| 32 |
3) for patches -- it would be great if we could keep them as long as |
| 33 |
upstream keeps the relevant tarballs. |
| 34 |
|
| 35 |
-- |
| 36 |
Best regards, |
| 37 |
Michał Górny |
Archives