> On Nov 30, 2016, at 7:30 AM, Alexander Kanavin 
> <alexander.kana...@linux.intel.com> wrote:
> On 11/29/2016 06:02 PM, Jeffrey Johnson wrote:
>> Apologies, I’m new to project/repository management thru github.
>> Should be fixed.
>> We may have to iterate thru ssh key exchange etc etc soon too, depending on
>> what is needed.

After resuming work I dropped in late August, here are some further thoughts …

> Thanks, I've rearranged the branches a little bit:
> - your OS X build hack is now in jeff/osxhack branch

OK. My changes can be resurrected as needed from wherever.

> - I removed that commit from the master branch, so master can be used to 
> track upstream, and nothing else. That means the branch has been force 
> pushed, so delete your local copy to avoid accidentally pushing the commit 
> again.

Creating a pristine rpm5/libhif:master makes merges “transparent” and 
simplifies syncing “upstream” changes, absolutely.

However, what is needed is a common point in the graph where new porting work 
can be merged and shared.

> - I'll publish rpm5 work in alex/rpm5 branch, will let you know when there's 
> something to look at.

At the moment there is no (except “upstream”) common point where porting merges 
can occur.

The obvious/simple merge point (and what was already in place) was 
rpm5/libhif:master which
could merge from an “upstream” remote.

This in fact is what is suggested by github:

Whether we follow git best practices on “feature” branches ignores the fact that
a porting collaboration needs merges, not isolation, and that there are only two
of us developing atm. If you wish to preview merges, or discuss what tasks are
needed in wiki/issues on github, we can do that. Meanwhile I would deem 
changes to add testable RPM5/MACOSX booleans (i.e. basically what you have 
from rpm5/libhif:master onto a jeff/osxhack “feature” branch as rather obvious 
and necessary porting needs.

There is the additional porting issue that libhif has pre-requisites, including 
(at least)
that will need to be shared for a successful porting collaboration.

The build procedures using CMAKE are quite complicated and in need of sharing 
as well.
I have been adding a non-brainer doit.sh that is easily modified (with paths 
and switches)
on different development platforms as needed.

73 de Jeff______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org

Reply via email to