Re: How best to change a hard-coded config search path, before compilation

[Lawrence Velázquez]

> On Nov 4, 2016, at 8:53 PM, A. Karl Kornel  wrote:
> 
> The first thing I was thinking of doing is using "reinplace" directly
> on the file in question, in the pre-build phase. The section method
> I came up with was to use a patch file to change the line, replacing
> "/etc" with "PREFIX_GOES_HERE" (or something), and then using
> reinplace to put in the correct path.
> 
> Both methods do the same thing, but in my mind the second method is
> better because it makes absolutely sure I am only changing one part of
> the file. Also, if the code changes in a future version, the patch
> will fail to apply. That will help me from missing changes.

We strongly prefer the second method, for the reasons you already gave.
Your portfile should contain a bit resembling this:

patchfiles use-macports-prefix.patch

post-patch {
reinplace s|__PREFIX__|${prefix}| file.ext
}

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

How best to change a hard-coded config search path, before compilation

[A. Karl Kornel]

Hello!

I am creating a port for a Python program called "clustershell", and I'd 
like some advice as to how to handle a hard-coded config file search 
path.


The clustershell program looks for configuration in a number of places, 
with "/etc/clustershell/" hard-coded as the first path, so I have to 
change it to use the prefix set at build time. What I was wondering is, 
what method should I use to make the change?


The first thing I was thinking of doing is using "reinplace" directly on 
the file in question, in the pre-build phase. The section method I came 
up with was to use a patch file to change the line, replacing "/etc" 
with "PREFIX_GOES_HERE" (or something), and then using reinplace to put 
in the correct path.


Both methods do the same thing, but in my mind the second method is 
better because it makes absolutely sure I am only changing one part of 
the file. Also, if the code changes in a future version, the patch will 
fail to apply. That will help me from missing changes.


Does anyone have any advice as to how best to proceed?  I appreciate any 
advice you can provide!


--
~ Karl Kornel
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Rainer Müller]

On 2016-11-04 18:46, Lawrence Velázquez wrote:
> Actually, I might have been thinking about another editor. My vim
> highlights the subject in *green* up until 50 chars, and then black for
> the overflow. But one can probably change that black to red if they want
> :P

.vimrc:
hi def link gitcommitOverflow Error

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [macports-ports] branch master updated: octave-image: add cxx11 portgroup, remove gcc-4.2 from compiler blacklist

[Ryan Schmidt]

> On Nov 4, 2016, at 15:18, Marius Schamschula 
>  wrote:
> 
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
> 
> https://github.com/macports/macports-ports/commit/1119466ab172e47ff602563e691649f1cbcae0cc
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 1119466  octave-image: add cxx11 portgroup, remove gcc-4.2 from 
> compiler blacklist
> 1119466 is described below
> 
> commit 1119466ab172e47ff602563e691649f1cbcae0cc
> Author: Marius Schamschula 
> AuthorDate: Fri Nov 4 15:16:37 2016 -0500
> 
> octave-image: add cxx11 portgroup, remove gcc-4.2 from compiler blacklist
> ---
>  math/octave-image/Portfile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/math/octave-image/Portfile b/math/octave-image/Portfile
> index 4da7048..ff6cc88 100644
> --- a/math/octave-image/Portfile
> +++ b/math/octave-image/Portfile
> @@ -2,6 +2,7 @@
>  
>  PortSystem  1.0
>  PortGroup   compiler_blacklist_versions 1.0
> +PortGroup   cxx11 1.0
>  PortGroup   octave 1.0
>  
>  octave.setupimage 2.6.1
> @@ -27,4 +28,4 @@ patchfiles-append   patch-src-Makefile.in.diff \
>  configure.env-append "PREFIX_BIN=${prefix}/bin"
>  
>  # https://savannah.gnu.org/bugs/?45096
> -compiler.blacklist-append   gcc-4.2 gcc-5.0 gcc-5.1
> +compiler.blacklist-append   gcc-5.0 gcc-5.1
> 

