Improve silverstripe.org Module and Widgets pages

166 views
Skip to first unread message

vikas srivastava

unread,
Mar 24, 2012, 12:42:25 PM3/24/12
to SilverStripe Core Development
Hi Philipp

I did some research on module download pages of drupal, wordpress,
joomla and i got some good point which we can implement with
silverstripe.org module and widget download page .

FRONT-END IMPROVEMENT (on main search page) :

1- we can add following extra search filters on search page in
addition to existing ones.

(I) Module categories - like e-commerce, developers module, security
etc.

(II) Sort-By - like most installed, most popular, last build, author,
date, latest etc.

(III) Status- like stable projects, under development etc.

2- we can add one small specific area showing few "latest modules".

3- similarly we can add another area showing few "latest updated
modules".

By adding 2 & 3 user can easily get to know that what additional
choice he/she have.

Note: I am assuming that search filters and page layout for module and
widget page will be same.

FRONT-END IMPROVEMENT (on particular module and widget page) :

we can add few new sections on module page in-addition to existing
one.

(I) Ranking : 1 to 5 star ranking system .

(II) Dependencies of module (if any) .

(III) Current no of issues with this particular module or widget, This
will help developers to directly access the current running issues.

(IV) Subversion : currently address to subversion is written as text
on silverstripe.org module download page . making a direct link or
fetching data from GIT will be more user friendly.

(V) Update module : we can add some method to detect users installed
version of module and accordingly can automatically download and
update users module (like in askubuntu site they give link to debian
packages for automatically install)

(VI) Project information section : This area may contain following
information about module or widget .
(a) Maintenance status : like highly, active .
(b) Development status :
(c) No of Reported Installs : this may use for searching
(d) Last modified : date/time

BACK END IMPROVEMENT :

i am assuming following about existing system.(please correct me
if i am wrong)

(1) All data related to module and widget is coming from GITHUB
server.
(2) Data is not stored internally anywhere on silverstripe.org.
(3) Currently silverstripe.org using "sphinx" as his search server.
(4) logged in users can access "submit your module" link.
(5) after filling module submission and reviewers confirmation using
"addons" module an new entry appears in silverstripe.org/module .

My Suggestion for improving back end .

(1) my past experience with drupal development says that using Apache
Solr can be more better than Sphinx. as silverstripe already have
apache solr module then implementing it with silverstripe is not big
task. (also drupal using this for his huge module repository and for
every search related thing in their site )

(2) we can try to improve synchronisation with github server to
silverstripe server. (i am not sure what kind of method you guys are
using now)

That is all in my mind now so please send me your suggestions and also
please try to remove my confusion about existing system . (finally so
sorry for this HUGE mail !!!) .

S.P. Mohanty

unread,
Mar 24, 2012, 12:54:59 PM3/24/12
to silverst...@googlegroups.com
Hi all,
for those of you who are intrested in the module pages project, this would be a very comprehensive starting point, a very detailed discussion on how it has to be in Drupal, but we can very much relate to the situation.

--Mohanty
http://web.iiit.ac.in/~sharada.mohanty


P.S. : btw Drupal has a very cool Module installation, page. wildkatana worked on some improvements last year, and he did a fab job. This is a link to his projects page, you guys can get inspired :) !! http://groups.drupal.org/node/145159



--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.




--
spM
web.iiit.ac.in/~sharada.mohanty

S.P. Mohanty

unread,
Mar 24, 2012, 12:56:49 PM3/24/12
to silverst...@googlegroups.com
Aww sorry, I guess, I forgot to add the main link I intended to send out to ya guys in the last link.
So spare the double mail,


Hi all,
for those of you who are intrested in the module pages project,
http://drupal.org/node/538904

 this would be a very comprehensive starting point, a very detailed discussion on how it has to be in Drupal, but we can very much relate to the situation.

--Mohanty
http://web.iiit.ac.in/~sharada.mohanty


P.S. : btw Drupal has a very cool Module installation, page. wildkatana worked on some improvements last year, and he did a fab job. This is a link to his projects page, you guys can get inspired :) !! http://groups.drupal.org/node/145159
--
spM
web.iiit.ac.in/~sharada.mohanty

xeraa

unread,
Mar 24, 2012, 2:48:03 PM3/24/12
to silverst...@googlegroups.com
Hi Vikas,

Awesome work - that's the kind of input we're looking for!

As a reminder: Sam said in another thread that the first task of this project will be to decide which module (ss.org's or Nicolaas') should form the basis for this project. While ss.org's code is available I'm not sure if Nicolaas' is. Maybe you could try to get in touch with him and take another look at the underlying basis of your project?

