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



-- 
Cheers,
Alberto Ruiz
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reply via email to