RFC: Git workflow

Mo Morsi mmorsi at redhat.com
Mon Feb 20 12:15:50 UTC 2012


On 02/17/2012 12:16 PM, Scott Seago wrote:
> 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.
>

Often we focus on our fedorapeople.org repo at the expense of updates to 
Fedora. If we update Fedora/EPEL more often, not only will bugfixes and 
new features land there quicker, but the install path will be that much 
easier for new users.

Unless there is some monumental incompatibility, an updated release can 
be pushed to Fedora. If there is a blocker, the maintainer should wait 
only till the next Fedora release to push it but should also try to pull 
bugfixes and new enhancements into the package during the meantime.

I ask that the maintainers of each component start updating their rpms 
in Fedora more regularly so that we can streamline the process and 
eliminate as many unnecessary steps as possible.

I'll start nagging individuals towards the end of every sprint and 
during our releases, coordinating w/ Steve to at least lighten the 
burden on the fedorapeople.org repo. If we can accomplish this and 
sanely manage our dependencies, the extra work on fedorapeople.org 
should be mitigated.

   -Mo




More information about the aeolus-devel mailing list