Allow me to clarify: You're free to use github mirrors, it's your right to do so. But I have the right not to cooperate with this. All Gnome maintainers have this right.
If you're going to enable those github mirrors, make sure any maintainer can easily turn off mirroring for their module. On ה', 2013-08-15 at 14:57 +0200, Alberto Ruiz wrote: > Hey there, > > I can't help but notice that your mail provider, mailoo has a twitter > account to promote themselves: https://twitter.com/mailoopointorg > > You should switch your email provider immediatly, as they are > promoting a centralized closed source service in their very frontpage! > > 2013/8/15 fr33domlover <fr33domlo...@mailoo.org>: > > Hey Jasper, > > > > Excellent questions. I suggest module maintainers decide together on > > each module, and other people can't control the mirroring in their name. > > You can suggest all that you want, but until the day > > > Or just take the simple solution: Use a free software decentralized git > > hosting. For example Gitorious or Gitlab. Gitlab seems to have many cool > > features like Github and it's fully free software you can run on your > > own server. > > > > Does anyone have something against using these, instead of the > > proprietary centralized alternative GitHub, which happens to be popular? > > > > It's not my fault people use GitHub. It certainly doesn't mean I get > > basic rights taken, just because people don't care enough about the > > freedom of the software they use. > > > > > > > > I refuse to endorse Github in any way, on the grounds of it being > > partially proprietary and centralized. Can anything make more sense than > > this? Isn't software freedom our basics? > > > > > > On ה', 2013-08-15 at 08:37 -0400, Jasper St. Pierre wrote: > >> > >> > >> > >> On Thu, Aug 15, 2013 at 8:34 AM, fr33domlover > >> <fr33domlo...@mailoo.org> wrote: > >> No problems, GNOME having read-only mirrors can be useful to > >> people. > >> > >> Just make sure there's an easy way to opt out. For example, I > >> wouldn't > >> want any of my code automatically uploaded to GitHub. I think > >> every > >> maintainer should have the right to cancel mirroring for their > >> module. > >> > >> If GitHub was free software, decentralized, etc, then I could > >> maybe > >> agree that mirroring can be activated by default for existing > >> and new > >> modules. But considering the nature of GitHub, I consider it > >> somewhat > >> rude to mirror a module without letting a maintainer an option > >> to cancel > >> it, or make it disabled by default and allowing the maintainer > >> to switch > >> it on. > >> > >> > >> > >> Who gets the say? What happens if there's two maintainers to a > >> project? What if you've contributed code to GNOME that's under a > >> different repository. What happens if someone manually mirrors your > >> repository under their own name. > >> > >> > >> It's not realistic to have an opt-out button for contributors. It's > >> free software, and that doesn't change whether we put it on a > >> proprietary platform or not. > >> > >> > >> On ה', 2013-08-15 at 13:20 +0100, Emmanuele Bassi wrote: > >> > hi Luis; > >> > > >> > thanks for answering. > >> > > >> > On 15 August 2013 13:00, Luis Menina > >> <liberfo...@freeside.fr> wrote: > >> > > Le 15/08/2013 12:44, Emmanuele Bassi a écrit : > >> > >>> Actually, the fact that we have to ask to opt out is an > >> issue in > >> > >>> itself. We shouldn't even have to. This should have been > >> opt in from > >> > >>> the start. People (maintainers and commiters in this > >> case) shouldn't > >> > >>> have to fight to get back what you have taken away from > >> them. > >> > >> > >> > >> considering that this is a mirroring system of a > >> distributed version > >> > >> control system, I'm puzzled as to what has been lost. you > >> still have > >> > >> all your rights to the software you maintain and commit > >> to, and you > >> > >> still have the right to push your work to more than one > >> repository. > >> > >> care to elaborate a bit more on this? > >> > > > >> > > I'm not a maintainer, but it seems to me that a maintainer > >> may want as > >> > > few entry points for patches as possible, or at least not > >> need to poll > >> > > to find patches. We already have bugzilla, or > >> git.gnome.org. If extra > >> > > clones exist and seem officially endorsed by GNOME, and > >> there's no > >> > > process to send those patches upstream, this clearly means > >> it's up to > >> > > the maintainer to poll for patches on these extra clones. > >> > > >> > as I said the last time the idea of a github clone was being > >> floated > >> > around, I don't want to look in multiple places for patches. > >> nor I > >> > want to get pull requests from mirrors I don't maintain > >> directly — and > >> > even then, I basically always say that if a patch is not on > >> Bugzilla, > >> > then it doesn't exist. > >> > > >> > the work that Alberto did, though, seem to be clear that: a) > >> the > >> > canonical place for submitting patches is Bugzilla, and b) > >> the GitHub > >> > clones are for mirroring only, so that people can easily > >> create a > >> > public fork on their own GitHub account when they wish to > >> hack on > >> > something. it is, essentially, a read-only mirror. as a > >> maintainer, I > >> > don't have a problem with exposing my code on multiple > >> venues — that's > >> > what I do already every day. > >> > > >> > ciao, > >> > Emmanuele. > >> > > >> > >> > >> > >> _______________________________________________ > >> desktop-devel-list mailing list > >> desktop-devel-list@gnome.org > >> https://mail.gnome.org/mailman/listinfo/desktop-devel-list > >> > >> > >> > >> -- > >> Jasper > >> > > > > > > _______________________________________________ > > desktop-devel-list mailing list > > desktop-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