There is no compiler "gcc-5.0" nor "gcc-5.1". It's called "macports-gcc-5". 
There's also probably no reason to blacklist any MacPorts FSF GCC compiler 
because there is no circumstance in which MacPorts would automatically select 
it. ___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: PR usage by people with commit access

[Joshua Root]

On 2016-11-5 06:14 , Daniel J. Luke wrote:

On Nov 4, 2016, at 2:09 PM, Sterling Smith  wrote:

In the past, I have seen responses to svn changelogs directed to the committer 
and copied to the dev list,


I expect that to continue to be the case.


so apparently port maintainers who are committers are not always the best 
reviewers.  How many times has there been a post-svn-commit debate about 
whether something warranted a revision bump?  I would recommend that any change 
that changes the build more than a version and checksum change warrants a pull 
request.  If no one acts to review it within the timeliness dictated of the 
committer, then they still have the prerogative and authority to commit the 
changes when they want.


-1 from me.

I'm not sure what problem this actually would solve, and it would be more work 
for committers.

[if we had lots of people capable and willing to do review every change, then I 
could see it being helpful - but we don't have that]


I can see PRs being helpful in the case where a committer has a change 
to someone else's port ready to go and they just want to run it by the 
maintainer. In that situation it's quicker and easier than the alternatives.


But in general, yeah, not enough hours in the day.

- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: PR usage by people with commit access

[Daniel J. Luke]

On Nov 4, 2016, at 2:09 PM, Sterling Smith  wrote:
> In the past, I have seen responses to svn changelogs directed to the 
> committer and copied to the dev list,

I expect that to continue to be the case.

> so apparently port maintainers who are committers are not always the best 
> reviewers.  How many times has there been a post-svn-commit debate about 
> whether something warranted a revision bump?  I would recommend that any 
> change that changes the build more than a version and checksum change 
> warrants a pull request.  If no one acts to review it within the timeliness 
> dictated of the committer, then they still have the prerogative and authority 
> to commit the changes when they want. 

-1 from me.

I'm not sure what problem this actually would solve, and it would be more work 
for committers.

[if we had lots of people capable and willing to do review every change, then I 
could see it being helpful - but we don't have that]

-- 
Daniel J. Luke



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Pull Requests for Work in Progress (WIP)

[Mojca Miklavec]

On 4 November 2016 at 18:55, Marko Käning wrote:
>
> Besides there is even a clearly visible RED "Work-In-Progress" label 
> available in the PR interface, which Mojca had spotted eventually.

I didn't spot it. I though it was useful and made it after this
discussion was started.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: PR usage by people with commit access

[Sterling Smith]

On Nov 4, 2016, at 10:50AM, Rainer Müller  wrote:

> On 2016-11-04 18:10, Ivan Larionov wrote:
> 
>> * Ability to get a feedback / review from other project members.
>> 
>> We use private github setup on my work and we have a rule that you
>> shouldn't commit directly to master in a project with multiple
>> contributors until it's very small change like fixing typo. Open PR,
>> ask for review, merge. Or fix issues and merge if you got any useful
>> comments on PR.
> 
> Who would be better to review the change then the maintainers of ports
> themselves? I feel like this would unnecessary slow down the process of
> getting the update out.
> 
> Rainer

In the past, I have seen responses to svn changelogs directed to the committer 
and copied to the dev list, so apparently port maintainers who are committers 
are not always the best reviewers.  How many times has there been a 
post-svn-commit debate about whether something warranted a revision bump?  I 
would recommend that any change that changes the build more than a version and 
checksum change warrants a pull request.  If no one acts to review it within 
the timeliness dictated of the committer, then they still have the prerogative 
and authority to commit the changes when they want. 

My two cents.

-Sterling
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Pull Requests for Work in Progress (WIP)

[Marko Käning]

On 04 Nov 2016, at 02:19 , Arno Hautala  wrote:
> But, it occurs to me that one of the goals of moving
> to GitHub is greater collaboration and that is facilitated by inline
> comments on the pull request. Plus, a completed pull request is one
> comment away from a work in progress anyway.

+1


> The alternative to WiP pull requests is posting multiple comparison
> URLs to reference different lines of code that must be opened in
> different windows. Plus, those references will break as soon as any
> changes are made to the branch.

Exactly, I don’t think this is the way to go.

But let’s those decide who would have to deal (or not) with those red “WIP” 
badges in GitHub PR interface every now and then...

Well, if it is too much red noise in the PR interface then one would have to 
have these discussions directly on the contributors’ private forks of the 
macports-ports.
Downside there: If one decides to kill one of these repos all their comments to 
the relevant code are gone. So, that’s perhaps an argument more for keeping WIP 
PRs?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: PR usage by people with commit access

[Lawrence Velázquez]

> On Nov 4, 2016, at 1:48 PM, Clemens Lang  wrote:
> 
>> * Using the same change methods as outside contributors may help to
>> develop better PR flow.

I am not particularly interested in accommodating contributors' workflow
expectations for their own sake. Their workflows may work for them but
not for us.

>> Currently I see some lack of the standard flow, maintainers commit
>> contributors' changes in different ways, PRs marked as rejected
>> while they're actually merged, people ask to enable "Allow edits
>> from maintainers" for PR, etc.
> 
> Absolutely agree.

I think this is mainly us trying to figure out a good workflow. I expect
things will settle down eventually.

>> * Ability to get a feedback / review from other project members.
> 
> Agree for the cases where other people interested in the ports and
> capable of reviewing exist, and those people have the time to review in
> a timely fashion.

Sure. I would encourage committers who want feedback to open as many PRs
as they want.

(You get a PR! You get a PR! Everybody gets a PR!!!)

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Pull Requests for Work in Progress (WIP)

[Marko Käning]

Hi Rainer,

On 03 Nov 2016, at 18:57 , Sterling Smith  wrote:
> On Nov 3, 2016, at 10:47AM, Rainer Müller  wrote:
> 
>> On 2016-11-03 17:49, Sterling Smith wrote:
>>> The main question of procedure is: Should the main macports repo be
>>> used for proposing review of work in progress via pull requests?  If
>>> not, what is the proposed method?
>> 
>> I propose you put your changes on a branch, add the compare URL to a
>> ticket or send an email to macports-dev.
>> 
>> In the case you referred to, this would be:
>> 
>> https://github.com/mkae/macports-ports/compare/master...mkae:qtcurve_upgrade-for-Qt5
>> 
> The downside (as I see it) of using the compare URL, as opposed to a full 
> pull request, is that line by line comments are not available.

I think this is _downside_ enough to NOT use the approach suggested by you, 
because loosing the reviewing features (comments directly in the code) doesn’t 
make reviewers’ work easier, does it!

Besides there is even a clearly visible RED "Work-In-Progress" label available 
in the PR interface, which Mojca had spotted eventually.

But, hey, who am I to oppose such a decision if the core team of committers 
doesn’t think it’s a good idea?
Perhaps we should initiate a poll among the top 10 or even 20 committers, who 
are carrying the major load of reviewing/committing for MacPorts’ ports repo???

Greets,
Marko

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: PR usage by people with commit access

[Rainer Müller]

On 2016-11-04 18:10, Ivan Larionov wrote:
> I'm not saying that you have to wait for review or something like
> this, but opening a PR from your branch and then merging it has some
> pros:
> 
> * Better visibility of changes. Instead of cloning full repository
> and digging through history I can search PRs by port name and see
> changes which were done by maintainers and contributors.

You cannot filter by portname in a reasonable way. GitHub search is just
too limited to support anything like that. That is one of the main
reasons we rejected GitHub Issues, which have the same problem.

Isn't it much easier to just view the history of the corresponding port
directory than a convoluted search? You can also do that on GitHub:

https://github.com/macports/macports-ports/commits/master/python/py-sqlparse

> * Using the same change methods as outside contributors may help to
> develop better PR flow. Currently I see some lack of the standard
> flow, maintainers commit contributors' changes in different ways, PRs
> marked as rejected while they're actually merged, people ask to
> enable "Allow edits from maintainers" for PR, etc.

They were "rejected" because GitHub does not have a way to mark them as
"merged" unless the exact same object was merged. In case the maintainer
had to make additional changes to the commit, GitHub will not recognize
them as merged.

The only solution we found so far is to push the modified commits back
to the pull request branch, which will mark the pull request as
"merged". However, that requires that pull request authors allow
modifications by maintainers.

> * Ability to get a feedback / review from other project members.
> 
> We use private github setup on my work and we have a rule that you
> shouldn't commit directly to master in a project with multiple
> contributors until it's very small change like fixing typo. Open PR,
> ask for review, merge. Or fix issues and merge if you got any useful
> comments on PR.

Who would be better to review the change then the maintainers of ports
themselves? I feel like this would unnecessary slow down the process of
getting the update out.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: PR usage by people with commit access

[Clemens Lang]

Hi,

On Fri, Nov 04, 2016 at 10:10:44AM -0700, Ivan Larionov wrote:
> I think this is a good practice for port maintainers with write access
> to repository still use PRs instead of direct commits to master.

I agree, with some limitations:

> * Better visibility of changes. Instead of cloning full repository and
> digging through history I can search PRs by port name and see changes
> which were done by maintainers and contributors.

It's more work. We're all doing this in our free time and clicking
through GitHub's Web UI a couple of times just for the searchability is
not worth the extra effort. If you want the full picture, you'll have to
search the history anyway, which luckily is now much faster than it used
to be with Subversion.

> * Using the same change methods as outside contributors may help to
> develop better PR flow. Currently I see some lack of the standard
> flow, maintainers commit contributors' changes in different ways, PRs
> marked as rejected while they're actually merged, people ask to enable
> "Allow edits from maintainers" for PR, etc.

Absolutely agree.

> * Ability to get a feedback / review from other project members.

Agree for the cases where other people interested in the ports and
capable of reviewing exist, and those people have the time to review in
a timely fashion.

> We use private github setup on my work and we have a rule that you
> shouldn't commit directly to master in a project with multiple
> contributors until it's very small change like fixing typo. Open PR,
> ask for review, merge. Or fix issues and merge if you got any useful
> comments on PR.

We do the same thing at my workplace, but this only works because there
are other people with an interest to review your changes (being paid to
do it). I'm not sure whether we have the manpower to review every commit
pushed into MacPorts.

-- 
Clemens
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Lawrence Velázquez]

> On Nov 4, 2016, at 1:43 PM, Marko Käning  wrote:
> 
>> On 04 Nov 2016, at 18:34 , Lawrence Velázquez  wrote:
>> 
>> It doesn't really do anything differently w.r.t. wrapping, but it
>> highlights subject-line overflow in an alarming red color.
> 
> that’s a nice feature.

Actually, I might have been thinking about another editor. My vim
highlights the subject in *green* up until 50 chars, and then black for
the overflow. But one can probably change that black to red if they want
:P

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Marko Käning]

