Let's say I lose my rights under §11 to the Covered Work. Could I ask a friend to give me a copy of the same Covered Work under the GNU GPL version 3 (via section 10) and then redistribute the covered work under the GNU GPL version 3?
Maybe §11 could be explicit about what "new licenses" means, perhaps something along the lines of: "Termination of Your rights disqualifies You from receiving new licenses covering the Received Work (including any future version of this license or those listed in section 10 of this license)."
Josh
On 01/27/2013 01:52 AM, Joshua Gay wrote:
Let's say I lose my rights under §11 to the Covered Work. Could I ask a friend to give me a copy of the same Covered Work under the GNU GPL version 3 (via section 10) and then redistribute the covered work under the GNU GPL version 3?
This is a *very* interesting question. It raises a problem that arises much more generally in free software. It is what I call the "magic relicensing problem". The general approach has been to sweep this under the rug.
It also relates closely to a question @vanden was raising on identi.ca - he asked whether the basic copyleft requirement in section 5 conflicted with section 10.
The "right answer" to your question has to be 'no'; the question is how to get there. One approach is to do nothing since (a) your hypothetical isn't realistic, after all, and (b) the solution I'm thinking of might destroy the nice, simple signal section 10 gives about GPL/AGPL compatibility and put us in GPLv3 (or Creative Commonsish) stylistic territory.
The solution I'm thinking of is that section 10 should be limited to 'Derived Works'. After all, why would one ever need to distribute copyleft-next under GPL/AGPL other than in what the FSF, certainly, would consider a 'Derived Work' scenario (using the terminology of copyleft-next -- a 'work based on the Program' or 'modified version' in GPLv3 parlance). Going further, maybe section 10 should be folded into section 5. You can Distribute a Derived Work under one of the following licenses: i) this License ii) a Later Version (unless We have explicitly said you can't) iii) GPLv2, AGPLv3, or later versions
If that were the case, then (let's say I'm the copyleft-next upstream licensor) your friend can't give you an unmodified version of the same work under GPLv3. He or she can give you a 'Derived Work' licensed under GPLv3. However, I don't think this means I am giving *you* a GPLv3 license as to what I wrote.
(Think of similar facts, except my code is BSD-licensed -- and suppose violaton of the BSD license has results approximately as harsh as under copyleft-next and GPLv3.)
Maybe §11 could be explicit about what "new licenses" means, perhaps something along the lines of: "Termination of Your rights disqualifies You from receiving new licenses covering the Received Work (including any future version of this license or those listed in section 10 of this license)."
That's kind of like another way to get at the solution I'm suggesting.
This definitely goes into the Nonexistent Issue Tracker. I think whether to do something about this depends mainly on how ugly the result is.
- RF
On 01/27/2013 02:50 AM, Richard Fontana wrote:
On 01/27/2013 01:52 AM, Joshua Gay wrote:
Let's say I lose my rights under §11 to the Covered Work. Could I ask a friend to give me a copy of the same Covered Work under the GNU GPL version 3 (via section 10) and then redistribute the covered work under the GNU GPL version 3?
This is a *very* interesting question. It raises a problem that arises much more generally in free software. It is what I call the "magic relicensing problem". The general approach has been to sweep this under the rug.
It also relates closely to a question @vanden was raising on identi.ca
- he asked whether the basic copyleft requirement in section 5
conflicted with section 10.
[...]
The solution I'm thinking of is that section 10 should be limited to 'Derived Works'. After all, why would one ever need to distribute copyleft-next under GPL/AGPL other than in what the FSF, certainly, would consider a 'Derived Work' scenario (using the terminology of copyleft-next -- a 'work based on the Program' or 'modified version' in GPLv3 parlance). Going further, maybe section 10 should be folded into section 5. You can Distribute a Derived Work under one of the following licenses: i) this License ii) a Later Version (unless We have explicitly said you can't) iii) GPLv2, AGPLv3, or later versions
If that were the case, then (let's say I'm the copyleft-next upstream licensor) your friend can't give you an unmodified version of the same work under GPLv3. He or she can give you a 'Derived Work' licensed under GPLv3. However, I don't think this means I am giving *you* a GPLv3 license as to what I wrote.
Pam Chestek raised a related issue in a github pull request: "Based on paragraph 6, the Received Work is licensed to the distributee under copyleft-next, so it's only the Derived Work that would be under an alternative license. And maybe not even really that; it might be just the delta between the Received Work and the Derived Work that would be under the new license. But I concede that my change, although I believe more accurate, might create confusion."
I am tracking the underlying issue here on github at https://github.com/richardfontana/copyleft-next/issues/30
- RF
I apologize that my job at Conservancy and volunteer work at FSF has made it impossible for me to fit in volunteer work to help copyleft-next. However, I find it quite disturbing that the project is returning to GitHub. I've submitted this merge request to prevent the slippery slope toward proprietary solutions that copyleft-next appears to be on. HBR should stand up for the software freedom of users.
Please merge:
https://gitorious.org/copyleft-next/copyleft-next/merge_requests/29
-- bkuhn
On 02/07/2013 09:28 PM, Bradley M. Kuhn wrote:
I apologize that my job at Conservancy and volunteer work at FSF has made it impossible for me to fit in volunteer work to help copyleft-next. However, I find it quite disturbing that the project is returning to GitHub. I've submitted this merge request to prevent the slippery slope toward proprietary solutions that copyleft-next appears to be on. HBR should stand up for the software freedom of users.
Please merge:
https://gitorious.org/copyleft-next/copyleft-next/merge_requests/29
-- bkuhn _______________________________________________ copyleft-next mailing list copyleft-next@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/copyleft-next
Bradley,
Please do also disclose a summary of your sidebar discussion with Richard Fontana as well as Claes Wallin that appears to be happening on Identica and other federated StatusNet sites. That appears to be germane to this merge request and yet not necessarily represented on-list. This e-mail list remains our primary means of record communications relative to the project.
I am minded at this point to ask that the folks who find the need to use GitHub please make themselves heard on list within our primary record of communications. The mailing list has functioned quite well as a de facto issue tracker thus far and I do not enjoy the notion of having to chase down discussion across multiple fora.
Stephen Michael Kellat
On Thu, Feb 07, 2013 at 10:14:17PM -0500, Stephen Michael Kellat wrote:
I am minded at this point to ask that the folks who find the need to use GitHub please make themselves heard on list within our primary record of communications. The mailing list has functioned quite well as a de facto issue tracker thus far and I do not enjoy the notion of having to chase down discussion across multiple fora.
This is a good point. I am the one at fault here.
I have assumed from the get-go that some people would wish to contribute via GitHub, hence my faithful mirroring of the Gitorious repository there. Yesterday I made convenience use of the GitHub issue tracker. This was in response to a rather unique situation, in which one GitHub contributor put a large set of useful changes, with a large set of useful comments, in one pull request. (The contributor first attempted to use Gitorious and found it too difficult.) For issue-management purposes I began to record individual issues from this pull request in the GitHub issue tracker. What I'll do from now on, and until some 'real' issue tracking solution is adopted, is avoid any temptation to use the GitHub issue tracker and instead use the mailing list.
- RF
Stephen Michael Kellat wrote at 22:14 (EST) on Thursday:
Please do also disclose a summary of your sidebar discussion with Richard Fontana as well as Claes Wallin that appears to be happening on Identica and other federated StatusNet sites.
Stephen, since that discussion is public, I am pretty sure it's not an HBR violation to discuss copyleft-next on identi.ca, since it's a public forum. But I see your point (more on that below).
Meanwhile, my understanding of the identi.ca conversation is this:
* Pam Chestek got copyleft-next off GitHub, and nothing there told her GitHub wasn't the canonical location for participation (this should be fixed immediately, IMO. I realize the README says it, but there should be something in big bold letters on GitHub: THIS IS A MIRROR ONLY. DO NOT SUBMIT PULL REQUESTS AND ISSUES HERE. USE MAILING LIST AND GITORIOUS [or whatever solution Fontana decides]. Ideally, the pull request/issue tracker should be turned off.
* Pam realized, probably after getting the checkout and seeing the readme, that Gitorious was preferred.
* Pam couldn't submit changes via Gitorious (at that point, presumably her tracking branches were all pointed at GitHub, which was probably part of the problem).
* Fontana opened an issue on GitHub to collaborate with Pam on the issue she raised.
* I theorized that this marked a distributing occurrence, since GitHub instance of copyleft-next seemed to be active again instead of just being a mirror. I complained heavily to Fontana about it, and Fontana countered with what I believed were incorrect analogies to GPLv3 drafting process (i.e., I thought copyleft-next was trying to avoid those, anyway!)
Pam and Fontana, is that summary accurate from your point of view?
I am minded at this point to ask that the folks who find the need to use GitHub please make themselves heard on list within our primary record of communications. The mailing list has functioned quite well as a de facto issue tracker thus far and I do not enjoy the notion of having to chase down discussion across multiple fora.
This is a good point. I'll try to avoid using identi.ca to discuss copyleft-next in future.
I do agree that having to follow GitHub, identi.ca, Gitorious, and this mailing list is annoying. While HBR doesn't prohibit it, I suggest we all work to restrain ourselves to use *only* the mailing list and Gitorious and nothing else for now, to avoid people having to track so many fora.
I have *so* little time for copyleft-next, thus I really am swayed by Stephen's point here. I had assumed that checking the git log from Gitorious and reading mailing list traffic would be adequate any time I had a moment to check in with copyleft-next. If that's not true: because of use of GitHub, identi.ca, or any other fora being used, we may want to nip it -- not because it's an HBR violation or even because one of those solutions is proprietary (identi.ca isn't after all), but because it makes it difficult to follow a conversation across so many fora.
I hadn't realized how big of a problem that is for people who have limited time for the project until Stephen raised it. Thanks for raising that point.
The summary is accurate from my viewpoint. I knew months ago that Richard had put the repository on Github, but the knowledge was old and I didn't realize bad. So after FOSDEM I went straight to Github. It would have taken really big red flags for me to wake up and realize that I was in the wrong place. I ultimately figured it out because of the reference to Gitorious in the license itself.
I was wrong in my dent when I said I downloaded from Github; I didn't, I edited right on Github. Upon realizing my error, I then dutifully downloaded from Gitorious and started over. As explained when I submitted to Github, the problem was that I couldn't figure out how to get the changes from my computer to Gitorious to ask for a merge, and I also suspect I probably also have it all configured wrong on my computer anyway. At that point I just gave up. I figured it was going to take me yet several more hours to figure it out, and while I considered it a worthwhile effort, I didn't have that time at the moment and wanted to wrap up my task and provide feedback after FOSDEM in a timely manner. Therefore the fateful decision to submit on Github.
Pam
On Fri, Feb 8, 2013 at 8:36 AM, Bradley M. Kuhn bkuhn@ebb.org wrote:
Stephen Michael Kellat wrote at 22:14 (EST) on Thursday:
Please do also disclose a summary of your sidebar discussion with Richard Fontana as well as Claes Wallin that appears to be happening on Identica and other federated StatusNet sites.
Stephen, since that discussion is public, I am pretty sure it's not an HBR violation to discuss copyleft-next on identi.ca, since it's a public forum. But I see your point (more on that below).
Meanwhile, my understanding of the identi.ca conversation is this:
Pam Chestek got copyleft-next off GitHub, and nothing there told her GitHub wasn't the canonical location for participation (this should be fixed immediately, IMO. I realize the README says it, but there should be something in big bold letters on GitHub: THIS IS A MIRROR ONLY. DO NOT SUBMIT PULL REQUESTS AND ISSUES HERE. USE MAILING LIST AND GITORIOUS [or whatever solution Fontana decides]. Ideally, the pull request/issue tracker should be turned off.
Pam realized, probably after getting the checkout and seeing the readme, that Gitorious was preferred.
Pam couldn't submit changes via Gitorious (at that point, presumably her tracking branches were all pointed at GitHub, which was probably part of the problem).
Fontana opened an issue on GitHub to collaborate with Pam on the issue she raised.
I theorized that this marked a distributing occurrence, since GitHub instance of copyleft-next seemed to be active again instead of just
being a mirror. I complained heavily to Fontana about it, and Fontana countered with what I believed were incorrect analogies to GPLv3 drafting process (i.e., I thought copyleft-next was trying to avoid those, anyway!)
Pam and Fontana, is that summary accurate from your point of view?
I am minded at this point to ask that the folks who find the need to use GitHub please make themselves heard on list within our primary record of communications. The mailing list has functioned quite well as a de facto issue tracker thus far and I do not enjoy the notion of having to chase down discussion across multiple fora.
This is a good point. I'll try to avoid using identi.ca to discuss copyleft-next in future.
I do agree that having to follow GitHub, identi.ca, Gitorious, and this mailing list is annoying. While HBR doesn't prohibit it, I suggest we all work to restrain ourselves to use *only* the mailing list and Gitorious and nothing else for now, to avoid people having to track so many fora.
I have *so* little time for copyleft-next, thus I really am swayed by Stephen's point here. I had assumed that checking the git log from Gitorious and reading mailing list traffic would be adequate any time I had a moment to check in with copyleft-next. If that's not true: because of use of GitHub, identi.ca, or any other fora being used, we may want to nip it -- not because it's an HBR violation or even because one of those solutions is proprietary (identi.ca isn't after all), but because it makes it difficult to follow a conversation across so many fora.
I hadn't realized how big of a problem that is for people who have limited time for the project until Stephen raised it. Thanks for raising that point. -- -- bkuhn _______________________________________________ copyleft-next mailing list copyleft-next@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/copyleft-next
On Fri, Feb 8, 2013 at 3:36 PM, Bradley M. Kuhn bkuhn@ebb.org wrote:
I'll try to avoid using identi.ca to discuss copyleft-next in future.
I do agree that having to follow GitHub, identi.ca, Gitorious, and this mailing list is annoying. While HBR doesn't prohibit it, I suggest we all work to restrain ourselves to use *only* the mailing list and Gitorious and nothing else for now, to avoid people having to track so many fora.
I'd suggest a tweak to this, if I may: discussions happen, on other media, and they may contain proposals or raise issues. Before they result in any kind of changes in copyleft-next, they could/should be referenced and discussed on this mailing list. Would that work, to address the too many fora?
Regarding import of existing github issues content, I'll be happy to make the import, when the project chooses its wanted tracker. There are about thirty issues so far, maybe not critical, but for traceability in the future it still makes sense, at least to me, to keep the data.
On Fri, Feb 08, 2013 at 11:37:00PM +0200, Engel Nyst wrote:
I'd suggest a tweak to this, if I may: discussions happen, on other media, and they may contain proposals or raise issues. Before they result in any kind of changes in copyleft-next, they could/should be referenced and discussed on this mailing list. Would that work, to address the too many fora?
I think that is probably workable.
The future issue tracker ought to be as acceptable as the mailing list IMO.
Regarding import of existing github issues content, I'll be happy to make the import, when the project chooses its wanted tracker. There are about thirty issues so far, maybe not critical, but for traceability in the future it still makes sense, at least to me, to keep the data.
Agreed.
- RF
On Fri, Feb 08, 2013 at 08:36:42AM -0500, Bradley M. Kuhn wrote:
Meanwhile, my understanding of the identi.ca conversation is this:
Pam Chestek got copyleft-next off GitHub, and nothing there told her GitHub wasn't the canonical location for participation (this should be fixed immediately, IMO. I realize the README says it, but there should be something in big bold letters on GitHub: THIS IS A MIRROR ONLY. DO NOT SUBMIT PULL REQUESTS AND ISSUES HERE. USE MAILING LIST AND GITORIOUS [or whatever solution Fontana decides]. Ideally, the pull request/issue tracker should be turned off.
Pam realized, probably after getting the checkout and seeing the readme, that Gitorious was preferred.
Pam couldn't submit changes via Gitorious (at that point, presumably her tracking branches were all pointed at GitHub, which was probably part of the problem).
Fontana opened an issue on GitHub to collaborate with Pam on the issue she raised.
I theorized that this marked a distributing occurrence, since GitHub instance of copyleft-next seemed to be active again instead of just being a mirror. I complained heavily to Fontana about it, and Fontana countered with what I believed were incorrect analogies to GPLv3 drafting process (i.e., I thought copyleft-next was trying to avoid those, anyway!)
Pam and Fontana, is that summary accurate from your point of view?
Except for the very last part, it's completely inaccurate, but Pam has corrected the error.
I do agree that having to follow GitHub, identi.ca, Gitorious, and this mailing list is annoying.
I agree with that too. For a long time it wasn't a practical problem.
- RF
On Sat, Feb 09, 2013 at 10:42:29AM -0500, Richard Fontana wrote:
Except for the very last part, it's completely inaccurate, but Pam has corrected the error.
Oops, Pam has said it is accurate, so my statement was completely inaccurate except in saying that the last part of Bradley's statement was accurate, since that part was clearly accurate.
- RF
On Fri, Feb 8, 2013 at 5:14 AM, Stephen Michael Kellat <skellat@fastmail.net
wrote:
Please do also disclose a summary of your sidebar discussion with Richard Fontana as well as Claes Wallin that appears to be happening on Identica and other federated StatusNet sites. That appears to be germane to this merge request and yet not necessarily represented on-list. This e-mail list remains our primary means of record communications relative to the project.
I am minded at this point to ask that the folks who find the need to use GitHub please make themselves heard on list within our primary record of communications. The mailing list has functioned quite well as a de facto issue tracker thus far and I do not enjoy the notion of having to chase down discussion across multiple fora.
Point taken. Completely unrelated to yesterday's issue, I have done this as well. I apologize. I can think of a couple circumstances when my random use of different sites (all three mentioned here) to provide feedback or potential issues, might pose problems from the perspective of the normal communication through the project's primary medium.
I believe many were unbaked comments or random ideas exchanges, due more to lack of expertise (or arguably even attention), and not intended as actual proposals. However, I have also submitted a couple issues, intended as proposals for copyleft-next, on github, or as comment to existing github issues. The first has been on github by mistake/inertia: I have initially missed the project's policy, thus I have submitted a pull request on github. I have immediately afterwards switched to gitorious, for subsequent merge requests.
In general, personally I use github, as a matter of randomness and convenience, however I do not support its use.
Re: github issues tracker. To my knowledge, it doesn't allow directly backing up the issues database. (though email notifications work). If this is still the case, I believe it to be one more reason not to settle for it, not for anything of real relevance to the project.
I apologize for not bringing issues of potential relevance to everyone's attention on the mailing list. I will fix that.
On Fri, Feb 08, 2013 at 04:58:20PM +0200, Engel Nyst wrote:
Point taken. Completely unrelated to yesterday's issue, I have done this as well. I apologize. I can think of a couple circumstances when my random use of different sites (all three mentioned here) to provide feedback or potential issues, might pose problems from the perspective of the normal communication through the project's primary medium.
I believe many were unbaked comments or random ideas exchanges, due more to lack of expertise (or arguably even attention), and not intended as actual proposals. However, I have also submitted a couple issues, intended as proposals for copyleft-next, on github, or as comment to existing github issues. The first has been on github by mistake/inertia: I have initially missed the project's policy, thus I have submitted a pull request on github. I have immediately afterwards switched to gitorious, for subsequent merge requests.
As for me, I was happy to receive such comments and ideas, regardless of medium. The only problem from my perspective was the practical one of having too many things to keep track of. I didn't say anything because I didn't want to discourage such participation. Same goes with pchestek. So I suppose the one mistake I made was active use of the GitHub issue tracker, yet this was not really a mistake because a few days earlier I had a presentation slide that said that the GitHub issue tracker was appropriate for use for the time being. Nevertheless I do not anticipate making further active use of the GitHub issue tracker at this time.
- RF
On Thu, Feb 07, 2013 at 09:28:42PM -0500, Bradley M. Kuhn wrote:
I apologize that my job at Conservancy and volunteer work at FSF has made it impossible for me to fit in volunteer work to help copyleft-next. However, I find it quite disturbing that the project is returning to GitHub.
The project is not 'returning to GitHub' (I'm not even sure what that would mean). Rather, a few people have recently been using GitHub to make contributions.
I've submitted this merge request to prevent the slippery slope toward proprietary solutions that copyleft-next appears to be on. HBR should stand up for the software freedom of users.
Please merge:
https://gitorious.org/copyleft-next/copyleft-next/merge_requests/29
I have rejected this merge request because it is outside the scope of the HBR. That is not in itself a rejection of the policy position you are advancing.
From the moment Gitorious began to be used as the canonical public
source repository, it was understood that the GitHub mirror would remain operative and even that continued use of the GitHub issue tracker for the GitHub repository was tolerable pending the adoption of some better option. Thus, I am just preserving the status quo.
I am thinking of ceasing use of Gitorious because I've had one too many problems with the service. But the solution won't be substitution of GitHub for Gitorious.
- RF
Richard Fontana wrote at 22:55 (EST) on Thursday:
The project is not 'returning to GitHub' (I'm not even sure what that would mean). Rather, a few people have recently been using GitHub to make contributions.
I'm not objecting to what other participants might do. The maintainer's use of GitHub, though, would make it official. Consider, for example, if Linus Torvalds started using GitHub as the location to accept merge requests.
I have rejected this merge request because it is outside the scope of the HBR. That is not in itself a rejection of the policy position you are advancing.
That makes sense. You are probably correct that it is outside HBR's scope.
Can we discuss institution of a rule that only Free Software and network services that share their code will be used to develop copyleft-next? Are you willing to consider such a rule (outside the scope of HBR, of course)?
even that continued use of the GitHub issue tracker for the GitHub repository was tolerable pending the adoption of some better option. Thus, I am just preserving the status quo.
I'm willing to set up a bugs-everywhere area in the canonical Git repository for copyleft-next and scrape all the content from there into bugs-everywhere, but *only* if there could be agreement that it would become canonical and use of the GitHub Issue Tracker would cease, with a statement on the GitHub page that says not to use the Issue Tracker, but to use bugs-everywhere instead. Is that agreeable?
One of the reasons (although a minor one -- lack of time due to my pre-existing highly demanding work and volunteer commitments is the primary reason) I haven't helped with the Issue tracker is fear that I'd put a lot of work in only to have it rejected by our dictator. :)
I am thinking of ceasing use of Gitorious because I've had one too many problems with the service. But the solution won't be substitution of GitHub for Gitorious.
It's very good to know that yesterday's incident *does not* indicate we're on a slippery slope back to GitHub. Perhaps we're on a slippery slope toward self-hosting, which is probably ok.
BTW, have you reported bugs to Gitorious? Offered patches?
On Fri, Feb 08, 2013 at 08:29:31AM -0500, Bradley M. Kuhn wrote:
Can we discuss institution of a rule that only Free Software and network services that share their code will be used to develop copyleft-next? Are you willing to consider such a rule (outside the scope of HBR, of course)?
Sure, it should be considered. But defining what that means may not be as easy as you are assuming.
I'm willing to set up a bugs-everywhere area in the canonical Git repository for copyleft-next and scrape all the content from there into bugs-everywhere, but *only* if there could be agreement that it would become canonical and use of the GitHub Issue Tracker would cease, with a statement on the GitHub page that says not to use the Issue Tracker, but to use bugs-everywhere instead. Is that agreeable?
I still want to investigate alternatives to bugs-everywhere. I'll try to do that soon.
It's very good to know that yesterday's incident *does not* indicate we're on a slippery slope back to GitHub. Perhaps we're on a slippery slope toward self-hosting, which is probably ok.
I don't understand why self-hosting is considered worse than using some gratis service that purports to offer its source code, which is what I read into your phrase "probably OK". Isn't self-hosting always *better* from a software freedom perspective?
BTW, have you reported bugs to Gitorious? Offered patches?
'Offering patches' doesn't make sense; even if a network service purports to provide its source code, there's no reliable way to know whether the source code is corresponding for immediate error-reporting purposes, so it's not worth the effort to try to build an instance of Gitorious myself, try to recreate the error, and then offer a patch upstream. If I were to do that, from a conservation of effort perspective I might as well just use Gitorious for self-hosting.
I pointed out one of the problems I was experiencing a while back to Gitorious, and it was corrected. As for the other mysterious glitches and suboptimal behavior I claim to have experienced, I am in the usual situation of not knowing what to report. To put it another way, it is less effort to find a non-Gitorious solution than to figure out how to usefully report the problems I've experienced.
- RF
Richard Fontana wrote:
I am tracking the underlying issue here on github at
BTW, could someone please state (or restate) the reasons that http://bugseverywhere.org/ was rejected as an issue tracker for copyleft-next?
-- bkuhn
On 02/07/2013 10:03 PM, Bradley M. Kuhn wrote:
Richard Fontana wrote:
I am tracking the underlying issue here on github at
BTW, could someone please state (or restate) the reasons that http://bugseverywhere.org/ was rejected as an issue tracker for copyleft-next?
-- bkuhn _______________________________________________ copyleft-next mailing list copyleft-next@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/copyleft-next
Bradley,
My logs lack reasoning in that regard. If we were to utilize BugsEverywhere, we could switch to Fossil SCM which is at least an integrated distributed system. See: http://fossil-scm.org/index.html/doc/trunk/www/index.wiki
Stephen Michael Kellat
On Thu, Feb 07, 2013 at 10:16:17PM -0500, Stephen Michael Kellat wrote:
On 02/07/2013 10:03 PM, Bradley M. Kuhn wrote:
Richard Fontana wrote:
I am tracking the underlying issue here on github at
BTW, could someone please state (or restate) the reasons that http://bugseverywhere.org/ was rejected as an issue tracker for copyleft-next?
Bradley,
My logs lack reasoning in that regard. If we were to utilize BugsEverywhere, we could switch to Fossil SCM which is at least an integrated distributed system. See: http://fossil-scm.org/index.html/doc/trunk/www/index.wiki
I remember BugsEverywhere being suggested by someone somewhere (possibly in a comment to a GitHub issue) but ISTR something about it was considered suboptimal. In any case I never investigated it or alternatives.
- RF
Richard Fontana wrote at 22:40 (EST) on Thursday:
ISTR something about [BugsEverywhere] was considered suboptimal.
Could you investigate BugsEverywhere and either approve it as a solution (in which case, I could help you set it up) or state clear reasons for objecting it?
Note that IMO "suboptimal" isn't a reason not to use something. GitHub is suboptimal in many ways (and not only the proprietary reasons of my concern). So is a mailing list. I hope you won't let the best be the enemy of the good.
On Fri, Feb 08, 2013 at 08:49:18AM -0500, Bradley M. Kuhn wrote:
I hope you won't let the best be the enemy of the good.
My basic criteria for an issue tracker are:
1) Not written in PHP 2) Doesn't use a database
On Fri, Feb 08, 2013 at 08:49:18AM -0500, Bradley M. Kuhn wrote:
Richard Fontana wrote at 22:40 (EST) on Thursday:
ISTR something about [BugsEverywhere] was considered suboptimal.
Could you investigate BugsEverywhere and either approve it as a solution (in which case, I could help you set it up) or state clear reasons for objecting it?
I have now investigated Bugs Everywhere. Unfortunately I object to it. This saddens me because it seems to come *very* close to what I have in mind for a perfect issue tracker.
My objections are that it appears to be poorly-documented and poorly-maintained to the point where the annoyance of using it will greatly exceed the benefits, and where the likelihood of future versions of it or its dependencies causing everything to break seems unusually high.
This is too bad, because I don't think there's anything better.
Note that IMO "suboptimal" isn't a reason not to use something. GitHub is suboptimal in many ways (and not only the proprietary reasons of my concern). So is a mailing list. I hope you won't let the best be the enemy of the good.
The problem is that Bugs Everywhere doesn't even meet my standard of 'good'.[1] If I were sufficiently skilled at Python or *wanted* to be (I *currently* don't), I'd consider helping out with or forking the project.
- RF
[1] I tried using both the version packaged in Fedora 17 and the more recent verson available from the project's Gitorious repository.
On Thu, Feb 07, 2013 at 01:05:26AM -0500, Richard Fontana wrote:
I am tracking the underlying issue here on github at https://github.com/richardfontana/copyleft-next/issues/30
In light of my response to Stephen, this can be ignored. Please use the mailing list to discuss this issue.
- RF
copyleft-next@lists.fedorahosted.org
-
Bradley M. Kuhn -
Engel Nyst -
Joshua Gay -
Pamela Chestek -
Richard Fontana -
Stephen Michael Kellat