RFC: Git workflow

Scott Seago sseago at redhat.com
Fri Feb 17 17:16:55 UTC 2012


On 02/17/2012 09:28 AM, Mo Morsi wrote:
>
>> 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
>
What about upstream releases? When we're back to regular dev sprint, we 
want to have end-of-sprint upstream releases. While we may push these 
all to rawhide, we won't want to update the in-release-fedora versions 
of Aeolus for every end-of-sprint, since we want packages in released 
fedora to be reasonably stable.

Stated another way, fedora isn't a place to host upstream releases -- 
it's an aggregator of upstream, not a source of upstream. In fact, 
fedora spec files are supposed to include the URL to the canonical 
upstream location for the upstream release -- which for the moment is 
fedorapeople. In addition, upstream releases are for more than just 
RHEL/Fedora We may be able to do away with an upstream yum repo as long 
as we host rpms/gems/tarballs/etc for each release on aeolusproject.org.

>   - 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