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
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
Mike McGrath (mmcgrath@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
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
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
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...
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
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
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?
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
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.
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
On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath mmcgrath@redhat.com 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
-----Original Message----- From: fedora-infrastructure-list-bounces@redhat.com [mailto:fedora- infrastructure-list-bounces@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@redhat.com 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.
On Tue, 9 Sep 2008, Brett Lentz wrote:
-----Original Message----- From: fedora-infrastructure-list-bounces@redhat.com [mailto:fedora- infrastructure-list-bounces@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@redhat.com 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
-----Original Message----- From: fedora-infrastructure-list-bounces@redhat.com [mailto:fedora- infrastructure-list-bounces@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@redhat.com [mailto:fedora- infrastructure-list-bounces@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@redhat.com 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.
On Tue, 9 Sep 2008, Brett Lentz wrote:
-----Original Message----- From: fedora-infrastructure-list-bounces@redhat.com [mailto:fedora- infrastructure-list-bounces@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@redhat.com 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
On Tue, 9 Sep 2008, Robin Norwood wrote:
On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath mmcgrath@redhat.com 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
On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath mmcgrath@redhat.com 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
On Tue, 9 Sep 2008, Robin Norwood wrote:
On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath mmcgrath@redhat.com 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
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@redhat.com 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?
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@redhat.com 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
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@redhat.com 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
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
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
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@redhat.com 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
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.
- 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
- 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
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.
- 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
- 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
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.
- 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
- 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.
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@redhat.com 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
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@redhat.com 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
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.
- 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?
- 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
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.
- 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.
- 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
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@redhat.com 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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
infrastructure@lists.fedoraproject.org
-
Bill Nottingham -
brett lentz -
Debarshi Ray -
Ian Weller -
Jeremy Katz -
Karel Zak -
Matt Domsch -
Mike McGrath -
Nigel Jones -
Paul W. Frields -
Robin Norwood -
susmit shannigrahi