Questions for a FAQ
by Seth Vidal
These are questions - not so much on answers, though:
- where do I get the pkgs to start working
tg2.repo from fpeople site
- what do I install?
yum install moksha
yum install python-tg-devtools-2.0-9.fc11.noarch
yum update #to make sure you have the latest bits in f11 otherwise
you'll get dep errors on:
python-simplejson, python-formencode, python-paste-deploy
- Is there any example code?
.....
- How do I start up a local instance of fcomm so I can test?
- git clone git://git.fedorahosted.org/fedoracommunity.git
- cd to fedoracommunity
- python setup.py egg_info
- paster serve development.ini
- now you'll have an instance of fcomm running on port 8080 of localhost
- I get a bunch of dep errors, how do I fix them?
- see above about what to install
- how do I start a simple app?
...
- how do I start a simple widget?
...
- do I have to put my app in the fcomm pkg in order for it to work/be
tested?
...
- once I have an app can I pkg it up as a separate pkg and just have it
require fcomm == someversion or do I have to submit it as a patch to
fcomm?
...
- Is there a good way to communicate with other apps/widgets?
...
- if I want to get data from another site - which connector routines
should I use?
...
- is there a simple place to cache/stash data for future use?
...
that's what I have to start with. More questions as I have them.
-sv
14 years, 7 months
Status Report for week of Aug 17th.
by John (J5) Palmieri
Since I am heading to Vegas tomorrow morning I'm sending in my status early.
* Worked on automating AMQP parsing from the XML spec file
* Got it parsing full frames and control payloads correctly
* Most basic types handled
* some complex types (enough to handle the 'start' control) handled
* full infrastructure for parsing all relevant info in specs along with initial support for multiple wire format versions (only supporting 0.10 but will be easy to add > 0.10 while still supporting 0.10 in future)
* some of the generated code needs some restructuring but that is incremental
* encoding support added but not tested
* will release code once I have encoded the 'start-ok' control (code is there but some types need encode rules) and I have time to write a README to get the test env up and running - most likely done early on Monday
* once I have an encoded frame it should be a matter of implementing the rest of the types and writing higher level flow control classes for the library to start being useful. QMF should be able to be handled similarly.
--
John (J5) Palmieri
Software Engineer
Red Hat, Inc.
14 years, 8 months
Usability Test Tasks - First Draft
by Máirín Duffy
Hi!
I've got some equipment ordered so we can do some proper video-based
usability tests of Fedora Community. In preparation, I've put together
an initial stab at a task list for the usability tests. Since I think we
want to capture the breadth of the site, but we also don't want to scare
our testers away from ever helping us out again by taking up too much of
their time, I put together two sets of tasks to assign to testers - 5
tasks per set. They shouldn't take any more than 20 minutes to run
through. I think if we could get at least 5 testers per task set we'd be
in good shape.
I also tacked on some introductory questions so we could get a feel for
the tester's previous Fedora Community experience or their initial
impressions of the site. There's also a set of closing discussion
questions to get the tester's feel for the site after running through
the tasks.
What do you think? Am I missing any essential functionality coverage
with these tasks? Is the balance between the two task sets fair? (I
tried to start both sets off with easier/quicker tasks and balance the
number of more involved tasks per each.)
~m
Test Requirements:
• Users must have an FAS account. Or we need to set up a test account so
they can view the people search portions of the site and so the package
maintenance sections of the site are meaningful. (If they own 0 packages
we'll not be able to test some of the core functionality I think we want
to.)
• Package portions of the test are going to be way more useful if we
have package maintainers as test users.
Introduction / First Impressions (All questions on front page)
• Have you seen this site before?
∘ (If yes) Where did you hear about it?
• Have you used this site before? If so, what have you used it for?
∘ (If yes) How did that go?
∘ (If yes) How often have you used this site?
• What are your first impressions, looking at this site now?
• What do you think this site is?
• What would you click on first?
• Any other comments you'd like to make about this site?
• What do you think of this page? Where would you click first?
TASK SET I
People
1) View your profile on this site. What do you think about it?
∘ Is the information accurate? Do your group memberships seem accurate?
Do your package affiliations seem accurate?
2) You've just spoken with Dennis Gilmore and he's asked you to open a
ticket for him in a fedorahosted.org trac instance. In order to cc
Dennis on the ticket, you'll need to figure out his FAS account name.
Where would you go to look it up?
Packages
3) Do you have any unpushed updates? Where would you go to look this up?
4) How are your builds doing? Where would you go to look this up?
5) Let's say you have a friend who is a little bit behind the times -
she is running Fedora 9. There's an annoying Inkscape bug that bothers
her - after searching the internet for a bit you found out the bug is
fixed in Inkscape version 0.47.
∘ Is Inkscape version 0.47 available in Fedora 9 for your friend?
∘ If Inkscape version 0.47 is not available for Fedora 9, can you
download an SRPM here to build it for her?
TASK SET II
People
1) You need help with yelp. Who's the package maintainer?
2) Luke Macken is going away on vacation for a couple of weeks and he's
asked you to look over his packages while he's gone. How many packages
does he have, and do any of them need attention? Where would you go to
look this up?
Packages
3) How would you file a bug against NetworkManager using this system?
4) What has changed in the 'ruby' package over the last few updates?
Where would you go to look this up?
5) How's the karma of your current testing updates doing? How would you
check up on this in Fedora Community?
Closing
• How well does Fedora Community support your package maintenance
workflow?
• Would you use Fedora Community to help maintain your packages? Which
parts?
• Is there any essential functionality missing from Fedora Community
that would help you maintain your packages more easily?
• Did you learn anything about Fedora Community's functionality through
this test?
• What do you think is the most useful function of Fedora Community?
• What are the least useful functions of Fedora Community?
Rejected Tasks (I came up with these but decided they were less
important than the ones I selected)
• How many bugs are open against python right now?
• You just found out from an artist friend that there's a handful of
supplemental plugin packages for the Gimp that let you do cool things.
Look them up - what are they?
• You see someone in freenode IRC with the nickname 'halfline' and
you're not sure what his/her real name is. Can you try looking it up
here?
• You'd like to meet with Kushal Das to discuss one of his packages, but
he's in a different time zone so you're not sure when would be a
reasonable time. Can you figure out your time difference with him and
work out a good time to propose a meeting with him on IRC?
14 years, 8 months
Moksha/Fedora Community Planning Meetings
by Tom Callaway
The Fedora Community (and Moksha) efforts have a regular public meeting
at 1400 UTC every Monday. We invite interested parties to participate in
our meeting.
You can join our meeting via Fedora Talk, extension 2001. For more
information about Fedora Talk, see:
http://talk.fedoraproject.org/
Our next meeting will be on Monday, August 24, 2009.
Thanks,
~spot
14 years, 8 months
Status report
by John (J5) Palmieri
* Been mostly working on the messaging infrastructure bits
* Drafted proposal for messaging sig at https://fedoraproject.org/wiki/Messaging_SIG/PublishSubscribeNotification...
* researched qpid components
* researched qmf framework
* Setup a proof of concept prototype environment on local machine - will get into a source repo once I have handshaking down
* Got amqp messages forwarding from one domain to another
* Got qmf object communicating to a client
* halfway got qmf objects forwarding from one domain to another
* I have a workaround
* Full feature won't be in until the next qpid release but workaround is good enough for now
* Setup Orbited to AMQP forwarding though the Fedora Community security domain (prototype environment)
* Started writing AMQP JavaScript client library
* Wrote bit manipulation classes
* Completed stage 1 of handshake
* Fully decoded server response (server capability negotiations)
* looking into writing a code generator for decoding/encoding the rest of the frames
* Wrote JavaScript socket monitoring utility
* decodes messages sent and received into a interactive hex dump for analyzing the wire protocol in conjunction with the specification
* Working on some of Paul's content management javascript licensing issues.
--
John (J5) Palmieri
Software Engineer
Red Hat, Inc.
14 years, 8 months
Re: python workflow modules
by John (J5) Palmieri
Have you looked at JBoss jBPM? http://www.jboss.com/products/jbpm/
What we want for our workflow is an independent service that we can setup workflow rules and have moksha simply update the service when a user completes a task.
----- "Seth Vidal" <skvidal(a)fedoraproject.org> wrote:
> On Tue, 11 Aug 2009, Seth Vidal wrote:
>
> > Yesterday at the phone call for fedora community I was asked to look
> at
> > various free python workflow modules - I found 3 that seemed
> > likely/reasonable and wrote a brief bit about them based on the
> available
> > info and a perusal of their source.
> >
> >
> > goflow - django based - free -not helpful for moksha other than to
> steal
> > code from - but it seems to be fairly well developed and on-target
> >
> > http://code.djangoproject.com/wiki/GoFlow
> > and
> > http://goflow.free.fr/doc/html/overview.html#preface
> >
> >
> > itools-workflow -document/file based workflow - simple scaffold -
> > expanding it shouldn't be too complicated at all. - gplv3
> >
> http://git.hforge.org/?p=itools.git;a=tree;f=workflow;h=a7ac74ccd80d2810b...
> >
> >
> > ruffus - mit license
> > http://code.google.com/p/ruffus/ - originally for bioinformatics -
> simple
> > structure - might be a bit too simple... - has no mechanism for
> remote
> > communication currently... - could be good - lots of room to amqp
> this -
> > could be bad - no structure to allow for it.
> >
> >
> > Goflow seems the best from a target standpoint but I think porting
> it over
> > to a tg2-infrastructure would be a fair bit of work.
> >
> > itools is extremely simple and is more or less a document/file
> state
> > machine.
> >
> > ruffus has a language and ordering/dependency information to
> control
> > workflow and could be a good place to base from.
> >
> >
> > I'm a little blurry on what moksha/fcomm's workflow requirements are
> - is
> > it activity or entity based most particularly and does it require
> remote
> > host jobs? I suspect it does require communication to tasks on
> other
> > systems but I figured I'd ask.
> >
>
> There are a number of other workflow modules but the ones I've not
> mentioned here were:
>
> 1. not free
> 2. dead projects
> 3. VERY closely tied to a specific queuing/task system normally for
> chemical processing or bioinformatics.
>
> -sv
>
> _______________________________________________
> moksha mailing list
> moksha(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/moksha
--
--
John (J5) Palmieri
Software Engineer
Red Hat, Inc.
14 years, 8 months
python workflow modules
by Seth Vidal
Yesterday at the phone call for fedora community I was asked to look at
various free python workflow modules - I found 3 that seemed
likely/reasonable and wrote a brief bit about them based on the available
info and a perusal of their source.
goflow - django based - free -not helpful for moksha other than to steal
code from - but it seems to be fairly well developed and on-target
http://code.djangoproject.com/wiki/GoFlow
and
http://goflow.free.fr/doc/html/overview.html#preface
itools-workflow -document/file based workflow - simple scaffold -
expanding it shouldn't be too complicated at all. - gplv3
http://git.hforge.org/?p=itools.git;a=tree;f=workflow;h=a7ac74ccd80d2810b...
ruffus - mit license
http://code.google.com/p/ruffus/ - originally for bioinformatics - simple
structure - might be a bit too simple... - has no mechanism for remote
communication currently... - could be good - lots of room to amqp this -
could be bad - no structure to allow for it.
Goflow seems the best from a target standpoint but I think porting it over
to a tg2-infrastructure would be a fair bit of work.
itools is extremely simple and is more or less a document/file state
machine.
ruffus has a language and ordering/dependency information to control
workflow and could be a good place to base from.
I'm a little blurry on what moksha/fcomm's workflow requirements are - is
it activity or entity based most particularly and does it require remote
host jobs? I suspect it does require communication to tasks on other
systems but I figured I'd ask.
-sv
14 years, 8 months
moksha.csh.rit.edu
by Luke Macken
Hey all,
Over the weekend I migrated the Moksha demo dashboard from my personal
Linode over to a Xen guest on a server on Computer Science House @ RIT.
http://moksha.csh.rit.edu
Let me know if you notice any issues.
Cheers,
luke
14 years, 8 months
New moksha.apps layout
by Luke Macken
Hey all,
So I recently started pulling out a lot of the "features" that I
initially added to Moksha into seperate isolated "apps" that can easily
be packaged up and installed seperately. The goal of this was to not
only slim down the "core" of Moksha, but to also figure out how we want
our basic skeleton apps to look.
>From here, I will be working on a quickstart template that will allow
people to run one command and have it spit out a basic Hello World-ish
Moksha app that can easily integrate with an existing TG2/Moksha/FComm
instance, or be run in isolation.
You can see the new `moksha.apps` module here:
https://fedorahosted.org/moksha/browser/moksha/apps
One of the more solid examples of the app layout is the moksha.metrics
app, which can be found here:
https://fedorahosted.org/moksha/browser/moksha/apps/metrics
The core of an 'app' is it's pavement.py file, which uses Paver (as
opposed to the old school setup.py setuptools method). Here is what the
metrics pavement.py looks like:
https://fedorahosted.org/moksha/browser/moksha/apps/metrics/pavement.py
As you can see at the top, it pulls in moksha.lib.paver_tasks, which
contains a few helper methods that I created to easily generate an RPM
for an app, and install it. This will allow us to easily script tedious
tasks that can be shared across all apps.
https://fedorahosted.org/moksha/browser/moksha/lib/paver_tasks.py
Once a user spits out a new app, they can run `paver rpm`, and spit out
an RPM of their application. This has been working great for me so far.
So, I'm open to comments, criticisms, suggestions to this new layout.
So far, I find it to be extremely modular and fairly clean, and using
Paver will allow us to make it extremely simple to work with the apps.
I'm hoping to hack out the app quickstart template along with some HOWTO
documentation this week, so please chime in if you have any suggestions.
Cheers,
luke
14 years, 8 months