Something that would make the list of improvements even cooler, would be wireframes for that.
So you can have a screenshot of the current system in your application and provide a wireframe on how it should look like in the future. No need to make it fancy, simple wireframes should be perfect for that.

And here are some inline comments:


1- we can add following extra search filters on search page in
addition to existing ones.

(I) Module categories - like e-commerce, developers module, security
etc.

This is based on some sort of tagging you provide? Would there be a set of predefined tags or how would you want to approach this?

(II) Sort-By - like most installed, most popular, last build, author,
date, latest etc.

Sounds good, but I'm not entirely sure if all of that information is easily available (for example most installed).
If a project is hosted on GitHub, you could add the number of forks / people watching.
 
FRONT-END IMPROVEMENT (on particular module and widget page) :

we can add few new sections on module page in-addition to existing
one.

(I) Ranking : 1 to 5 star ranking system .

Users can log in and rank any project once?
 
(III) Current no of issues with this particular module or widget, This
will help developers to directly access the current running issues.

You would take that information from GitHub or where does it come from?
 
(V) Update module : we can add some method to detect users installed
version of module and accordingly can automatically download and
update users module (like in askubuntu site they give link to debian
packages for automatically install)

I'm not sure how this would work out from a technical point of view, but I'm open for suggestions.
 
(VI) Project information section : This area may contain following
information about module or widget .
            (a) Maintenance status : like highly, active .

What's the metric for that? I assume that would be somewhat similar to the status on Google code?
 
BACK END IMPROVEMENT :

     i am assuming following about existing system.(please correct me
if i am wrong)

(1) All data related to module and widget is coming from GITHUB
server.
(2) Data is not stored internally anywhere on silverstripe.org.

If you want to provide a search, you'll need to store some data - I don't assume you'd want to do a web service call for each module on each query ;-).
 
(1) my past experience with drupal development says that using Apache
Solr can be more better than Sphinx. as silverstripe already have
apache solr module then implementing it with silverstripe is not big
task. (also drupal using this for his huge module repository and for
every search related thing in their site )

If there are major advantages to be gained, we can probably talk about that. However, someone at ss.org will need to set that up for you, so I can't give you a definitive answer for that.


Cheers,
Philipp

vikas srivastava

unread,
Mar 25, 2012, 1:47:58 AM3/25/12
to SilverStripe Core Development

Hi S.P. Mohanty
I was looking on links provided by you, but if i am not wrong
those drupal projects are trying to improve module page on installed
drupal Admin section . but here our task is to improve module download
page on silverstripe.org. tell me if i am wrong ?

Ingo Schommer

unread,
Mar 25, 2012, 7:10:32 AM3/25/12
to silverst...@googlegroups.com
I've added some comments on how I see this idea progressing
Vikas, please make sure to read Andrew's project idea on the module base system to ensure we're all on the same page.

vikas srivastava

unread,
Mar 25, 2012, 10:32:52 AM3/25/12
to SilverStripe Core Development
Hi Philipp
Thanks for your feedback . Here are my opinions ...

(1) As i posted on sam's post that improving existing stable system
will be better option than adopting new one. until we are pretty sure
that new system is far better thank existing one but I can only
suggest last decision will be yours .

(2) I already started working on wire frame . I will send you that
very soon .

(3) [ (I) Module categories - like e-commerce, developers module,
security
> etc. ---This is based on some sort of tagging you provide? Would there be a set of
>predefined tags or how would you want to approach this? ] -

