Hash: SHA256

On Thu, Oct 13, 2016 at 11:30:39AM -0700, Andrew David Wong wrote:
> 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.

Not necessary - option 3 is about keeping only build scripts (.spec,
etc) in our repository, but pull the actual source from upstream. 
I'm somehow reluctant for creating a single multi-package repository,
mostly because qubes-builder (currently) does not support building a
single package from such repo. So updating a single package means
rebuilding all of them. But should be easy to fix - for example keep
packages in separate directories (which is good idea anyway) and only
point qubes-builder at those subdirectories.

> 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.)

Yes, this is the other option. The question here is: where should those
forks be (current github org or a new one) and how should be named
(original name, or some forced naming scheme like qubes-app-*)?

> [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

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Version: GnuPG v2


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