Brainstorming tasks for next sprint

Jason Guiditta jguiditt at redhat.com
Tue Feb 14 15:46:24 UTC 2012


On 13/02/12 16:06 -0500, Matt Wagner wrote:
>Hi all,
>
>As we start to wrap up bug-fixing, I was hoping to get a conversation
>going about what we need to tackle in upcoming sprints.
>
>What else do you think we should try to focus on?
>
>-- Matt
>

Another thing we should really get designed and buttoned up is
security.  Mo has a page up with a list of TODOs on the wiki[1], and I
added provider credential encryption.  I don't have a string opinion
right now how to encrypt those credentials, but it needs to be really
secure, which it currently falls very short on, imo.

In the theme of my 'incubator' idea, I think we should consider moving
the site (or perhaps just portions of it) to openshift[2].  This would
allow us to potnetially do some really cool stuff, and build out the
site to be much more dynamic.  Of course, this would require some
coordination with those doing 'official' documentation, like jclift,
but we can probably sandbox that somewhat, and make it easier at the
same time for more of the team to contribute to site updates and new
features there.  We could host an official project blog (like matty
suggested recently), have better integration with things like
twitter/identica, facebook(?), and any other social media.  Project
planning (redmine or some future system we chose/build) and more
community-oriented features could go there as well.

Better patch management than just sending to list.  This is a _very_
long-standing issue that we need to attempt (again) to resolve.  I am
not against trying pull requests in github (probably on some trial
basis, with a small group vetting it and assembling feedback, so as to
not throw everybody off on something we may or may not keep).  There
are also a number of other projects around for this kind of thing that
we could pilot - patchwork and gerrit in the public space, and our own
(not the best name) trapaas, that resulted from some work mzatko did
for me when he was an intern (think the code is on github, not sure in
what state).  I am sure there are plenty of other options we coudl
consider, these are just a couple I remember from last tiem I looked
at this problem.  But the fact remains - the list is a poor patch
management tool, and is insufficient for our needs.

-j


[1]
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Hardening_the_app
[2] https://openshift.redhat.com



More information about the aeolus-devel mailing list