Removal of old projects from fedorahosted.

[susmit shannigrahi]

Hi,

This is w.r.t to ticket #714[1].

As explained by mmcgrath, Fedora has a policy to remove _any_ hosted
projects that are
not altered or updated for last six months.

Here is the list of projects, which falls into this category and they
will soon be removed.

--------------------------------------------------------------------------------------------------------------------
These directories have not been altered for 6 months
/srv/svn/hardlink 	 group: svnhardlink
/srv/svn/package-jitsu 	 group: svnpackage-jitsu
/srv/svn/repoview 	 group: svnrepoview
/srv/svn/ols 	 group: svnols
/srv/svn/setarch 	 group: svnsetarch
/srv/svn/authd 	 group: svnauthd
/srv/svn/system-config-keyboard.old 	 group: svnsystem-config-keyboard


/srv/hg/camelus 	 group: hgcamelus
/srv/hg/passwd 	 group: hgpasswd
/srv/hg/bodhi.old 	 group: gitbodhi
/srv/hg/guest-account 	 group: hgguest-account
/srv/hg/timeconfig 	 group: hgtimeconfig
/srv/hg/LHCP 	 group: hgLHCP
/srv/hg/virt-manager 	 group: hgvirt-manager
/srv/hg/pam-redhat 	 group: hgpam-redhat
/srv/hg/tmpwatch 	 group: hgtmpwatch


/srv/git/splatbind.git 	 group: gitsplatbind
/srv/git/system-config-securitylevel.git 	 group: gitsystem-config-securitylevel


If you have any update with respect to this, and don't want any/some
project(s) be removed, please
let us know.

Thanks.



[1]https://fedorahosted.org/fedora-infrastructure/ticket/714


-- 
Regards,
Susmit.

=============================================
ssh
0x86DD170A
http://www.fedoraproject.org/wiki/user:susmit
=============================================

[Mike McGrath]

On Tue, 9 Sep 2008, susmit shannigrahi wrote:

>  Hi,
>
>  This is w.r.t to ticket #714[1].
>
>  As explained by mmcgrath, Fedora has a policy to remove _any_ hosted
>  projects that are
>  not altered or updated for last six months.
>
>  Here is the list of projects, which falls into this category and they
>  will soon be removed.
>
>
> --------------------------------------------------------------------------------------------------------------------
>  These directories have not been altered for 6 months
>  /srv/svn/hardlink 	 group: svnhardlink
>  /srv/svn/package-jitsu 	 group: svnpackage-jitsu
>  /srv/svn/repoview 	 group: svnrepoview
>  /srv/svn/ols 	 group: svnols
>  /srv/svn/setarch 	 group: svnsetarch
>  /srv/svn/authd 	 group: svnauthd
>  /srv/svn/system-config-keyboard.old 	 group: svnsystem-config-keyboard
>
>
>  /srv/hg/camelus 	 group: hgcamelus
>  /srv/hg/passwd 	 group: hgpasswd
>  /srv/hg/bodhi.old 	 group: gitbodhi
>  /srv/hg/guest-account 	 group: hgguest-account
>  /srv/hg/timeconfig 	 group: hgtimeconfig
>  /srv/hg/LHCP 	 group: hgLHCP
>  /srv/hg/virt-manager 	 group: hgvirt-manager
>  /srv/hg/pam-redhat 	 group: hgpam-redhat
>  /srv/hg/tmpwatch 	 group: hgtmpwatch
>
>
>  /srv/git/splatbind.git 	 group: gitsplatbind
>  /srv/git/system-config-securitylevel.git 	 group: gitsystem-config-securitylevel
>
>
>  If you have any update with respect to this, and don't want any/some
>  project(s) be removed, please
>  let us know.
>
>
>  [1]https://fedorahosted.org/fedora-infrastructure/ticket/714
>  
So I guess the best thing from here is to send an email to each group
notifying them of what has happened and why we'd like to remove their
project.  tell them how to get the code off if they still want it, etc,
etc.

Lots of people on this list use hosted projects, what do you think?

	-Mike

[Bill Nottingham]

Mike McGrath (mmcgrath(a)redhat.com) said: 
>  > [1]https://fedorahosted.org/fedora-infrastructure/ticket/714
>  
>  So I guess the best thing from here is to send an email to each group
>  notifying them of what has happened and why we'd like to remove their
>  project.  tell them how to get the code off if they still want it, etc,
>  etc.
>  
>  Lots of people on this list use hosted projects, what do you think? 
I'm leery of having a hard and fast 6-month-rule; especially for
projects which aren't translated, it's possible to have a decent period
without code changes.

Maybe review-at-six-months?

Bill

[Jeremy Katz]

On Tue, 2008-09-09 at 20:33 +0530, susmit shannigrahi wrote:
>  As explained by mmcgrath, Fedora has a policy to remove _any_ hosted
>  projects that are
>  not altered or updated for last six months. 
Hmmm -- this seems a little problematic.  It's definitely possible to
have a "mature" project which doesn't see a lot of changes.  Not that
all of these necessarily fall into that case, but some of them
definitely do

Jeremy

[Mike McGrath]

On Tue, 9 Sep 2008, Jeremy Katz wrote:

>  On Tue, 2008-09-09 at 20:33 +0530, susmit shannigrahi wrote:
>  > As explained by mmcgrath, Fedora has a policy to remove _any_ hosted
>  > projects that are
>  > not altered or updated for last six months.
>
>  Hmmm -- this seems a little problematic.  It's definitely possible to
>  have a "mature" project which doesn't see a lot of changes.  Not that
>  all of these necessarily fall into that case, but some of them
>  definitely do
>  
It's not actually a hard and fast rule.  The wording is:

https://fedorahosted.org/web/terms

"The Fedora Project reserves the right to remove any project from our
system that does not meet the following criteria:

   1. Code contained in the project does not meet our license requirements
   2. No significant changes have been committed or applied for at least
six (6) months
"

	-Mike

[Matt Domsch]

On Tue, Sep 09, 2008 at 12:02:04PM -0400, Jeremy Katz wrote:
>  On Tue, 2008-09-09 at 20:33 +0530, susmit shannigrahi wrote:
>  > As explained by mmcgrath, Fedora has a policy to remove _any_ hosted
>  > projects that are
>  > not altered or updated for last six months.
>  
>  Hmmm -- this seems a little problematic.  It's definitely possible to
>  have a "mature" project which doesn't see a lot of changes.  Not that
>  all of these necessarily fall into that case, but some of them
>  definitely do 
yeah, like setarch.  Isn't likely to change much...


-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

[Karel Zak]

