On 17/05/2016 01:00, Mauro Condarelli wrote:
> Hi,
>
> This kind of workflow is a bit complex, but has several advantages:
>
> a) everyone can directly clone the main directory without further
> requirements.
> b) everyone (with free github account) can submit issues and discuss them.
> c) everyone (with free github account) can submit patches.
> d) maintainers retain control of central repository.
> e) maintainers can request small (or big) changes to patches motivating the
> request.
> f) submitters retain control of the actual patch.
> g) infrastructure at github guides everybody easing the work.
> h) there is no need to give every contributor write access to central
> repository.
> i) there is no need for maintainers to manually incorporate patches.
>
> All this may seem overcomplex, but it's actually longer to explain than to do.
>
> It is important people is aware about what the change in infrastructure
> actually means.
> I hope this answers Adam's concerns below.
Thank you for taking the time to explain, but it doesn't (well,
partially) explain how to solve my "concern". We ideally want a larger
number of "maintainers" available to share the burden of developing
backuppc, and allowing the survival of backuppc when a couple of people
are too busy for extended periods of time. Consider if we have 3
maintainers, and one moves job, another is simply swamped with
work/family, and one is not really a developer, and gets bored of
working on backuppc. We need to actively maintain this group of
maintainers, and ensure there is always enough to allow someone else to
be added, and to remove the old maintainers that can be confirmed as no
longer interested.
So, lets say we now have 20 maintainers. One of those happens to be ...
accidentally dangerous. They follow the work flow, sending their pull
request, but since they are also a maintainer, then they immediately
accept the request, and it is committed to the main backuppc repo. Every
user after this point now ends up with a system that is corrupting 0.1%
of files backed up. It might take years before this is noticed and
tracked back to the original commit. Consider how that could be
different if the maintainer had the intent to cause damage (without
notice) or to steal information if ($domainname="cia.gov") { send_secrets }
So, I feel that we would like to enforce some peer review. Perhaps the
solution is to require 2 maintainers to approve a patch, but I fear that
increases the workload/makes the process more fragile.
Ultimately, perhaps I'm being silly, and just seeing demons where none
exist. I'm sure many open source projects would have similar issues, and
have solved them.
Regards,
Adam
> Il 16/05/2016 15:33, Adam Goryachev ha scritto:
>> On 16/05/2016 23:06, Alexander Moisseev wrote:
>>> On 16.05.2016 15:50, Adam Goryachev wrote:
>>>> Finally, I've created a github account for myself, I can't promise to do
>>>> much, but if I can at least have the ability to submit patches, then I'd
>>>> appreciate it. Having never worked with github before (other than
>>>> checking out code to use), is there an ability to have (for example) 10
>>>> people active on the project, where any one of them can submit patches,
>>>> and commit patches, but each user can't commit their own patch? Just to
>>>> ensure some level of community review?
>>> Of course it is.
>> Sorry, as I mentioned, I'm not a github user (until now).
>>
>>> Any GitHub user can make pull requests, but only organization members can
>>> commit them into the code base.
>> So what you meant is no then? ie, one organisation member can submit a
>> patch *and* commit the same patch, without any sort of review. Sure,
>> others can see the commits, and potentially submit and commit a patch to
>> undo the "erroneous" commit, but not the same as preventing the wrong
>> commit in the first place.
>>
>> Ideally, anyone can submit a patch
>> Ideally, any "approved" person can commit a patch, as long as it isn't
>> their own
>>
>> Could that be done?
>>
>> PS, I think I forgot to include my github account name "adamgoryachev",
>> I can't promise to be terribly helpful, but I do try from time to time.
>>
>> Regards,
>> Adam
>>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> BackupPC-users mailing list
> BackupPC-users AT lists.sourceforge DOT net
> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki: http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
