9:59 a.m.
Hi,
I thought it is time to kick off a first discussion.
I'd like to pick up on the idea of an additional add-on git repo under the Minishift
umbrella.
The idea is to create a new repo, let's call it minishift/add-ons, where we collect
non core add-ons.
Several people have started creating add-ons, but atm there is no central place to share
them.
We could add them to minishift/minishift, but this puts us in charge of maintaining them
and
ensuring that they work, etc.
The minishift/add-ons repo is supposed to resolve this. The idea is that we just offer a
central place
for collecting these add-ons. To a great extend we would then rely on the community to
point out and fix issues.
Examples of add-ons which could be moved there are the Fabric8 add-on [1] or the
launch.openshift.io add-on [2]. There
is also a whole bunch of add-ons Jorge is creating as we converts his shell script
wrappers to add-ons.
Ideally I would like to create such a repository as part of this sprint, latest the next.
Thoughts?
[1] https://github.com/minishift/minishift/pull/1043
[2] https://github.com/minishift/minishift/pull/998
11:53 p.m.
On 25 Jul 2017 8:30 p.m., "Hardy Ferentschik" <hardy(a)ferentschik.de>
wrote:
Sure. Many more I believe.
> [1] https://github.com/minishift/minishift/pull/1043
> [2] https://github.com/minishift/minishift/pull/998
>
_______________________________________________
> Minishift Mailing List mailing list -- minishift(a)lists.minishift.io
> To unsubscribe send an email to minishift-leave(a)lists.minishift.io
Hi,
I thought it is time to kick off a first discussion.
I'd like to pick up on the idea of an additional add-on git repo under
the
Minishift umbrella.
The idea is to create a new repo, let's call it
minishift/add-ons, where
we collect non core add-ons.
+1 Sooner or later we need this.
Several people have started creating add-ons, but atm there is no central
place to
share them.
We could add them to minishift/minishift, but this puts us in charge
of
maintaining them and
ensuring that they work, etc.
Because of such reasons.
The minishift/add-ons repo is supposed to resolve this. The idea is
that
we just offer a central place
for collecting these add-ons. To a great extend we would then rely on
the
community to point out and fix issues.
Examples of add-ons which could be moved there are the Fabric8 add-on [1]
or the
launch.openshift.io add-on [2]. There
is also a whole bunch of add-ons Jorge is creating as we converts his
shell script wrappers to add-ons.
Ideally I would like to create such a repository as part of this
sprint,
latest the next.
Might be discussion, planning this sprint and execution on next sprint
would be good. Not in a rush IMO.
> Thoughts?
1:43 a.m.
On Tue, Jul 25, 2017 at 8:29 PM, Hardy Ferentschik <hardy(a)ferentschik.de> wrote:
Hi,
I thought it is time to kick off a first discussion.
I'd like to pick up on the idea of an additional add-on git repo under the Minishift
umbrella.
The idea is to create a new repo, let's call it minishift/add-ons, where we collect
non core add-ons.
why we put `-` in between we can just call it minishift/addons, any
specific reason?
Several people have started creating add-ons, but atm there is no central place to share
them.
We could add them to minishift/minishift, but this puts us in charge of maintaining them
and
ensuring that they work, etc.
I agree, and we always rely on addon creator.
The minishift/add-ons repo is supposed to resolve this. The idea is that we just offer a
central place
for collecting these add-ons. To a great extend we would then rely on the community to
point out and fix issues.
+1
Examples of add-ons which could be moved there are the Fabric8 add-on [1] or the
launch.openshift.io add-on [2]. There
is also a whole bunch of add-ons Jorge is creating as we converts his shell script
wrappers to add-ons.
Ideally I would like to create such a repository as part of this sprint, latest the next.
I do agree.
Thoughts?
[1] https://github.com/minishift/minishift/pull/1043
[2] https://github.com/minishift/minishift/pull/998
_______________________________________________
Minishift Mailing List mailing list -- minishift(a)lists.minishift.io
To unsubscribe send an email to minishift-leave(a)lists.minishift.io
--
Praveen Kumar
http://fedoraproject.org/wiki/User:Kumarpraveen
http://fedoraproject.org/
http://kumar-pravin.blogspot.com
5:32 a.m.
Hi,
> I'd like to pick up on the idea of an additional add-on git
repo under the Minishift umbrella.
> The idea is to create a new repo, let's call it minishift/add-ons, where we
collect non core add-ons.
why we put `-` in between we can just call it minishift/addons, any
specific reason?
Because the spelling we use in the docs is 'add-on' with hyphon. In code we use
AddOn or similar.
I feel we should align with that, but can be convinced otherwise. Reads a bit nicer as
well.
As long we we don't start using capitalization in the repo name. So either
'add-ons' or 'addons'.
Under no circumstances addOns or similar.
> Several people have started creating add-ons, but atm there is
no central place to share them.
> We could add them to minishift/minishift, but this puts us in charge of maintaining
them and
> ensuring that they work, etc.
I agree, and we always rely on addon creator.
+1
--Hardy
5:40 a.m.
On Tue, Jul 25, 2017 at 8:29 PM, Hardy Ferentschik <hardy(a)ferentschik.de>
wrote:
Hi,
I thought it is time to kick off a first discussion.
I'd like to pick up on the idea of an additional add-on git repo under the
Minishift umbrella.
The idea is to create a new repo, let's call it minishift/add-ons, where
we collect non core add-ons.
Several people have started creating add-ons, but atm there is no central
place to share them.
We could add them to minishift/minishift, but this puts us in charge of
maintaining them and
ensuring that they work, etc.
The minishift/add-ons repo is supposed to resolve this. The idea is that
we just offer a central place
for collecting these add-ons. To a great extend we would then rely on the
community to point out and fix issues.
Examples of add-ons which could be moved there are the Fabric8 add-on [1]
or the launch.openshift.io add-on [2]. There
is also a whole bunch of add-ons Jorge is creating as we converts his
shell script wrappers to add-ons.
Ideally I would like to create such a repository as part of this sprint,
latest the next.
Thoughts?
+1. It definitely adds value to the community.
-Lala
[1] https://github.com/minishift/minishift/pull/1043
[2] https://github.com/minishift/minishift/pull/998
_______________________________________________
Minishift Mailing List mailing list -- minishift(a)lists.minishift.io
To unsubscribe send an email to minishift-leave(a)lists.minishift.io
2:14 p.m.
Hi,
any more strong feelings regarding 'addons' vs 'add-ons' regarding the
repo name?
Ideally I would like to create the repo prior to the 1.4.0 release announcement in order
to include and advertise it there.
--Hardy
6:44 p.m.
> > The idea is to create a new repo, let's call it
minishift/add-ons,
where we collect non core add-ons.
> we can just call it minishift/addons
Why not minishift/contrib and have a subfolder add-ons
We might allow more kinds of controls in future
--
Gerard Braad | http://gbraad.nl
[ Doing Open Source Matters ]
2:26 a.m.
Hi,
>> we can just call it minishift/addons
Why not minishift/contrib and have a subfolder add-ons
We might allow more kinds of controls in future
I don't quite understand what you are after here. 'contrib' does not really
make much sense to me.
What is this supposed to mean in the context of Minishift. Also, even though I am not
saying there
won't ever be other configurable components we want to externalize, I don't see
this happening
in the near future. If this situation will occur, we can always do a rename and/or
restructure of
the repo. For now, it seems to be a bit of a long shot to me.
--Hardy
3:11 a.m.
On Wed, Aug 2, 2017 at 12:44 AM, Hardy Ferentschik <hardy(a)ferentschik.de>
wrote:
Hi,
any more strong feelings regarding 'addons' vs 'add-ons' regarding the
repo name?
I would suggest we append "minishift" to the repo name because when an user
clones the repo the local directory name would be better if it is
minishift-addons as compared to add-ons or addons. It is not go code so
users do not need to maintain the directory structure of minishift/addons
for the local copy. Though user can still clone it to be minishift-addons
even if we name it addons or add-ons but that would not be default
experience.
Ideally I would like to create the repo prior to the 1.4.0 release
announcement in order to include and advertise it there.
+1.
-Lala
______________________________________________
Minishift Mailing List mailing list -- minishift(a)lists.minishift.io
To unsubscribe send an email to minishift-leave(a)lists.minishift.io
3:20 a.m.
On Wed, Aug 2, 2017 at 4:11 PM, Lalatendu Mohanty <lmohanty(a)redhat.com>
wrote:
On Wed, Aug 2, 2017 at 12:44 AM, Hardy Ferentschik <hardy(a)ferentschik.de>
wrote:
>
> any more strong feelings regarding 'addons' vs 'add-ons' regarding
the
> repo name?
>
I would suggest we append "minishift" to the repo name because when an
user clones the repo the local directory name would be better if it is
minishift-addons as compared to add-ons or addons.
I believe this is up to the user. I have many repository renamed by hand,
to create some order, and if the name is in use already they get an
alternative name (suffixed with -1 IIRC) . For instance, docker/machine is
also a very generic term, or expressjs/express. I think minishift/addons is
clear enough. Although, as I mentioned I'd rather see 'contrib' as it
indicates that people can propose addons and other material which serve or
help with minishift. Pretty much as what is done for many of the ansible
repos we have. Renaming a repository is not something you should think
lightly about (rather don't do).
3:29 a.m.
On Wed, Aug 2, 2017 at 1:50 PM, Gerard Braad <me(a)gbraad.nl> wrote:
On Wed, Aug 2, 2017 at 4:11 PM, Lalatendu Mohanty <lmohanty(a)redhat.com>
wrote:
>
> On Wed, Aug 2, 2017 at 12:44 AM, Hardy Ferentschik <hardy(a)ferentschik.de>
> wrote:
>>
>> any more strong feelings regarding 'addons' vs 'add-ons'
regarding the
>> repo name?
>>
>
> I would suggest we append "minishift" to the repo name because when an
> user clones the repo the local directory name would be better if it is
> minishift-addons as compared to add-ons or addons.
>
I believe this is up to the user. I have many repository renamed by hand,
to create some order, and if the name is in use already they get an
alternative name (suffixed with -1 IIRC) . For instance, docker/machine is
also a very generic term, or expressjs/express. I think minishift/addons is
clear enough.
I disagree because machine is a go project. So contributors need to keep
it in docker/machine but for a non go project I do not think we can apply
the same logic. Also add-ons is a very generic name and it might be
confusing to me if I have lot of directories.
Although, as I mentioned I'd rather see 'contrib' as it indicates that
people can propose addons and other material which serve or help
with
minishift. Pretty much as what is done for many of the ansible repos we
have.
Renaming a repository is not something you should think lightly
about
(rather don't do).
+1.
3:40 a.m.
Hi,
On Wed, Aug 2, 2017 at 4:29 PM, Lalatendu Mohanty <lmohanty(a)redhat.com>
wrote:
add-ons is a very generic name and it might be confusing to me if I have
lot of directories.
git clone http://github.com/minishift/addons.git minishift-addons
or else it is just a mv away...
I think we should focus on the meaning of the word first, and what our
goals are.
regards,
Gerard
--
Gerard Braad | http://gbraad.nl
[ Doing Open Source Matters ]
9:49 a.m.
Hi,
I would suggest we append "minishift" to the repo name
because when an user
clones the repo the local directory name would be better if it is
minishift-addons as compared to add-ons or addons. It is not go code so
users do not need to maintain the directory structure of minishift/addons
for the local copy. Though user can still clone it to be minishift-addons
even if we name it addons or add-ons but that would not be default
experience.
+1, I think this is a good idea. Especially, since it would be consistent with the naming
of the other minishift repos (minishift-centos-iso, minishift-b2d-iso,
minishift-ci-jobs).
I agree with Gerard that it is easy to clone into any directory one wants, but as Lala
is saying, it is not the default experience.
--Hardy
1760
days inactive
1768
days old
12 comments
5 participants
participants (5)
-
Budh Ram -
Gerard Braad -
Hardy Ferentschik -
Lalatendu Mohanty -
Praveen Kumar