On Tue, Sep 09, 2008 at 02:35:56PM -0500, Matt Domsch wrote:
>  On Tue, Sep 09, 2008 at 12:02:04PM -0400, Jeremy Katz wrote:
>  > On Tue, 2008-09-09 at 20:33 +0530, susmit shannigrahi wrote:
>  > > As explained by mmcgrath, Fedora has a policy to remove _any_ hosted
>  > > projects that are
>  > > not altered or updated for last six months.
>  > 
>  > Hmmm -- this seems a little problematic.  It's definitely possible to
>  > have a "mature" project which doesn't see a lot of changes.  Not that
>  > all of these necessarily fall into that case, but some of them
>  > definitely do 
 good point.

>  yeah, like setarch.  Isn't likely to change much... 
 Bad example. setarch(1) was merged into util-linux-ng one year ago.

    Karel

-- 
 Karel Zak  <kzak(a)redhat.com&gt;

[Debarshi Ray]

>  As explained by mmcgrath, Fedora has a policy to remove _any_ hosted
>  projects that are
>  not altered or updated for last six months. 
I am pleasantly suprised to see that Opyum is not in that list. :-)

The thing with Opyum is that its functionality has been very nicely
ported to PackageKit by one of my friends during this year's Google
Summer of Code. Fedora 8 still caries Opyum, but its useless for
Fedora 9 and onwards. I just want to wait till Fedora 8 is EOLed after
which I would not want it to hog resources on fedorahosted.org any
more.

Happy hacking,
Debarshi

[Ian Weller]

On Tue, Sep 09, 2008 at 10:20:25PM +0530, Debarshi Ray wrote:
>  The thing with Opyum is that its functionality has been very nicely
>  ported to PackageKit by one of my friends during this year's Google
>  Summer of Code. Fedora 8 still caries Opyum, but its useless for
>  Fedora 9 and onwards. I just want to wait till Fedora 8 is EOLed after
>  which I would not want it to hog resources on fedorahosted.org any
>  more.
>   
SourceForge.net (gah! I know) has a policy that not only prevents
projects from being automatically removed simply for the sake of being
idle, but that prevents most projects from being removed at all, even at
the developer's request; this policy is for the contingency of source
code, making it still available to people who still want it, even though
the project may be dead.

If there's no way to retrieve the source code for a project that has
been removed from Fedora Hosted, is the project not gone forever -- and
more importantly, do we want that?

-- 
Ian Weller <ianweller(a)gmail.com&gt;                  http://ianweller.org
GnuPG fingerprint:  E51E 0517 7A92 70A2 4226  B050 87ED 7C97 EFA8 4A36
"Technology is a word that describes something that doesn't work yet."
  ~ Douglas Adams

[Mike McGrath]

On Tue, 9 Sep 2008, Ian Weller wrote:

>  On Tue, Sep 09, 2008 at 10:20:25PM +0530, Debarshi Ray wrote:
>  > The thing with Opyum is that its functionality has been very nicely
>  > ported to PackageKit by one of my friends during this year's Google
>  > Summer of Code. Fedora 8 still caries Opyum, but its useless for
>  > Fedora 9 and onwards. I just want to wait till Fedora 8 is EOLed after
>  > which I would not want it to hog resources on fedorahosted.org any
>  > more.
>  >
>  SourceForge.net (gah! I know) has a policy that not only prevents
>  projects from being automatically removed simply for the sake of being
>  idle, but that prevents most projects from being removed at all, even at
>  the developer's request; this policy is for the contingency of source
>  code, making it still available to people who still want it, even though
>  the project may be dead.
>  
This is one of the things we're hoping to prevent with fedorahosted.  The
hope is that the fedorahosted brand will be known for good, active
projects.  Not vaporware.

>  If there's no way to retrieve the source code for a project that
> has
>  been removed from Fedora Hosted, is the project not gone forever -- and
>  more importantly, do we want that?
>  
Depends.  We'll certainly be contacting the project members and let them
know whats up giving them the option to grab the raw source tree (already
available via rsync) and the trac install.

In general from the infrastructure side I'd say we want to keep the
barrier to enter low but the quality high.  Certainly there's projects
that don't need to be updated every 6 months but we can identify those and
deal accordingly.

	-Mike

[Ian Weller]

On Tue, Sep 09, 2008 at 03:35:41PM -0500, Mike McGrath wrote:
>  This is one of the things we're hoping to prevent with
> fedorahosted.  The
>  hope is that the fedorahosted brand will be known for good, active
>  projects.  Not vaporware.
>  
>  We'll certainly be contacting the project members and let them
>  know whats up giving them the option to grab the raw source tree (already
>  available via rsync) and the trac install.
>  
>  In general from the infrastructure side I'd say we want to keep the
>  barrier to enter low but the quality high.  Certainly there's projects
>  that don't need to be updated every 6 months but we can identify those and
>  deal accordingly.
>   
None of this seems to agree with the open source philosophy. From what I
understand, one should always be able to access code, whether dead,
buggy, or release candidate, or whatever. I understand the idea of
keeping a code center clean and newish, but I think it would turn away
more projects than dead codebases would.

-- 
Ian Weller <ianweller(a)gmail.com&gt;                  http://ianweller.org
GnuPG fingerprint:  E51E 0517 7A92 70A2 4226  B050 87ED 7C97 EFA8 4A36
"Technology is a word that describes something that doesn't work yet."
  ~ Douglas Adams

[Mike McGrath]

On Tue, 9 Sep 2008, Ian Weller wrote:

>  On Tue, Sep 09, 2008 at 03:35:41PM -0500, Mike McGrath wrote:
>  > This is one of the things we're hoping to prevent with fedorahosted.  The
>  > hope is that the fedorahosted brand will be known for good, active
>  > projects.  Not vaporware.
>  >
>  > We'll certainly be contacting the project members and let them
>  > know whats up giving them the option to grab the raw source tree (already
>  > available via rsync) and the trac install.
>  >
>  > In general from the infrastructure side I'd say we want to keep the
>  > barrier to enter low but the quality high.  Certainly there's projects
>  > that don't need to be updated every 6 months but we can identify those and
>  > deal accordingly.
>  >
>  None of this seems to agree with the open source philosophy. From what I
>  understand, one should always be able to access code, whether dead,
>  buggy, or release candidate, or whatever. I understand the idea of
>  keeping a code center clean and newish, but I think it would turn away
>  more projects than dead codebases would.
>  
Let me know when you get archives.fedorahosted.org up, I'll make sure to
send all this unused code your way ;-)

We're not trying to be the end all hosting for everyone.  If that turns
people away, there are plenty of alternatives.  We're looking for people
who have active and interesting projects.

	-Mike

[Robin Norwood]