Hi Larry,

On 04 Nov 2016, at 18:34 , Lawrence Velázquez  wrote:

> It doesn't really do anything differently w.r.t. wrapping, but it
> highlights subject-line overflow in an alarming red color.

that’s a nice feature. Will have to test whether that works as documented
in our WorkingWithGit wiki page...


> Not a waste of time! Can't know what the water is like without dipping
> your toe in. We appreciate your enthusiasm :)

Well, I respect the work you guys have been done and are doing for MacPorts
and I appreciate that you do the same for those who try to support this
operation to the best of their knowledge.

:)

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Marko Käning]

On 02 Nov 2016, at 23:33 , Ryan Schmidt  wrote:

> ...my initial reaction to your template (and my initial reaction when I saw 
> it mentioned previously) was "TL;DR”.

I got it now. :)


>> vim does that with syntax highlighting automatically nowadays when it
>> notices you are writing a commit message. If you need an indication on
>> your line width, may I suggest you configure your editor appropriately?
> 
> Can we document in the WorkingWithGit page how to do that? I have no idea.

I thought exactly the same, Ryan! ;-)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Marko Käning]

On 02 Nov 2016, at 01:03 , Lawrence Velázquez  wrote:
> To be honest, this template adds so much comment noise that I can't
> imagine ever using it.

