IRC channel
by Yaakov Nemoy
Hey List,
I've registered #ekg (freenode), if we should want it to be
#fedora-ekg, or we can't legitimately use 'ekg', so it should be
##ekg, let me know.
-Yaakov
15 years, 1 month
This project for GSOC?
by Michael DeHaan
This seems to be a simple one to get some help with.
I was looking to mentor Cobbler and am probably not the best fit (still
distracted), but I think we should propose it.
The code base is small and has /lots/ of places it can go, which are, I
believe, excellent signs it can be a huge success.
--Michael
15 years, 2 months
current priorities, from my perspective
by Max Spevack
Thanks to Yaakov's efforts, I have the milestones and the data that I
needed for this week. The next big milestone, from a Red Hat point of
view, is next Wednesday (March 25th), at which point I will definitely
need to be able to get statistics out of the Red Hat mailman instance,
which we know is a bit buggy still.
Interested to hear your thoughts on these requests Yaakov, given the
25th as the next big milestone date.
>From my POV, here are the priorities:
(1) Getting a successful run of EKG with the following config:
[lists]
cobbler = fhmailman
cobbler-devel = fhmailman
ekg = fhmailman
rel-eng = fpmailman
genome-list = rhmailman
ovirt-devel = rhmailman
freeipa-devel = rhmailman
freeipa-users = rhmailman
spacewalk-list = rhmailman
spacewalk-devel = rhmailman
fedora-devel-list = rhmailman
thincrust-devel = rhmailman
func-list = rhmailman
epel-devel-list = rhmailman
fpmailman and fhmailman are working perfectly. rhmailman still has some
bugs.
(2) A few minor cosmetic enhancements to the output page.
For each month/quarter/year:
a. In addition to the domain totals & deltas, sum the total messages
and total delta.
b. Show a "inside RH/outside RH" subtotal, where "inside RH" is defined
for now as @redhat.com or @jboss.com, but is extensible in such a way
that we can say "these domains should be grouped together and given a
certain tag" for any set of domains that we want.
--Max
15 years, 2 months
Preferences on best ways to generate HTML
by Yaakov Nemoy
Hey List,
Quick question, of these two possibilities, which design methodology do you prefer? I'm asking this because i want to know what kind of code you want to see yourself.
1) We generate HTML using some form of code generation techniques, using an object oriented library that spits out html fragments that can be validated and put together using python code. This falls under the Object-Proxy design pattern.
2) We use XML templates that can be transformed using xslt or python into xhtml or html, this is akin to what we do in turbo gears, and i'll probably use genshi since that is well known by our websites team. This is the MVC design pattern.
Remember, both are 'correct' but i don't think this will turn into a bikeshed argument. I'm just looking for opinions from you all on what you prefer.
For my recreation of v2 in v3, i'm gonna use expensive string manipulations, simply to have something deliverable, but switching will not be difficult once i decide which pattern to use.
Looking forward to your input.
-Yaakov
15 years, 2 months
Status 2009.03.13
by Yaakov Nemoy
Happy Friday the Thirteenth,
After being caught in the perfectionists dillemma, (do you develop something that works perfectly or is designed perfectly?), i have a working scanner. I originally opted for designed perfectly, because version 3 is not meant to be a prototype anymore. As a result, i had some subtle issues with some multiclass inheritance, and then dealing with too much automagic in regards to SQLAlchemy. I can honestly say though, that the scanner is working now, with reasonable success, and is very extensible. At some point i'll have to document this.
If you're feeling adventurous, have a look. Meanwhile, i'm going to spend the rest of the afternoon having a stab at the rest of the deliverables i promised Max over my spring break.
Beware of Pi on the Ides of March,
-Yaakov
15 years, 2 months
Looking more at GitHub graphs -- they're jQuery -- let's do this (for mailing lists)
by Michael DeHaan
So I was looking a bit deeper. This stuff is jQuery!
Unfortunately, it's compressed up -- maybe someone can find the
uncompressed version.
Here's a slightly modified version that someone made though, which isn't.
http://dmitry.baranovskiy.com/work/github/
http://dmitry.baranovskiy.com/work/github/impact-code.js
It looks like we can use the same engine to show our listsas they change
over time.
So instead of the "pac man" graph in slices (one pacman per quarter),
show the stack as it drifts left to right and we watch domains wax and
wane.
Snapshots are still important for numerical reports, but aren't /as/
import for visualization, and it may be easier to spot trends -- is this
one domain cyclical in contribution or constant? Do users contribute
continuously or come and go for this project?
The one thing we'd want to do is make sure the same domains always
recieved the same colors, but other than that, I think this is beautiful.
--Michael
15 years, 2 months
Github "impact" graphs
by Michael DeHaan
I think these are some very interesting visualizations, though obviously
they are only mining commit data, not patch data, which doesn't account
for all the contributors in many instances.
See examples:
http://github.com/mpdehaan/cobbler/graphs/impact
http://github.com/mpdehaan/func/graphs/impact
You can see Func had some initial collaboration that was interesting and
then a spurt during Google Summer of Code.
Cobbler's really only gotten a good spurt over the last year, but is
shifting to at least 50% outside contribution. (A /ton/ of outside
patches happened via me applying them though)
While this data is skewed from only tracking things with git
attribution, increasingly though, more contributors
everywhere are using github, leading to better data.
The reason I brought this up is that this widget could be a very
interesting way to prevent list activity over time -- and maybe we can
borrow from the idea.
--Michael
15 years, 2 months