I had one plan and I got something similar on the Andrew's Post
(http://groups.google.com/group/silverstripe-dev/browse_thread/thread/
8f9202a7f6a877b/8b66c5eba5b42502?lnk=gst&q=Andrew#8b66c5eba5b42502) .
I was thinking about some kind of info file in root of module
directory. which can store some short of meta tag about module like SS
version required, dependencies, package or group of module it belongs
(it will help us making categories) . Andrew suggesting similar with
composer/packagist in json file format or we can try to do this with
something new approach. implementing it with existing modules can be
painful task. but i am considering it as part of whole idea.

(4) [(II) Sort-By - like most installed, most popular, last build,
author,
> date, latest etc.----
>Sounds good, but I'm not entirely sure if all of that information is easily
>available (for example most installed).
>If a project is hosted on GitHub, you could add the number of forks /
>people watching. ]

we can get no of install by counting no of clicks on download-link of
module , we can relate popularity to the ranking of module and no of
installation .I think we can get the information about the last build
from GitHub.

(5)[>(I) Ranking : 1 to 5 star ranking system .
>Users can log in and rank any project once? ]

we need to think about it because allowing anonymous user to rank may
go into wrong direction. But allowing users to rank projects multiple
times will be better idea.

(6) > (III) Current no of issues with this particular module or
widget, This
> will help developers to directly access the current running issues.
>You would take that information from GitHub or where does it come from?
>On Mar 25, 4:10 pm, Ingo Schommer <ingo.schom...@gmail.com> wrote:

as you suggested in later point that web service call for each module
on each query is not good idea so storing some data about modules on
SS server will be right approach and then creating some
Synchronisation method with actual data stored on GitHub will work
nice . But also we do need to create a method so data on SS server can
update automatically when changes occurs on data stored on GitHub .

(7) >[ (V) Update module : we can add some method to detect users
installed
> version of module and accordingly can automatically download and
> update users module (like in askubuntu site they give link to debian
> packages for automatically install)
>I'm not sure how this would work out from a technical point of view, but
>I'm open for suggestions.]

I do need some deep research on this point but I am pretty sure that
it is possible !

(8) [> (VI) Project information section : This area may contain
following
> information about module or widget .
>(a) Maintenance status : like highly, active .
>What's the metric for that? I assume that would be somewhat similar to the
>status on Google code? ]

we can achieve this on the basis of no of commits , changes in past
few days,months on GitHub .

(9) As i said storing some data on SS server will be good. only then
we can make better indexing in Sphinx or Solr .

(10) > (1) my past experience with drupal development says that using
Apache
> Solr can be more better than Sphinx. as silverstripe already have
> apache solr module then implementing it with silverstripe is not big
> task. (also drupal using this for his huge module repository and for
> every search related thing in their site )

>If there are major advantages to be gained, we can probably talk about
>that. However, someone at ss.org will need to set that up for you, so I
>can't give you a definitive answer for that.

Actually I did some research on Sphinx v/s Solr and there is not
much difference in terms of performance so now I think we should drop
this idea because it needs lots of work and major changes in existing
system. I don't think you guys are ready to change something else
which is not much related to this project idea.

That all in my mind , as registration process starting from
tomorrow I need to do some concrete job about this idea. so please
send me your feedback as soon as possible .

Thanks


On Mar 25, 4:10 pm, Ingo Schommer <ingo.schom...@gmail.com> wrote:
> I've added some comments on how I see this idea progressing
> to a similar
> thread:https://groups.google.com/d/msg/silverstripe-dev/IbNAQyeg5gc/1r0AwuRL...

xeraa

unread,
Mar 25, 2012, 6:44:25 PM3/25/12
to silverst...@googlegroups.com
Hi Vikas,
 
(1) As i posted on sam's post that improving existing stable system
will be better option than adopting new one. until we are pretty sure
that new system is far better thank existing one but I can only
suggest last decision will be yours .

While this is a good point, I think you should go though the pros and cons of each approach as this is probably the most fundamental decision for this project.

(3) [ (I) Module categories - like e-commerce, developers module,
security
> etc. ---This is based on some sort of tagging you provide? Would there be a set of
>predefined tags or how would you want to approach this? ] -

       I had one plan and I got something similar on the Andrew's Post
(http://groups.google.com/​group/silverstripe-dev/browse_​thread/thread/
8f9202a7f6a877b/​8b66c5eba5b42502?lnk=gst&q=​Andrew#8b66c5eba5b42502
) .
I was thinking about some kind of info file in root of module
directory. which can store some short of meta tag about module like SS
version required, dependencies, package or group of module it belongs
(it will help us making categories) . Andrew suggesting similar with
composer/packagist in json file format or we can try to do this with
something new approach. implementing it with existing modules can be
painful task. but i am considering it as part of whole idea.

Sounds good. Any ideas how we could avoid synonyms or different ways of writing, like ecommerce, e-commerce, shop,...? Do we keep a list of suggested tasks as a best practice and low effort approach or should there be something more sophisticated?
 
(4)  [(II) Sort-By - like most installed, most popular, last build,
author,
> date, latest etc.----
>Sounds good, but I'm not entirely sure if all of that information is easily
>available (for example most installed).
>If a project is hosted on GitHub, you could add the number of forks /
>people watching. ]

 we can get no of install by counting no of clicks on download-link of
module , we can relate popularity to the ranking of module and no of
installation .I think we can get the information about the last build
from GitHub.

Do we have the number of clicks somewhere (easily accessible from your module)? I honestly don't know by heart how this is handled.
 
(5)[>(I) Ranking : 1 to 5 star ranking system .
>Users can log in and rank any project once? ]

 we need to think about it because allowing anonymous user to rank may
go into wrong direction. But allowing users to rank projects multiple
times will be better idea.

IMHO everyone should only be able to vote once, otherwise you could totally break the system (10 votes for a module overall, 5 extremely good ones from one person). However, people could probably change their rating later on.
 
(6) > (III) Current no of issues with this particular module or
widget, This
> will help developers to directly access the current running issues.
>You would take that information from GitHub or where does it come from?
>On Mar 25, 4:10 pm, Ingo Schommer <ingo.schom...@gmail.com> wrote:

as you suggested in later point that web service call for each module
on each query is not good idea so storing some data about modules on
SS server will be right approach and then creating some
Synchronisation method with actual data stored on GitHub will work
nice . But also we do need to create a method so data on SS server can
update automatically when changes occurs on data stored on GitHub .

Yeah - you'll probably want to fetch the latest data from GitHub each night to keep it up to date. We might want to discuss the interval with the sys admin, but that's something we can do once the project has started.

(7) >[ (V) Update module : we can add some method to detect users
installed
> version of module and accordingly can automatically download and
> update users module (like in askubuntu site they give link to debian
> packages for automatically install)
>I'm not sure how this would work out from a technical point of view, but
>I'm open for suggestions.]

 I do need some deep research on this point but I am pretty sure that
it is possible !

Ok, sounds interesting.
I just don't think you can influence other tabs (assuming you're logged into the CMS while browsing the module page) and if you're logged into the CMS of two different sites, this might get interesting.
 
(8) [> (VI) Project information section : This area may contain
following
> information about module or widget .
>(a) Maintenance status : like highly, active .
>What's the metric for that? I assume that would be somewhat similar to the
>status on Google code? ]

we can achieve this on the basis of no of commits , changes in past
few days,months on GitHub .

Sounds reasonable, good.
 
(9) As i said storing some data on SS server will be good. only then
we can make better indexing in Sphinx or Solr .

(10) > (1) my past experience with drupal development says that using
Apache
> Solr can be more better than Sphinx. as silverstripe already have
> apache solr module then implementing it with silverstripe is not big
> task. (also drupal using this for his huge module repository and for
> every search related thing in their site )

>If there are major advantages to be gained, we can probably talk about
>that. However, someone at ss.org will need to set that up for you, so I
>can't give you a definitive answer for that.

  Actually I did some research on Sphinx v/s Solr and there is not
much difference in terms of performance so now I think we should drop
this idea because it needs lots of work and major changes in existing
system. I don't think you guys are ready to change something else
which is not much related to this project idea.

Hope I've been able to clear up some issues and you can start writing your application.
(I must admit, I've started my GSoC application only four days before the final deadline, so you have still plenty of time ;-) ).

Cheers,
Philipp

vikas srivastava

unread,
Mar 26, 2012, 11:24:16 AM3/26/12
to silverst...@googlegroups.com
Hello Philipp

Thank you so much for your suggestions . Here are some inline answers ..

 
 >Sounds good. Any ideas how we could avoid synonyms or different ways of writing, like ecommerce, e-commerce, shop,...? >Do we keep a list of suggested tasks as a best practice and low effort approach or should there be something more >sophisticated?

I am not much sure about right approach but we could have some predefined tags .

 >Do we have the number of clicks somewhere (easily accessible from your module)? I honestly don't know by heart how this >is handled.

we can add something like download counter .


>IMHO everyone should only be able to vote once, otherwise you could totally break the system (10 votes for a module >overall, 5 extremely good ones from one person). However, people could probably change their rating later on.

That will be also right approach to implement this idea .


(1) I am attaching wire-frames with mail . So please have a look and send me your feedback .

(2) There are many confusions floating around regarding this idea like
 what will be the base module for this project?
 Are we ready to use composer/packagist or not?

can we have some concrete answers for these topics so we can start some research on that .

Thanks

 



Cheers,
Philipp

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/156Nzz7S6nIJ.

To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.



--
Warm Regards
Vikas Srivastava  :)

sswire.pdf

xeraa

unread,
Mar 26, 2012, 6:45:59 PM3/26/12
to silverst...@googlegroups.com
Hi Vikas,
 
 >Sounds good. Any ideas how we could avoid synonyms or different ways of writing, like ecommerce, e-commerce, shop,...? >Do we keep a list of suggested tasks as a best practice and low effort approach or should there be something more >sophisticated?

I am not much sure about right approach but we could have some predefined tags .

I think that's a good approach. Start simple and get stuff done, if it's required we can always add a more approach later on.
 
 >Do we have the number of clicks somewhere (easily accessible from your module)? I honestly don't know by heart how this >is handled.

we can add something like download counter .

I'm not sure how this will work with a rewritten module manager, but this is a relatively minor point. Make an assumption and we'll change it later on, if it's required.
 
>IMHO everyone should only be able to vote once, otherwise you could totally break the system (10 votes for a module >overall, 5 extremely good ones from one person). However, people could probably change their rating later on.

That will be also right approach to implement this idea .


(1) I am attaching wire-frames with mail . So please have a look and send me your feedback 

Great!
Don't worry about the final design - I think one of ss.org's designers will help or at least need to approve your layout.

Maybe we could plan to add some more features? If you take a look at https://drupal.org/project/apachesolr they support different versions depending of the underlying system (this must be supported by the underlying module manager, but you could document your ideas and we'll then synchronize that with the other module), provide a direct link to documentation (probably a GitBug wiki in our case,...) etc.
Just want to provide some additional ideas - if you think we shouldn't add anything else, that's fine (reasons in your proposal would of course be nice if you don't want to add anything explicitly).
 
(2) There are many confusions floating around regarding this idea like
 what will be the base module for this project?
 Are we ready to use composer/packagist or not?

 IMHO that decision is unfolding at https://groups.google.com/forum/?fromgroups#!topic/silverstripe-dev/CPkgKn9qh3s at the moment. Watch that thread and I hope we'll have a decision shortly.

Cheers,
Philipp

vikas srivastava

unread,
Apr 1, 2012, 1:59:39 AM4/1/12
to silverst...@googlegroups.com
Hi Philipp

Thanks for your suggestions and also Sorry for late reply , from past three days I was busy with my mid-term exams. I am planning to submit my application tomorrow so before that I want you to review my understanding about this project . Because its yet not decided that what exact module we are going to improve and what method we are going to implement for getting information about module , with some assumption I am trying to define some possible task list for this GSOC Idea . So have a look and tell me where I should improve.  

(1) Its sure that we will store data like dependencies, meta tags, version compatibility of modules/widget in some file. file may be .json file,  .info file (drupal guys using such method) or may be we can use any specific file of module for storing those data about module ( like wordpress using style.css for storing data about themes) .

(2) Now when data stored in one of such files module maintainer will push this file along with other files of module on repository of module (GitHub or Packagist).

(3) Module developers will provide URL of his module repository. system will fetch all data from that repository and then mark it as sandbox project. After confirmation from system Admin (someone who is responsible for approval of new modules) system will create a download page for that module and synchronise with that URL, System will also extract info file of module (system know that which file required for getting information about module), after getting information from info file we can sort, arrange that module in ss.org server.

(4) We can use different URL for subversion or we can implement any method so module/system will look for any specific branch on git for that subversion.

(5) Now when module will update on git repository it should automatically update on ss.org server. We can implement this by GitHub service hooks, so when any changes will occur on repository it will call to our module/system for synchronisation with new data. other option could be to set some cron for looking changes on every module repository and accordingly we can update module data on ss.org server.

(6) System should have ability to create packages of module on ss.org server. it should also have ability to change info file according to changes in module, like new version number etc.

(7) For getting information about number of issues system should have ability to sync with ss.org bug tracking system.


Based on above requirements following task need to be done .

(1) Define structure of info file

(2) Implement method so system can automatically fetch data from url of repository. 

(3) Implement method so system can talk to info file.

(4) According to data available in info file create structure of search page. Because many search fields will depend on data provided by info file like dependencies, SS version compatibility.

(5) Create structure of module download page.

(6) Implement method so system can automatically create download pages of module .

(7) Implement method so system can handle data of different branches of same module (for subversion).

(8) Define cron jobs for automatic updates and implement it with system (for automatic updates).

(9) Improve system's module packaging ability .
  
(10) Sync system with ss.org bug tracking system .

(11) Arrange existing module database according to new system .

(12) We may need to re-index the sphinx search server according to new data uploaded on ss.org server .

So please review this and send me feedback asap  and Thanks for your time .


Cheers,
Philipp

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/q_8Xqzo3_4wJ.

To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

xeraa

unread,
Apr 1, 2012, 7:59:10 PM4/1/12
to silverst...@googlegroups.com
Hi Vikas,
 
(1) Its sure that we will store data like dependencies, meta tags, version compatibility of modules/widget in some file. file may be .json file,  .info file (drupal guys using such method) or may be we can use any specific file of module for storing those data about module ( like wordpress using style.css for storing data about themes) .

IMHO it will be a JSON file, but that's probably more specific than it needs to be. Simply assume that there will be some (semi) structured text file containing the relevant information.
 
(2) Now when data stored in one of such files module maintainer will push this file along with other files of module on repository of module (GitHub or Packagist).

Yeah - Git / SVN repo or Packagist.
 
(3) Module developers will provide URL of his module repository. system will fetch all data from that repository and then mark it as sandbox project. After confirmation from system Admin (someone who is responsible for approval of new modules) system will create a download page for that module and synchronise with that URL, System will also extract info file of module (system know that which file required for getting information about module), after getting information from info file we can sort, arrange that module in ss.org server.

Right.
 
(4) We can use different URL for subversion or we can implement any method so module/system will look for any specific branch on git for that subversion.

I'd imagine something like trunk / master for general code and branches like 2.3, 2.4, 3.0,... for specific versions (much like SS's core setup). But this is only an initial idea and definitely up for debate.
 
(5) Now when module will update on git repository it should automatically update on ss.org server. We can implement this by GitHub service hooks, so when any changes will occur on repository it will call to our module/system for synchronisation with new data. other option could be to set some cron for looking changes on every module repository and accordingly we can update module data on ss.org server.

All authors would have to set up the post-commit-hook (and this will only work on GitHub), so I'd rather go with a pull approach. This would most likely be triggered by a cron job.
 
(6) System should have ability to create packages of module on ss.org server. it should also have ability to change info file according to changes in module, like new version number etc.

GitHub provides packages (I assume you mean compressed folders of the code), so we'd only need to take care of non-GitHub repos.
I don't quite get what you mean with "it should also have ability to change info file according to changes in module, like new version number etc."? I'd assume the module's author will do that and we're only reading that information. You don't have commit rights to the repo anyway.

(7) For getting information about number of issues system should have ability to sync with ss.org bug tracking system.

As Sam has written in another thread, SS's own modules will start using GitHub issues in the future. So I think we should get the data from there. Especially since third party party modules are generally not using SS's Trac.

Based on above requirements following task need to be done .

(1) Define structure of info file

IMHO that's primarily the job of the other project, but you'll have to cooperate on that.
 
(2) Implement method so system can automatically fetch data from url of repository. 

Yes, but the current code can already do (at least part of) that.
 
(3) Implement method so system can talk to info file.

IMHO you'll only need to read it (you can't commit to it anyway).
 
(4) According to data available in info file create structure of search page. Because many search fields will depend on data provided by info file like dependencies, SS version compatibility.

Right.
 
(5) Create structure of module download page.

Right.
 
(6) Implement method so system can automatically create download pages of module .

Do you mean the detailed view of the module?
 
(7) Implement method so system can handle data of different branches of same module (for subversion).

IMHO both Git and SVN.
 
(8) Define cron jobs for automatic updates and implement it with system (for automatic updates).

Right.
 
(9) Improve system's module packaging ability .

Or redirect to the GitHub package.
 
(10) Sync system with ss.org bug tracking system .

See point above on that.

(11) Arrange existing module database according to new system .

Right.
 
(12) We may need to re-index the sphinx search server according to new data uploaded on ss.org server .

Absolutely.

This sounds very promising so far.
Can you try to make some (rough) schedule - keeping the mid-term evaluation in mind? Thanks!
Any other questions?

Cheers,
Philipp 

vikas srivastava

unread,
Apr 2, 2012, 12:49:49 AM4/2/12
to silverst...@googlegroups.com
Thanks philipp for your suggestion. now everything is clear. I will try my best to schedule these task.

 
>(6) Implement method so system can automatically create download pages of module .
>Do you mean the detailed view of the module?
yes , that what I want to implement . so system can automatically create our predefined structure of module download page with all available information about module.

Thanks again !!!

 


Cheers,
Philipp 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/uIAXZ773DVwJ.

To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

Ingo Schommer

unread,
Apr 15, 2012, 5:47:08 AM4/15/12
to silverst...@googlegroups.com
Hello Vikas,

There is one central aspect of the project that will still need to be decided:
Should it be a separate website, or integrated as a module into the
existing silverstripe.org codebase? This decision will have an impact on your project scope. 
I've started a separate thread on that, because its a decision beyond GSOC, really:

You didn't note anything about automated testing in your proposal.
This is a mission-critical piece of code for the whole community,
and I expect it to have a good test coverage to be written alongside
the project (not at the end). You can get started on that with 
In terms of preparing yourself for the development phase,
I would suggest that you try to contribute tests to an existing module
of your choosing (most of them have lots of untested code),
submit a pull request to that module, and demonstrate your ability here 
by linking to that pull request.

Ranking: To combat spam, I think only logged-in members should be able to rank.
Their ranking would be correlated to their account to avoid double submissions.

Comments: I would suggest we use Disqus, rather than build our own commenting system,
or use the comments module. Allows for easier moderation, and is in line with our other
commenting solutions (on api.silverstripe.org and doc.silverstripe.org). 
On the other hand, makes it a bit harder to identify "most discussed modules" etc.

Sync with Bugtrackers issue counts: I think that should be out of scope, simply because
there's so much else to do (particularly given my notes on automated testing above).

All the best
Ingo

vikas srivastava

unread,
Apr 16, 2012, 3:46:08 AM4/16/12
to silverst...@googlegroups.com
Hello Ingo 
Thanks for your feedback. I have some experience of manual testing but I never did anything like automated testing so it will take some extra time to learn. which is not possible before 20th april, but there is no problem to include automated testing during project implementation. I already reserved some time for testing in my proposal so that time could be use for automated testing .

>Ranking: To combat spam, I think only logged-in members should be able to rank.
>Their ranking would be correlated to their account to avoid double submissions.

exactly that's what i planned for .

>Comments: I would suggest we use Disqus, rather than build our own commenting system,
>or use the comments module. Allows for easier moderation, and is in line with our other
>commenting solutions (on api.silverstripe.org and doc.silverstripe.org). 
>On the other hand, makes it a bit harder to identify "most discussed modules" etc.

 I need to research more about this.

 >Sync with Bugtrackers issue counts: I think that should be out of scope, simply because
>there's so much else to do (particularly given my notes on automated testing above)

Yes you are right because automated testing will consume lots of time .

warm regards 
vikas srivastava   


--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/EYY7PaZQlNwJ.

To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

Ingo Schommer

unread,
Apr 16, 2012, 4:25:12 AM4/16/12
to silverst...@googlegroups.com
Just for reference, Vikas' proposal is available at 

https://docs.google.com/openid=0B8utgor20eMdaHdreGtnY3VRVi1MNmkxWjhuT1hBZw

vikas srivastava

unread,
Apr 16, 2012, 4:47:12 AM4/16/12
to silverst...@googlegroups.com
Sorry ingo , its my bad correct link to my proposal is 

On Mon, Apr 16, 2012 at 1:55 PM, Ingo Schommer <ingo.s...@gmail.com> wrote:
Just for reference, Vikas' proposal is available at 

https://docs.google.com/openid=0B8utgor20eMdaHdreGtnY3VRVi1MNmkxWjhuT1hBZw

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/T0Y4rsdcWeUJ.

To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

vikas srivastava

unread,
May 9, 2012, 10:26:12 AM5/9/12
to silverst...@googlegroups.com
Hello friends
         Sorry for being quiet for long time. I have already filled project page on GitHub wiki (https://github.com/silverstripe/gsoc-wiki/wiki/GSOC-2012-Project:-Improve-silverstripe.org-Modules-and-Widgets-page), so please have a look on that. Me and UncleCheese had some discussion regarding this project on Monday and we discussed few things to achieve this project. We want community opinion and clearance on few things.

1- Instead of improving "Addons" module create a new module for replacing existing one .

2- In first phase of project implement it on SS2 and in second phase upgrade it for SS3 .

3- How we will get code of ss.org for porting our module. As Ingo suggested in other thread (https://groups.google.com/forum/#!topic/silverstripe-dev/okskE6R4ZQI/discussion) to move module page on separate website, UncleCheese is also in favor of this idea .

4- This project is highly depends on outcome of "Module System Refactoring" project (https://github.com/silverstripe/gsoc-wiki/wiki/GSOC-2012-Project:-Module-System-Refactoring). So we need to define schedule and task of each of project such that they don't impact with each other.  

Nicolaas Thiemen Francken - Sunny Side Up

unread,
May 9, 2012, 5:54:55 PM5/9/12
to silverst...@googlegroups.com
Let me know if you need some help / input from me.

Nicolaas

Ingo Schommer

unread,
May 9, 2012, 6:10:01 PM5/9/12
to silverst...@googlegroups.com
Hey Vikas,

What's the motivation with starting on SS2, then upgrading to SS3 later?
Sounds like unnecessary work to me. SS3 is in beta, and we're using
it for early stage client projects ourselves, so have an interest in keeping it stable.
Your project is scheduled for go live in August, so I don't think the beta state should of concern.

Ingo

Richard Rudy

unread,
May 9, 2012, 6:36:10 PM5/9/12
to silverst...@googlegroups.com
If an August launch is a concern for beta I may start upgrading a site I've been working on that has been put on hold for a rebrand.

Sent from my iPhone
> --
> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

xeraa

unread,
May 9, 2012, 9:50:12 PM5/9/12
to silverst...@googlegroups.com
Hi Vikas,
 
3- How we will get code of ss.org for porting our module. As Ingo suggested in other thread (https://groups.google.com/forum/#!topic/silverstripe-dev/okskE6R4ZQI/discussion) to move module page on separate website, UncleCheese is also in favor of this idea .

I assume the integration of logins between your subdomain (I assume) and the rest of ss.org is included, right? Gave the PDF a quick look, but didn't see it - only Sphinx issues. Apologies if I've overlooked it.

I'd try to break down the schedule a little more. The first phase stretches something like 6 weeks, which is IMHO too much.


Cheers,
Philipp

vikas srivastava

unread,
May 11, 2012, 12:53:32 AM5/11/12
to silverst...@googlegroups.com
Thanks Nicolaas, Ingo, Philipp

 @Nicolaas - I have been looking on your site ssmods.com and I think it could help us for getting some basic idea of implementation because you already done few thing there (like category, tags, extracting README file).

@Ingo - I am agree with you . I think only reason UncleCheese suggested me to Implement it on SS2 because of my poor knowledge of SilverStripe and Tutorials for SS3 are outdated. But this is not big problem because you guys are always available to help me .


@Philipp

>I assume the integration of logins between your subdomain (I assume) and the rest of ss.org is included, right? Gave the >PDF a quick look, but didn't see it - only Sphinx issues. Apologies if I've overlooked it.
 

If decision made to move module pages on separate website then integrating it with ss.org login system would be primary task. During proposal creation I assumed to work directly on ss.org that why it was not included in my proposal.
    Search integration between 2 sites will be a challenging task a I need to research more for this. 
      

--

Nicolaas Thiemen Francken - Sunny Side Up

unread,
May 11, 2012, 1:15:22 AM5/11/12
to silverst...@googlegroups.com
Hi Vikas

Just send me a PM and I can send you my contact details (in case you
would like to have a chat).

nicolaas

Ingo Schommer

unread,
May 11, 2012, 4:44:32 AM5/11/12
to silverst...@googlegroups.com
In terms of search integration, we already have http://silverstripe.org/search,
which is an OpenSearch consumer for api.ss.org, doc.ss.org and ss.org.
Apart from that, OpenSearch is supported by many other clients,
like browsers and IDEs, so seems like a good way forward for
the module listing as well.

The implementation is based on this module: https://github.com/chillu/opensearchclient
You'd need to generate the OpenSearch description and feed
yourself, but that's fairly trivial - see example from the forum:

Ingo

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

vikas srivastava

unread,
May 11, 2012, 10:08:56 AM5/11/12
to silverst...@googlegroups.com
Thanks Ingo I will definitely look into these API . 

vikas srivastava

unread,
May 15, 2012, 2:59:22 AM5/15/12
to silverst...@googlegroups.com
Hello
    Is it clear that we will use separate website for module pages? If yes, then who will setup modules.silverstripe.org website for this project? 

Will Rossiter

unread,
May 15, 2012, 3:03:10 AM5/15/12
to silverst...@googlegroups.com
Trivial point but I'd like the separate site at something like extensions.silverstripe.org since I see themes and widgets (while perhaps out of scope for this GSOC) also moving to community managed resources IMHO.

vikas srivastava

unread,
May 15, 2012, 3:21:48 AM5/15/12
to silverst...@googlegroups.com
Thanks Will
    according to requirement of this project (https://github.com/silverstripe/gsoc-wiki/wiki/Project-Idea:-Improve-ss.org-modules) I am assuming that widget pages are also included in project scope. I think that is the problem behind separating extensions, module, widget pages on separate website because it needs maintenance overhead of 3 almost same type of website. alternatively we can use something like downloads.silverstripe.org/modules ,
downloads.silverstripe.org/extensions,
downloads.silverstripe.org/themes. But someone in community need to decide this very soon.        

vikas srivastava

unread,
May 15, 2012, 4:32:20 AM5/15/12
to silverst...@googlegroups.com
sorry my bad ! didn't noticed that module, widgets and themes all fall in extensions category . so our separate website should have domain like extensions.silverstripe.org/modules , extensions.silverstripe.org/widget , extensions.silverstripe.org/themes .
Reply all
Reply to author
Forward
0 new messages