That’s fine ok, your decision. :)


>> --- ~/.git-commit-template ---
>> #  Please enter the commit message for your changes. Lines starting
>> #  with '#' will be ignored, and an empty message aborts the commit.
>> #
>> #   -> The title MUST not be longer than 50 characters. 
> 
> I don't think we should dictate a hard limit on this. Sometimes it's
> hard to say anything meaningful in 50 characters, especially since we
> prepend port names to the subject line. Anything less than 60 chars is
> generally good enough.

Please, check out our own WorkingWithGit wiki page. That’s exactly the
source of information I used to set up the commit template suggestion.
I just included our publicly available commit rules for the committers. 


>> #   -> You MUST wrap all further lines at 72 characters.
>> #
>> #  For more information on how to write commit messages see MacPorts'
>> #  wiki at https://trac.macports.org/wiki/WorkingWithGit#commitmessages
>> #
>> # ==[ Subject: One meaningful line ONLY!  ]==|
>> 
>> # ==[ Blank: Follow the Subject with a blank line, do NOT remove ]=|
>> 
>> # ==[ Details: Describe what changed and explain why it changed]===|
> 
> This is all informative exactly once.

Yes.


> As Clemens already noted, these aren't the supported keywords.

I am aware of that!


>> I have fantasised a little here what concerns the (perhaps upcoming)
>> BUILDBOT feature.
> 
> I wouldn't hold my breath on this.