On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath <mmcgrath(a)redhat.com&gt; wrote:
>  In general from the infrastructure side I'd say we want to keep
> the
>  barrier to enter low but the quality high.  Certainly there's projects
>  that don't need to be updated every 6 months but we can identify those and
>  deal accordingly. 
How about 'delisting' instead of deleting?  I'm operating under the
assumption that the infrastructure burden of hosting the project isn't
the problem you're trying to solve, and that keeping the projects at
fedora hosted relevant is.

A delisted project simply wouldn't appear on the main fedora hosted
list of projects, but would still be available via direct link.  That
way, nothing is lost, but the clutter vanishes.

You could even have yet another category for projects that are known
to be abandoned.

-RN

-- 
Robin Norwood

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching

[brett lentz]

>  -----Original Message-----
>  From: fedora-infrastructure-list-bounces(a)redhat.com [mailto:fedora-
>  infrastructure-list-bounces(a)redhat.com] On Behalf Of Robin Norwood
>  Sent: Tuesday, September 09, 2008 6:11 PM
>  To: Fedora Infrastructure
>  Subject: Re: Removal of old projects from fedorahosted.
>  
>  On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath <mmcgrath(a)redhat.com&gt;
>  wrote:
>  > In general from the infrastructure side I'd say we want to keep the
>  > barrier to enter low but the quality high.  Certainly there's
>  projects
>  > that don't need to be updated every 6 months but we can identify
>  those and
>  > deal accordingly.
>  
>  How about 'delisting' instead of deleting?  I'm operating under the
>  assumption that the infrastructure burden of hosting the project isn't
>  the problem you're trying to solve, and that keeping the projects at
>  fedora hosted relevant is.
>  
>  A delisted project simply wouldn't appear on the main fedora hosted
>  list of projects, but would still be available via direct link.  That
>  way, nothing is lost, but the clutter vanishes.
>  
>  You could even have yet another category for projects that are known
>  to be abandoned.
>   
What about using a Sourceforge-style project classification scheme? Allow
projects to self-identify their status (Alpha, Beta, Stable, Abandoned,
etc.). That would allow us to craft policies around project updates that are
more in line with their current development status. It would also allow us
to filter the main project page according to development status.

For example: maybe alpha projects need to be updated at least every 3-6
months, but stable projects would only need a minimum of a yearly or
bi-yearly update to be considered "actively maintained."

---Brett.

[Mike McGrath]

On Tue, 9 Sep 2008, Brett Lentz wrote:

>  > -----Original Message-----
>  > From: fedora-infrastructure-list-bounces(a)redhat.com [mailto:fedora-
>  > infrastructure-list-bounces(a)redhat.com] On Behalf Of Robin Norwood
>  > Sent: Tuesday, September 09, 2008 6:11 PM
>  > To: Fedora Infrastructure
>  > Subject: Re: Removal of old projects from fedorahosted.
>  >
>  > On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath <mmcgrath(a)redhat.com&gt;
>  > wrote:
>  > > In general from the infrastructure side I'd say we want to keep the
>  > > barrier to enter low but the quality high.  Certainly there's
>  > projects
>  > > that don't need to be updated every 6 months but we can identify
>  > those and
>  > > deal accordingly.
>  >
>  > How about 'delisting' instead of deleting?  I'm operating under the
>  > assumption that the infrastructure burden of hosting the project isn't
>  > the problem you're trying to solve, and that keeping the projects at
>  > fedora hosted relevant is.
>  >
>  > A delisted project simply wouldn't appear on the main fedora hosted
>  > list of projects, but would still be available via direct link.  That
>  > way, nothing is lost, but the clutter vanishes.
>  >
>  > You could even have yet another category for projects that are known
>  > to be abandoned.
>  >
>
>  What about using a Sourceforge-style project classification scheme? Allow
>  projects to self-identify their status (Alpha, Beta, Stable, Abandoned,
>  etc.). That would allow us to craft policies around project updates that are
>  more in line with their current development status. It would also allow us
>  to filter the main project page according to development status.
>
>  For example: maybe alpha projects need to be updated at least every 3-6
>  months, but stable projects would only need a minimum of a yearly or
>  bi-yearly update to be considered "actively maintained."
>  
Why?

	-Mike

[brett lentz]

>  -----Original Message-----
>  From: fedora-infrastructure-list-bounces(a)redhat.com [mailto:fedora-
>  infrastructure-list-bounces(a)redhat.com] On Behalf Of Mike McGrath
>  Sent: Tuesday, September 09, 2008 6:37 PM
>  To: Fedora Infrastructure
>  Subject: RE: Removal of old projects from fedorahosted.
>  
>  On Tue, 9 Sep 2008, Brett Lentz wrote:
>  
>  > > -----Original Message-----
>  > > From: fedora-infrastructure-list-bounces(a)redhat.com [mailto:fedora-
>  > > infrastructure-list-bounces(a)redhat.com] On Behalf Of Robin Norwood
>  > > Sent: Tuesday, September 09, 2008 6:11 PM
>  > > To: Fedora Infrastructure
>  > > Subject: Re: Removal of old projects from fedorahosted.
>  > >
>  > > On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath <mmcgrath(a)redhat.com&gt;
>  > > wrote:
>  > > > In general from the infrastructure side I'd say we want to keep
>  the
>  > > > barrier to enter low but the quality high.  Certainly there's
>  > > projects
>  > > > that don't need to be updated every 6 months but we can identify
>  > > those and
>  > > > deal accordingly.
>  > >
>  > > How about 'delisting' instead of deleting?  I'm operating under
> the
>  > > assumption that the infrastructure burden of hosting the project
>  isn't
>  > > the problem you're trying to solve, and that keeping the projects
>  at
>  > > fedora hosted relevant is.
>  > >
>  > > A delisted project simply wouldn't appear on the main fedora hosted
>  > > list of projects, but would still be available via direct link.
>  That
>  > > way, nothing is lost, but the clutter vanishes.
>  > >
>  > > You could even have yet another category for projects that are
>  known
>  > > to be abandoned.
>  > >
>  >
>  > What about using a Sourceforge-style project classification scheme?
>  Allow
>  > projects to self-identify their status (Alpha, Beta, Stable,
>  Abandoned,
>  > etc.). That would allow us to craft policies around project updates
>  that are
>  > more in line with their current development status. It would also
>  allow us
>  > to filter the main project page according to development status.
>  >
>  > For example: maybe alpha projects need to be updated at least every
>  3-6
>  > months, but stable projects would only need a minimum of a yearly or
>  > bi-yearly update to be considered "actively maintained."
>  >
>  
>  Why?
>   
This would help prevent having more stable projects up on the chopping block
every six months simply because they haven't done anything recently. 

