On Thu, Aug 15, 2013 at 8:34 AM, fr33domlover <[email protected]>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 <[email protected]> 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 > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Jasper
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
