Getting back to this. What should we do with code to which no one claims ownership or the owner cannot be found?
-Mike
On Tue, 23 Sep 2008, Jeroen van Meeuwen wrote:
Mike McGrath wrote:
Getting back to this. What should we do with code to which no one claims ownership or the owner cannot be found?
Has something like an AWOL procedure been considered?
Not really, thats kind of what I'm probing about. People didn't like the 6 month rule so I'm fine getting rid of that. But someone needs to be accountable for the code itself at all times and I'm hoping to have some policy in place that clearly states it.
-Mike
On Tue, 2008-09-23 at 16:53 -0500, Mike McGrath wrote:
On Tue, 23 Sep 2008, Jeroen van Meeuwen wrote:
Mike McGrath wrote:
Getting back to this. What should we do with code to which no one claims ownership or the owner cannot be found?
Has something like an AWOL procedure been considered?
Not really, thats kind of what I'm probing about. People didn't like the 6 month rule so I'm fine getting rid of that. But someone needs to be accountable for the code itself at all times and I'm hoping to have some policy in place that clearly states it.
-Mike
I'd prefer to not see orphaned projects go away completely, if there is some way to keep them around in a stripped down, minimalist format.
The process I'd like to see would be:
1. Do the usual 6 month project no-activity process. 2. If there is no response in N days, or mail to the project admin bounces in a fatal way (i.e. "no such user" vs. "mailbox full"), we call out to the general fedora-devel community to see if anyone wants to adopt the project and become its new maintainer. 3. If no new maintainer is found, we would then migrate the project to a central repository for orphaned projects.
The central repository would contain a bare minimum of the project's files:
* a tar.bz2 of the last revision of all files, with no revision history. * an archive of any documentation, such as the trac wiki pages. (again, just the text, with no need to preserve revision history)
This way, we can preserve a stripped down version of the project's files for a (hopefully) lower infrastructure cost.
Would something like this be possible/desired?
---Brett.
Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln
On Tue, 23 Sep 2008, Brett Lentz wrote:
On Tue, 2008-09-23 at 16:53 -0500, Mike McGrath wrote:
On Tue, 23 Sep 2008, Jeroen van Meeuwen wrote:
Mike McGrath wrote:
Getting back to this. What should we do with code to which no one claims ownership or the owner cannot be found?
Has something like an AWOL procedure been considered?
Not really, thats kind of what I'm probing about. People didn't like the 6 month rule so I'm fine getting rid of that. But someone needs to be accountable for the code itself at all times and I'm hoping to have some policy in place that clearly states it.
-Mike
I'd prefer to not see orphaned projects go away completely, if there is some way to keep them around in a stripped down, minimalist format.
The process I'd like to see would be:
- Do the usual 6 month project no-activity process.
- If there is no response in N days, or mail to the project admin
bounces in a fatal way (i.e. "no such user" vs. "mailbox full"), we call out to the general fedora-devel community to see if anyone wants to adopt the project and become its new maintainer. 3. If no new maintainer is found, we would then migrate the project to a central repository for orphaned projects.
For how long would 3) happen?
-Mike
On Tue, 2008-09-23 at 18:14 -0500, Mike McGrath wrote:
On Tue, 23 Sep 2008, Brett Lentz wrote:
On Tue, 2008-09-23 at 16:53 -0500, Mike McGrath wrote:
On Tue, 23 Sep 2008, Jeroen van Meeuwen wrote:
Mike McGrath wrote:
Getting back to this. What should we do with code to which no one claims ownership or the owner cannot be found?
Has something like an AWOL procedure been considered?
Not really, thats kind of what I'm probing about. People didn't like the 6 month rule so I'm fine getting rid of that. But someone needs to be accountable for the code itself at all times and I'm hoping to have some policy in place that clearly states it.
-Mike
I'd prefer to not see orphaned projects go away completely, if there is some way to keep them around in a stripped down, minimalist format.
The process I'd like to see would be:
- Do the usual 6 month project no-activity process.
- If there is no response in N days, or mail to the project admin
bounces in a fatal way (i.e. "no such user" vs. "mailbox full"), we call out to the general fedora-devel community to see if anyone wants to adopt the project and become its new maintainer. 3. If no new maintainer is found, we would then migrate the project to a central repository for orphaned projects.
For how long would 3) happen?
-Mike
I think that it depends on our constraints. Perhaps we could measure our rate of growth, and strike a balance between maintaining an orphaned projects archive and our available resources?
As this is one of those "nice to have" type of deals, I would expect these archived files to be first on the chopping block if we need to free up infrastructure resources for something that's more actively maintained.
If you want to set a more firm SLA, how does 2 years (one RHEL release cycle) sound?
On Tue, 2008-09-23 at 13:58 -0500, Mike McGrath wrote:
Getting back to this. What should we do with code to which no one claims ownership or the owner cannot be found?
* Make Trac Read Only (maybe static content too, in old.fedorahosted.org/projectname/) * Disable commit group in FAS (in particular to get rid of cla+1 entitlements if the commit group is their only group) * Chown SCM dir to remove write access
- Nigel
On Wed, 24 Sep 2008, Nigel Jones wrote:
On Tue, 2008-09-23 at 13:58 -0500, Mike McGrath wrote:
Getting back to this. What should we do with code to which no one claims ownership or the owner cannot be found?
- Make Trac Read Only (maybe static content too, in
old.fedorahosted.org/projectname/)
- Disable commit group in FAS (in particular to get rid of cla+1
entitlements if the commit group is their only group)
- Chown SCM dir to remove write access
For how long? Here's the concern. At some point between now and the end of time decisions are going to have to be made about these projects. I'm trying to have us learn a lesson from the elvis move as well trying to make sure other's lack of planning doesn't become Infrastructures problem. Something has to happen with bits that belong to no one, so far no one has put a time limit on any of these things.
-Mike
On Tue, 2008-09-23 at 18:43 -0500, Mike McGrath wrote:
On Wed, 24 Sep 2008, Nigel Jones wrote:
On Tue, 2008-09-23 at 13:58 -0500, Mike McGrath wrote:
Getting back to this. What should we do with code to which no one claims ownership or the owner cannot be found?
- Make Trac Read Only (maybe static content too, in
old.fedorahosted.org/projectname/)
- Disable commit group in FAS (in particular to get rid of cla+1
entitlements if the commit group is their only group)
- Chown SCM dir to remove write access
For how long? Here's the concern. At some point between now and the end of time decisions are going to have to be made about these projects. I'm trying to have us learn a lesson from the elvis move as well trying to make sure other's lack of planning doesn't become Infrastructures problem. Something has to happen with bits that belong to no one, so far no one has put a time limit on any of these things.
IIRC the GPL at least requires that the code be kept for 3 years (hence why we can't clean the look-a-side cache from memory).
We could do this a variety of ways, tarball a SCM dump and throw it on archives.fp.o for instance.
- Nigel
Nigel Jones wrote:
IIRC the GPL at least requires that the code be kept for 3 years (hence why we can't clean the look-a-side cache from memory).
AFAIK that only goes to /distribution/ under GPLv2 section 3b, not the "upstream" SCM, but then again I'm not sure and it may be worthwhile looking into the requirements of the Licenses of the software in these SCMs.
-Jeroen
On Wed, 2008-09-24 at 01:59 +0200, Jeroen van Meeuwen wrote:
Nigel Jones wrote:
IIRC the GPL at least requires that the code be kept for 3 years (hence why we can't clean the look-a-side cache from memory).
AFAIK that only goes to /distribution/ under GPLv2 section 3b, not the "upstream" SCM, but then again I'm not sure and it may be worthwhile looking into the requirements of the Licenses of the software in these SCMs.
Distribution is very loose in my terms.
Technically by distributing the source code, we are errr acting as a distribution point. IANAL but that's my view.
-Jeroen
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Nigel Jones wrote:
On Wed, 2008-09-24 at 01:59 +0200, Jeroen van Meeuwen wrote:
Nigel Jones wrote:
IIRC the GPL at least requires that the code be kept for 3 years (hence why we can't clean the look-a-side cache from memory).
AFAIK that only goes to /distribution/ under GPLv2 section 3b, not the "upstream" SCM, but then again I'm not sure and it may be worthwhile looking into the requirements of the Licenses of the software in these SCMs.
Distribution is very loose in my terms.
Technically by distributing the source code, we are errr acting as a distribution point. IANAL but that's my view.
Perhaps. But the GPLv2 portion that has the three year clause deals with distributing binaries. Upstream SCM would be releasing source, so that doesn't apply. If the upstream on fedorahosted was releasing binary tarballs then it might be a little greyer. Although one would hope they were releasing both binary tarballs and source tarballs. Then it would fall under a different clause with no timeframe.
-Toshio
Toshio Kuratomi wrote:
Nigel Jones wrote:
On Wed, 2008-09-24 at 01:59 +0200, Jeroen van Meeuwen wrote:
Nigel Jones wrote:
IIRC the GPL at least requires that the code be kept for 3 years (hence why we can't clean the look-a-side cache from memory).
AFAIK that only goes to /distribution/ under GPLv2 section 3b, not the "upstream" SCM, but then again I'm not sure and it may be worthwhile looking into the requirements of the Licenses of the software in these SCMs.
Distribution is very loose in my terms.
Technically by distributing the source code, we are errr acting as a distribution point. IANAL but that's my view.
Perhaps. But the GPLv2 portion that has the three year clause deals with distributing binaries. Upstream SCM would be releasing source, so that doesn't apply. If the upstream on fedorahosted was releasing binary tarballs then it might be a little greyer. Although one would hope they were releasing both binary tarballs and source tarballs. Then it would fall under a different clause with no timeframe.
Given that we alone can think of a couple of arguments for or against GPL distribution for 3 years or not, and there's other licenses as well, this might be more appropriately handled by the legally literate people (no offense to you, I just know I certainly am not)
-Jeroen
Jeroen van Meeuwen wrote:
Given that we alone can think of a couple of arguments for or against GPL distribution for 3 years or not, and there's other licenses as well, this might be more appropriately handled by the legally literate people (no offense to you, I just know I certainly am not)
Definitely. Especially since the base question isn't answered: Is fedorahosted responsible for satisfying the GPL clauses or is the upstream author who is responsible for the project hosted on fedorahosted responsible.
-Toshio
On Wed, Sep 24, 2008 at 09:43:29AM -0700, Toshio Kuratomi wrote:
Jeroen van Meeuwen wrote:
Given that we alone can think of a couple of arguments for or against GPL distribution for 3 years or not, and there's other licenses as well, this might be more appropriately handled by the legally literate people (no offense to you, I just know I certainly am not)
Definitely. Especially since the base question isn't answered: Is fedorahosted responsible for satisfying the GPL clauses or is the upstream author who is responsible for the project hosted on fedorahosted responsible.
IANAL, but...
Whomever distributes the binaries is responsible for ensuring source is available, either concurrently (ideally)(such as GPLv2 3a), or via offer-to-provide-source-on-media (GPLv2 3b).
If binaries are not distributed from fedorahosted, then fedorahosted is not responsible for providing source for any length of time.
If binaries _are_ distributed from fedorahosted, e.g. compiled bits put into releases/, then I would expect fedorahosted to concurrently carry the source code used to build those binaries. Yes, this should be fedorahosted policy. It keeps us 100% out of the GPLv2 3b time bomb.
I would not want to see us take on any obligation on behalf of another party to keep source available for an undetermined length of time without explicit intention to do so. fedorahosted is for source. If someone downloads that source, distributes a binary to someone and claims GPLv2 3c means that fedorahosted has to provide the source for them for 3 years, they're wrong.
The three year clock is a crock. If you don't know when the last time you distributed binary under GPLv2 3b, then you can't know when the clock starts, so you can't know when the clock ends. Stay away from it. Seriously.
-Matt
On Wed, 2008-09-24 at 13:36 -0500, Matt Domsch wrote:
Whomever distributes the binaries is responsible for ensuring source is available, either concurrently (ideally)(such as GPLv2 3a), or via offer-to-provide-source-on-media (GPLv2 3b).
If binaries are not distributed from fedorahosted, then fedorahosted is not responsible for providing source for any length of time.
If binaries _are_ distributed from fedorahosted, e.g. compiled bits put into releases/, then I would expect fedorahosted to concurrently carry the source code used to build those binaries. Yes, this should be fedorahosted policy. It keeps us 100% out of the GPLv2 3b time bomb.
I would think of Fedorahosted just as i would think of a paid colo facility. Just because I may have offered software for download via the colo facility, and then I terminate my account (either due to ending a contract, or breach of contract) doesn't put the colo facility on the legal hook for software I may have hosted there.
Same goes for Fedorahosted. We can have a clear agreement as to what would breach one's "contract" with Fedorahosted, and that Fedorahosted is not responsible for any legal obligations regarding source availability.
On Wed, 24 Sep 2008, Toshio Kuratomi wrote:
Jeroen van Meeuwen wrote:
Given that we alone can think of a couple of arguments for or against GPL distribution for 3 years or not, and there's other licenses as well, this might be more appropriately handled by the legally literate people (no offense to you, I just know I certainly am not)
Definitely. Especially since the base question isn't answered: Is fedorahosted responsible for satisfying the GPL clauses or is the upstream author who is responsible for the project hosted on fedorahosted responsible.
The note I got back from legal says that as long as our policy has been clearly stated all along (and it has) we only have that as a legal obligation which is 6 months with no changes.
-Mike
Mike McGrath wrote:
For how long? Here's the concern. At some point between now and the end of time decisions are going to have to be made about these projects. I'm trying to have us learn a lesson from the elvis move as well trying to make sure other's lack of planning doesn't become Infrastructures problem. Something has to happen with bits that belong to no one, so far no one has put a time limit on any of these things.
So what I was thinking is we have several processes in place in case this happens with a package, right? One can orphan a package in which case it get's removed almost instantaneously, or start AWOL for unresponsive maintainers, and (...), so maybe what we're looking for has already been thought of -it has just not been mixed up and stirred and applied to the specific case of an upstream SCM yet.
-Jeroen
infrastructure@lists.fedoraproject.org
-
brett lentz -
Jeroen van Meeuwen -
Jesse Keating -
Matt Domsch -
Mike McGrath -
Nigel Jones -
Toshio Kuratomi