Obviously, each time this comes up, fedora-admin will gradually collect this
information anyway just by virtue of having the discussion of whom to
delete. 

However, it doesn't make sense to me to discard this information each time
the current discussion ends. It also doesn't makes sense to continually
rehash this same discussion over the same projects every six months if
everyone suddenly forgets that the foo project is a stable app that doesn't
see many updates because it "just works." Or, more plausibly, whenever we
have a new member that asks "what about project foo? Why doesn't it get
deleted?"

It seems like it would be better to just have a more robust process and
encourage project state information to be better documented for future
discussions and future admins.

It's also entirely possible that I'm over-thinking the issue. :-)

---Brett.

[Mike McGrath]

On Tue, 9 Sep 2008, Brett Lentz wrote:

>  > -----Original Message-----
>  > From: fedora-infrastructure-list-bounces(a)redhat.com [mailto:fedora-
>  > infrastructure-list-bounces(a)redhat.com] On Behalf Of Robin Norwood
>  > Sent: Tuesday, September 09, 2008 6:11 PM
>  > To: Fedora Infrastructure
>  > Subject: Re: Removal of old projects from fedorahosted.
>  >
>  > On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath <mmcgrath(a)redhat.com&gt;
>  > wrote:
>  > > In general from the infrastructure side I'd say we want to keep the
>  > > barrier to enter low but the quality high.  Certainly there's
>  > projects
>  > > that don't need to be updated every 6 months but we can identify
>  > those and
>  > > deal accordingly.
>  >
>  > How about 'delisting' instead of deleting?  I'm operating under the
>  > assumption that the infrastructure burden of hosting the project isn't
>  > the problem you're trying to solve, and that keeping the projects at
>  > fedora hosted relevant is.
>  >
>  > A delisted project simply wouldn't appear on the main fedora hosted
>  > list of projects, but would still be available via direct link.  That
>  > way, nothing is lost, but the clutter vanishes.
>  >
>  > You could even have yet another category for projects that are known
>  > to be abandoned.
>  >
>
>  What about using a Sourceforge-style project classification scheme? Allow
>  projects to self-identify their status (Alpha, Beta, Stable, Abandoned,
>  etc.). That would allow us to craft policies around project updates that are
>  more in line with their current development status. It would also allow us
>  to filter the main project page according to development status.
>
>  For example: maybe alpha projects need to be updated at least every 3-6
>  months, but stable projects would only need a minimum of a yearly or
>  bi-yearly update to be considered "actively maintained."
>  
Actually re-reading this I think people are confused about my intent.
We're going to contact the individuals to let them know their options.  If
they really want to keep the repo around and they have a good reason,
it'll probably stay around.  not all repos are active every 6 months but
they are still important projects.  However there are probably lots of
projects that don't fit into this category, and they're more then welcome
to host their projects elsewhere.  As I explained earlier its not a hard
and fast rule, we just reserve the right to remove it.

	-Mike

[Mike McGrath]

On Tue, 9 Sep 2008, Robin Norwood wrote:

>  On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath
> <mmcgrath(a)redhat.com&gt; wrote:
>  > In general from the infrastructure side I'd say we want to keep the
>  > barrier to enter low but the quality high.  Certainly there's projects
>  > that don't need to be updated every 6 months but we can identify those and
>  > deal accordingly.
>
>  How about 'delisting' instead of deleting?  I'm operating under the
>  assumption that the infrastructure burden of hosting the project isn't
>  the problem you're trying to solve, and that keeping the projects at
>  fedora hosted relevant is.
>
>  A delisted project simply wouldn't appear on the main fedora hosted
>  list of projects, but would still be available via direct link.  That
>  way, nothing is lost, but the clutter vanishes.
>
>  You could even have yet another category for projects that are known
>  to be abandoned.
>  
Nope, the terms of use are already pretty clear.  And no one has provided
a compelling reason to keep these projects around, just lots of
suggestions on how to keep them around.  Deleted is what we want, not
delisted or saved forever or anything like that.  We're not going to
commit any resources to a project that choosed not to use this free
service.

	-Mike

[Robin Norwood]

On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath <mmcgrath(a)redhat.com&gt; wrote:
>  Nope, the terms of use are already pretty clear.  And no one has
> provided
>  a compelling reason to keep these projects around, just lots of
>  suggestions on how to keep them around.  Deleted is what we want, not
>  delisted or saved forever or anything like that.  We're not going to
>  commit any resources to a project that choosed not to use this free
>  service. 
Well, because sooner or later, you'll delete a project that someone
didn't want deleted, and they'll be ticked off.  Maybe they'll open a
ticket and convince the infra. team to restore the data from a backup,
or maybe they'll just be ticked off and rant about how much Fedora
sucks for deleting this thing they didn't want deleted.

Again, I'm assuming the per-project maintenence cost is near zero (ie,
a little bit of disk space).  If not, then maybe I could see a case
for automatically deleting old projects.

-RN

-- 
Robin Norwood

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching

[Mike McGrath]

On Tue, 9 Sep 2008, Robin Norwood wrote:

>  On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath
> <mmcgrath(a)redhat.com&gt; wrote:
>  > Nope, the terms of use are already pretty clear.  And no one has provided
>  > a compelling reason to keep these projects around, just lots of
>  > suggestions on how to keep them around.  Deleted is what we want, not
>  > delisted or saved forever or anything like that.  We're not going to
>  > commit any resources to a project that choosed not to use this free
>  > service.
>
>  Well, because sooner or later, you'll delete a project that someone
>  didn't want deleted, and they'll be ticked off.  Maybe they'll open a
>  ticket and convince the infra. team to restore the data from a backup,
>  or maybe they'll just be ticked off and rant about how much Fedora
>  sucks for deleting this thing they didn't want deleted.
>  
I'm fine with that.  Its well documented.  and its not like we're going to
rm -rf the thing.  We'll keep it around for a while but no promises.

>  Again, I'm assuming the per-project maintenence cost is near zero
> (ie,
>  a little bit of disk space).  If not, then maybe I could see a case
>  for automatically deleting old projects.
>  
Ah, thats an incorrect assumption.

	-Mike

[Paul W. Frields]

