Hash: SHA512

On 2016-10-13 10:19, Marek Marczykowski-Górecki wrote:
> On Thu, Oct 13, 2016 at 02:21:24PM +0000, Manuel Amador (Rudd-O) wrote:
>> On 10/12/2016 10:16 PM, Marek Marczykowski-Górecki wrote:
>>> Hi,
>>> [...packagin 3rd party software...]
>>> Any thoughts?
>> I think it depends on whether the 3rd party software is meant to be
>> upstreamed into Qubes OS.
>> For example, in the case of my tools, I would like them to be
>> upstreamed, therefore the ideal thing to do would be to incorporate them
>> into the QubesOS Github org, and then add them as extra sources in the
>> builder.  That requires, of course, that Qubes OS the project provide a
>> proper process for vetting for upstreaming, and upstreaming vetted
>> software.  Ultimately the Qubes OS devs end up controlling that
>> software, and the future contribution process is simply based on pull
>> requests.
> This is generally a good idea, but I'm afraid some social effect: this
> may look like taking the software away from the original author, taking
> the credit for it. But on the other hand, the repository still will have
> commit history, and "forked from ..." reference.
> Andrew, any though on this aspect?

We certainly should aim for a solution that allows authors to retain
ownership of and control over their own software, as well as
receive credit and recognition for it, if only because this is likely
to promote more contributions from individuals who care (quite
reasonably, IMHO) about those things.

In options 1-4, the software ends up in a Qubes-owned repo no matter
what, right? It's just a matter of whether it's the official QubesOS
repo or a new repo we create specifically for that purpose.

If we want to allow authors to retain control (on GitHub) of their
own software (and not any other contributor's software), then it seems
like the only option is to allow each author to host their own
software under their own account (or an account they control).

What if we just fork those repos (either into the official QubesOS
account or into a separate one created for this purpose), then
update the forks based on changes to the author-owned original
repos (only accepting author-signed commits and/or tags, of course,
and perhaps after a review process)? Isn't that essentially what
we're already doing with i3[1], awesome[2], and yubikey[3]?
(Awesome yubikey are forked from repos owned by woju
and you, so maybe those don't really count.)

[1] https://github.com/QubesOS/qubes-desktop-linux-i3
]2] https://github.com/QubesOS/qubes-desktop-linux-awesome
[3] https://github.com/QubesOS/qubes-app-yubikey

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS


You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to