I am not. I know that this won’t have priority and will only be implemented
if someone really sees a benefit in test-building stuff on an individual
builder.


> We have the wiki and guide for documentation. This template is not the
> place for documentation.

Well, actually, I do see your point. But what good is it if even you didn’t
know the rules about the maximum number of chars in a line? ;-) Having said
that I also think that you’ll mostly have a hard time to bring a conscience
message including the port name into just 50 characters!


>> But perhaps all this is overkill?!
> 
> In case it's not obvious, I think this is serious overkill.

You made very obvious to me.

I do know now what not to do in the future: trying to come up with such kind
of suggestions - while not being a professional software developer and just
some guy who tries to support a collaborative initiative like MacPorts to the
best of his (admittedly) limited knowledge.

Moving on to the next response...
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Lawrence Velázquez]

> On Nov 4, 2016, at 1:30 PM, Marko Käning  wrote:
> 
> Oh, I’d be using vim as well, good to know that it does support git.
> I didn’t know that vim would be able to treat commit message line
> formatting for the first and the 3r+ lines differently with 50 and 72
> chars respectively.

It doesn't really do anything differently w.r.t. wrapping, but it
highlights subject-line overflow in an alarming red color.

> Well, this was a trigger for a discussion about the topic of
> a template which potentially could make the committer’s life easier...
> But I understood in the meantime that I could have just used my spare
> time much better for other things than trying to care about such silly
> things like a commit template. I thought what KDE has is a good
> starting point and I believed MacPorts devs would see value in it.
> I have now been taught that I wasted my time and yours.

Not a waste of time! Can't know what the water is like without dipping
your toe in. We appreciate your enthusiasm :)

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Marko Käning]

Hi,

