Turning the opscode-webui2 repo from private to public


#1

Hi,

I’ve asked this at the last irc meeting, but it wasn’t on the agenda so I
was asked to discuss it at a later time.
I was told that the webui2 repo is kept private mainly because it is a
proprietary product. When asked how would turning the repo would make any
difference when we already share the code publically as part of
the opscode-manage plugin/package I was told that there are some javascript
files which are only available in minified form in the package.
Given how easy is to reformat js code if no other obfuscated method is
used, I think that keeping the repo private doesn’t really help with
anything, but makes it harder to report bugs (as AFAIK the prefered method
is to use github issues for reporting the bug to the appropriate
repository) or to send pull request.
I would like to know if there are other reasons for keeping the repo
private or if there is any chance or plans for turning it into public.

Thanks!


Ferenc Kovács
@Tyr43l - http://tyrael.hu


#2

My 10c,

If nothing else they could create an empty public repo just for
reporting bugs. I admit CoreOS made me fond of this idea as it helps
with triage.

On 1/10/15 4:44 AM, Ferenc Kovacs wrote:

Hi,

I’ve asked this at the last irc meeting, but it wasn’t on the agenda so
I was asked to discuss it at a later time.
I was told that the webui2 repo is kept private mainly because it is a
proprietary product. When asked how would turning the repo would make
any difference when we already share the code publically as part of
the opscode-manage plugin/package I was told that there are some
javascript files which are only available in minified form in the package.
Given how easy is to reformat js code if no other obfuscated method is
used, I think that keeping the repo private doesn’t really help with
anything, but makes it harder to report bugs (as AFAIK the prefered
method is to use github issues for reporting the bug to the appropriate
repository) or to send pull request.
I would like to know if there are other reasons for keeping the repo
private or if there is any chance or plans for turning it into public.

Thanks!


Ferenc Kovács
@Tyr43l - http://tyrael.hu
!DSPAM:54b11ea3231786337816477!


#3

On Jan 10, 2015, at 2:01 PM, Scott M. Likens scott@likens.us wrote:

My 10c,

If nothing else they could create an empty public repo just for
reporting bugs. I admit CoreOS made me fond of this idea as it helps
with triage.

https://github.com/coreos/bugs/issues

This already exists https://github.com/opscode/chef-server

–Noah


#4

You can report bugs at the chef-server repo. It’s not on github because it is not open source - the fact that you can see it within the (proprietary licensed) package doesn’t mean you can fork,edit, compile, or even run it without submitting to our terms of use.

Sent from my iPhone

On Jan 10, 2015, at 4:44 AM, Ferenc Kovacs tyra3l@gmail.com wrote:

Hi,

I’ve asked this at the last irc meeting, but it wasn’t on the agenda so I was asked to discuss it at a later time.
I was told that the webui2 repo is kept private mainly because it is a proprietary product. When asked how would turning the repo would make any difference when we already share the code publically as part of the opscode-manage plugin/package I was told that there are some javascript files which are only available in minified form in the package.
Given how easy is to reformat js code if no other obfuscated method is used, I think that keeping the repo private doesn’t really help with anything, but makes it harder to report bugs (as AFAIK the prefered method is to use github issues for reporting the bug to the appropriate repository) or to send pull request.
I would like to know if there are other reasons for keeping the repo private or if there is any chance or plans for turning it into public.

Thanks!


Ferenc Kovács
@Tyr43l - http://tyrael.hu


#5

On Sun, Jan 11, 2015 at 1:31 AM, Adam Jacob adam@chef.io wrote:

You can report bugs at the chef-server repo.

thanks!

It’s not on github because it is not open source

(it is on github, but in a private repo, under opscode/opscode-webui2),
yeah, I was aware that it isn’t open source(only Chef Server core is
licensed under the Apache license) but in it’s current situation (where
there seems to be no “secret” stuff in the repo) I thought it would make
sense to have it in a public repo, and the replies I got it on irc was
showing that the idea was at least considered before:
https://botbot.me/freenode/chef-hacking/2015-01-08/?msg=29060922&page=2

  • the fact that you can see it within the (proprietary licensed) package
    doesn’t mean you can fork,edit, compile, or even run it without submitting
    to our terms of use.

