2014 dreaming

[Paul W. Frields]

On Wed, Jan 08, 2014 at 07:10:43PM +0100, Pierre-Yves Chibon wrote:
> On Thu, Dec 19, 2013 at 02:16:31PM -0700, Kevin Fenzi wrote:
> > Greetings. 
> > 
> > I meant to send this out sooner, but with the Fedora 20 release things
> > have been crazy. :) Now that we are nearing the end of 2013, I think it
> > might be a nice time to think ahead to next year. 
> > 
> > What would you love to see happen? What would you like to work on
> > making happen? 
> > (even if it's not practical resource wise or logistically)
> > 
> > Here's a list of some of mine: 
> > 
> > * 0 downtime upgrades. By this I mean we can update and reboot all our
> >   servers (probibly in some specific order with specific actions
> >   between) and not have to schedule any downtime or notify users
> >   anything is going on. This means at least that we have db
> >   replication/failover working and 2 of everything. 
> > 
> > * Migration to ansible fully done, with all hosts moved over and
> >   rebuilt and working. 
> > 
> > * Migration to RHEL7. :)
> > 
> > * Ticket queue down to a very small set. When I first started it was
> >   gigantic, then I closed/fixed/redirected a lot of the ticket and we
> >   started going down in number, but over the last year or so we have
> >   hovered between 140-150. 
> > 
> > * Migration to hyperkitty/mailman3 complete with all lists moved. 
> > 
> > * All hosts selinux enforcing. :) 
> > 
> > * No "app" servers left. All applications split out to their own (at
> >   least pair) of instances. 
> > 
> > * Logging from every app/server goes to a known place and we process
> >   them all looking for problems.
> 
> Here is my list (in no particular order):
> 
> * FAS3
>   - We need to port FAS to a new(er) framework
>   - Move the user auth completely out of FAS?
>   - Unit-tests!
>   - Integrate w/ announces -> new election, new deadline...
> * Develop a 0Auth server?
> * fedocal
>    - A number of changes and enhancements are required and I started a little
>      bit on this already :)
> * pkgdb2
>   - We are already close, but we need to push it to production
>     and fix the bugs that will be encountered
> * Port our webapp to 2FA
>   - Toshio started some work on this but we need to continue it
> * Unit-tests
>   - This makes our product so much more robust that we really
>     should keep writing them
> * Fedmsg-Notifications (FMN)
>   - Already quite advanced, we need to push it to production and
>     add new notification options.
> * Cnucnu web
>   - Basis is there but it would be nice to add to the database more
>     mapping of the project in more linux distribution than just Fedora
> * Review-server
>   - Kick the package review-request out of bugzilla
>   - Tight(er) integration with koji
>   - Run fedora-review on each changes
>   - Run scratch build on each changes
>   - Provide a temporary git repo for each review that could then be
>     merged into the official git repo after the review
>   - This seems to interest the dev and stack group, see third point at:
>     https://fedoraproject.org/wiki/User:Mmaslano/Draft:Env_and_Stack_PRD#Automation
>   - We may want to see with tflink and the QA if there are tools in addition to
>     fedora-review that could be included
> * Elections
>   - It would be nice to re-work the election application to build in some
>     sort of plugin systems allowing different votes
>   - Eventually it would be very nice to merge nuancier into election as
>     a plugin
>   => I have no real idea yet on how to do so, I just think it would be nice
>      to have it :)
> * MirrorManager
>   - With FAS it is probably the oldest application that we have that does not
>     have a new version coming. We need to update it (new db scheme (?), new
>     framework, unit-tests...)
> * Auto-rebuild
>   - Using fedmsg or koji directly we are able to retrieve the date of the last
>     successful build of any packages in our collections. This way we could trigger
>     an automatic rebuild to check FTBFS of every package every X time (6 month?).
> * Auto-rebuild of broken deps
>   - When we detect a broken deps we should try to rebuild all the dependency and
>     propose the change to the packager if the build succeeded

Along the lines of automatic rebuilding, we should also think about
what it will take to support the vision of continuous integration and
increased automated testing that people like mattdm, threebean, and
tflink have been discussing.

Maybe this is a difficult proposition simply using our current lineup
of koji servers -- uncertain.  But would it be possible to spin up
instances in the cloud to build what Matt calls "artifacts" (loose
term, could be a spin, could be a set of packages TBD)?  I don't have
answers here, only questions really.  But this seems like an area we
should really be diving into.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com