On 02 Nov 2016, at 00:08 , Clemens Lang  wrote:
> Developers are free to use your template if they want to. We don't want
> to mandate using it though (since we couldn't enforce it anyway).

yeah, I am aware of that.


> vim does that with syntax highlighting automatically nowadays when it
> notices you are writing a commit message. If you need an indication on
> your line width, may I suggest you configure your editor appropriately?

Oh, I’d be using vim as well, good to know that it does support git.
I didn’t know that vim would be able to treat commit message line formatting
for the first and the 3r+ lines differently with 50 and 72 chars respectively.


>> # --[ Links to issues on MacPorts' trac ]--|
>> #ISSUE:  
>> #RESOLVES:   
>> #BLOCKED BY: 
> 
> You could have taken the time to actually adjust this to what MacPorts'
> Trac instance accepts. See
> https://trac.edgewall.org/wiki/CommitTicketUpdater
> for the description of the plugins that does this for us and
> https://github.com/macports/trac.macports.org/blob/master/conf/trac.ini#L251
> for the configuration we use.

Yes, I could have, indeed, but I thought it was clear from my post that I was
trying to start a discussion about it and that I didn’t intend to deliver a
ready-made template with everything already prepared. Especially not because
I knew you weren’t fond of the whole idea anyways. How right I was I see from
the responses in this thread. ;-)


>> # --[ Links to other pull requests at GitHub ]—|
>> #PR:  
>> #
>> ##EXAMPLE:
>> # PR:  #123
> 
> Could use the documented keywords GitHub accepts to handle pull requests
> (you can close pull requests from commit messages!)

I could have done this too, yes. But I didn’t know about this GitHub
functionality up to now.


> Additionally, I don't like the upper case keywords.

Well, this was a trigger for a discussion about the topic of a template which
potentially could make the committer’s life easier... But I understood in the
meantime that I could have just used my spare time much better for other
things than trying to care about such silly things like a commit template.
I thought what KDE has is a good starting point and I believed MacPorts devs
would see value in it. I have now been taught that I wasted my time and yours.
Fine with me.

Moving on to the next response...
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[Michael]

On 2016-11-03, at 10:39 PM, David Bariod  wrote:

> Hello,
> 
> Personnally, I would just commit such change. It is cheap, can be reworked 
> later and be ketp safe in a private remote repository in case of disaster.
> With git there are no reason to not commit event not ready yet change set.
> 
> Best regards,
> David

I assume that last line should be "to not commit even not ready yet change 
sets".

I agree that you can commit anything.
But only if you follow the rule of not working/committing directly to master.
Leave your junk on a side branch, and put the fixed-up work into master later.


---
Entertaining minecraft videos
http://YouTube.com/keybounce

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

PR usage by people with commit access

[Ivan Larionov]

I think this is a good practice for port maintainers with write access to 
repository still use PRs instead of direct commits to master.

I'm not saying that you have to wait for review or something like this, but 
opening a PR from your branch and then merging it has some pros:

* Better visibility of changes. Instead of cloning full repository and digging 
through history I can search PRs by port name and see changes which were done 
by maintainers and contributors.
* Using the same change methods as outside contributors may help to develop 
better PR flow. Currently I see some lack of the standard flow, maintainers 
commit contributors' changes in different ways, PRs marked as rejected while 
they're actually merged, people ask to enable "Allow edits from maintainers" 
for PR, etc.
* Ability to get a feedback / review from other project members.

We use private github setup on my work and we have a rule that you shouldn't 
commit directly to master in a project with multiple contributors until it's 
very small change like fixing typo. Open PR, ask for review, merge. Or fix 
issues and merge if you got any useful comments on PR.

--
With best regards, Ivan Larionov.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: rsync not being kept up to date?

[Adam Mercer]

On Fri, Nov 4, 2016 at 11:14 AM, Ryan Schmidt  wrote:

> What does this port contain? Does it download 2GB of data and repackage it? 
> Does it generate 2GB of data?

It contains the output of numerical relativity simulations that
routines in the lalsimualtion port read in and scale for different
parameters. We're investigating other ways to distribute this data as
when it was 10s of Mbs it wasn't that much of a problem, but now it
is.