of course, but does that mean that if I find an obvious bug I can’t paste
the diff for the fix to the github issue?
if that’s ok, I fail to see why would it bad if it would be easier to
report/fix bugs or just communicate about them (see
https://github.com/opscode/opscode-omnibus/issues/535#issuecomment-58610366
or
https://github.com/opscode/opscode-omnibus/issues/534#issuecomment-58129263
or
https://tickets.opscode.com/browse/CHEF-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel)
where it is a PITA to follow the discussion for those without access to the
repo.
but IANAL, and it is your decision, it was just something I wanted to ask!


Ferenc Kovács
@Tyr43l - http://tyrael.hu


#6

Hey Ferenc,

I want to follow up on this. Right now the webui2 repo is, as you’ve
stated, private (we’re actually going to rename the repo to match the
product name, which is Chef Management Console, so in the near future
that repo will have a new name). It is private because it is a propriety
feature of Chef and the current policy for now is to keep all propriety
feature repos private. As you said, it’s not actually difficult to
reverse engineer the code if you so desire. We know this, but we trust
you all and trust that you won’t rip off the code for your own purposes,
since this code is propriety.

We can certainly have a discussion about opening the repo, but I don’t
expect that to change in the near term. While Chef is a very open
company, for proprietary features we’re not in the habit of just giving
the code away, even if we purposefully don’t make it hard to reverse
engineer. You’re more than welcome to add it to the IRC meeting agenda,
however, as it’s worth having a discussion about.

You are very welcome to open bugs for the Management Console and any of
the server adds agains the chef-server repo. The team working on the
Management Console will see them there. It is probably worth considering
if we wanted to create an empty repo for the filing of issues (which we
did with the chef-server repo itself). For now though, just use the
chef-server repo. We’ll be more than happy to work with you to get the
bug addressed, although we do recognize that it’s a bit of a pain to
communicate about a repo you can’t see.

Thanks,

Mark Mzyk

Ferenc Kovacs mailto:tyra3l@gmail.com
January 12, 2015 at 2:21 PM

On Sun, Jan 11, 2015 at 1:31 AM, Adam Jacob <adam@chef.io
mailto:adam@chef.io> wrote:

You can report bugs at the chef-server repo.

thanks!

It's not on github because it is not open source

(it is on github, but in a private repo, under opscode/opscode-webui2),
yeah, I was aware that it isn’t open source(only Chef Server core is
licensed under the Apache license) but in it’s current situation
(where there seems to be no “secret” stuff in the repo) I thought it
would make sense to have it in a public repo, and the replies I got it
on irc was showing that the idea was at least considered before:
https://botbot.me/freenode/chef-hacking/2015-01-08/?msg=29060922&page=2 https://botbot.me/freenode/chef-hacking/2015-01-08/?msg=29060922&page=2

- the fact that you can see it within the (proprietary licensed)
package doesn't mean you can fork,edit, compile, or even run it
without submitting to our terms of use.

of course, but does that mean that if I find an obvious bug I can’t
paste the diff for the fix to the github issue?
if that’s ok, I fail to see why would it bad if it would be easier to
report/fix bugs or just communicate about them (see
https://github.com/opscode/opscode-omnibus/issues/535#issuecomment-58610366
or
https://github.com/opscode/opscode-omnibus/issues/534#issuecomment-58129263
or
https://tickets.opscode.com/browse/CHEF-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel)
where it is a PITA to follow the discussion for those without access
to the repo.
but IANAL, and it is your decision, it was just something I wanted to ask!


Ferenc Kovács
@Tyr43l - http://tyrael.hu
Adam Jacob mailto:adam@chef.io
January 10, 2015 at 7:31 PM
You can report bugs at the chef-server repo. It’s not on github
because it is not open source - the fact that you can see it within
the (proprietary licensed) package doesn’t mean you can fork,edit,
compile, or even run it without submitting to our terms of use.

Sent from my iPhone

On Jan 10, 2015, at 4:44 AM, Ferenc Kovacs <tyra3l@gmail.com
mailto:tyra3l@gmail.com> wrote:

Ferenc Kovacs mailto:tyra3l@gmail.com
January 10, 2015 at 7:44 AM
Hi,

I’ve asked this at the last irc meeting, but it wasn’t on the agenda
so I was asked to discuss it at a later time.
I was told that the webui2 repo is kept private mainly because it is a
proprietary product. When asked how would turning the repo would make
any difference when we already share the code publically as part of
the opscode-manage plugin/package I was told that there are some
javascript files which are only available in minified form in the package.
Given how easy is to reformat js code if no other obfuscated method is
used, I think that keeping the repo private doesn’t really help with
anything, but makes it harder to report bugs (as AFAIK the prefered
method is to use github issues for reporting the bug to the
appropriate repository) or to send pull request.
I would like to know if there are other reasons for keeping the repo
private or if there is any chance or plans for turning it into public.

Thanks!


Ferenc Kovács
@Tyr43l - http://tyrael.hu