[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: [KDE/Mac] Suggestion to set up a central MacPorts/KDE repository for easy exchange of MacPorts p
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2014-05-10 2:56:32
Message-ID: 6FCE4E27-0406-41F0-847B-F81235F4AAEE () gmail ! com
[Download RAW message or body]


On 10/05/2014, at 10:06 AM, mk-lists@email.de wrote:

> Hi Nicolas,
> Hi Ian,
> 
> On 09 May 2014, at 10:00 , Nicolas Pavillon <nicos@macports.org> wrote:
> > I could eventually send you the Portfiles if it could help. I kept them to track \
> > the probable changes to apply when migrating to KDE 4.13 on Macports.
> 
> what do you think about putting those files onto a public repository [1] like I did \
> it for your intermediate fix [2] for cmake a few weeks ago?

I am just reacting to keyword in context (VISIBILITY), but could [2] have had \
something to do with the fixing of KDE in August 2013 to be clang-ready?  Refer to \
final comments in: https://bugs.kde.org/show_bug.cgi?id=300429 and \
https://trac.macports.org/ticket/34605

> 1)
> We could make use of [1] for this purpose, if you like. I could - instead of \
> Mercurial - also use git, if that’s more to your taste. I am using a Mercurial repo \
> for years to exchange port files with Brad [3]. In there your change [1] is also \
> reflected as commit [4].

I don't like the idea of Mercurial.  At my age I do not want to be learning an \
eleventh or twelfth source-code control system … :-)  I kicked and screamed enough \
when KDE went from SVN to git … :-)  So please consider either git or SVN.

> 2)
> On the other hand one might want to avoid using non-free services like BitBucket or \
> GitHub and instead go for KDE’s infrastructure itself... 
> Therefore I asked around on #kde-sysadmin and Ben told me to neither use git-lab \
> nor scratch repos and instead make use of a repo at git.kde.org.

You would have to have KDE login and commit access, but I guess Ben is one of
the guys who hands that out, if you have a need and are recommended by someone.
Or, for infrequent usage, I could commit on anyone else's behalf.  Once inside, there
are lots of places to put tools and partly developed stuff you wish to share.

People even have semi-private branches in the main parts of the repository, but I \
have never been bold enough to do that.  Have a look at the Branch: master dropdown \
list in: https://projects.kde.org/projects/kde/kdelibs/repository

One of the most popular places for sharing new stuff is Playground:
https://projects.kde.org/projects/playground see an example:
https://projects.kde.org/projects/playground/devtools/kdev-executebrowser/repository
For a general overview of all KDE repositories, see https://projects.kde.org/projects

> 3)
> Another option might be to simply stay on MacPorts’ SVN server by creating your own \
> user branch following [5] where you could put e.g. your current KDE 4.13 port files \
> which would then be visible on [6] and could easily be accessed by all of us. This \
> might help Ian regarding his tries to get KDE 4.13 up and running. 
> 
> Nicolas, what do you think?
> 
> Ian, what would you prefer?

Either a KDE or a MacPorts repository would suit me fine - git or SVN.
Meanwhile I am hoping Nicolas will send me an advance copy of his
Portfiles to get me going again … :-)

Cheers, Ian W.

> [1] https://bitbucket.org/mkae/macports-kde/wiki/Home
> [2] https://trac.macports.org/ticket/41321
> [3] https://bitbucket.org/mkae/mkbg-macports
> [4] https://bitbucket.org/mkae/mkbg-macports/commits/fcf5353a8851bed18765a8d32093065c45e7624d
>  [5] https://trac.macports.org/wiki/CommittersGuide/PersonalSVNRepository
> [6] https://svn.macports.org/repository/macports/users/

_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic