> 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
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
The obvious/simple merge point (and what was already in place) was
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
that will need to be shared for a successful porting collaboration.
The build procedures using CMAKE are quite complicated and in need of sharing
I have been adding a non-brainer doit.sh that is easily modified (with paths
on different development platforms as needed.
73 de Jeff______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List firstname.lastname@example.org