From: Tiwei Bie <tiwei.bie@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, bruce.richardson@intel.com,
yuanhan.liu@linux.intel.com, konstantin.ananyev@intel.com,
stephen@networkplumber.org
Subject: Re: [dpdk-dev] [RFC] proposal of allowing personal/project repos on DPDK.org
Date: Sat, 3 Jun 2017 10:19:36 +0800 [thread overview]
Message-ID: <20170603021936.GA12050@debian-ZGViaWFuCg> (raw)
In-Reply-To: <136058706.0Fjdze3SFe@xps>
On Fri, Jun 02, 2017 at 05:29:48PM +0200, Thomas Monjalon wrote:
> 01/06/2017 07:07, Tiwei Bie:
> > Hello everyone,
> >
> > We'd like to make a proposal of making DPDK.org allow hosting
> > some personal/project repos, which could be very useful when
> > someone wants to try some experimental projects in DPDK. Many
> > formal/mature opensource communities allow this. Such as:
> [...]
>
> So you are asking for a forge.
> It requires some maintenance effort.
>
> > But currently on DPDK.org, for the repos of DPDK, besides the main
> > repo, there are just one repo for stable release, few old repos
> > which are obsoleted, and some "-next" repos which are mainly used
> > as the preparation of pull requests for different subsystems of DPDK.
>
> Yes they are the official DPDK repos.
>
> > Some “-next” repos may be developed individually for a short time
> > when they are created, but will always be merged to the main repo
> > after few releases. We think they are too formal/limited to try
> > new ideas.
>
> Why? Do you need to host a repo on dpdk.org to try a new idea?
>
Yeah. We have some new ideas to try in DPDK, and we are longing to
host some repos on dpdk.org to show them to the community. Such as
some virtio 1.1 prototyping. DPDK is one of the best places to practice
those new ideas. We want to show it in a formal way to promote the
development of virtio in DPDK. Currently, it's done in a temporary
branch of Yuanhan's next-virtio tree:
http://dpdk.org/browse/next/dpdk-next-virtio/commit/?h=for-testing
It's very inconvenient, and just like what you said, it is an official
DPDK repo, and actually we are misusing it. :-(
> > What we want to proposal is to make DPDK.org allow hosting some
> > DPDK based repos which may be very experimental, which even not
> > be planned to be merged back to the main repo directly, and may
> > be deleted directly if it proves that no one really cares about
> > it. Just like what other opensource communities did, allow some
> > core developers/vendors create their own repos and try ideas on
> > DPDK.org without too many restrictions. We think it can provide
> > people a very convenient way to try ideas in DPDK community and
> > eventually help DPDK grow.
> >
> > Allowing it won't have any negative impact on the existing repos
> > of DPDK, instead, it can help to keep them tidy and clean when
> > someone wants/needs to try some very experimental and big ideas
> > publicly in DPDK as he/she can start it in an experimental repo.
> > An experimental repo can be merged back to the main repo when it
> > proves to be mature and useful, or could just be deleted when no
> > one really cares about it any more.
> >
> > Please share your thoughts on this. Many thanks! :-)
>
> I am against adding some user repos in this list:
> http://dpdk.org/browse/
> I think the list of official repos must be kept light for good visibility.
>
Yeah, I totally agree with you. The list of official repos should
definitely be kept as light as possible.
> But we can imagine a forge for users at a different location like
> http://dpdk.org/users/
> However why not using another public forge for this need?
>
It's definitely OK to show those repos at http://dpdk.org/users/ or
any other similar locations. Technically, we can use any public forge
for this need. But it would seems less connected with DPDK community
and be harder for other people to figure it out quickly. And we really
don't want such things hinder the development of the new ideas.
Anyway, DPDK is not a small community any more. We should learn from
other mature open source communities such as FreeBSD/Linux. If we have
some concerns on the maintenance effort, we should think about how to
fix it, rather than letting it kill this proposal.
Thank you very much for sharing your thoughts! :-)
Best regards,
Tiwei Bie
next prev parent reply other threads:[~2017-06-03 2:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-01 5:07 Tiwei Bie
2017-06-01 9:36 ` Dumitrescu, Cristian
2017-06-02 0:50 ` Yuanhan Liu
2017-06-02 15:29 ` Thomas Monjalon
2017-06-02 18:37 ` Dumitrescu, Cristian
2017-06-02 20:37 ` Stephen Hemminger
2017-06-05 7:47 ` Olivier Matz
2017-06-03 2:19 ` Tiwei Bie [this message]
2017-06-19 13:29 ` Thomas Monjalon
2017-06-20 6:16 ` Tiwei Bie
2017-06-20 7:21 ` Thomas Monjalon
2017-06-20 7:28 ` Tiwei Bie
[not found] <1085704550.1206846.1496479255188.ref@mail.yahoo.com>
2017-06-03 8:40 ` Manoj Mallawaarachchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170603021936.GA12050@debian-ZGViaWFuCg \
--to=tiwei.bie@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@intel.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
--cc=yuanhan.liu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).