On Tue, 2008-09-09 at 21:02 -0500, Mike McGrath wrote:
>  On Tue, 9 Sep 2008, Robin Norwood wrote:
>  
>  > On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath <mmcgrath(a)redhat.com&gt; wrote:
>  > > Nope, the terms of use are already pretty clear.  And no one has provided
>  > > a compelling reason to keep these projects around, just lots of
>  > > suggestions on how to keep them around.  Deleted is what we want, not
>  > > delisted or saved forever or anything like that.  We're not going to
>  > > commit any resources to a project that choosed not to use this free
>  > > service.
>  >
>  > Well, because sooner or later, you'll delete a project that someone
>  > didn't want deleted, and they'll be ticked off.  Maybe they'll open a
>  > ticket and convince the infra. team to restore the data from a backup,
>  > or maybe they'll just be ticked off and rant about how much Fedora
>  > sucks for deleting this thing they didn't want deleted.
>  >
>  
>  I'm fine with that.  Its well documented.  and its not like we're going to
>  rm -rf the thing.  We'll keep it around for a while but no promises.
>  
>  > Again, I'm assuming the per-project maintenence cost is near zero (ie,
>  > a little bit of disk space).  If not, then maybe I could see a case
>  > for automatically deleting old projects.
>  >
>  
>  Ah, thats an incorrect assumption. 
Is there a way to balance deactivating the greater project needs with
the value of the source code as a useful historical artifact?  In other
words, if we reduced (for example) an active git-based project to just
the .git stuff, and made it available for download only, then the cost
really is just disk space, right?

I wouldn't want to see Infrastructure roped into committing lots of
resources to carry a ton of dead projects.  If there's a significant
per-project maintenance cost, even if it just adds up to something
significant over hundreds of projects, the work has to be justified
somehow.  Is there a way to keep the source around but not induce the
maintenance cost?  Am I being naive about this?

-- 
Paul W. Frields
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://paul.frields.org/   -  -   http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

[Mike McGrath]

On Wed, 10 Sep 2008, Paul W. Frields wrote:

>  On Tue, 2008-09-09 at 21:02 -0500, Mike McGrath wrote:
>  > On Tue, 9 Sep 2008, Robin Norwood wrote:
>  >
>  > > On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath <mmcgrath(a)redhat.com&gt;
> wrote:
>  > > > Nope, the terms of use are already pretty clear.  And no one has provided
>  > > > a compelling reason to keep these projects around, just lots of
>  > > > suggestions on how to keep them around.  Deleted is what we want, not
>  > > > delisted or saved forever or anything like that.  We're not going to
>  > > > commit any resources to a project that choosed not to use this free
>  > > > service.
>  > >
>  > > Well, because sooner or later, you'll delete a project that someone
>  > > didn't want deleted, and they'll be ticked off.  Maybe they'll open
> a
>  > > ticket and convince the infra. team to restore the data from a backup,
>  > > or maybe they'll just be ticked off and rant about how much Fedora
>  > > sucks for deleting this thing they didn't want deleted.
>  > >
>  >
>  > I'm fine with that.  Its well documented.  and its not like we're going to
>  > rm -rf the thing.  We'll keep it around for a while but no promises.
>  >
>  > > Again, I'm assuming the per-project maintenence cost is near zero (ie,
>  > > a little bit of disk space).  If not, then maybe I could see a case
>  > > for automatically deleting old projects.
>  > >
>  >
>  > Ah, thats an incorrect assumption.
>
>  Is there a way to balance deactivating the greater project needs with
>  the value of the source code as a useful historical artifact?  In other
>  words, if we reduced (for example) an active git-based project to just
>  the .git stuff, and made it available for download only, then the cost
>  really is just disk space, right?
>  
Nope not just disk space.

>  I wouldn't want to see Infrastructure roped into committing lots
> of
>  resources to carry a ton of dead projects.  If there's a significant
>  per-project maintenance cost, even if it just adds up to something
>  significant over hundreds of projects, the work has to be justified
>  somehow.  Is there a way to keep the source around but not induce the
>  maintenance cost?  Am I being naive about this?
>  
Backups, time to maintain, bandwidth for the backups, testing when we make
changes, people to notify should our Infrastructure get compromised again,
etc, the unknown.

Its all those little things that people don't think about that I worries
me.  What's the benefit of keeping them around?  I mean, I can commit
to saying "we'll remove a project and keep it offline for a year if someone
complains we'll give it to them".


I guess I'm just putting my foot down on this since almost all the support
for "keep everything around forever" has come from people that don't have
to deal with the consequences of that decision.  This isn't a file being
kept on someones desktop...

	-Mike

[Jeremy Katz]

On Tue, 2008-09-09 at 21:33 -0500, Mike McGrath wrote:
>  On Wed, 10 Sep 2008, Paul W. Frields wrote:
>  > On Tue, 2008-09-09 at 21:02 -0500, Mike McGrath wrote:
>  > > On Tue, 9 Sep 2008, Robin Norwood wrote:
>  > >
>  > > > On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath <mmcgrath(a)redhat.com&gt;
> wrote:
>  > > > > Nope, the terms of use are already pretty clear.  And no one has
> provided
>  > > > > a compelling reason to keep these projects around, just lots of
>  > > > > suggestions on how to keep them around.  Deleted is what we want,
> not
>  > > > > delisted or saved forever or anything like that.  We're not going
> to
>  > > > > commit any resources to a project that choosed not to use this free
>  > > > > service.
>  > > >
>  > > > Well, because sooner or later, you'll delete a project that someone
>  > > > didn't want deleted, and they'll be ticked off.  Maybe they'll
> open a
>  > > > ticket and convince the infra. team to restore the data from a backup,
>  > > > or maybe they'll just be ticked off and rant about how much Fedora
>  > > > sucks for deleting this thing they didn't want deleted.
>  > > >
>  > >
>  > > I'm fine with that.  Its well documented.  and its not like we're going
> to
>  > > rm -rf the thing.  We'll keep it around for a while but no promises.
>  > >
>  > > > Again, I'm assuming the per-project maintenence cost is near zero
> (ie,
>  > > > a little bit of disk space).  If not, then maybe I could see a case
>  > > > for automatically deleting old projects.
>  > > >
>  > >
>  > > Ah, thats an incorrect assumption.
>  >
>  > Is there a way to balance deactivating the greater project needs with
>  > the value of the source code as a useful historical artifact?  In other
>  > words, if we reduced (for example) an active git-based project to just
>  > the .git stuff, and made it available for download only, then the cost
>  > really is just disk space, right?
>  >
>  
>  Nope not just disk space.
>  
>  > I wouldn't want to see Infrastructure roped into committing lots of
>  > resources to carry a ton of dead projects.  If there's a significant
>  > per-project maintenance cost, even if it just adds up to something
>  > significant over hundreds of projects, the work has to be justified
>  > somehow.  Is there a way to keep the source around but not induce the
>  > maintenance cost?  Am I being naive about this?
>  >
>  
>  Backups, time to maintain, bandwidth for the backups, testing when we make
>  changes, people to notify should our Infrastructure get compromised again,
>  etc, the unknown. 
Backups really are equivalent to disk space.  Testing for changes --
maybe.  But if it's really that inactive, then a change is unlikely to
break it.  And if it does, then when someone notices, they'll holler.  

