spring cleaning
23 views
Skip to first unread message
David Buchmann
Dec 18, 2015, 11:49:22 AM12/18/15
to symfony-...@googlegroups.com
hi,
it seems to me we that for the number of consistent contributors, have
too many bundles and too many places we try to move forward, resulting
in going very slow, and in delivering a bad dev experience with
undocumented or completely broken code.
i propose that we start noting on the bundle github pages when a bundle
is not maintained, and also clearly mark them in the documentation and
in the TOC of the doc.
if we find maintainers for some of them, all the better. but i would
rather focus on the core parts than spread thin over many bundles.
my proposal would be to mark the following as unmaintained:
BlogBundle, MediaBundle, SearchBundle, CreateBundle, SimpleCmsBundle
do i miss something that should be in this list? is somebody not only
convinced we need to keep some of the above active, but also willing to
do that?
regards,david
--
Liip AG // Agile Web Development // T +41 43 500 39 80
CH-8005 Zurich // PGP 0xA581808B // www.liip.ch
it seems to me we that for the number of consistent contributors, have
too many bundles and too many places we try to move forward, resulting
in going very slow, and in delivering a bad dev experience with
undocumented or completely broken code.
i propose that we start noting on the bundle github pages when a bundle
is not maintained, and also clearly mark them in the documentation and
in the TOC of the doc.
if we find maintainers for some of them, all the better. but i would
rather focus on the core parts than spread thin over many bundles.
my proposal would be to mark the following as unmaintained:
BlogBundle, MediaBundle, SearchBundle, CreateBundle, SimpleCmsBundle
do i miss something that should be in this list? is somebody not only
convinced we need to keep some of the above active, but also willing to
do that?
regards,david
--
Liip AG // Agile Web Development // T +41 43 500 39 80
CH-8005 Zurich // PGP 0xA581808B // www.liip.ch
Wouter de Jong
Dec 19, 2015, 6:09:26 AM12/19/15
to Daniel Leech
I agree that we need to rethink about which bundles we work on and which
not (and also if we continue to see CMF as a whole, or as seperate projects,
like FOS does).
Instead of deciding which bundles not to support, I think it's good to assign
one or two main maintainers for each bundle. Some bundles will probably
have no maintainer that is interested, so it'll not be supported as a consequence.
For me, I'm willing to be the main maintainer of TreeBrowserBundle, Testing
and CreateBundle (I did some work on this locally, I do think this is an important
feature)
--
You received this message because you are subscribed to the Google Groups "symfony-cmf-devs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to symfony-cmf-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Lukas Kahwe Smith
Dec 19, 2015, 6:52:24 AM12/19/15
to symfony-...@googlegroups.com
> On 19 Dec 2015, at 12:09, Wouter de Jong <jong.de...@gmail.com> wrote:
>
> I agree that we need to rethink about which bundles we work on and which
> not (and also if we continue to see CMF as a whole, or as seperate projects,
> like FOS does).
>
> Instead of deciding which bundles not to support, I think it's good to assign
> one or two main maintainers for each bundle. Some bundles will probably
> have no maintainer that is interested, so it'll not be supported as a consequence.
>
> For me, I'm willing to be the main maintainer of TreeBrowserBundle, Testing
> and CreateBundle (I did some work on this locally, I do think this is an important
> feature)
regards,
Lukas Kahwe Smith
sm...@pooteeweet.org
David Buchmann
Dec 19, 2015, 9:56:32 AM12/19/15
to symfony-...@googlegroups.com
i like that proposal, wouter.
do we put those maintainers into the readme of the bundles? or only in
the wiki?
On 19.12.2015 12:09, Wouter de Jong wrote:
> I agree that we need to rethink about which bundles we work on and which
> not (and also if we continue to see CMF as a whole, or as seperate projects,
> like FOS does).
>
> Instead of deciding which bundles not to support, I think it's good to
> assign
> one or two main maintainers for each bundle. Some bundles will probably
> have no maintainer that is interested, so it'll not be supported as a
> consequence.
>
> For me, I'm willing to be the main maintainer of TreeBrowserBundle, Testing
> and CreateBundle (I did some work on this locally, I do think this is an
> important
> feature)
>
>
> 2015-12-18 17:49 GMT+01:00 David Buchmann <da...@liip.ch
> <mailto:da...@liip.ch>>:
> CH-8005 Zurich // PGP 0xA581808B // www.liip.ch <http://www.liip.ch>
do we put those maintainers into the readme of the bundles? or only in
the wiki?
On 19.12.2015 12:09, Wouter de Jong wrote:
> I agree that we need to rethink about which bundles we work on and which
> not (and also if we continue to see CMF as a whole, or as seperate projects,
> like FOS does).
>
> Instead of deciding which bundles not to support, I think it's good to
> assign
> one or two main maintainers for each bundle. Some bundles will probably
> have no maintainer that is interested, so it'll not be supported as a
> consequence.
>
> For me, I'm willing to be the main maintainer of TreeBrowserBundle, Testing
> and CreateBundle (I did some work on this locally, I do think this is an
> important
> feature)
>
>
> 2015-12-18 17:49 GMT+01:00 David Buchmann <da...@liip.ch
>
> hi,
>
> it seems to me we that for the number of consistent contributors, have
> too many bundles and too many places we try to move forward, resulting
> in going very slow, and in delivering a bad dev experience with
> undocumented or completely broken code.
>
> i propose that we start noting on the bundle github pages when a bundle
> is not maintained, and also clearly mark them in the documentation and
> in the TOC of the doc.
>
> if we find maintainers for some of them, all the better. but i would
> rather focus on the core parts than spread thin over many bundles.
>
> my proposal would be to mark the following as unmaintained:
>
> BlogBundle, MediaBundle, SearchBundle, CreateBundle, SimpleCmsBundle
>
> do i miss something that should be in this list? is somebody not only
> convinced we need to keep some of the above active, but also willing to
> do that?
>
> regards,david
> --
> Liip AG // Agile Web Development // T +41 43 500 39 80
> <tel:%2B41%2043%20500%2039%2080>
> hi,
>
> it seems to me we that for the number of consistent contributors, have
> too many bundles and too many places we try to move forward, resulting
> in going very slow, and in delivering a bad dev experience with
> undocumented or completely broken code.
>
> i propose that we start noting on the bundle github pages when a bundle
> is not maintained, and also clearly mark them in the documentation and
> in the TOC of the doc.
>
> if we find maintainers for some of them, all the better. but i would
> rather focus on the core parts than spread thin over many bundles.
>
> my proposal would be to mark the following as unmaintained:
>
> BlogBundle, MediaBundle, SearchBundle, CreateBundle, SimpleCmsBundle
>
> do i miss something that should be in this list? is somebody not only
> convinced we need to keep some of the above active, but also willing to
> do that?
>
> regards,david
> --
> Liip AG // Agile Web Development // T +41 43 500 39 80
> CH-8005 Zurich // PGP 0xA581808B // www.liip.ch <http://www.liip.ch>
>
> --
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to symfony-cmf-de...@googlegroups.com
> <mailto:symfony-cmf-devs%2Bunsu...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to symfony-cmf-de...@googlegroups.com
> --
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to symfony-cmf-de...@googlegroups.com
> <mailto:symfony-cmf-de...@googlegroups.com>.
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to symfony-cmf-de...@googlegroups.com
Daniel Leech
Dec 19, 2015, 10:25:39 AM12/19/15
to symfony-...@googlegroups.com
I also agree that we should officially "unmaintain" some of our bundles.
gmx Privat
Dec 20, 2015, 1:32:01 PM12/20/15
to symfony-...@googlegroups.com
An other way instead of reducing the bundles would be to win new maintainers. In know we try to Do it, but re-sort documentation and the way we present the CMF, would bring more people on our side. The CMF still has got the bad Image to be really hard to use, which is wrong.
> To unsubscribe from this group and stop receiving emails from it, send an email to symfony-cmf-de...@googlegroups.com.
Daniel Leech
Dec 20, 2015, 1:50:11 PM12/20/15
to symfony-...@googlegroups.com
Well, imo, some of the bundles are more useful than others.
Going by Davids list:
The MediaBundle has questionable purpose (I could never really
understand it).
The BlogBundle was meant as a "demo" - I had originally wanted to create
a BlogBundle uniquely using the CMF, but the CMF doesn't currently have
all the tools to make an effective blog (f.e. tagging), so its not a
viable product, and in anycase we have the cmf-sandbox.
The SearchBundle could be many things, but it is currently an
integration for Liip Google Search.
I would prefer that people made their own "SimpleCms" rather than use
the bundle, i.e. I think it could be replaced with a nice tutorial.
Wouter has already said he would maintain the Create bundle, but I don't
know much about that one.
..
I would rather that we concentrated on things that have a definite
purpose and usefulness - things that could be adopted by CMS systems.
Going by Davids list:
The MediaBundle has questionable purpose (I could never really
understand it).
The BlogBundle was meant as a "demo" - I had originally wanted to create
a BlogBundle uniquely using the CMF, but the CMF doesn't currently have
all the tools to make an effective blog (f.e. tagging), so its not a
viable product, and in anycase we have the cmf-sandbox.
The SearchBundle could be many things, but it is currently an
integration for Liip Google Search.
I would prefer that people made their own "SimpleCms" rather than use
the bundle, i.e. I think it could be replaced with a nice tutorial.
Wouter has already said he would maintain the Create bundle, but I don't
know much about that one.
..
I would rather that we concentrated on things that have a definite
purpose and usefulness - things that could be adopted by CMS systems.
Ben Glassman
Dec 20, 2015, 2:15:22 PM12/20/15
to symfony-cmf-devs
I would tend to agree that the CMF media, blog and simple cms bundles have been the ones we have not used heavily. SimpleCMS was great as an example when understanding the CMF initially and perhaps would be useful to remain as a demo as was mentioned rather than a maintained bundle. Having both simple cms and blog bundle as essentially examples of how you can solve common CMS related problems using the core CMF tools seems like it may be a good way of clearly communicating the intent of the core components.
I think replacing simple cms with a tutorial is a good idea. We began our CMS by using simple cms and quickly realized that was not the right approach.
It seems there is already a tutorial which covers both simple cms functionality and blog functionality http://symfony.com/doc/current/cmf/tutorial/getting-started.html so I'm wondering what features blog bundle and simple cms provide that are not outlined here.
I have the most familiarity with the seo, menu and routing components if there are specific issues that are in need of addressing.
Reply all
Reply to author
Forward
0 new messages