Cheers

Adam
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: rsync not being kept up to date?

[Joshua Root]

On 2016-11-5 03:14 , Ryan Schmidt wrote:




On Nov 4, 2016, at 08:03, Adam Mercer  wrote:

Or is there a way to tell
the buildbot not to produce packages?


Whether the buildbot distributes the binary is based on whether its stated 
license is distributable or not. But I'm reluctant to suggest you change the 
license to something not distributable if it is.


Instead of replacing the license string, you could append some 
human-readable string that indicates that we don't want to upload 
binaries. As long as it's not in the list of recognised licenses it will 
have that effect.


- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Rainer Müller]

On 2016-11-04 03:41, Lawrence Velázquez wrote:
>> On Nov 3, 2016, at 9:48 PM, Ryan Schmidt  wrote:
>>
>> I did already run "git branch -D l2dy-curl-ca-bundle-update" when "git
>> branch -d l2dy-curl-ca-bundle-update" failed because of an error.
> 
> Do you remember what the error was? The next time it happens could you
> let me know? I could certainly have overlooked something.

After the branch was pushed to the remote master, locally the commits
are only in this branch. You need to do another pull on the master
branch, which will introduce these changes locally, before you can
delete the changes without error.

$ git checkout master
$ git pull --rebase
$ git branch -d l2dy-curl-ca-bundle-update

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] CommittersGuide/PersonalSVNRepository modified

[Rainer Müller]

On 2016-11-04 05:01, Lawrence Velázquez wrote:
>> On Nov 2, 2016, at 9:40 PM, MacPorts  wrote:
>>
>> Page "CommittersGuide/PersonalSVNRepository" was changed by raimue
>> Diff URL: 
>> 
>> Revision 9
>> Comment: No longer applies after move to GitHub
>> Changes:

[...]

> Is there a reason you didn't just delete the page?

Deleting a wiki page also erases all of its history and it is irreversible.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

[René J . V . Bertin]

On Friday November 04 2016 23:52:30 Joshua Root wrote:

>We could really do without this kind of sarcastic, insinuated personal 
>attack.

For the record, there was nothing personal intended in my remark; it was 
inspired by recent exchanges I've seen that involved more than just the 2 
people cited. Apologies if I forgot that English remains a foreign language for 
me.

As to remarks that can be (mis)interpreted as often barely insinuated personal 
attacks: I'm most definitely not the only one on here who can be accused of 
that. And I'd hope certainly not of harsh or borderline vulgar language.

I won't be replying any further.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

[Joshua Root]

On 2016-11-4 19:36 , René J. V. Bertin wrote:

Lawrence Velázquez wrote:


Overall, can we just stop this discussion, please? We settled to stay

migrating is not worth it right now. At this point, we are kicking
a horse that is dead and buried and worm food, and it is wasting
everyone's time and energy. Enough.


So is this the kind of attitude with which you think to motivate others to
contribute to help make MP better?

Great job, really.


We could really do without this kind of sarcastic, insinuated personal 
attack. Cool it.


And yes, by explaining just how unlikely we are to make this change, 
Larry is attempting to direct contributions towards more productive 
areas. We're not doing another ticket migration any time soon, and we're 
even less likely to add a second bug tracker.


- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[David Bariod]

On Fri, Nov 4, 2016 at 10:20 AM, Chris Jones 
wrote:

> Hi,
>
> On 04/11/16 09:16, David Bariod wrote:
>
>>
>>
>> On Fri, Nov 4, 2016 at 9:55 AM, Chris Jones > > wrote:
>>
>>
>>
>> On 04/11/16 05:39, David Bariod wrote:
>>
>> Hello,
>>
>> Personnally, I would just commit such change. It is cheap, can be
>> reworked later and be ketp safe in a private remote repository
>> in case
>> of disaster.
>> With git there are no reason to not commit event not ready yet
>> change set.
>>
>>
>> I would not do this, as you then might end up with a lot of
>> intermediary commits in the history. better I think to work on
>> independent projects on independent branches.
>>
>>
>> Then you can do a git rebase -i to clean up when you want to publish
>> your final state.
>>
>
> Still, if you have independent pieces of work in progress, its still
> better IMHO to separate them into branches. The policy of not working on
> the master with git is not my idea, its a widely held piece of (good)
> advice, for various reasons.
>