As for the people to notify bit, I liked Nigel's idea of delist
+read-only -- then you don't have to worry about notifying, but at the
same time, it's easy to have access restored if it becomes relevant.

>  Its all those little things that people don't think about that I
> worries
>  me.  What's the benefit of keeping them around?  I mean, I can commit
>  to saying "we'll remove a project and keep it offline for a year if someone
>  complains we'll give it to them". 
The benefit of keeping them around is the same as the benefit for why we
don't prune historical src.rpms or tarballs from distcvs.  Or why we
don't prune the history of source repos in general.

Yes, it may be ancient history, but it's still history.  And there's a
lot that can be learned from history.  Just ask the people that have
done things like importing _all_ kernel history since the dawn of time
(that at least they can find tarballs for).  Or ajax and his "X since
the dawn of time" archive.

>  I guess I'm just putting my foot down on this since almost all
> the support
>  for "keep everything around forever" has come from people that don't have
>  to deal with the consequences of that decision.  This isn't a file being
>  kept on someones desktop... 
You're right, it's not a file that's being kept on someone's desktop.
It's something far more important -- it's the DNA of the evolution of
open source.

Jeremy

[Mike McGrath]

On Tue, 9 Sep 2008, Jeremy Katz wrote:
>  >
>  > Backups, time to maintain, bandwidth for the backups, testing when we make
>  > changes, people to notify should our Infrastructure get compromised again,
>  > etc, the unknown.
>
>  Backups really are equivalent to disk space.  Testing for changes --
>  maybe.  But if it's really that inactive, then a change is unlikely to
>  break it.  And if it does, then when someone notices, they'll holler.
>  
yeah, when you backup to disk over a LAN, neither of which we do.

>  Yes, it may be ancient history, but it's still history.  And
> there's a
>  lot that can be learned from history.  Just ask the people that have
>  done things like importing _all_ kernel history since the dawn of time
>  (that at least they can find tarballs for).  Or ajax and his "X since
>  the dawn of time" archive.
>
>  > I guess I'm just putting my foot down on this since almost all the support
>  > for "keep everything around forever" has come from people that don't
> have
>  > to deal with the consequences of that decision.  This isn't a file being
>  > kept on someones desktop...
>
>  You're right, it's not a file that's being kept on someone's desktop.
>  It's something far more important -- it's the DNA of the evolution of
>  open source.
>  
Then they can keep their DNA somewhere else.

	-Mike

[Mike McGrath]

On Tue, 9 Sep 2008, Mike McGrath wrote:

>  On Tue, 9 Sep 2008, Jeremy Katz wrote:
>  > >
>  > > Backups, time to maintain, bandwidth for the backups, testing when we make
>  > > changes, people to notify should our Infrastructure get compromised again,
>  > > etc, the unknown.
>  >
>  > Backups really are equivalent to disk space.  Testing for changes --
>  > maybe.  But if it's really that inactive, then a change is unlikely to
>  > break it.  And if it does, then when someone notices, they'll holler.
>  >
>
>  yeah, when you backup to disk over a LAN, neither of which we do.
>  
Actually this isn't true, we do local backup to remote disk over a LAN via
a sync, we also do a remote backup to tape.

	-Mike

[Mike McGrath]

On Tue, 9 Sep 2008, Jeremy Katz wrote:

>  On Tue, 2008-09-09 at 21:33 -0500, Mike McGrath wrote:
>  > On Wed, 10 Sep 2008, Paul W. Frields wrote:
>  > > On Tue, 2008-09-09 at 21:02 -0500, Mike McGrath wrote:
>  > > > On Tue, 9 Sep 2008, Robin Norwood wrote:
>  > > >
>  > > > > On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath
> <mmcgrath(a)redhat.com&gt; wrote:
>  > > > > > Nope, the terms of use are already pretty clear.  And no one has
> provided
>  > > > > > a compelling reason to keep these projects around, just lots of
>  > > > > > suggestions on how to keep them around.  Deleted is what we
> want, not
>  > > > > > delisted or saved forever or anything like that.  We're not
> going to
>  > > > > > commit any resources to a project that choosed not to use this
> free
>  > > > > > service.
>  > > > >
>  > > > > Well, because sooner or later, you'll delete a project that
> someone
>  > > > > didn't want deleted, and they'll be ticked off.  Maybe
> they'll open a
>  > > > > ticket and convince the infra. team to restore the data from a
> backup,
>  > > > > or maybe they'll just be ticked off and rant about how much
> Fedora
>  > > > > sucks for deleting this thing they didn't want deleted.
>  > > > >
>  > > >
>  > > > I'm fine with that.  Its well documented.  and its not like we're
> going to
>  > > > rm -rf the thing.  We'll keep it around for a while but no promises.
>  > > >
>  > > > > Again, I'm assuming the per-project maintenence cost is near zero
> (ie,
>  > > > > a little bit of disk space).  If not, then maybe I could see a case
>  > > > > for automatically deleting old projects.
>  > > > >
>  > > >
>  > > > Ah, thats an incorrect assumption.
>  > >
>  > > Is there a way to balance deactivating the greater project needs with
>  > > the value of the source code as a useful historical artifact?  In other
>  > > words, if we reduced (for example) an active git-based project to just
>  > > the .git stuff, and made it available for download only, then the cost
>  > > really is just disk space, right?
>  > >
>  >
>  > Nope not just disk space.
>  >
>  > > I wouldn't want to see Infrastructure roped into committing lots of
>  > > resources to carry a ton of dead projects.  If there's a significant
>  > > per-project maintenance cost, even if it just adds up to something
>  > > significant over hundreds of projects, the work has to be justified
>  > > somehow.  Is there a way to keep the source around but not induce the
>  > > maintenance cost?  Am I being naive about this?
>  > >
>  >
>  > Backups, time to maintain, bandwidth for the backups, testing when we make
>  > changes, people to notify should our Infrastructure get compromised again,
>  > etc, the unknown.
>
>  Backups really are equivalent to disk space.  Testing for changes --
>  maybe.  But if it's really that inactive, then a change is unlikely to
>  break it.  And if it does, then when someone notices, they'll holler.
>
>  As for the people to notify bit, I liked Nigel's idea of delist
>  +read-only -- then you don't have to worry about notifying, but at the
>  same time, it's easy to have access restored if it becomes relevant.
>  
So it seems I'm alone here, if we have to keep everything forever, thats
what it'll be.  I'll just have to see to it we have the resources and
backup materials in the future when that time comes.  I have a question
and a suggestion for people.

