Hi, Thorsten!
I'm interested in the GSoC Package WebUI project idea.
I am well acquainted with the basic principles and methods of working with repoview and pkgdb. I have a desire to make a site that provides information on all packages and has convenient tools for searching, grouping, resolving dependencies, etc... I consider that the best variant for development of the new application is the use or improvement repoview or pkgdb.
I think that http://packages.ubuntu.com/ and http://www.debian.org/distrib/packages are very convenient and functional tools.
I have a good experience in user interface design and development of web applications: -- scripting languages: perl, python, php and the popular frameworks for them, like Catalyst, Django and ZendFramework -- XML, HTML / XHTML, CSS, semantic and cross-browser making-up -- graphic tools
What is the main criteria for application?
http://fedoraproject.org/wiki/SummerCoding/2008/Ideas
"pk" == pavel khardikov writes:
pk> Hi, Thorsten! I'm interested in the GSoC Package WebUI project pk> idea.
pk> I am well acquainted with the basic principles and methods of pk> working with repoview and pkgdb. I have a desire to make a site pk> that provides information on all packages and has convenient tools pk> for searching, grouping, resolving dependencies, etc... I pk> consider that the best variant for development of the new pk> application is the use or improvement repoview or pkgdb.
pk> I think that http://packages.ubuntu.com/ and pk> http://www.debian.org/distrib/packages are very convenient and pk> functional tools.
pk> I have a good experience in user interface design and development pk> of web applications: -- scripting languages: perl, python, php and pk> the popular frameworks for them, like Catalyst, Django and pk> ZendFramework -- XML, HTML / XHTML, CSS, semantic and pk> cross-browser making-up -- graphic tools
pk> What is the main criteria for application?
pk> http://fedoraproject.org/wiki/SummerCoding/2008/Ideas
It seems that the WebUI overlaps considerably with the "MyFedora" idea which has already been started:
http://fedoraproject.org/wiki/MyFedora
perhaps there should be a link on the GSOC ideas page to MyFedora and vice-versa.
On 23.03.2008 23:14, Alex Lancaster wrote:
"pk" == pavel khardikov writes:
pk> Hi, Thorsten! I'm interested in the GSoC Package WebUI project pk> idea.
Note: I added this old idea (¹) to the pages months ago when Quaid asked something like "we want to make sure we have enough good ideas for the next GSoC, so feel free to add ideas to the wiki page, even if the GSoC is still many months away"
(¹) it was on the FESCo agenda months ago when Fedora Extras still existed, but was forgotten over time
[...] pk> I think that http://packages.ubuntu.com/ and pk> http://www.debian.org/distrib/packages are very convenient and pk> functional tools.
Fully agreed. I use those webpages round about once every two weeks if I need to know what debian or ubuntu do.
[...] pk> What is the main criteria for application?
No idea -- as I said, I just added the idea to the wiki. I have no ideas nor skills how to actually realize the WebUI; thus I don't think I can mentor this idea further *and* I don't have the time or interest for it. Sorry.
pk> http://fedoraproject.org/wiki/SummerCoding/2008/Ideas It seems that the WebUI overlaps considerably with the "MyFedora" idea which has already been started:
Yeah, MyFedora was still young (or even not born yet) when I added the idea to the wiki. I don't know much about MyFedora, but afaics it could need help as well and might be a good GSoC project.
Cu knurd
Thorsten Leemhuis writes:
On 23.03.2008 23:14, Alex Lancaster wrote:
> "pk" == pavel khardikov writes: >
pk> Hi, Thorsten! I'm interested in the GSoC Package WebUI project pk> idea.
Note: I added this old idea (¹) to the pages months ago when Quaid asked something like "we want to make sure we have enough good ideas for the next GSoC, so feel free to add ideas to the wiki page, even if the GSoC is still many months away"
(¹) it was on the FESCo agenda months ago when Fedora Extras still existed, but was forgotten over time
[...] pk> I think that http://packages.ubuntu.com/ and pk> http://www.debian.org/distrib/packages are very convenient and pk> functional tools.
Fully agreed. I use those webpages round about once every two weeks if I need to know what debian or ubuntu do.
[...] pk> What is the main criteria for application?
No idea -- as I said, I just added the idea to the wiki. I have no ideas nor skills how to actually realize the WebUI; thus I don't think I can mentor this idea further *and* I don't have the time or interest for it. Sorry.
pk> http://fedoraproject.org/wiki/SummerCoding/2008/Ideas It seems that the WebUI overlaps considerably with the "MyFedora" idea which has already been started:
Yeah, MyFedora was still young (or even not born yet) when I added the idea to the wiki. I don't know much about MyFedora, but afaics it could need help as well and might be a good GSoC project.
Cu knurd
Hi!
Thanks for your reply. It is a great pity :(
If I understood there is no reason to start doing Package WebUI from the very begining because MyFedora project is aimed at solving the same problems. In what way the idea of Package WebUI can be relate to GSoC?
As far as I can see the idea of WebInstall is similar? Is WebInstall project still relevant to GSoC or MyFedora will cope with its functions?
On 24.03.2008 17:46, Pavel Khardikov wrote:
Thorsten Leemhuis writes:
On 23.03.2008 23:14, Alex Lancaster wrote:
>> "pk" == pavel khardikov writes: >>
[...] pk> http://fedoraproject.org/wiki/SummerCoding/2008/Ideas It seems that the WebUI overlaps considerably with the "MyFedora" idea which has already been started:
Yeah, MyFedora was still young (or even not born yet) when I added the idea to the wiki. I don't know much about MyFedora, but afaics it could need help as well and might be a good GSoC project.
Thanks for your reply. It is a great pity :(
If I understood there is no reason to start doing Package WebUI from the very begining because MyFedora project is aimed at solving the same problems.
I'm can not properly answer this question. J5 (the MyFedora develop) likely can do that better.
From what I can see on
http://fedoraproject.org/wiki/MyFedora it seems to me that developers are the main target audience of MyFedora. Only the second screenshot indicates that MyFedora might provide something like packages.debian.org (which also provides a good service for users)
In what way the idea of Package WebUI can be relate to GSoC?
As far as I can see the idea of WebInstall is similar? Is WebInstall project still relevant to GSoC or MyFedora will cope with its functions?
I'd suggest you contact J5, the developer of MyFedora. Maybe he can help to answer the question if a separate WebUI makes sense (which I doubt).
Cu knurd
Thorsten Leemhuis writes:
On 24.03.2008 17:46, Pavel Khardikov wrote:
Thorsten Leemhuis writes:
On 23.03.2008 23:14, Alex Lancaster wrote:
>>> "pk" == pavel khardikov writes: >>> >>>
[...] pk> http://fedoraproject.org/wiki/SummerCoding/2008/Ideas It seems that the WebUI overlaps considerably with the "MyFedora" idea which has already been started:
Yeah, MyFedora was still young (or even not born yet) when I added the idea to the wiki. I don't know much about MyFedora, but afaics it could need help as well and might be a good GSoC project.
Thanks for your reply. It is a great pity :(
If I understood there is no reason to start doing Package WebUI from the very begining because MyFedora project is aimed at solving the same problems.
I'm can not properly answer this question. J5 (the MyFedora develop) likely can do that better.
From what I can see on
http://fedoraproject.org/wiki/MyFedora it seems to me that developers are the main target audience of MyFedora. Only the second screenshot indicates that MyFedora might provide something like packages.debian.org (which also provides a good service for users)
In what way the idea of Package WebUI can be relate to GSoC?
As far as I can see the idea of WebInstall is similar? Is WebInstall project still relevant to GSoC or MyFedora will cope with its functions?
I'd suggest you contact J5, the developer of MyFedora. Maybe he can help to answer the question if a separate WebUI makes sense (which I doubt).
Cu knurd
Ok.
Thanks for your reply.
Pavel Khardikov wrote:
Thorsten Leemhuis writes:
On 24.03.2008 17:46, Pavel Khardikov wrote:
Thorsten Leemhuis writes:
On 23.03.2008 23:14, Alex Lancaster wrote:
>>>> "pk" == pavel khardikov writes: >>>>
[...] pk> http://fedoraproject.org/wiki/SummerCoding/2008/Ideas It seems that the WebUI overlaps considerably with the "MyFedora" idea which has already been started:
Yeah, MyFedora was still young (or even not born yet) when I added the idea to the wiki. I don't know much about MyFedora, but afaics it could need help as well and might be a good GSoC project.
Thanks for your reply. It is a great pity :(
If I understood there is no reason to start doing Package WebUI from the very begining because MyFedora project is aimed at solving the same problems.
I'm can not properly answer this question. J5 (the MyFedora develop) likely can do that better.
From what I can see on
http://fedoraproject.org/wiki/MyFedora it seems to me that developers are the main target audience of MyFedora. Only the second screenshot indicates that MyFedora might provide something like packages.debian.org (which also provides a good service for users)
In what way the idea of Package WebUI can be relate to GSoC?
As far as I can see the idea of WebInstall is similar? Is WebInstall project still relevant to GSoC or MyFedora will cope with its functions?
I'd suggest you contact J5, the developer of MyFedora. Maybe he can help to answer the question if a separate WebUI makes sense (which I doubt).
Cu knurd
Ok.
Thanks for your reply.
Sorry I didn't this thread earlier, Pavel, how interested in this are you? How self-motivated? I could see doing something like this as a GSoC project but hadn't really thought about it before. We should have a talk between you, J5 (John Palmieri -- myfedora), skvidal (Seth Vidal -- repoview/yum metadata), and I (abadger1999 -- pkgdb) about what would be a useful and good chunk of code for a GSoC project.
I can be found on IRC as abadger1999, in irc.freenode.net #fedora-admin, #fedora-devel. Like I said, I haven't thought about doing this until now so we'd need to get busy on this if you're interested.
-Toshio
Oke, sounds all very interesting but i would like to know a few details.
Lets assume WebUI is the one that is gonna be developed for a moment (otherwise fill in the name you want).
1. Will the WebUI be able to contact the koji package database? 2. What is the preferred language to write this in? php? java? python etc? 3. Is is gonna be a part of fedora (hosted on the fedora place) or is it all just community work that fedora will initialize but than pulls it hands of?
I'm asking those things because i'm interested in this as well and letting WebUI work with Koji's package database seems like a perfect solution to me because all the packages for fedora are in there already so all you have to do then is make it possible in the koji database to fetch distribution specific rpm's (so for F7 only, F8 only, Rawhide only or all and i'm sure (i hope) the current database of koji can already do this (tags)).
And last question. How do you need to make it? Make it with developer visitors in mind (so making it a bit technical won't do much harm) or make it so that Everyone can use it, even the completely new linux user which only knows a few basic computer things?
Also if making it for the last group (which i expect) than it might be handy to make something of a firefox plugin (or something else) as well to just click "install" in the WebUI and than the package gets: Downloaded and Installed. And then i don't mean the normal FF download window and then double clicking on the rpm file.
Just my thoughts about this. Mark.
Mark wrote:
Oke, sounds all very interesting but i would like to know a few details.
Like I say, I hadn't thought about this as a GSoC project before so none of my answers are set in stone:
Lets assume WebUI is the one that is gonna be developed for a moment (otherwise fill in the name you want).
- Will the WebUI be able to contact the koji package database?
I hadn't thought so but we could talk to the koji authors about it. I've heard two thoughts on access to koji's db at different times:
1) koji is one possible front-end to koji db. Other front ends could access it.
2) koji db should only be accessed through koji's xmlrpc calls.
I'm not sure which of these two is the current answer. We'd need to talk to mbonnet and mikem about which they prefer.
- What is the preferred language to write this in? php? java? python etc?
Must be python. I'm very heavily in favor of it being a feature of either the pkgdb or myfedora. I think it makes more sense of it being a part of pkgdb and then myfedora can import it to one of its tabs (as it's currently doing with other pkgdb, koji, bodhi pages).
- Is is gonna be a part of fedora (hosted on the fedora place) or is
it all just community work that fedora will initialize but than pulls it hands of?
Part of Fedora.
I'm asking those things because i'm interested in this as well and letting WebUI work with Koji's package database seems like a perfect solution to me because all the packages for fedora are in there already so all you have to do then is make it possible in the koji database to fetch distribution specific rpm's (so for F7 only, F8 only, Rawhide only or all and i'm sure (i hope) the current database of koji can already do this (tags)).
The other option is to get this information from the yum repodata. This lacks historical information (it's only information in the present repository) but that may be the way to go for several reasons:
* We've had issues with kojidb failing to scale under the load that koji can place on it (we'll be getting a database server dedicated to koji at some point which may alleviate this but that's both speculative and something for the future.)
* repodata will show what's available to yum for downloading which is synced with what an end-user will see.
And last question. How do you need to make it? Make it with developer visitors in mind (so making it a bit technical won't do much harm) or make it so that Everyone can use it, even the completely new linux user which only knows a few basic computer things?
The initial proposal sounds like the latter.
Also if making it for the last group (which i expect) than it might be handy to make something of a firefox plugin (or something else) as well to just click "install" in the WebUI and than the package gets: Downloaded and Installed. And then i don't mean the normal FF download window and then double clicking on the rpm file.
That could be handy but it would need to be talked over with the PackageKit authors rather than me :-)
-Toshio
</snip>
The other option is to get this information from the yum repodata. This lacks historical information (it's only information in the present repository) but that may be the way to go for several reasons:
- We've had issues with kojidb failing to scale under the load that koji
can place on it (we'll be getting a database server dedicated to koji at some point which may alleviate this but that's both speculative and something for the future.)
Than i suggest we wait till this is resolved. Using the repodate, parsing that and kepping that up to date is way harder than using koji's db. Another option might be to have a seperate database with only the needed information that is synced with koji everyday.
- repodata will show what's available to yum for downloading which is
synced with what an end-user will see.
Like said.. doing it this way will make it extra hard while it's not needed (or should not be needed).
And last question. How do you need to make it? Make it with developer visitors in mind (so making it a bit technical won't do much harm) or make it so that Everyone can use it, even the completely new linux user which only knows a few basic computer things?
The initial proposal sounds like the latter.
Also if making it for the last group (which i expect) than it might be handy to make something of a firefox plugin (or something else) as well to just click "install" in the WebUI and than the package gets: Downloaded and Installed. And then i don't mean the normal FF download window and then double clicking on the rpm file.
That could be handy but it would need to be talked over with the PackageKit authors rather than me :-)
What does PackageKit have to do with it? Isn't it just a "yum -y install %package_name%" command that needs to be executed.. i don't see how PackageKit fits in this.
-Toshio
About the language it needs to be written in.. (Python).. byw bye oppertunity for me to make it unless i learn python :) i do know Java and PHP.
Mark
Mark wrote:
</snip> > The other option is to get this information from the yum repodata. This > lacks historical information (it's only information in the present > repository) but that may be the way to go for several reasons: > > * We've had issues with kojidb failing to scale under the load that koji > can place on it (we'll be getting a database server dedicated to koji at > some point which may alleviate this but that's both speculative and > something for the future.)
Than i suggest we wait till this is resolved. Using the repodate, parsing that and kepping that up to date is way harder than using koji's db. Another option might be to have a seperate database with only the needed information that is synced with koji everyday.
No parsing necessary. repodata is available as an sqlite database. yum has API to find, and download the repodata already. Copying and syncing the data around strikes me as extra work.
- repodata will show what's available to yum for downloading which is
synced with what an end-user will see.
Like said.. doing it this way will make it extra hard while it's not needed (or should not be needed).
That really depends on what you are expecting the end application to look like. Who you're serving and what they need to see first.
And last question. How do you need to make it? Make it with developer visitors in mind (so making it a bit technical won't do much harm) or make it so that Everyone can use it, even the completely new linux user which only knows a few basic computer things?
The initial proposal sounds like the latter.
Also if making it for the last group (which i expect) than it might be handy to make something of a firefox plugin (or something else) as well to just click "install" in the WebUI and than the package gets: Downloaded and Installed. And then i don't mean the normal FF download window and then double clicking on the rpm file.
That could be handy but it would need to be talked over with the PackageKit authors rather than me :-)
What does PackageKit have to do with it? Isn't it just a "yum -y install %package_name%" command that needs to be executed.. i don't see how PackageKit fits in this.
1) If you're on Fedora 8 and you click on the rawhide version of a package you're going to need more than that to install it.
2) PackageKit is working on a way to do this already so why reinvent the wheel.
-Toshio
About the language it needs to be written in.. (Python).. byw bye oppertunity for me to make it unless i learn python :) i do know Java and PHP.
That's too bad. Unfortunately, especially with something like GSoC it's imperative to have something at the end that we can maintain. Having an add on written in java or php, especially when its going to be working with a project already written in python is just going to be trouble.
-Toshio
lol .. i was considering to apply for this idea .. was busy a few days ago, looked at fedora-devel today .. and i see this thread ..
.<
On Thu, 2008-03-27 at 20:23 +0100, Mark wrote:
About the language it needs to be written in.. (Python).. byw bye oppertunity for me to make it unless i learn python :) i do know Java and PHP.
Seriously, just learn Python. Java should have already taught you OOP, and PHP should have already taught you loosely-typed "script" style programming, and the use of lists and hashes as fundamental data types, and that's maybe 95% of what underlies Python you know already.
2008/4/4 Callum Lerwick seg@haxxed.com:
On Thu, 2008-03-27 at 20:23 +0100, Mark wrote:
About the language it needs to be written in.. (Python).. byw bye oppertunity for me to make it unless i learn python :) i do know Java and PHP.
Seriously, just learn Python. Java should have already taught you OOP, and PHP should have already taught you loosely-typed "script" style programming, and the use of lists and hashes as fundamental data types, and that's maybe 95% of what underlies Python you know already.
To nitpick a bit :Python is strongly typed as far as I know
Arthur Pemberton wrote:
2008/4/4 Callum Lerwick seg@haxxed.com:
On Thu, 2008-03-27 at 20:23 +0100, Mark wrote:
About the language it needs to be written in.. (Python).. byw bye oppertunity for me to make it unless i learn python :) i do know Java and PHP.
Seriously, just learn Python. Java should have already taught you OOP, and PHP should have already taught you loosely-typed "script" style programming, and the use of lists and hashes as fundamental data types, and that's maybe 95% of what underlies Python you know already.
To nitpick a bit :Python is strongly typed as far as I know
It is also dynamically typed which many people interpret as loosely typed even though that is technically inaccurate.
Rahul
2008/4/4, Callum Lerwick seg@haxxed.com:
On Thu, 2008-03-27 at 20:23 +0100, Mark wrote:
About the language it needs to be written in.. (Python).. byw bye oppertunity for me to make it unless i learn python :) i do know Java and PHP.
Seriously, just learn Python. Java should have already taught you OOP, and PHP should have already taught you loosely-typed "script" style programming, and the use of lists and hashes as fundamental data types, and that's maybe 95% of what underlies Python you know already.
I have enough on my todo list already for the coming months. python together with this project isn't high on it. i'm more then willing to help when needed but not a full time SoC application. I will help in: - template stuff - mocking the design up - ajax technology stuff
And there is more then enough to do in those 3 alone. When you (the one who is gonna do this project) need my help on this just drop me a line and i will give it my best shot.
On Fri, Apr 4, 2008 at 7:12 PM, Mark markg85@gmail.com wrote:
2008/4/4, Callum Lerwick seg@haxxed.com:
On Thu, 2008-03-27 at 20:23 +0100, Mark wrote:
About the language it needs to be written in.. (Python).. byw bye oppertunity for me to make it unless i learn python :) i do know Java and PHP.
Seriously, just learn Python. Java should have already taught you OOP, and PHP should have already taught you loosely-typed "script" style programming, and the use of lists and hashes as fundamental data types, and that's maybe 95% of what underlies Python you know already.
I have enough on my todo list already for the coming months. python together with this project isn't high on it. i'm more then willing to help when needed but not a full time SoC application. I will help in:
- template stuff
- mocking the design up
- ajax technology stuff
And there is more then enough to do in those 3 alone. When you (the one who is gonna do this project) need my help on this just drop me a line and i will give it my best shot.
Hey all,
This thread kinda died after my last post but i'm really wondering how this project stands now at this moment in the middle of the GSoC. If it made it in in the first place.. where i can track the development.. things like that.
O btw. i still am more then willing to help with it!
I hope to hear about this project. Mark.
On Mon, Jul 28, 2008 at 12:50 PM, Mark markg85@gmail.com wrote:
On Fri, Apr 4, 2008 at 7:12 PM, Mark markg85@gmail.com wrote:
2008/4/4, Callum Lerwick seg@haxxed.com:
On Thu, 2008-03-27 at 20:23 +0100, Mark wrote:
About the language it needs to be written in.. (Python).. byw bye oppertunity for me to make it unless i learn python :) i do know Java and PHP.
Seriously, just learn Python. Java should have already taught you OOP, and PHP should have already taught you loosely-typed "script" style programming, and the use of lists and hashes as fundamental data types, and that's maybe 95% of what underlies Python you know already.
I have enough on my todo list already for the coming months. python together with this project isn't high on it. i'm more then willing to help when needed but not a full time SoC application. I will help in:
- template stuff
- mocking the design up
- ajax technology stuff
And there is more then enough to do in those 3 alone. When you (the one who is gonna do this project) need my help on this just drop me a line and i will give it my best shot.
Hey all,
This thread kinda died after my last post but i'm really wondering how this project stands now at this moment in the middle of the GSoC. If it made it in in the first place.. where i can track the development.. things like that.
O btw. i still am more then willing to help with it!
I hope to hear about this project. Mark.
The student who applied for this did not have their application accepted. I guess they decided not to do it otherwise. I myself have not had the time to try it.
Arthur Pemberton wrote:
On Mon, Jul 28, 2008 at 12:50 PM, Mark markg85@gmail.com wrote:
On Fri, Apr 4, 2008 at 7:12 PM, Mark markg85@gmail.com wrote:
2008/4/4, Callum Lerwick seg@haxxed.com:
On Thu, 2008-03-27 at 20:23 +0100, Mark wrote:
About the language it needs to be written in.. (Python).. byw bye oppertunity for me to make it unless i learn python :) i do know Java and PHP.
Seriously, just learn Python. Java should have already taught you OOP, and PHP should have already taught you loosely-typed "script" style programming, and the use of lists and hashes as fundamental data types, and that's maybe 95% of what underlies Python you know already.
I have enough on my todo list already for the coming months. python together with this project isn't high on it. i'm more then willing to help when needed but not a full time SoC application. I will help in:
- template stuff
- mocking the design up
- ajax technology stuff
And there is more then enough to do in those 3 alone. When you (the one who is gonna do this project) need my help on this just drop me a line and i will give it my best shot.
Hey all,
This thread kinda died after my last post but i'm really wondering how this project stands now at this moment in the middle of the GSoC. If it made it in in the first place.. where i can track the development.. things like that.
O btw. i still am more then willing to help with it!
I hope to hear about this project. Mark.
The student who applied for this did not have their application accepted. I guess they decided not to do it otherwise. I myself have not had the time to try it.
However, some people are working on this problem as a different application rather than the PackageDB. Look at https://fedorahosted.org/amber or talk with rnorwood and otaylor on irc.freenode.net
-Toshio
Hey all,
This thread kinda died after my last post but i'm really wondering how this project stands now at this moment in the middle of the GSoC. If it made it in in the first place.. where i can track the development.. things like that.
O btw. i still am more then willing to help with it!
I hope to hear about this project. Mark.
The student who applied for this did not have their application accepted. I guess they decided not to do it otherwise. I myself have not had the time to try it.
However, some people are working on this problem as a different application rather than the PackageDB. Look at https://fedorahosted.org/amber or talk with rnorwood and otaylor on irc.freenode.net
-Toshio
Good to see atleast some development. I was just hoping to see something visual.. I will see if i can get in contact with those 2 you mentioned.
Mark wrote:
Good to see atleast some development. I was just hoping to see something visual.. I will see if i can get in contact with those 2 you mentioned.
https://fedoraproject.org/wiki/Features/ApplicationInstaller
Mockups:
http://yipyop.com/fedora/images/fedora_apps.png http://yipyop.com/fedora/images/fedora_app_page.png
Rahul
On Mon, Jul 28, 2008 at 11:23 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Mark wrote:
Good to see atleast some development. I was just hoping to see something visual.. I will see if i can get in contact with those 2 you mentioned.
https://fedoraproject.org/wiki/Features/ApplicationInstaller
Thanx for the link
Mockups:
http://yipyop.com/fedora/images/fedora_apps.png http://yipyop.com/fedora/images/fedora_app_page.png
Rahul
Damn! those images look nice! Good job!
On Mon, Jul 28, 2008 at 4:28 PM, Mark markg85@gmail.com wrote:
On Mon, Jul 28, 2008 at 11:23 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Mark wrote:
Good to see atleast some development. I was just hoping to see something visual.. I will see if i can get in contact with those 2 you mentioned.
https://fedoraproject.org/wiki/Features/ApplicationInstaller
Thanx for the link
Mockups:
http://yipyop.com/fedora/images/fedora_apps.png http://yipyop.com/fedora/images/fedora_app_page.png
Rahul
Would be interesting to see a Qt version of this which would just use the web as the UI with WebKit
Would be interesting to see a Qt version of this which would just use the web as the UI with WebKit
I don't get what QT has to do with it.. it's a web based project!
And for the real life demo: http://publictest10.fedoraproject.org/amber/
That... doesn't look as good as the mockups.. any reason why that's the case? If it's just because the mockup hasn't been made in html file yet then i can help with that.
Mark wrote:
Would be interesting to see a Qt version of this which would just use the web as the UI with WebKit
I don't get what QT has to do with it.. it's a web based project!
And for the real life demo: http://publictest10.fedoraproject.org/amber/
That... doesn't look as good as the mockups.. any reason why that's the case? If it's just because the mockup hasn't been made in html file yet then i can help with that.
Read the discussions at
https://www.redhat.com/archives/fedora-websites-list/2008-July/msg00034.html
Contact Robin Norwood if you can help.
Rahul
On Wed, 2008-03-26 at 21:36 -0700, Toshio Kuratomi wrote:
Pavel Khardikov wrote:
Thorsten Leemhuis writes:
On 24.03.2008 17:46, Pavel Khardikov wrote:
Thorsten Leemhuis writes:
On 23.03.2008 23:14, Alex Lancaster wrote:
>>>>> "pk" == pavel khardikov writes: >>>>> [...] pk> http://fedoraproject.org/wiki/SummerCoding/2008/Ideas It seems that the WebUI overlaps considerably with the "MyFedora" idea which has already been started:
Yeah, MyFedora was still young (or even not born yet) when I added the idea to the wiki. I don't know much about MyFedora, but afaics it could need help as well and might be a good GSoC project.
Thanks for your reply. It is a great pity :(
If I understood there is no reason to start doing Package WebUI from the very begining because MyFedora project is aimed at solving the same problems.
I'm can not properly answer this question. J5 (the MyFedora develop) likely can do that better.
From what I can see on
http://fedoraproject.org/wiki/MyFedora it seems to me that developers are the main target audience of MyFedora. Only the second screenshot indicates that MyFedora might provide something like packages.debian.org (which also provides a good service for users)
In what way the idea of Package WebUI can be relate to GSoC?
As far as I can see the idea of WebInstall is similar? Is WebInstall project still relevant to GSoC or MyFedora will cope with its functions?
I'd suggest you contact J5, the developer of MyFedora. Maybe he can help to answer the question if a separate WebUI makes sense (which I doubt).
Cu knurd
Ok.
Thanks for your reply.
Sorry I didn't this thread earlier, Pavel, how interested in this are you? How self-motivated? I could see doing something like this as a GSoC project but hadn't really thought about it before. We should have a talk between you, J5 (John Palmieri -- myfedora), skvidal (Seth Vidal -- repoview/yum metadata), and I (abadger1999 -- pkgdb) about what would be a useful and good chunk of code for a GSoC project.
I can be found on IRC as abadger1999, in irc.freenode.net #fedora-admin, #fedora-devel. Like I said, I haven't thought about doing this until now so we'd need to get busy on this if you're interested.
-Toshio
So, MyFedora, while being developer targeted is taking a user designed approach. What this means is that instead of displaying all the information in the world about a subject (say packages) it displays the most common actions and information a developer would need in their day to day work. For instance, I am working on the build page and what it shows is what builds were done for a package, if there is an error it will display a link for the log that is most likely to have the error in it. If there are downloads available it will show only the package and sub packages, excluding debuginfo and devel for the arch the user is running on. There is a more link to see all of the downloads so I do add some drill down facilities but it is not a priority. The part I am working on now is if the package is in testing or candidate repos and you have the rights to request a push it will have an action to push to a release via bodhi. And that is just the builds page. In every case I pull from our existing tools via json or xmlrpc instead of recreating databases.
Now that I have outlined the development mentality for MyFedora I have a couple of ideas where this GSoC Project should fit in.
First, there are two elements we want to consider, a package database and an application database. Users care about applications (a collection of packages which make up a program which is usually launched from a menu), developers care about package (a collection of interrelated files and rules for putting them on a disk as well as specifying dependencies). One tool could most likely have a UI and DB to fit both with minor tweaks.
If you want to just make a data mining tool it will most likely be better off as a separate TurboGears project in which MyFedora could access its data based off of specific packages.
If you wanted it to be part of MyFedora you will have to think in terms of the users, what do they want to see, how do they want to see it, what actions would they need and how does it integrate with other Fedora tools.
Personally if it was part of MyFedora I would want it to be much more than just a view into a package. I would want people to be able to write comments, have annotations for the next build, be able to trace unneeded dependencies, be able to see and download patches to send to upstream, and it should be able to do this without looking like the barf of information the Debian package db is (however useful that barf of information is ;) In other words it should be a tool towards making fedora packages and the upstream sources they pulled from better.
If you are up for that challenge (and I am not saying you have to get it all done but move in that direction) then it will be a perfect fit for MyFedora. I would be happy to mentor.
2008/3/27, John (J5) Palmieri johnp@redhat.com:
So, MyFedora, while being developer targeted is taking a user designed approach. What this means is that instead of displaying all the information in the world about a subject (say packages) it displays the most common actions and information a developer would need in their day to day work. For instance, I am working on the build page and what it shows is what builds were done for a package, if there is an error it will display a link for the log that is most likely to have the error in it. If there are downloads available it will show only the package and sub packages, excluding debuginfo and devel for the arch the user is running on. There is a more link to see all of the downloads so I do add some drill down facilities but it is not a priority. The part I am working on now is if the package is in testing or candidate repos and you have the rights to request a push it will have an action to push to a release via bodhi. And that is just the builds page. In every case I pull from our existing tools via json or xmlrpc instead of recreating databases.
Now that I have outlined the development mentality for MyFedora I have a couple of ideas where this GSoC Project should fit in.
First, there are two elements we want to consider, a package database and an application database. Users care about applications (a collection of packages which make up a program which is usually launched from a menu), developers care about package (a collection of interrelated files and rules for putting them on a disk as well as specifying dependencies). One tool could most likely have a UI and DB to fit both with minor tweaks.
If you want to just make a data mining tool it will most likely be better off as a separate TurboGears project in which MyFedora could access its data based off of specific packages.
If you wanted it to be part of MyFedora you will have to think in terms of the users, what do they want to see, how do they want to see it, what actions would they need and how does it integrate with other Fedora tools.
Personally if it was part of MyFedora I would want it to be much more than just a view into a package. I would want people to be able to write comments, have annotations for the next build, be able to trace unneeded dependencies, be able to see and download patches to send to upstream, and it should be able to do this without looking like the barf of information the Debian package db is (however useful that barf of information is ;) In other words it should be a tool towards making fedora packages and the upstream sources they pulled from better.
If you are up for that challenge (and I am not saying you have to get it all done but move in that direction) then it will be a perfect fit for MyFedora. I would be happy to mentor.
-- John (J5) Palmieri johnp@redhat.com
I'm interested and willing but python stops me.. Are there any docs on that koji database communication with xmlrpc? if so.. where are they?
Oke everyone i made a nice little html + javascrip page of a possible solution to make it suitable for the developer AND the completely new linux users. Take a look here [1] and see for yourself.
I didn't spend any time at the look (obvious) but it's just to get the idea of what is possible today. the link works 100% fine in FF but IE might show it a little different.
So what do you think of it? btw.. done in about 40 minutes. Also the ajax technology is NOT used in this example but if something like this is gonna be made for real than i think using ajax here to load the developer information would be a perfect fit.
On Thu, 2008-03-27 at 23:00 +0100, Mark wrote:
Oke everyone i made a nice little html + javascrip page of a possible solution to make it suitable for the developer AND the completely new linux users. Take a look here [1] and see for yourself.
I didn't spend any time at the look (obvious) but it's just to get the idea of what is possible today. the link works 100% fine in FF but IE might show it a little different.
So what do you think of it? btw.. done in about 40 minutes. Also the ajax technology is NOT used in this example but if something like this is gonna be made for real than i think using ajax here to load the developer information would be a perfect fit.
Looks good, a couple of comments:
This is more suited to an application view as you have the install link. For package view I would want to see the latest versions built and released in each of the important repos (devel, F-8, F-7, RHEL-5, RHEL-4, RHEL-3) with the ability to see all the builds. If a specific package version is selected it should show if it is released and in what version. The icon should be grabbed from the package if it has one, same with the description (perhaps we could allow wiki like editing here for better descriptions, but I feel that is only good if it can somehow update the package too).
If you are doing packages it is geared towards developers anyway so there is no need for the Developer Info link. Instead I would have direct links above the comments or even as a sidebar for things like patches, source tarball download, dependency tracker, etc. For things that are useful to be on the main page but hidden such as file lists another section that when clicked on expands.
Oh and upstream info is just as important as the package info so the upstream stats such as where to get the original sources and homepage info. In the future even showing that a new version has been released would be great but one step at a time.
On Thu, 2008-03-27 at 21:38 +0100, Mark wrote:
2008/3/27, John (J5) Palmieri johnp@redhat.com:
So, MyFedora, while being developer targeted is taking a user designed approach. What this means is that instead of displaying all the information in the world about a subject (say packages) it displays the most common actions and information a developer would need in their day to day work. For instance, I am working on the build page and what it shows is what builds were done for a package, if there is an error it will display a link for the log that is most likely to have the error in it. If there are downloads available it will show only the package and sub packages, excluding debuginfo and devel for the arch the user is running on. There is a more link to see all of the downloads so I do add some drill down facilities but it is not a priority. The part I am working on now is if the package is in testing or candidate repos and you have the rights to request a push it will have an action to push to a release via bodhi. And that is just the builds page. In every case I pull from our existing tools via json or xmlrpc instead of recreating databases.
Now that I have outlined the development mentality for MyFedora I have a couple of ideas where this GSoC Project should fit in.
First, there are two elements we want to consider, a package database and an application database. Users care about applications (a collection of packages which make up a program which is usually launched from a menu), developers care about package (a collection of interrelated files and rules for putting them on a disk as well as specifying dependencies). One tool could most likely have a UI and DB to fit both with minor tweaks.
If you want to just make a data mining tool it will most likely be better off as a separate TurboGears project in which MyFedora could access its data based off of specific packages.
If you wanted it to be part of MyFedora you will have to think in terms of the users, what do they want to see, how do they want to see it, what actions would they need and how does it integrate with other Fedora tools.
Personally if it was part of MyFedora I would want it to be much more than just a view into a package. I would want people to be able to write comments, have annotations for the next build, be able to trace unneeded dependencies, be able to see and download patches to send to upstream, and it should be able to do this without looking like the barf of information the Debian package db is (however useful that barf of information is ;) In other words it should be a tool towards making fedora packages and the upstream sources they pulled from better.
If you are up for that challenge (and I am not saying you have to get it all done but move in that direction) then it will be a perfect fit for MyFedora. I would be happy to mentor.
-- John (J5) Palmieri johnp@redhat.com
I'm interested and willing but python stops me..
What are you good at? Even having someone write templates and javascript are important. 70% of my work is in JavaScript with JSON. The backend is there to pull data. Also, this is Summer of Code, a good time to learn something new if you already know other server side languages. TurboGears and python is pretty much our infrastructure. It makes doing things like utilizing FAS2 for single sign-on quite easy.
Are there any docs on that koji database communication with xmlrpc?
That is all done with the koji python module. It can't be done via pure javascript because of browser security preventing cross site communications. Basically what I do is setup a json call on MyFedora and have that call the xmlrpc from the server.
if so.. where are they?
yum install koji koji --list-apis
That will show you the api's.
2008/3/27, John (J5) Palmieri johnp@redhat.com:
On Thu, 2008-03-27 at 21:38 +0100, Mark wrote:
2008/3/27, John (J5) Palmieri johnp@redhat.com:
So, MyFedora, while being developer targeted is taking a user designed approach. What this means is that instead of displaying all the information in the world about a subject (say packages) it displays the most common actions and information a developer would need in their day to day work. For instance, I am working on the build page and what it shows is what builds were done for a package, if there is an error it will display a link for the log that is most likely to have the error in it. If there are downloads available it will show only the package and sub packages, excluding debuginfo and devel for the arch the user is running on. There is a more link to see all of the downloads so I do add some drill down facilities but it is not a priority. The part I am working on now is if the package is in testing or candidate repos and you have the rights to request a push it will have an action to push to a release via bodhi. And that is just the builds page. In every case I pull from our existing tools via json or xmlrpc instead of recreating databases.
Now that I have outlined the development mentality for MyFedora I have a couple of ideas where this GSoC Project should fit in.
First, there are two elements we want to consider, a package database and an application database. Users care about applications (a collection of packages which make up a program which is usually launched from a menu), developers care about package (a collection of interrelated files and rules for putting them on a disk as well as specifying dependencies). One tool could most likely have a UI and DB to fit both with minor tweaks.
If you want to just make a data mining tool it will most likely be better off as a separate TurboGears project in which MyFedora could access its data based off of specific packages.
If you wanted it to be part of MyFedora you will have to think in terms of the users, what do they want to see, how do they want to see it, what actions would they need and how does it integrate with other Fedora tools.
Personally if it was part of MyFedora I would want it to be much more than just a view into a package. I would want people to be able to write comments, have annotations for the next build, be able to trace unneeded dependencies, be able to see and download patches to send to upstream, and it should be able to do this without looking like the barf of information the Debian package db is (however useful that barf of information is ;) In other words it should be a tool towards making fedora packages and the upstream sources they pulled from better.
If you are up for that challenge (and I am not saying you have to get it all done but move in that direction) then it will be a perfect fit for MyFedora. I would be happy to mentor.
-- John (J5) Palmieri johnp@redhat.com
I'm interested and willing but python stops me..
What are you good at? Even having someone write templates and javascript are important. 70% of my work is in JavaScript with JSON.
I can do javascript with jQuery and i can probably do JSON as well. templates is also not a problem
The backend is there to pull data. Also, this is Summer of Code, a good time to learn something new if you already know other server side languages. TurboGears and python is pretty much our infrastructure. It makes doing things like utilizing FAS2 for single sign-on quite easy.
yeah learn something new.. well i want to learn C, C++ and Vala. python isn't really high on that list but i also want to learn that one. (damn that's gonna be a lot of programming languages in my head (php, java, c, c++, vala, html, css, python, javascript))
Are there any docs on that koji database communication with xmlrpc?
That is all done with the koji python module. It can't be done via pure javascript because of browser security preventing cross site communications. Basically what I do is setup a json call on MyFedora and have that call the xmlrpc from the server.
bottleneck... no python knowledge (yet)
if so.. where are they?
yum install koji koji --list-apis
nice
That will show you the api's.
Thanx for the info
2008/3/28, John (J5) Palmieri johnp@redhat.com:
On Thu, 2008-03-27 at 23:00 +0100, Mark wrote:
Oke everyone i made a nice little html + javascrip page of a possible solution to make it suitable for the developer AND the completely new linux users. Take a look here [1] and see for yourself.
I didn't spend any time at the look (obvious) but it's just to get the idea of what is possible today. the link works 100% fine in FF but IE might show it a little different.
So what do you think of it? btw.. done in about 40 minutes. Also the ajax technology is NOT used in this example but if something like this is gonna be made for real than i think using ajax here to load the developer information would be a perfect fit.
Looks good, a couple of comments:
This is more suited to an application view as you have the install link. For package view I would want to see the latest versions built and released in each of the important repos (devel, F-8, F-7, RHEL-5, RHEL-4, RHEL-3) with the ability to see all the builds.
Agreed
If a specific package version is selected it should show if it is released and in what version.
Well.. this is just a example of how it could look.. Agreed on the idea but can be different in other packages
The icon should be grabbed from the package if it has one, same with the description (perhaps we could allow wiki like editing here for better descriptions, but I feel that is only good if it can somehow update the package too).
Hehe this is just html and javascript ^_^ i didn't add in full xmlrpc and json calls to get that information but again Agreed! The wiki like idea is awsome but that it would have to have right permissions to the koji database in the specfile section. And for that (to keep somekind of a log) it would probably be best to split the specfile in sections in the database. so the %description is in a seperate column, the %files list is in a seperate column etc..
If you are doing packages it is geared towards developers anyway so there is no need for the Developer Info link. Instead I would have direct links above the comments or even as a sidebar for things like patches, source tarball download, dependency tracker, etc. For things that are useful to be on the main page but hidden such as file lists another section that when clicked on expands.
That's a lot of stuff to hide and have links to. Perhaps there should just be a "More information" that opens the sidebar in which you can choose what information you would like to see. Than the sidebar contains _everything_ that is known of the package. That would be better i think. So partly agreed with modifications.
Oh and upstream info is just as important as the package info so the upstream stats such as where to get the original sources and homepage info. In the future even showing that a new version has been released would be great but one step at a time.
I can't imagine that those things can be hard to add _unless_ that information is not stored in it's own column and thus has to be grabbed out of the specfile. and the new version release should be possible now judging from the koji tags i see everywhere....
I will try to add in that sidebar stuff tomorrow just to see how that would work. also making the page on 100% width.
John (J5) Palmieri johnp@redhat.com
Mark
On Fri, 2008-03-28 at 00:25 +0100, Mark wrote:
2008/3/27, John (J5) Palmieri johnp@redhat.com:
On Thu, 2008-03-27 at 21:38 +0100, Mark wrote:
2008/3/27, John (J5) Palmieri johnp@redhat.com:
So, MyFedora, while being developer targeted is taking a user designed approach. What this means is that instead of displaying all the information in the world about a subject (say packages) it displays the most common actions and information a developer would need in their day to day work. For instance, I am working on the build page and what it shows is what builds were done for a package, if there is an error it will display a link for the log that is most likely to have the error in it. If there are downloads available it will show only the package and sub packages, excluding debuginfo and devel for the arch the user is running on. There is a more link to see all of the downloads so I do add some drill down facilities but it is not a priority. The part I am working on now is if the package is in testing or candidate repos and you have the rights to request a push it will have an action to push to a release via bodhi. And that is just the builds page. In every case I pull from our existing tools via json or xmlrpc instead of recreating databases.
Now that I have outlined the development mentality for MyFedora I have a couple of ideas where this GSoC Project should fit in.
First, there are two elements we want to consider, a package database and an application database. Users care about applications (a collection of packages which make up a program which is usually launched from a menu), developers care about package (a collection of interrelated files and rules for putting them on a disk as well as specifying dependencies). One tool could most likely have a UI and DB to fit both with minor tweaks.
If you want to just make a data mining tool it will most likely be better off as a separate TurboGears project in which MyFedora could access its data based off of specific packages.
If you wanted it to be part of MyFedora you will have to think in terms of the users, what do they want to see, how do they want to see it, what actions would they need and how does it integrate with other Fedora tools.
Personally if it was part of MyFedora I would want it to be much more than just a view into a package. I would want people to be able to write comments, have annotations for the next build, be able to trace unneeded dependencies, be able to see and download patches to send to upstream, and it should be able to do this without looking like the barf of information the Debian package db is (however useful that barf of information is ;) In other words it should be a tool towards making fedora packages and the upstream sources they pulled from better.
If you are up for that challenge (and I am not saying you have to get it all done but move in that direction) then it will be a perfect fit for MyFedora. I would be happy to mentor.
-- John (J5) Palmieri johnp@redhat.com
I'm interested and willing but python stops me..
What are you good at? Even having someone write templates and javascript are important. 70% of my work is in JavaScript with JSON.
I can do javascript with jQuery and i can probably do JSON as well. templates is also not a problem
The backend is there to pull data. Also, this is Summer of Code, a good time to learn something new if you already know other server side languages. TurboGears and python is pretty much our infrastructure. It makes doing things like utilizing FAS2 for single sign-on quite easy.
yeah learn something new.. well i want to learn C, C++ and Vala. python isn't really high on that list but i also want to learn that one. (damn that's gonna be a lot of programming languages in my head (php, java, c, c++, vala, html, css, python, javascript))
Are there any docs on that koji database communication with xmlrpc?
That is all done with the koji python module. It can't be done via pure javascript because of browser security preventing cross site communications. Basically what I do is setup a json call on MyFedora and have that call the xmlrpc from the server.
bottleneck... no python knowledge (yet)
if so.. where are they?
yum install koji koji --list-apis
nice
That will show you the api's.
Thanx for the info
2008/3/28, John (J5) Palmieri johnp@redhat.com:
On Thu, 2008-03-27 at 23:00 +0100, Mark wrote:
Oke everyone i made a nice little html + javascrip page of a possible solution to make it suitable for the developer AND the completely new linux users. Take a look here [1] and see for yourself.
I didn't spend any time at the look (obvious) but it's just to get the idea of what is possible today. the link works 100% fine in FF but IE might show it a little different.
So what do you think of it? btw.. done in about 40 minutes. Also the ajax technology is NOT used in this example but if something like this is gonna be made for real than i think using ajax here to load the developer information would be a perfect fit.
Looks good, a couple of comments:
This is more suited to an application view as you have the install link. For package view I would want to see the latest versions built and released in each of the important repos (devel, F-8, F-7, RHEL-5, RHEL-4, RHEL-3) with the ability to see all the builds.
Agreed
If a specific package version is selected it should show if it is released and in what version.
Well.. this is just a example of how it could look.. Agreed on the idea but can be different in other packages
The icon should be grabbed from the package if it has one, same with the description (perhaps we could allow wiki like editing here for better descriptions, but I feel that is only good if it can somehow update the package too).
Hehe this is just html and javascript ^_^ i didn't add in full xmlrpc and json calls to get that information but again Agreed! The wiki like idea is awsome but that it would have to have right permissions to the koji database in the specfile section. And for that (to keep somekind of a log) it would probably be best to split the specfile in sections in the database. so the %description is in a seperate column, the %files list is in a seperate column etc..
If you are doing packages it is geared towards developers anyway so there is no need for the Developer Info link. Instead I would have direct links above the comments or even as a sidebar for things like patches, source tarball download, dependency tracker, etc. For things that are useful to be on the main page but hidden such as file lists another section that when clicked on expands.
That's a lot of stuff to hide and have links to. Perhaps there should just be a "More information" that opens the sidebar in which you can choose what information you would like to see. Than the sidebar contains _everything_ that is known of the package. That would be better i think. So partly agreed with modifications.
Oh and upstream info is just as important as the package info so the upstream stats such as where to get the original sources and homepage info. In the future even showing that a new version has been released would be great but one step at a time.
I can't imagine that those things can be hard to add _unless_ that information is not stored in it's own column and thus has to be grabbed out of the specfile. and the new version release should be possible now judging from the koji tags i see everywhere....
I will try to add in that sidebar stuff tomorrow just to see how that would work. also making the page on 100% width.
Another good thing to do before diving to far into the mockup is to take a screenshot of various package web systems and in the gimp or in a similar way, point out the sections which are important so we can assign labels. I would suggest setting up a wiki page off of the MyFedora wiki page (http://fedoraproject.org/wiki/MyFedora) for package info. Once we have a list of labels you can then do the mockup using the labels as placeholders. We can drill down this way to finally get a list of data you want to grab. I can then fill in the backend from there.
BTW here is the style sheet I am using (it is not complete yet):
https://fedorahosted.org/myfedora/browser/myfedora/static/css/myfedora-style...
and the genshi template gives you an idea of the structure we use:
https://fedorahosted.org/myfedora/browser/myfedora/templates/packages/master... https://fedorahosted.org/myfedora/browser/myfedora/templates/packages/builds...
The template language may look a bit weird at first but you don't have to worry about loops and such, just how the css elements are used.
On Tue, Mar 25, 2008 at 12:46 AM, Pavel Khardikov sonic@inetwork.ru wrote:
Hi!
Thanks for your reply. It is a great pity :(
If I understood there is no reason to start doing Package WebUI from the very begining because MyFedora project is aimed at solving the same problems.
IMO, PkgDB is much better choice to be used as the base of package webui, as its already integrates with Koji, and Bodhi. Revamp the UI, add features like comments, pybugzilla, etc. Then, provide an interface for communicating with MyFedora (json or something).
In what way the idea of Package WebUI can be relate to GSoC?
As far as I can see the idea of WebInstall is similar? Is WebInstall project still relevant to GSoC or MyFedora will cope with its functions?
WebInstall will require client side adjustments such as a handler for url webinstall://path/to/package/metadata.xml or maybe extension based handler for a metadata file named, for example, mysoftware.webinstall. The client tool then will call packagekit or other necessary thing to get the software installed. (Hey , anybody applied for this Idea yet? :P )
MyFedora/PackageWebUI will be a good place to place the links to the metadata.
Webinstall is a different sofware, but if PackageWebUI willing to provide metadatas, they both can work together greatly as one way for users to find Fedora softwares.
======================== Just adding a bit details about my idea for PkgWebUI:
I am interested of a place where users can easily find details about a software in Fedora repository, access bug reports related to the packages, and communicate with other users of the software. The detail section be somewhat like Fedora Daily Package's informations, and the rest similar to Wine's AppDB. I would love if WebInstall URLS are integrated together with PackageWebUI to allow users to install packages by clicking a link at the site.
I am familiar with Plone, Django, a bit of TurboGears, and the usual web development stack (HTML/CSS/PHP and stuff). A python addict myself, and would love to develop something pythonic although my skills are more in the sysadmin side. As a Fedora ambassador, I see the PackageWebUI can be a good place to encourage user involvement to the community (though the comment section will require some idea to make it not over-loading after a lot of people commented - 1 thread comment section sounds scary for long term).
a little unrelated to this thread (but related to GSOC), I am familar with Debarashi's implementation of Opyum, (used the procedures manually through shell commands [tar,cp,system-cdinstall-helper,etc], not comfortable with opyum's GUI) .. and would also like it to be in PackageKit .. however, C turns me off ..
-- Best regards. Pavel Khardikov
fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Izhar Firdaus wrote:
a little unrelated to this thread (but related to GSOC), I am familar with Debarashi's implementation of Opyum, (used the procedures manually through shell commands [tar,cp,system-cdinstall-helper,etc], not comfortable with opyum's GUI) .. and would also like it to be in PackageKit .. however, C turns me off ..
Refer
http://hughsient.livejournal.com/54131.html
Rahul
On Fri, Mar 28, 2008 at 4:53 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Izhar Firdaus wrote:
a little unrelated to this thread (but related to GSOC), I am familar with Debarashi's implementation of Opyum, (used the procedures manually through shell commands [tar,cp,system-cdinstall-helper,etc], not comfortable with opyum's GUI) .. and would also like it to be in PackageKit .. however, C turns me off ..
Refer
eh? .. hughsient already started doing the feature? ..
he put that in the GSOC idea page, and it looks like he started it earlier before gsoc is even started .. lol http://fedoraproject.org/wiki/SummerCoding/2008/Ideas#head-4ac0b11e181e6e309...
Rahul
--
fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
I wonder what the real goal is with this? I read things where it seems like it's gonna be a AIO (All in one) webapp for normal users and developers and i read things where it's for normal users only.
I personally think that IF this is gonna be made and done as a GSoC project than better make it a AIO project which has everything the developers need (basically koji) and has everything the normal users need (WebUI/PkgDB etc) and perhaps add in bugzilla reports per application. so for example. when i look (as a user) on the firefox page i see something simular of that what i made + a sidebar (or something else) that contains many developer links like: Bugzilla Reports. When clicked on that all the bugs that are filled against firefox will also be available (as a list) in the package..
this would be the way to go if you ask me but than it isn't just a WebUI for fedora's packages anymore.. it's WAY more. Also the things that you (John) want to show in this is already nearly everything a developer needs so that's also why i think it would be best to make a AIO program of this.
Just found something that would probably fit nicely in this project as well. When you simply list the applications that are under a category you _could_ get a simple list.. or you could get a (still simple) list with some more information [1] which will be nice for new users. Expereinced users might also find it nice to have.
Take a look at this link [1]. I especially like the reting behind it. Now another good example of this is the *-look sites (kde-look, gnome-look, xfce-look etc....
On Sat, Mar 29, 2008 at 12:07 AM, Mark markg85@gmail.com wrote:
I wonder what the real goal is with this?
if for me, my goal would be trying to provide a place for users to easily gain informations about a certain packages which interest them. Also, to add features that would try to encourage contribution to the package (wiki/updates-testing notification/etc)
I read things where it seems like it's gonna be a AIO (All in one) webapp for normal users and developers and i read things where it's for normal users only.
AIO sounds more like a target for MyFedora .. a one stop place to access everything Fedora .. while PackageWebUI/PkgDB would be focusing on things surrounding packages, and try to be good at it.
I personally think that IF this is gonna be made and done as a GSoC project than better make it a AIO project which has everything the developers need (basically koji) and has everything the normal users need (WebUI/PkgDB etc) and perhaps add in bugzilla reports per application. so for example. when i look (as a user) on the firefox page i see something simular of that what i made + a sidebar (or something else) that contains many developer links like: Bugzilla Reports. When clicked on that all the bugs that are filled against firefox will also be available (as a list) in the package..
this would be the way to go if you ask me but than it isn't just a WebUI for fedora's packages anymore.. it's WAY more. Also the things that you (John) want to show in this is already nearly everything a developer needs so that's also why i think it would be best to make a AIO program of this.
On Sat, Mar 29, 2008 at 2:56 AM, Mark markg85@gmail.com wrote:
Just found something that would probably fit nicely in this project as well. When you simply list the applications that are under a category you _could_ get a simple list.. or you could get a (still simple) list with some more information [1] which will be nice for new users. Expereinced users might also find it nice to have.
Take a look at this link [1]. I especially like the reting behind it. Now another good example of this is the *-look sites (kde-look, gnome-look, xfce-look etc....
+1 .. though i would prefer labels/tag approach rather than fixed categories
2008/3/28, Izhar Firdaus kagesenshi.87@gmail.com:
On Sat, Mar 29, 2008 at 12:07 AM, Mark markg85@gmail.com wrote:
I read things where it seems like it's gonna be a AIO (All in one) webapp for normal users and developers and i read things where it's for normal users only.
AIO sounds more like a target for MyFedora .. a one stop place to access everything Fedora .. while PackageWebUI/PkgDB would be focusing on things surrounding packages, and try to be good at it.
What's the point in having both? So the AIO in MyFedora and than again a part of it in WebUI.. What i can understand is making one AIO and make some sections of it so configurable that for a user it looks like 2 different applications 1. developers stuff 2. new user stuff
I personally think that IF this is gonna be made and done as a GSoC project than better make it a AIO project which has everything the developers need (basically koji) and has everything the normal users need (WebUI/PkgDB etc) and perhaps add in bugzilla reports per application. so for example. when i look (as a user) on the firefox page i see something simular of that what i made + a sidebar (or something else) that contains many developer links like: Bugzilla Reports. When clicked on that all the bugs that are filled against firefox will also be available (as a list) in the package..
this would be the way to go if you ask me but than it isn't just a WebUI for fedora's packages anymore.. it's WAY more. Also the things that you (John) want to show in this is already nearly everything a developer needs so that's also why i think it would be best to make a AIO program of this.
On Sat, Mar 29, 2008 at 2:56 AM, Mark markg85@gmail.com wrote:
Just found something that would probably fit nicely in this project as well. When you simply list the applications that are under a category you _could_ get a simple list.. or you could get a (still simple) list with some more information [1] which will be nice for new users. Expereinced users might also find it nice to have.
Take a look at this link [1]. I especially like the reting behind it. Now another good example of this is the *-look sites (kde-look, gnome-look, xfce-look etc....
+1 .. though i would prefer labels/tag approach rather than fixed categories
thanx. it's just about how it looks. the tags stuff is indeed better to use here because the koji database seems to use it a lot and works out quite nice. and i would also provide the user to choose between list view (little info) and More info (which would be the one i just showed here).
Another idea that i just thought of was the option for the person visiting a package to have the ability to "notify" the package owners of a new package. A condition i would add is that before the user can actually submit the new release link he will get a list with all the current known versions of that package to prevent useless input.
On Sat, Mar 29, 2008 at 4:54 AM, Mark markg85@gmail.com wrote:
2008/3/28, Izhar Firdaus kagesenshi.87@gmail.com:
On Sat, Mar 29, 2008 at 12:07 AM, Mark markg85@gmail.com wrote:
I read things where it seems like it's gonna be a AIO (All in one) webapp for normal users and developers and i read things where it's for normal users only.
AIO sounds more like a target for MyFedora .. a one stop place to access everything Fedora .. while PackageWebUI/PkgDB would be focusing on things surrounding packages, and try to be good at it.
What's the point in having both? So the AIO in MyFedora and than again a part of it in WebUI.. What i can understand is making one AIO and make some sections of it so configurable that for a user it looks like 2 different applications
- developers stuff
- new user stuff
I would like to see PackageWebUI focusing on packages-related tasks, and let MyFedora be the the one stop place which integrates -> { FAS, Fedora voting system, latest Fedora announcements, planet, PackageWebUI, etc } .. but thats just me, I dont know what J5 is planning for it.
I personally think that IF this is gonna be made and done as a GSoC project than better make it a AIO project which has everything the developers need (basically koji) and has everything the normal users need (WebUI/PkgDB etc) and perhaps add in bugzilla reports per application. so for example. when i look (as a user) on the firefox page i see something simular of that what i made + a sidebar (or something else) that contains many developer links like: Bugzilla Reports. When clicked on that all the bugs that are filled against firefox will also be available (as a list) in the package..
this would be the way to go if you ask me but than it isn't just a WebUI for fedora's packages anymore.. it's WAY more. Also the things that you (John) want to show in this is already nearly everything a developer needs so that's also why i think it would be best to make a AIO program of this.
On Sat, Mar 29, 2008 at 2:56 AM, Mark markg85@gmail.com wrote:
Just found something that would probably fit nicely in this project as well. When you simply list the applications that are under a category you _could_ get a simple list.. or you could get a (still simple) list with some more information [1] which will be nice for new users. Expereinced users might also find it nice to have.
Take a look at this link [1]. I especially like the reting behind it. Now another good example of this is the *-look sites (kde-look, gnome-look, xfce-look etc....
+1 .. though i would prefer labels/tag approach rather than fixed categories
thanx. it's just about how it looks. the tags stuff is indeed better to use here because the koji database seems to use it a lot and works out quite nice. and i would also provide the user to choose between list view (little info) and More info (which would be the one i just showed here).
Another idea that i just thought of was the option for the person visiting a package to have the ability to "notify" the package owners of a new package. A condition i would add is that before the user can actually submit the new release link he will get a list with all the current known versions of that package to prevent useless input.
Mark, u and I share the same mind!!! .. haha .. I just wrote out my proposal last night about what I want PackageWebUI to have, just put it on http://fedoraproject.org/wiki/MohdIzharFirdaus/GSOC2008
I wonder if pavel still interested with this idea .. he havent replied to this thread for a while ..
Izhar Firdaus wrote:
On Sat, Mar 29, 2008 at 4:54 AM, Mark markg85@gmail.com wrote:
2008/3/28, Izhar Firdaus kagesenshi.87@gmail.com:
On Sat, Mar 29, 2008 at 12:07 AM, Mark markg85@gmail.com wrote:
I read things where it seems like it's gonna be a AIO (All in one)
webapp for normal users and developers and i read things where it's for normal users only.
AIO sounds more like a target for MyFedora .. a one stop place to access everything Fedora .. while PackageWebUI/PkgDB would be focusing on things surrounding packages, and try to be good at it.
What's the point in having both? So the AIO in MyFedora and than again a part of it in WebUI.. What i can understand is making one AIO and make some sections of it so configurable that for a user it looks like 2 different applications
- developers stuff
- new user stuff
I would like to see PackageWebUI focusing on packages-related tasks, and let MyFedora be the the one stop place which integrates -> { FAS, Fedora voting system, latest Fedora announcements, planet, PackageWebUI, etc } .. but thats just me, I dont know what J5 is planning for it.
I personally think that IF this is gonna be made and done as a GSoC project than better make it a AIO project which has everything the developers need (basically koji) and has everything the normal users need (WebUI/PkgDB etc) and perhaps add in bugzilla reports per application. so for example. when i look (as a user) on the firefox page i see something simular of that what i made + a sidebar (or something else) that contains many developer links like: Bugzilla Reports. When clicked on that all the bugs that are filled against firefox will also be available (as a list) in the package..
this would be the way to go if you ask me but than it isn't just a WebUI for fedora's packages anymore.. it's WAY more. Also the things that you (John) want to show in this is already nearly everything a developer needs so that's also why i think it would be best to make a AIO program of this.
On Sat, Mar 29, 2008 at 2:56 AM, Mark markg85@gmail.com wrote:
Just found something that would probably fit nicely in this project as well. When you simply list the applications that are under a category you _could_ get a simple list.. or you could get a (still simple) list with some more information [1] which will be nice for new users. Expereinced users might also find it nice to have.
Take a look at this link [1]. I especially like the reting behind it. Now another good example of this is the *-look sites (kde-look, gnome-look, xfce-look etc....
+1 .. though i would prefer labels/tag approach rather than fixed categories
thanx. it's just about how it looks. the tags stuff is indeed better to use here because the koji database seems to use it a lot and works out quite nice. and i would also provide the user to choose between list view (little info) and More info (which would be the one i just showed here).
Another idea that i just thought of was the option for the person visiting a package to have the ability to "notify" the package owners of a new package. A condition i would add is that before the user can actually submit the new release link he will get a list with all the current known versions of that package to prevent useless input.
Mark, u and I share the same mind!!! .. haha .. I just wrote out my proposal last night about what I want PackageWebUI to have, just put it on http://fedoraproject.org/wiki/MohdIzharFirdaus/GSOC2008
I wonder if pavel still interested with this idea .. he havent replied to this thread for a while ..
Hello, Izhar!
Excuse me for not writting in this list for long time.
I still have a great interest in Fedora and GSoC projects in particular.
At one of my first letters Thorsten Leemhuis replied:
"No idea - as I said, I just added the idea to the wiki. I have no ideas nor skills how to actually realize the WebUI, thus I don't think I can mentor this idea further and * * I don't have the time or interest for it. Sorry. "
and
"I'd suggest you contact J5, the developer of MyFedora. Maybe he can help to answer the question if a separate WebUI makes sense (which I doubt). "
As I understood there is no sence to create another project that performs the same tasks and functions as MyFedora.
Perhaps I have not correctly understood.
On Sat, Mar 29, 2008 at 6:33 PM, Pavel Khardikov sonic@inetwork.ru wrote:
Hello, Izhar!
Excuse me for not writting in this list for long time.
I still have a great interest in Fedora and GSoC projects in particular.
At one of my first letters Thorsten Leemhuis replied:
"No idea - as I said, I just added the idea to the wiki. I have no ideas nor skills how to actually realize the WebUI, thus I don't think I can mentor this idea further and * * I don't have the time or interest for it. Sorry. "
and
"I'd suggest you contact J5, the developer of MyFedora. Maybe he can help to answer the question if a separate WebUI makes sense (which I doubt). "
As I understood there is no sence to create another project that performs the same tasks and functions as MyFedora.
Same goes for me, but looking Mockups, It looks a lot like PackageDB, but with an improved UI .. so, in my mind, rather than making MyFedora take PackageDB's ( http://admin.fedoraproject.org/pkgdb | https://fedorahosted.org/packagedb/ ) work, why dont extend PackageDB? .. PackageDB code is already out there .. revamp the UI, add more features .. I used the name "PackageWebUI" was because thats the title in the Fedora GSOC Idea page .. but I would prefer an approach of improving pkgdb rather than writing a new one..
my.fedoraproject.org / MyFedora - the name sounds more like a Fedora AIO to me, and thats also what i understand from
"my.fedoraproject.org is a project to integrate all of the Fedora infrastructure in one place. The goal is to create a modular web page in which each module would pull views from the various Fedora resources and display them to the user.",
and one of those modules, could be an integration to PkgDB/PackageWebUI .. Unix philosophy: "Write programs that do one thing and do it well." .. PkgDB focuses on packages, MyFedora focuses on integrating the rest of Fedora infrastructure. Of course, provide a way for all of them to communicate with each other (JSON,XMLRPC,whatever).
Or do J5 have different view about this?, both idea ( improve MyFedora / improve PackageDB ) sounds okay to me, just that I feel that if MyFedora implements those features, PackageDB and the effort made for it previously would be rendered of no-use (or perhaps thats what one of MyFedora's goal - to obsolete packagedb ) ..
On Sat, Mar 29, 2008 at 7:10 PM, Izhar Firdaus kagesenshi.87@gmail.com > Same goes for me, but looking Mockups, It looks a lot like PackageDB, s/Mockups/MyFedora mockups/
On Sat, Mar 29, 2008 at 7:10 PM, Izhar Firdaus kagesenshi.87@gmail.com wrote:
Same goes for me, but looking Mockups, It looks a lot like PackageDB, but with an improved UI .. so, in my mind, rather than making MyFedora take PackageDB's ( http://admin.fedoraproject.org/pkgdb | https://fedorahosted.org/packagedb/ ) work, why dont extend PackageDB? .. PackageDB code is already out there .. revamp the UI, add more features .. I used the name "PackageWebUI" was because thats the title in the Fedora GSOC Idea page .. but I would prefer an approach of improving pkgdb rather than writing a new one..
my.fedoraproject.org / MyFedora - the name sounds more like a Fedora AIO to me, and thats also what i understand from
"my.fedoraproject.org is a project to integrate all of the Fedora infrastructure in one place. The goal is to create a modular web page in which each module would pull views from the various Fedora resources and display them to the user.",
and one of those modules, could be an integration to PkgDB/PackageWebUI .. Unix philosophy: "Write programs that do one thing and do it well." .. PkgDB focuses on packages, MyFedora focuses on integrating the rest of Fedora infrastructure. Of course, provide a way for all of them to communicate with each other (JSON,XMLRPC,whatever).
hurm ... on another look at it at a different perspective ... MyFedora could be where the all the UI improvements to be done .. and let packagedb as one of the backend providers for MyFedora .. and instead of packagedb become the centralized everything all-about-packages site with bodhi and koji details are also queried there, myfedora could be the place which connects packagedb, bodhi, koji, and the rest of the infrastructure ...
and yes .. both idea sounds great :D
Izhar Firdaus пишет:
On Sat, Mar 29, 2008 at 6:33 PM, Pavel Khardikov sonic@inetwork.ru wrote:
Hello, Izhar!
Excuse me for not writting in this list for long time.
I still have a great interest in Fedora and GSoC projects in particular.
At one of my first letters Thorsten Leemhuis replied:
"No idea - as I said, I just added the idea to the wiki. I have no ideas nor skills how to actually realize the WebUI, thus I don't think I can mentor this idea further and * * I don't have the time or interest for it. Sorry. "
and
"I'd suggest you contact J5, the developer of MyFedora. Maybe he can help to answer the question if a separate WebUI makes sense (which I doubt). "
As I understood there is no sence to create another project that performs the same tasks and functions as MyFedora.
Same goes for me, but looking Mockups, It looks a lot like PackageDB, but with an improved UI .. so, in my mind, rather than making MyFedora take PackageDB's ( http://admin.fedoraproject.org/pkgdb | https://fedorahosted.org/packagedb/ ) work, why dont extend PackageDB? .. PackageDB code is already out there .. revamp the UI, add more features .. I used the name "PackageWebUI" was because thats the title in the Fedora GSOC Idea page .. but I would prefer an approach of improving pkgdb rather than writing a new one..
my.fedoraproject.org / MyFedora - the name sounds more like a Fedora AIO to me, and thats also what i understand from
"my.fedoraproject.org is a project to integrate all of the Fedora infrastructure in one place. The goal is to create a modular web page in which each module would pull views from the various Fedora resources and display them to the user.",
and one of those modules, could be an integration to PkgDB/PackageWebUI .. Unix philosophy: "Write programs that do one thing and do it well." .. PkgDB focuses on packages, MyFedora focuses on integrating the rest of Fedora infrastructure. Of course, provide a way for all of them to communicate with each other (JSON,XMLRPC,whatever).
Or do J5 have different view about this?, both idea ( improve MyFedora / improve PackageDB ) sounds okay to me, just that I feel that if MyFedora implements those features, PackageDB and the effort made for it previously would be rendered of no-use (or perhaps thats what one of MyFedora's goal - to obsolete packagedb ) ..
I agree with you. IMHO, need to use as a basis packagedb (revamp the UI, add more features, etc). Make it pretty and convenient for users.
Pavel Khardikov wrote:
Izhar Firdaus пишет:
Same goes for me, but looking Mockups, It looks a lot like PackageDB, but with an improved UI .. so, in my mind, rather than making MyFedora take PackageDB's ( http://admin.fedoraproject.org/pkgdb | https://fedorahosted.org/packagedb/ ) work, why dont extend PackageDB? .. PackageDB code is already out there .. revamp the UI, add more features .. I used the name "PackageWebUI" was because thats the title in the Fedora GSOC Idea page .. but I would prefer an approach of improving pkgdb rather than writing a new one..
my.fedoraproject.org / MyFedora - the name sounds more like a Fedora AIO to me, and thats also what i understand from
"my.fedoraproject.org is a project to integrate all of the Fedora infrastructure in one place. The goal is to create a modular web page in which each module would pull views from the various Fedora resources and display them to the user.",
and one of those modules, could be an integration to PkgDB/PackageWebUI .. Unix philosophy: "Write programs that do one thing and do it well." .. PkgDB focuses on packages, MyFedora focuses on integrating the rest of Fedora infrastructure. Of course, provide a way for all of them to communicate with each other (JSON,XMLRPC,whatever).
Or do J5 have different view about this?, both idea ( improve MyFedora / improve PackageDB ) sounds okay to me, just that I feel that if MyFedora implements those features, PackageDB and the effort made for it previously would be rendered of no-use (or perhaps thats what one of MyFedora's goal - to obsolete packagedb ) ..
I agree with you. IMHO, need to use as a basis packagedb (revamp the UI, add more features, etc). Make it pretty and convenient for users.
I've clarified the Package WebUI idea a bit [1]_
Basically, the data is going to need to reside in the PackageDB. MyFedora may choose to pull that information out as raw data or as an import of the PackageDB UI. We'll have to evaluate that later. the focus of this particular project would be to provide a task or application oriented interface to the information in rpms. This will require a fair bit of additional db schema as the current schema is oriented towards packages and we'll want to pull information about programs, libraries, etc out of the packages.
There are other possible projects revolving around the packagedb and myfedora. For instance, the PackageDB UI is in desperate need of a clean up (the present UI is what I threw together to make the intial release.) If someone wanted to take the time to mockup a new UI and implement the html templates/javascript functions to make it work, that would be a much needed project as well.
.. _[1]: http://fedoraproject.org/wiki/SummerCoding/2008/Ideas#head-fc035207c713afb64...
-Toshio
Toshio Kuratomi wrote:
Pavel Khardikov wrote:
Izhar Firdaus wrote:
Same goes for me, but looking Mockups, It looks a lot like PackageDB, but with an improved UI .. so, in my mind, rather than making MyFedora take PackageDB's ( http://admin.fedoraproject.org/pkgdb | https://fedorahosted.org/packagedb/ ) work, why dont extend PackageDB? .. PackageDB code is already out there .. revamp the UI, add more features .. I used the name "PackageWebUI" was because thats the title in the Fedora GSOC Idea page .. but I would prefer an approach of improving pkgdb rather than writing a new one..
my.fedoraproject.org / MyFedora - the name sounds more like a Fedora AIO to me, and thats also what i understand from
"my.fedoraproject.org is a project to integrate all of the Fedora infrastructure in one place. The goal is to create a modular web page in which each module would pull views from the various Fedora resources and display them to the user.",
and one of those modules, could be an integration to PkgDB/PackageWebUI .. Unix philosophy: "Write programs that do one thing and do it well." .. PkgDB focuses on packages, MyFedora focuses on integrating the rest of Fedora infrastructure. Of course, provide a way for all of them to communicate with each other (JSON,XMLRPC,whatever).
Or do J5 have different view about this?, both idea ( improve MyFedora / improve PackageDB ) sounds okay to me, just that I feel that if MyFedora implements those features, PackageDB and the effort made for it previously would be rendered of no-use (or perhaps thats what one of MyFedora's goal - to obsolete packagedb ) ..
I agree with you. IMHO, need to use as a basis packagedb (revamp the UI, add more features, etc). Make it pretty and convenient for users.
I've clarified the Package WebUI idea a bit [1]_
Basically, the data is going to need to reside in the PackageDB. MyFedora may choose to pull that information out as raw data or as an import of the PackageDB UI. We'll have to evaluate that later. the focus of this particular project would be to provide a task or application oriented interface to the information in rpms. This will require a fair bit of additional db schema as the current schema is oriented towards packages and we'll want to pull information about programs, libraries, etc out of the packages.
There are other possible projects revolving around the packagedb and myfedora. For instance, the PackageDB UI is in desperate need of a clean up (the present UI is what I threw together to make the intial release.) If someone wanted to take the time to mockup a new UI and implement the html templates/javascript functions to make it work, that would be a much needed project as well.
.. _[1]: http://fedoraproject.org/wiki/SummerCoding/2008/Ideas#head-fc035207c713afb64...
-Toshio
I thought to realize exactly these functions of Package WebUI project from the very begining as the idea for GSoC. But unfortunately there is no time till deadline for presenting applications :-( I wish I had a chance to do UI for package WebUI pretty, convinient and clear for everyone.
Pavel Khardikov wrote:
Toshio Kuratomi wrote:
Pavel Khardikov wrote:
Izhar Firdaus wrote:
Same goes for me, but looking Mockups, It looks a lot like PackageDB, but with an improved UI .. so, in my mind, rather than making MyFedora take PackageDB's ( http://admin.fedoraproject.org/pkgdb | https://fedorahosted.org/packagedb/ ) work, why dont extend PackageDB? .. PackageDB code is already out there .. revamp the UI, add more features .. I used the name "PackageWebUI" was because thats the title in the Fedora GSOC Idea page .. but I would prefer an approach of improving pkgdb rather than writing a new one..
my.fedoraproject.org / MyFedora - the name sounds more like a Fedora AIO to me, and thats also what i understand from
"my.fedoraproject.org is a project to integrate all of the Fedora infrastructure in one place. The goal is to create a modular web page in which each module would pull views from the various Fedora resources and display them to the user.",
and one of those modules, could be an integration to PkgDB/PackageWebUI .. Unix philosophy: "Write programs that do one thing and do it well." .. PkgDB focuses on packages, MyFedora focuses on integrating the rest of Fedora infrastructure. Of course, provide a way for all of them to communicate with each other (JSON,XMLRPC,whatever).
Or do J5 have different view about this?, both idea ( improve MyFedora / improve PackageDB ) sounds okay to me, just that I feel that if MyFedora implements those features, PackageDB and the effort made for it previously would be rendered of no-use (or perhaps thats what one of MyFedora's goal - to obsolete packagedb ) ..
I agree with you. IMHO, need to use as a basis packagedb (revamp the UI, add more features, etc). Make it pretty and convenient for users.
I've clarified the Package WebUI idea a bit [1]_
Basically, the data is going to need to reside in the PackageDB. MyFedora may choose to pull that information out as raw data or as an import of the PackageDB UI. We'll have to evaluate that later. the focus of this particular project would be to provide a task or application oriented interface to the information in rpms. This will require a fair bit of additional db schema as the current schema is oriented towards packages and we'll want to pull information about programs, libraries, etc out of the packages.
There are other possible projects revolving around the packagedb and myfedora. For instance, the PackageDB UI is in desperate need of a clean up (the present UI is what I threw together to make the intial release.) If someone wanted to take the time to mockup a new UI and implement the html templates/javascript functions to make it work, that would be a much needed project as well.
.. _[1]: http://fedoraproject.org/wiki/SummerCoding/2008/Ideas#head-fc035207c713afb64...
-Toshio
I thought to realize exactly these functions of Package WebUI project from the very begining as the idea for GSoC. But unfortunately there is no time till deadline for presenting applications :-( I wish I had a chance to do UI for package WebUI pretty, convinient and clear for everyone.
Be careful what you wish for :-) ''' The new deadline for student applications is Monday, April 7, 2008. Please see the revised program timeline for full details on the updated Google Summer of Code 2008 schedule. ''' http://code.google.com/soc/2008/
-Toshio
On Sat, 2008-03-29 at 19:10 +0800, Izhar Firdaus wrote:
On Sat, Mar 29, 2008 at 6:33 PM, Pavel Khardikov sonic@inetwork.ru wrote:
Hello, Izhar!
Excuse me for not writting in this list for long time.
I still have a great interest in Fedora and GSoC projects in particular.
At one of my first letters Thorsten Leemhuis replied:
"No idea - as I said, I just added the idea to the wiki. I have no ideas nor skills how to actually realize the WebUI, thus I don't think I can mentor this idea further and * * I don't have the time or interest for it. Sorry. "
and
"I'd suggest you contact J5, the developer of MyFedora. Maybe he can help to answer the question if a separate WebUI makes sense (which I doubt). "
As I understood there is no sence to create another project that performs the same tasks and functions as MyFedora.
Same goes for me, but looking Mockups, It looks a lot like PackageDB, but with an improved UI .. so, in my mind, rather than making MyFedora take PackageDB's ( http://admin.fedoraproject.org/pkgdb | https://fedorahosted.org/packagedb/ ) work, why dont extend PackageDB? .. PackageDB code is already out there .. revamp the UI, add more features .. I used the name "PackageWebUI" was because thats the title in the Fedora GSOC Idea page .. but I would prefer an approach of improving pkgdb rather than writing a new one..
my.fedoraproject.org / MyFedora - the name sounds more like a Fedora AIO to me, and thats also what i understand from
"my.fedoraproject.org is a project to integrate all of the Fedora infrastructure in one place. The goal is to create a modular web page in which each module would pull views from the various Fedora resources and display them to the user.",
and one of those modules, could be an integration to PkgDB/PackageWebUI .. Unix philosophy: "Write programs that do one thing and do it well." .. PkgDB focuses on packages, MyFedora focuses on integrating the rest of Fedora infrastructure. Of course, provide a way for all of them to communicate with each other (JSON,XMLRPC,whatever).
Or do J5 have different view about this?, both idea ( improve MyFedora / improve PackageDB ) sounds okay to me, just that I feel that if MyFedora implements those features, PackageDB and the effort made for it previously would be rendered of no-use (or perhaps thats what one of MyFedora's goal - to obsolete packagedb ) ..
There is a balance here. For everything I have to pull from there is a cost in terms of calls I have to make to different backends per page along with the extra work to recreate the GUI for each module. The different backends are taking a tools centric approach to manipulating data where as My Fedora takes a more data centric approach (here is the data how would I like to manipulate and display). I agree the data side of it should be part of PackageDB but unless someone really wants to work on a separate PackageDB UI I would just have that be a simple dump of the database in a slightly nicer form.
In any case my thoughts on the subject are logged somewhere else in the thread where I talk about Apps vs. Packages and how a separate app would look different from a My Fedora app. Read there.
On Sat, Mar 29, 2008 at 9:01 PM, John (J5) Palmieri johnp@redhat.com wrote
Or do J5 have different view about this?, both idea ( improve MyFedora / improve PackageDB ) sounds okay to me, just that I feel that if MyFedora implements those features, PackageDB and the effort made for it previously would be rendered of no-use (or perhaps thats what one of MyFedora's goal - to obsolete packagedb ) ..
There is a balance here. For everything I have to pull from there is a cost in terms of calls I have to make to different backends per page along with the extra work to recreate the GUI for each module. The different backends are taking a tools centric approach to manipulating data where as My Fedora takes a more data centric approach (here is the data how would I like to manipulate and display). I agree the data side
In other words, instead of calling interfaces provided by these backends (which is, obviously, more costly) , MyFedora will be directly access the databases and manipulate the data to be in a more user-centric and useful views (am I right?).
of it should be part of PackageDB but unless someone really wants to work on a separate PackageDB UI I would just have that be a simple dump of the database in a slightly nicer form.
In any case my thoughts on the subject are logged somewhere else in the thread where I talk about Apps vs. Packages and how a separate app would look different from a My Fedora app. Read there.
I couldnt find the thread, is it in this list or another list?. iirc i've read it before. an App may have multiple Packages.
--
John (J5) Palmieri johnp@redhat.com
On Sat, 2008-03-29 at 22:44 +0800, Izhar Firdaus wrote:
On Sat, Mar 29, 2008 at 9:01 PM, John (J5) Palmieri johnp@redhat.com wrote
Or do J5 have different view about this?, both idea ( improve MyFedora / improve PackageDB ) sounds okay to me, just that I feel that if MyFedora implements those features, PackageDB and the effort made for it previously would be rendered of no-use (or perhaps thats what one of MyFedora's goal - to obsolete packagedb ) ..
There is a balance here. For everything I have to pull from there is a cost in terms of calls I have to make to different backends per page along with the extra work to recreate the GUI for each module. The different backends are taking a tools centric approach to manipulating data where as My Fedora takes a more data centric approach (here is the data how would I like to manipulate and display). I agree the data side
In other words, instead of calling interfaces provided by these backends (which is, obviously, more costly) , MyFedora will be directly access the databases and manipulate the data to be in a more user-centric and useful views (am I right?).
I generally do not want to talk to a DB directly though if performance becomes an issue I might have to. Generally it goes
MyFedora <-json-> mfquery proxy <-json/xmlrpc etc.-> Fedora Resource <-db connection-> DB.
The proxy is there so I can call async via JavaScript so the only thing one would gain from a direct DB connection is to get rid of the HTTP connection to the fedora resource but then you lose any of the business logic above and beyond the actual data. For instance I just added optional functionality to the 'list' call in bodhi to check every release request in the list and flag if the logged in user is allowed to modify the request. I could have done that as a separate check in MyFedora but it would take longer and I would have to replicate the logic for determining if a user is allowed to modify. If it changed in bodhi MyFedora would be out of sync and the user would be presented with inconstant UI.
of it should be part of PackageDB but unless someone really wants to work on a separate PackageDB UI I would just have that be a simple dump of the database in a slightly nicer form.
In any case my thoughts on the subject are logged somewhere else in the thread where I talk about Apps vs. Packages and how a separate app would look different from a My Fedora app. Read there.
I couldnt find the thread, is it in this list or another list?. iirc i've read it before. an App may have multiple Packages.
It is in the same thread:
https://www.redhat.com/archives/fedora-devel-list/2008-March/msg02528.html
Read to the end of that thread as there are more tidbits there.
John (J5) Palmieri wrote:
I agree the data side In other words, instead of calling interfaces provided by these backends (which is, obviously, more costly) , MyFedora will be directly access the databases and manipulate the data to be in a more user-centric and useful views (am I right?).
I generally do not want to talk to a DB directly though if performance becomes an issue I might have to. Generally it goes
MyFedora <-json-> mfquery proxy <-json/xmlrpc etc.-> Fedora Resource <-db connection-> DB.
The proxy is there so I can call async via JavaScript so the only thing one would gain from a direct DB connection is to get rid of the HTTP connection to the fedora resource but then you lose any of the business logic above and beyond the actual data.
Why not throw in a hook to use memcached (http://www.danga.com/memcached/) in front the DB queries? Then if you have performance/scaling problems you just add more cache.
Do you all want me to upgrade my initial "mockup" with more options or not? I kinda know what i want to have in it and i know what should get in (nearly everything that we know of the rpm).... i think it's mainly the sidebar (or whereever it's gonna be placed) that really mather s in a possible new version.
On Sat, Mar 29, 2008 at 11:50 PM, John (J5) Palmieri johnp@redhat.com wrote:
On Sat, 2008-03-29 at 22:44 +0800, Izhar Firdaus wrote:
On Sat, Mar 29, 2008 at 9:01 PM, John (J5) Palmieri johnp@redhat.com wrote
Or do J5 have different view about this?, both idea ( improve MyFedora / improve PackageDB ) sounds okay to me, just that I feel that if MyFedora implements those features, PackageDB and the effort made for it previously would be rendered of no-use (or perhaps thats what one of MyFedora's goal - to obsolete packagedb ) ..
There is a balance here. For everything I have to pull from there is a cost in terms of calls I have to make to different backends per page along with the extra work to recreate the GUI for each module. The different backends are taking a tools centric approach to manipulating data where as My Fedora takes a more data centric approach (here is the data how would I like to manipulate and display). I agree the data side
In other words, instead of calling interfaces provided by these backends (which is, obviously, more costly) , MyFedora will be directly access the databases and manipulate the data to be in a more user-centric and useful views (am I right?).
I generally do not want to talk to a DB directly though if performance becomes an issue I might have to. Generally it goes
MyFedora <-json-> mfquery proxy <-json/xmlrpc etc.-> Fedora Resource <-db connection-> DB.
MyFedora but it would take longer and I would have to replicate the logic for determining if a user is allowed to modify. If it changed in bodhi MyFedora would be out of sync and the user would be presented with inconstant UI.
of it should be part of PackageDB but unless someone really wants to work on a separate PackageDB UI I would just have that be a simple dump of the database in a slightly nicer form.
In your opinion, which would be better? a project which adds value to PackageDB or a project which focuses on the PackageDB related integration with MyFedora ?
Izhar Firdaus wrote:
On Sat, Mar 29, 2008 at 11:50 PM, John (J5) Palmieri johnp@redhat.com wrote:
On Sat, 2008-03-29 at 22:44 +0800, Izhar Firdaus wrote:
On Sat, Mar 29, 2008 at 9:01 PM, John (J5) Palmieri johnp@redhat.com wrote
Or do J5 have different view about this?, both idea ( improve MyFedora / improve PackageDB ) sounds okay to me, just that I feel that if MyFedora implements those features, PackageDB and the effort made for it previously would be rendered of no-use (or perhaps thats what one of MyFedora's goal - to obsolete packagedb ) ..
There is a balance here. For everything I have to pull from there is a cost in terms of calls I have to make to different backends per page along with the extra work to recreate the GUI for each module. The different backends are taking a tools centric approach to manipulating data where as My Fedora takes a more data centric approach (here is the data how would I like to manipulate and display). I agree the data side
In other words, instead of calling interfaces provided by these backends (which is, obviously, more costly) , MyFedora will be directly access the databases and manipulate the data to be in a more user-centric and useful views (am I right?).
I generally do not want to talk to a DB directly though if performance becomes an issue I might have to. Generally it goes
MyFedora <-json-> mfquery proxy <-json/xmlrpc etc.-> Fedora Resource <-db connection-> DB.
MyFedora but it would take longer and I would have to replicate the logic for determining if a user is allowed to modify. If it changed in bodhi MyFedora would be out of sync and the user would be presented with inconstant UI.
of it should be part of PackageDB but unless someone really wants to work on a separate PackageDB UI I would just have that be a simple dump of the database in a slightly nicer form.
In your opinion, which would be better? a project which adds value to PackageDB or a project which focuses on the PackageDB related integration with MyFedora ?
PackageDB.
But I'm the packagedb author :-)
My reasoning is that what we need to do centers around getting the data from the rpms and users into a database. MyFedora may pull that information as raw data or it may directly import the interface that the packagedb provides but that data belongs in the packagedb. So that's the more important area.
Also, some of the rewriting of the PakcageDB UI that MyFedora might want to do should be done in the PackageDB instead. The current UI could really do with a user interface designer's criticism nad mockups to make it better.
-Toshio
On Fri, 2008-03-28 at 17:01 +0800, Izhar Firdaus wrote:
eh? .. hughsient already started doing the feature? ..
Nope, it was throwaway prototype code.
he put that in the GSOC idea page, and it looks like he started it earlier before gsoc is even started .. lol http://fedoraproject.org/wiki/SummerCoding/2008/Ideas#head-4ac0b11e181e6e309...
No, I did some throwaway code, that we decided probably wasn't the right way to do it, nothing went into git. My blog was mainly showing people the _effect_ and interactions I wanted, not the implementation.
Richard.
-
Alex Lancaster -
Arthur Pemberton -
Callum Lerwick -
John (J5) Palmieri -
Les Mikesell -
Mark -
Mohd Izhar Firdaus Ismail -
Pavel Khardikov -
Rahul Sundaram -
Richard Hughes -
Thorsten Leemhuis -
Toshio Kuratomi