> 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:
https://help.github.com/articles/syncing-a-fork/
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
structural
changes to add testable RPM5/MACOSX booleans (i.e. basically what you have
pushed
from rpm5/libhif:master onto a jeff/osxhack “feature” branch as rather obvious
immediate
and necessary porting needs.
There is the additional porting issue that libhif has pre-requisites, including
(at least)
rpm
rpm-python
libsolv
librepo
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