1) What do we do with projects to which no owner or responsible party can
be found?  This caused major headaches during the elvis move...  headaches
we still have today.  What would you have us do?



2) Right before we start removing projects is _not_ the time to discuss
the policy.  When the policy is put in place... thats the time to discuss
it.

	-Mike

[Jeremy Katz]

On Tue, 2008-09-09 at 22:44 -0500, Mike McGrath wrote:
>  So it seems I'm alone here, if we have to keep everything
> forever, thats
>  what it'll be.  I'll just have to see to it we have the resources and
>  backup materials in the future when that time comes.  I have a question
>  and a suggestion for people.
>  
>  1) What do we do with projects to which no owner or responsible party can
>  be found?  This caused major headaches during the elvis move...  headaches
>  we still have today.  What would you have us do? 
I think the idea of making them read-only/owned by an "admin" type group
seems reasonable at first blush.  It doesn't get rid of all of the
problems, but it does help with a number of them

>  2) Right before we start removing projects is _not_ the time to
> discuss
>  the policy.  When the policy is put in place... thats the time to discuss
>  it. 
I don't disagree at all.  I must have missed the initial discussion in
my sea of mail or I would have chimed in then :-/  

Jeremy

[Mike McGrath]

On Wed, 10 Sep 2008, Jeremy Katz wrote:

>  On Tue, 2008-09-09 at 22:44 -0500, Mike McGrath wrote:
>  > So it seems I'm alone here, if we have to keep everything forever, thats
>  > what it'll be.  I'll just have to see to it we have the resources and
>  > backup materials in the future when that time comes.  I have a question
>  > and a suggestion for people.
>  >
>  > 1) What do we do with projects to which no owner or responsible party can
>  > be found?  This caused major headaches during the elvis move...  headaches
>  > we still have today.  What would you have us do?
>
>  I think the idea of making them read-only/owned by an "admin" type group
>  seems reasonable at first blush.  It doesn't get rid of all of the
>  problems, but it does help with a number of them
>
>  > 2) Right before we start removing projects is _not_ the time to discuss
>  > the policy.  When the policy is put in place... thats the time to discuss
>  > it.
>
>  I don't disagree at all.  I must have missed the initial discussion in
>  my sea of mail or I would have chimed in then :-/
>  
no worries, I can admit to blowing my top last night, long day.  We'll
figure something out.  Taking a step back my core concerns are code to
which no one is responsible and what to do about that code.  _especially_
if its still in use somewhere.  It actually complicated the move away from
elvis quite a bit and I want to make sure that doesn't happen again.

We can look at that philosophically and practically.

	-Mike

[Paul W. Frields]

On Wed, 2008-09-10 at 09:57 -0500, Mike McGrath wrote:
>  On Wed, 10 Sep 2008, Jeremy Katz wrote:
>  
>  > On Tue, 2008-09-09 at 22:44 -0500, Mike McGrath wrote:
>  > > So it seems I'm alone here, if we have to keep everything forever, thats
>  > > what it'll be.  I'll just have to see to it we have the resources and
>  > > backup materials in the future when that time comes.  I have a question
>  > > and a suggestion for people.
>  > >
>  > > 1) What do we do with projects to which no owner or responsible party can
>  > > be found?  This caused major headaches during the elvis move...  headaches
>  > > we still have today.  What would you have us do?
>  >
>  > I think the idea of making them read-only/owned by an "admin" type group
>  > seems reasonable at first blush.  It doesn't get rid of all of the
>  > problems, but it does help with a number of them
>  >
>  > > 2) Right before we start removing projects is _not_ the time to discuss
>  > > the policy.  When the policy is put in place... thats the time to discuss
>  > > it.
>  >
>  > I don't disagree at all.  I must have missed the initial discussion in
>  > my sea of mail or I would have chimed in then :-/
>  >
>  
>  no worries, I can admit to blowing my top last night, long day.  We'll
>  figure something out.  Taking a step back my core concerns are code to
>  which no one is responsible and what to do about that code.  _especially_
>  if its still in use somewhere.  It actually complicated the move away from
>  elvis quite a bit and I want to make sure that doesn't happen again.
>  
>  We can look at that philosophically and practically. 
I think your concerns are really rational and well-placed.  Hope we
didn't get too irksome, and thanks for "deconfusifying" (a favorite
made-up word) the scenarios about how FI would approach de-listing.

-- 
Paul W. Frields
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://paul.frields.org/   -  -   http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

[Jeremy Katz]

On Tue, 2008-09-09 at 20:34 -0500, Mike McGrath wrote:
>  On Tue, 9 Sep 2008, Robin Norwood wrote:
>  > On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath <mmcgrath(a)redhat.com&gt; wrote:
>  > > In general from the infrastructure side I'd say we want to keep the
>  > > barrier to enter low but the quality high.  Certainly there's projects
>  > > that don't need to be updated every 6 months but we can identify those and
>  > > deal accordingly.
>  >
>  > How about 'delisting' instead of deleting?  I'm operating under the
>  > assumption that the infrastructure burden of hosting the project isn't
>  > the problem you're trying to solve, and that keeping the projects at
>  > fedora hosted relevant is.
>  >
>  > A delisted project simply wouldn't appear on the main fedora hosted
>  > list of projects, but would still be available via direct link.  That
>  > way, nothing is lost, but the clutter vanishes.
>  >
>  > You could even have yet another category for projects that are known
>  > to be abandoned.
>
>  Nope, the terms of use are already pretty clear.  And no one has provided
>  a compelling reason to keep these projects around, just lots of
>  suggestions on how to keep them around.  Deleted is what we want, not
>  delisted or saved forever or anything like that.  We're not going to
>  commit any resources to a project that choosed not to use this free
>  service. 
Compelling reason: application is in Fedora today, maintained in
fedorahosted and ends up in RHEL.  A year after RHEL release, the app is
obsoleted by something else in Fedora.  Thus, the app in hosted
basically gets very little in the way of updates.  But keeping the
source repository available is very important for any updates later
needed for RHEL.

Jeremy

[Mike McGrath]

On Tue, 9 Sep 2008, Jeremy Katz wrote:

