On Tue, 24 Apr 2018 10:56:24 -0700 Ken Cunningham
wrote:
> This is a good discussion to have. MacPorts has at times in the
> past bogged down rather impressively with PRs, ticket submissions,
> and updates sitting for so long people lost interest. I know I very
> nearly did.
One thing I've noted
On 2018-4-26 00:44 , Perry E. Metzger wrote:
> I tend to think it's a better way of working but it's up to the
> community as a whole to say if it's really the right way to do
> things. (If people really don't like it, I can hang back more.)
To be clear, I have no problem at all with you (or anyon
Hi,
I just want to say that I find it magnificent what you achieved with PRs.
At the moment there is no single PR older than 4 days and if I ignore
the "add GitHub handle" ones, there are only 9 PRs left (older than
one hour).
Yes, sure, mistakes happen all the time, but they happened just as
we
I have one request though. You are sometimes asking people to close
the PRs because you don't want unfinished PRs in the queue. I would
like to suggest adding a special label to such PRs before closing
them, saying something like "workneeded". I would occasionally like to
be able to search for s
On 2018-04-25, at 9:23 AM, Chris Jones wrote:
>
>> I have one request though. You are sometimes asking people to close
>> the PRs because you don't want unfinished PRs in the queue. I would
>> like to suggest adding a special label to such PRs before closing
>> them, saying something like "workn
Doing this should prevent the MR being merged, and make it clear the author is
still working on something, but want to submit the MR now for other reasons
(like not to forget it, or start to get comments etc.). I use this regularly in
other systems at work and it works really well...
We shou
On Apr 25, 2018, at 11:31, Chris Jones wrote:
> Personally, I would like to see MacPorts go in exactly the opposite
> direction, so migrate away from using trac for anything much. I also happen
> to think, one way or another this will naturally happen as people get used
> to, and see all the a
On Apr 25, 2018, at 11:23, Chris Jones wrote:
> I don't think there is any need to re-invent our own system here. There is an
> already standard why of dong this, which is to declare the request as 'Work
> In Progress'. This is trivially done by adding 'WIP' to the start of the PR
> title.
Wou
On 25 April 2018 at 18:23, Chris Jones wrote:
>
>> I have one request though. You are sometimes asking people to close
>> the PRs because you don't want unfinished PRs in the queue. I would
>> like to suggest adding a special label to such PRs before closing
>> them, saying something like "workneed
> On 25 Apr 2018, at 5:46 pm, Ryan Schmidt wrote:
>
>
>> On Apr 25, 2018, at 11:31, Chris Jones wrote:
>>
>> Personally, I would like to see MacPorts go in exactly the opposite
>> direction, so migrate away from using trac for anything much. I also happen
>> to think, one way or another thi
> On 25 Apr 2018, at 5:47 pm, Ryan Schmidt wrote:
>
>> On Apr 25, 2018, at 11:23, Chris Jones wrote:
>>
>> I don't think there is any need to re-invent our own system here. There is
>> an already standard why of dong this, which is to declare the request as
>> 'Work In Progress'. This is tri
On 2018-04-25, at 11:02 AM, Chris Jones wrote:
>
> That, frankly, would be absurb.
>
> Chris
Absurd might be strong. It depends on the stage of your work.
A nearly completed patch that needs a few tweaks is one thing.
A PR list full of [WIP] PRs that have gone nowhere for six or twelve months
On Wed, 25 Apr 2018 11:47:21 -0500 Ryan Schmidt
wrote:
> On Apr 25, 2018, at 11:23, Chris Jones wrote:
>
> > I don't think there is any need to re-invent our own system here.
> > There is an already standard why of dong this, which is to
> > declare the request as 'Work In Progress'. This is triv
On Apr 25, 2018, at 13:02, Chris Jones wrote:
> On 25 Apr 2018, at 5:46 pm, Ryan Schmidt wrote:
>
>>> On Apr 25, 2018, at 11:31, Chris Jones wrote:
>>>
>>> Personally, I would like to see MacPorts go in exactly the opposite
>>> direction, so migrate away from using trac for anything much. I al
> On 25 Apr 2018, at 7:08 pm, Perry E. Metzger wrote:
>
> On Wed, 25 Apr 2018 11:47:21 -0500 Ryan Schmidt
> wrote:
>> On Apr 25, 2018, at 11:23, Chris Jones wrote:
>>
>>> I don't think there is any need to re-invent our own system here.
>>> There is an already standard why of dong this, which
On Apr 25, 2018, at 13:12, Chris Jones wrote:
> Labels are fine. A label can be used to mark a MR as WIP. my point is we
> should mark them in a standard way, that triggers github to correctly treat
> the MR as ‘work in progress’ the same way as every other project on github
> does...
Sure.
On Wed, 25 Apr 2018 18:48:33 +0200 Mojca Miklavec
wrote:
> I admit that I do find value in WIP PRs from time to time. Like ...
> someone submitting an update to a library that needs coordinated
> update with dependent ports that need to be tested individually. But
> there are plenty other examples
> On 25 Apr 2018, at 7:11 pm, Ryan Schmidt wrote:
>
>
>> On Apr 25, 2018, at 13:02, Chris Jones wrote:
>>
>> On 25 Apr 2018, at 5:46 pm, Ryan Schmidt wrote:
>>
On Apr 25, 2018, at 11:31, Chris Jones wrote:
Personally, I would like to see MacPorts go in exactly the opposite
>
> On 25 Apr 2018, at 7:13 pm, Perry E. Metzger wrote:
>
> On Wed, 25 Apr 2018 18:48:33 +0200 Mojca Miklavec
> wrote:
>> I admit that I do find value in WIP PRs from time to time. Like ...
>> someone submitting an update to a library that needs coordinated
>> update with dependent ports that ne
On Wed, 25 Apr 2018 11:08:10 -0700 Ken Cunningham
wrote:
> A nearly completed patch that needs a few tweaks is one thing.
>
> A PR list full of [WIP] PRs that have gone nowhere for six or
> twelve months like I see in some projects is another. That is just
> noise.
Agreed. But we have a tool to
On Wed, 25 Apr 2018 19:17:57 +0100 Chris Jones
wrote:
> > If it is something is a long term project, if it is
> > going to take six months say, then this isn't really a Pull
> > Request (which really means "this should be considered for
> > merging now"), and really what is probably better is to s
On Thu, 26 Apr 2018 01:19:59 +1000 Joshua Root
wrote:
> On 2018-4-26 00:44 , Perry E. Metzger wrote:
> > I tend to think it's a better way of working but it's up to the
> > community as a whole to say if it's really the right way to do
> > things. (If people really don't like it, I can hang back m
On 2018-04-25 21:02, Perry E. Metzger wrote:
> On Thu, 26 Apr 2018 01:19:59 +1000 Joshua Root
> wrote:
>> On 2018-4-26 00:44 , Perry E. Metzger wrote:
>>> I tend to think it's a better way of working but it's up to the
>>> community as a whole to say if it's really the right way to do
>>> things.
On Wed, 25 Apr 2018 21:40:46 +0200 Rainer Müller
wrote:
> This seems a problem that only occurs in the context of pull
> requests.
>
> I think the openmaintainer policy was intended for changes coming
> from other project members and not necessarily for patches coming
> from external contributors
On Wed, Apr 25, 2018 at 11:47:21AM -0500, Ryan Schmidt wrote:
On Apr 25, 2018, at 11:23, Chris Jones wrote:
I don't think there is any need to re-invent our own system here. There is an
already standard why of dong this, which is to declare the request as 'Work In
Progress'. This is trivially
On Apr 25, 2018, at 20:07, Zero King wrote:
> On Wed, Apr 25, 2018 at 11:47:21AM -0500, Ryan Schmidt wrote:
>> On Apr 25, 2018, at 11:23, Chris Jones wrote:
>>
>>> I don't think there is any need to re-invent our own system here. There is
>>> an already standard why of dong this, which is to de
On Wed, Apr 25, 2018 at 09:16:08PM -0500, Ryan Schmidt wrote:
On Apr 25, 2018, at 20:07, Zero King wrote:
On Wed, Apr 25, 2018 at 11:47:21AM -0500, Ryan Schmidt wrote:
On Apr 25, 2018, at 11:23, Chris Jones wrote:
I don't think there is any need to re-invent our own system here. There is an
On Apr 25 09:25:44, ken.cunningham.web...@gmail.com wrote:
> > We should allow (encourage even) WIP PRs to be submitted, when the work is
> > in a state that warrants it.
> >
> > Chris
>
> Personally i would think those would better be trac tickets, as that model
> seems to work better for comm
On Apr 25 11:46:42, ryandes...@macports.org wrote:
> When we switched to GitHub, we spent a lot of time considering whether to
> move our Trac tickets to GitHub Issues. Smaller macOS forge projects were
> happy with that change, but after careful consideration, we came to the
> conclusion that G
On 26 April 2018 at 08:21, Jan Stary wrote:
>
> What are the top three Trac features
> that Github issues don't have?
This is my personal list, others might have something different on
their priority list:
1.) Add labels for ports. This is a feature that GitHub issues have in
principle, but we co
On 26/04/18 07:52, Mojca Miklavec wrote:
On 26 April 2018 at 08:21, Jan Stary wrote:
What are the top three Trac features
that Github issues don't have?
This is my personal list, others might have something different on
their priority list:
1.) Add labels for ports. This is a feature that
On 26/04/18 07:19, Jan Stary wrote:
On Apr 25 09:25:44, ken.cunningham.web...@gmail.com wrote:
We should allow (encourage even) WIP PRs to be submitted, when the work is in a
state that warrants it.
Chris
Personally i would think those would better be trac tickets, as that model
seems to
On Apr 26, 2018, at 2:21 AM, Jan Stary wrote:
> What are the top three Trac features
> that Github issues don't have?
This has been discussed on the mailing list several times already - you should
probably search through the archives before demanding that someone take time
and rehash this for y
On Apr 26, 2018, at 01:52, Mojca Miklavec wrote:
> 3.) This is not a problem for new issues, but for migration of old
> issues: When attempting the initial migration, GitHub would not let us
> keep the original ticket numbering and would assign a semi-random
> number to the issues.
Providing a r
34 matches
Mail list logo