Yes, using different branch is definitely a good idea

David
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[David Bariod]

On Fri, Nov 4, 2016 at 9:55 AM, Chris Jones 
wrote:

>
>
> On 04/11/16 05:39, David Bariod wrote:
>
>> Hello,
>>
>> Personnally, I would just commit such change. It is cheap, can be
>> reworked later and be ketp safe in a private remote repository in case
>> of disaster.
>> With git there are no reason to not commit event not ready yet change set.
>>
>
> I would not do this, as you then might end up with a lot of intermediary
> commits in the history. better I think to work on independent projects on
> independent branches.
>

Then you can do a git rebase -i to clean up when you want to publish your
final state.

David
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[Chris Jones]

On 04/11/16 05:39, David Bariod wrote:

Hello,

Personnally, I would just commit such change. It is cheap, can be
reworked later and be ketp safe in a private remote repository in case
of disaster.
With git there are no reason to not commit event not ready yet change set.


I would not do this, as you then might end up with a lot of intermediary 
commits in the history. better I think to work on independent projects 
on independent branches.


Chris



Best regards,
David

On Fri, Nov 4, 2016 at 2:56 AM, Ryan Schmidt > wrote:

With Subversion, I was accustomed to keeping changes in my working
copy that I was not ready to commit yet.

Git doesn't let me do that. It complains and tells me to git stash
and later git stash pop.

Well, I tried that. I git stashed, then made changes to curl and
committed them, and later when I tried to git stash pop, my other
changes that I had in my git clone were not restored. I have no idea
where they are now.

I can get these particular changes back from my old Subversion
working copy, but I don't understand how I'm meant to work with git
when I have changes that I'm not ready to commit yet, yet there are
other changes I need to make and commit elsewhere within that same
clone.

___
macports-dev mailing list
macports-dev@lists.macosforge.org

https://lists.macosforge.org/mailman/listinfo/macports-dev





___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[Chris Jones]

On 04/11/16 04:18, Sterling Smith wrote:


On Nov 3, 2016, at 7:54PM, Arno Hautala  wrote:


On Thu, Nov 3, 2016 at 9:56 PM, Ryan Schmidt  wrote:


Well, I tried that. I git stashed, then made changes to curl and committed 
them, and later when I tried to git stash pop, my other changes that I had in 
my git clone were not restored. I have no idea where they are now.


There's also another paradigm to adopt which avoids stashing entirely.
Just always work in a branch and feel free to commit even if you're in
the middle of something. In your case, you're working on something
(let's say it's wget), but curl needs to be fixed too. Commit your
incomplete changes on the "wget-update" branch, `git checkout -b
curl-update master` to create and checkout a curl branch, complete
your work there, and then switch back to the "wget-update" branch.

This is my preference.  I tried stash as well once, and had trouble with it.


I would agree.

You should get out of the habit of working on the master branch. Leave 
that pristine and in sync with GitHub. For each separate project you are 
working out create a branch (from the master) and work on that. When you 
are ready you can then push that branch to GitHub and create a pull 
request for it.


Chris



-Sterling
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

[René J . V . Bertin]

Lawrence Velázquez wrote:

>>> Overall, can we just stop this discussion, please? We settled to stay
> migrating is not worth it right now. At this point, we are kicking
> a horse that is dead and buried and worm food, and it is wasting
> everyone's time and energy. Enough.

So is this the kind of attitude with which you think to motivate others to 
contribute to help make MP better?

Great job, really.

R

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev