RFC: Git workflow

Mo Morsi mmorsi at redhat.com
Fri Feb 17 14:28:28 UTC 2012


> Some random thoughts on this topic:
>
> Tbh, I have all but halted any aeolus conductor work until the
> "temporary release-related" stuff is sorted and conductor development is
> following some suitably sane process for accepting patches.  I'm
> currently sufficiently confused as to where patches should go and where
> I should push those patches once accepted.
>
> Being not directly on either conductor or infrastructure core
> development teams, I have found it hard to keep up with the various
> changes in development processes.
>
> Further, I think this is going to be a recurring problem each release,
> no?  It seems better to find a single comfortable development process
> that has a lower potential for common mistakes (like selecting the wrong
> branch for a patch) and that works when in and out of a release cycle.
>
> Perhaps it's better to revisit the comments made (much?) earlier on list
> about having many more frequent and smaller releases, that way the teams
> are always in a release cycle and not, uh, cycling between release and
> development.
>

Agreed, here some additional factors in the development process that I 
feel could use some improvement and proposed solutions to them.

  - changing practices regarding patch, commits, and repo management
      - proposed solution: all development happens on github master, we 
pull / cherry pick commits into other branches and repos as necessary. 
Keeps things simple and in line w/ other community practices

  - release engineering
      - if we can, drop our fedorapeople repo and just use the Fedora, 
RHN repos to manage components. The developers on each Aeolus 
subcomponent are responsible for releasing the version of the component 
that work w/ the platform at hand. Keeps things decentralized and more 
maintainable. See [1] for the currently assigned packagers/maintainers 
for each component

   - many UI rewrites (there seems to continuously be lots of time and 
patches devoted to fixing UI bugs and packaging up new dependencies for 
UI interactions)
      - we allocate more time to / focus on the conductor backend, QE 
has been asking for this as well to help develop their test strategies.

   - need bigger community / userbase
      - we need to simplify the application, requiring the average-joe 
end user to run through the current installation and configure process 
is a bit much IMO. Securing the application and deploying a public / 
easy-to-use solution would go a long way w/ all of this

    -Mo

[1] https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Packaging



More information about the aeolus-devel mailing list