>  On Tue, 2008-09-09 at 20:34 -0500, Mike McGrath wrote:
>  > On Tue, 9 Sep 2008, Robin Norwood wrote:
>  > > On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath <mmcgrath(a)redhat.com&gt;
> wrote:
>  > > > In general from the infrastructure side I'd say we want to keep the
>  > > > barrier to enter low but the quality high.  Certainly there's
> projects
>  > > > that don't need to be updated every 6 months but we can identify those
> and
>  > > > deal accordingly.
>  > >
>  > > How about 'delisting' instead of deleting?  I'm operating under
> the
>  > > assumption that the infrastructure burden of hosting the project isn't
>  > > the problem you're trying to solve, and that keeping the projects at
>  > > fedora hosted relevant is.
>  > >
>  > > A delisted project simply wouldn't appear on the main fedora hosted
>  > > list of projects, but would still be available via direct link.  That
>  > > way, nothing is lost, but the clutter vanishes.
>  > >
>  > > You could even have yet another category for projects that are known
>  > > to be abandoned.
>  >
>  > Nope, the terms of use are already pretty clear.  And no one has provided
>  > a compelling reason to keep these projects around, just lots of
>  > suggestions on how to keep them around.  Deleted is what we want, not
>  > delisted or saved forever or anything like that.  We're not going to
>  > commit any resources to a project that choosed not to use this free
>  > service.
>
>  Compelling reason: application is in Fedora today, maintained in
>  fedorahosted and ends up in RHEL.  A year after RHEL release, the app is
>  obsoleted by something else in Fedora.  Thus, the app in hosted
>  basically gets very little in the way of updates.  But keeping the
>  source repository available is very important for any updates later
>  needed for RHEL.
>  
I don't see why that project would get removed.  I really think I'm
getting misunderstood here.

1) we send an email to the group members explaining their project is stale
and asking to remove it.

2) they respond saying they'd like to not have it removed. (it stays)

3) they respond saying its no longer used and it can be removed (we remove
it or they move it elsewhere)

4) no one responds (it gets removed)

	-Mike

[Jeremy Katz]

On Tue, 2008-09-09 at 21:20 -0500, Mike McGrath wrote:
>  I don't see why that project would get removed.  I really think
> I'm
>  getting misunderstood here. 
I think that part of the misunderstanding is that I don't see "six
months" as equivalent to "stale".  We're not even to the seven year
point of RHEL 2.1.  And there are definitely things that I personally
migrated from elvis -> fedorahosted that, while not relevant with
"current" distros still are for older RHEL.

>  1) we send an email to the group members explaining their project is
> stale
>  and asking to remove it.
>  2) they respond saying they'd like to not have it removed. (it stays) 
It stays for how long?  If we look at the set of what's being talked
about here, I can already tell you that the vast majority are going to
fall into the "wanting to be kept" category.  Which means that we're
doing a lot of administrative overhead for how much gain?

>  3) they respond saying its no longer used and it can be removed (we
> remove
>  it or they move it elsewhere)
>  4) no one responds (it gets removed) 
Within what time period?  And if it later becomes relevant/needed again
we just hope that someone has a backup?

Jeremy

[Mike McGrath]

On Tue, 9 Sep 2008, Jeremy Katz wrote:

>  On Tue, 2008-09-09 at 21:20 -0500, Mike McGrath wrote:
>  > I don't see why that project would get removed.  I really think I'm
>  > getting misunderstood here.
>
>  I think that part of the misunderstanding is that I don't see "six
>  months" as equivalent to "stale".  We're not even to the seven year
>  point of RHEL 2.1.  And there are definitely things that I personally
>  migrated from elvis -> fedorahosted that, while not relevant with
>  "current" distros still are for older RHEL.
>
>  > 1) we send an email to the group members explaining their project is stale
>  > and asking to remove it.
>  > 2) they respond saying they'd like to not have it removed. (it stays)
>
>  It stays for how long?  If we look at the set of what's being talked
>  about here, I can already tell you that the vast majority are going to
>  fall into the "wanting to be kept" category.  Which means that we're
>  doing a lot of administrative overhead for how much gain?
>  
Till they say otherwise or until the board says to take it down.

>  > 3) they respond saying its no longer used and it can be removed
> (we remove
>  > it or they move it elsewhere)
>  > 4) no one responds (it gets removed)
>
>  Within what time period?  And if it later becomes relevant/needed again
>  we just hope that someone has a backup?
>  
Yep, its well documented and if thats not ok for them, there's other
offerings out there.  I will not let our offering become another
sourceforge and become the butt of every packagers jokes.

Bottom line, hosting isn't what _WE_ do.  its a value added service and
I'm keeping that well in mind.  As far as administrative overhead.  I've
spent far more time on sending emails about it then it took for us to run
the scripts and contact the hosts.

fedorahosted != elvis
fedorahosted != sourceforge

If you want elvis, you can put your stuff there.

	-Mike

[Nigel Jones]

On Tue, 2008-09-09 at 22:11 -0400, Jeremy Katz wrote:
>  On Tue, 2008-09-09 at 20:34 -0500, Mike McGrath wrote:
>  > On Tue, 9 Sep 2008, Robin Norwood wrote:
>  > > On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath <mmcgrath(a)redhat.com&gt;
> wrote:
>  > > > In general from the infrastructure side I'd say we want to keep the
>  > > > barrier to enter low but the quality high.  Certainly there's
> projects
>  > > > that don't need to be updated every 6 months but we can identify those
> and
>  > > > deal accordingly.
>  > >
>  > > How about 'delisting' instead of deleting?  I'm operating under
> the
>  > > assumption that the infrastructure burden of hosting the project isn't
>  > > the problem you're trying to solve, and that keeping the projects at
>  > > fedora hosted relevant is.
>  > >
>  > > A delisted project simply wouldn't appear on the main fedora hosted
>  > > list of projects, but would still be available via direct link.  That
>  > > way, nothing is lost, but the clutter vanishes.
>  > >
>  > > You could even have yet another category for projects that are known
>  > > to be abandoned.
>  >
>  > Nope, the terms of use are already pretty clear.  And no one has provided
>  > a compelling reason to keep these projects around, just lots of
>  > suggestions on how to keep them around.  Deleted is what we want, not
>  > delisted or saved forever or anything like that.  We're not going to
>  > commit any resources to a project that choosed not to use this free
>  > service.
>  
>  Compelling reason: application is in Fedora today, maintained in
>  fedorahosted and ends up in RHEL.  A year after RHEL release, the app is
>  obsoleted by something else in Fedora.  Thus, the app in hosted
>  basically gets very little in the way of updates.  But keeping the
>  source repository available is very important for any updates later
>  needed for RHEL. 
Also, isn't there something in the GPL about keeping
everything around
for (at least) three years?

I think delisting is better than removing, I'd even be prepared to say
"delisting+read only" is an even better choice (think: disappears off
main fh.o and the commit group gets "disabled" or set to
"inactive" (i.e. shell access isn't given as part of that group)), after
three years, then by all means.

Six months just seems short (that's my only thought).

- Nigel
>  
>  Jeremy
>  
>  _______________________________________________
>  Fedora-infrastructure-list mailing list
>  Fedora-infrastructure-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
>   
-- 
Nigel Jones <dev(a)nigelj.com&gt;