Hello
Succesfully ran the portindex2json.
and saved it ino a json.
So what next?
On 25 April 2018 at 17:22, Mojca Miklavec wrote:
> On 25 April 2018 at 13:45, Vishnu wrote:
> > Hi
> >
> > I ran portindex.
> > It gives me 2 files Portindex and Portindex.quick
>
> I suggest to keep the discussio
On 25 April 2018 at 14:45, Vishnu wrote:
> Hello
>
> Succesfully ran the portindex2json.
> and saved it ino a json.
>
> So what next?
Wonderful, that's very good news, that will make it much easier to
proceed with the rest of the tasks.
Now:
- play a bit with "port search python", "port info pyth
On Tue, 24 Apr 2018 09:31:04 -0700 Ken Cunningham
wrote:
> Portfile authors need to manually "revbump" the library's dependent
> ports when supporting libraries change significantly.
>
> It's not automatically figured out by MacPorts.
Do we have a Trac issue for having it automatically determine
On Wed, 25 Apr 2018 04:43:12 +1000 Joshua Root
wrote:
> On 2018-4-25 03:56 , Ken Cunningham wrote:
> > Waiting for the maintainer to review the ticket submission
> > someday often resulted in months of nothing happening, or years.
>
> The maintainer timeout was 72 hours all along, so that's not
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:25 , Perry E. Metzger wrote:
> On Wed, 25 Apr 2018 04:43:12 +1000 Joshua Root
> wrote:
>> On 2018-4-25 03:56 , Ken Cunningham wrote:
>>> Waiting for the maintainer to review the ticket submission
>>> someday often resulted in months of nothing happening, or years.
>>
>> The maint
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
On 2018-4-26 01:10 , Joshua Root wrote:
> On 2018-4-26 00:25 , Perry E. Metzger wrote:
>> On Wed, 25 Apr 2018 04:43:12 +1000 Joshua Root
>> wrote:
>>> On 2018-4-25 03:56 , Ken Cunningham wrote:
Waiting for the maintainer to review the ticket submission
someday often resulted in months of
On Apr 25, 2018, at 10:10, Joshua Root wrote:
> On 2018-4-26 00:25 , Perry E. Metzger wrote:
>> On Wed, 25 Apr 2018 04:43:12 +1000 Joshua Root wrote:
>>> On 2018-4-25 03:56 , Ken Cunningham wrote:
Waiting for the maintainer to review the ticket submission
someday often resulted in months
On Apr 25, 2018, at 09:02, Perry E. Metzger wrote:
> On Tue, 24 Apr 2018 09:31:04 -0700 Ken Cunningham wrote:
>> Portfile authors need to manually "revbump" the library's dependent
>> ports when supporting libraries change significantly.
>>
>> It's not automatically figured out by MacPorts.
>
>
Hi
I think its best if you can create a repository under Macports.
I'll be coding there.
Also while trying to install mpstats .
I am getting these error
Warning: configured user/group macports does not exist, will build as root
---> Cleaning mpstats
---> Updating database of binaries
Warning:
So it looks like there's no way to dig out of the
protobuf-cpp/protobuf3-cpp mistake without having a minor amount of
pain.
Following raimue's suggestion documented in:
https://trac.macports.org/ticket/56135
what I'm going to do is obsolete both of those and replace them with
a "protobuf" port. In
On 2018-4-26 01:34 , Ryan Schmidt wrote:
>
> On Apr 25, 2018, at 09:02, Perry E. Metzger wrote:
>> On Tue, 24 Apr 2018 09:31:04 -0700 Ken Cunningham wrote:
>>> Portfile authors need to manually "revbump" the library's dependent
>>> ports when supporting libraries change significantly.
>>>
>>> It's
Great discussion!
My preference for my Openmaintainer ports are probably more conservative /
controlling than those listed already. For any change except comment fixing and
rev-bumps due to dependency ABI / API changes, I prefer there to be a PR that I
can review before committing. I prefer a P
On 2018-4-26 01:39 , Vishnu wrote:
> Hi
>
> I think its best if you can create a repository under Macports.
> I'll be coding there.
>
> Also while trying to install mpstats .
> I am getting these error
>
> Warning: configured user/group macports does not exist, will build as root
Our build syst
On 2018-04-25 17:10, Joshua Root wrote:
> On 2018-4-26 00:25 , Perry E. Metzger wrote:
>> On Wed, 25 Apr 2018 04:43:12 +1000 Joshua Root
>> wrote:
>>> On 2018-4-25 03:56 , Ken Cunningham wrote:
Waiting for the maintainer to review the ticket submission
someday often resulted in months of
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
Hi
Still same error..Dont know what to do.
On 25 April 2018 at 21:24, Joshua Root wrote:
> On 2018-4-26 01:39 , Vishnu wrote:
> > Hi
> >
> > I think its best if you can create a repository under Macports.
> > I'll be coding there.
> >
> > Also while trying to install mpstats .
> > I am getting
On 25 April 2018 at 17:54, Joshua Root wrote:
> On 2018-4-26 01:39 , Vishnu wrote:
>> Hi
>>
>> I think its best if you can create a repository under Macports.
>> I'll be coding there.
>>
>> Also while trying to install mpstats .
>> I am getting these error
>>
>> Warning: configured user/group macpo
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
On 2018-4-26 02:19 , Mojca Miklavec wrote:
> On 25 April 2018 at 17:54, Joshua Root wrote:
>> Our build system only knows how to create users on macOS. You'll have to
>> create the macports user manually.
>
> Should we at least place a more helpful message somewhere?
> Perhaps at the end of "make
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
Hi,
I've been wanting to ask for a long time already: wouldn't it be about
time to start switching to an explicit "closed maintainer" policy
instead?
That is: having to explicitly declare ports to be under a closed
maintainer policy, while keeping openmaintainer as default otherwise.
Of course th
On 2018-04-25, at 10:13 AM, Mojca Miklavec wrote:
> And if there's a need, we could of course define more levels of "how
> closed" a port should be. This is another case where for a lot of
> software updates are usually trivial, while for others it may break
> your system (say, when software switc
> 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
There's a port I suspect hasn't built in a long while. How can I
check on what is and isn't building on the buildbots?
--
Perry E. Metzgerpmetz...@macports.org
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
anyone?
On 25 April 2018 at 21:49, Vishnu wrote:
> Hi
>
> Still same error..Dont know what to do.
>
>
> On 25 April 2018 at 21:24, Joshua Root wrote:
>
>> On 2018-4-26 01:39 , Vishnu wrote:
>> > Hi
>> >
>> > I think its best if you can create a repository under Macports.
>> > I'll be coding the
Hi Vishnu,
On Thu, Apr 26, 2018 at 12:33 AM, Vishnu wrote:
> anyone?
>
> On 25 April 2018 at 21:49, Vishnu wrote:
>>
>> Hi
>>
>> Still same error..Dont know what to do.
>>
Could you please paste the error that you are getting somewhere e.g.,
dpaste.de ?
It would be really helpful if you join I
On Wed, 25 Apr 2018 10:33:28 -0500 Ryan Schmidt
wrote:
> I would consider many of those things to be changes that I would
> make even if the port is not openmaintainer. For example, if I
> update icu to a new library version, it is my responsibility to
> revbump all ports linking with icu, regardl
On Wed, 25 Apr 2018 10:34:47 -0500 Ryan Schmidt
wrote:
> On Apr 25, 2018, at 09:02, Perry E. Metzger wrote:
> > On Tue, 24 Apr 2018 09:31:04 -0700 Ken Cunningham wrote:
> >> Portfile authors need to manually "revbump" the library's
> >> dependent ports when supporting libraries change significan
On 2018-04-25, at 11:58 AM, Perry E. Metzger wrote:
> There's a port I suspect hasn't built in a long while. How can I
> check on what is and isn't building on the buildbots?
>
> --
> Perry E. Metzger pmetz...@macports.org
check packages.macports.org and see if it's there
and if
On Thu, 26 Apr 2018 01:46:27 +1000 Joshua Root
wrote:
> On 2018-4-26 01:34 , Ryan Schmidt wrote:
> >
> > On Apr 25, 2018, at 09:02, Perry E. Metzger wrote:
> >> On Tue, 24 Apr 2018 09:31:04 -0700 Ken Cunningham wrote:
> >>> Portfile authors need to manually "revbump" the library's
> >>> depen
It is exactly the same error as in previous one.
> ---> Cleaning mpstats
> ---> Updating database of binaries
> Warning: Error determining file type of `/opt/local/bin/captoinfo':
> invalid command name "fileIsBinary"
> Warning: A file belonging to the `ncurses' port is missing or
> unreadable.
On Wed, 25 Apr 2018 12:13:37 -0700 Ken Cunningham
wrote:
> On 2018-04-25, at 11:58 AM, Perry E. Metzger wrote:
>
> > There's a port I suspect hasn't built in a long while. How can I
> > check on what is and isn't building on the buildbots?
>
> check packages.macports.org and see if it's there
S
Yes I did add 'revupgrade_autorun no' line to
/opt/local/etc/macports/macports.conf
with sudo..
I cross checked it..it has been updated.
On 26 April 2018 at 00:54, Jackson Isaac wrote:
> On Thu, Apr 26, 2018 at 12:49 AM, Vishnu wrote:
> > It is exactly the same error as in previous one.
> >
>
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 Apr 25, 2018, at 14:14, Perry E. Metzger wrote:
> I don't know that this is needed. As I noted, there are other package
> systems that just note that they have to rebuild dependents if a
> package they depend on has a major version bump.
>
> Or maybe I don't understand the problem well enough
On Apr 25, 2018, at 14:26, Perry E. Metzger wrote:
> So the package in question is "rethinkdb",
> packages.macports.org doesn't seem to show the package there. Does
> that mean it indeed hasn't built in a long time?
In this case, it means rethinkdb is not distributable.
On Thu, Apr 26, 2018 at 1:02 AM, Vishnu wrote:
> these are the errors.
>
> On 26 April 2018 at 00:59, Vishnu wrote:
>>
>> Yes I did add 'revupgrade_autorun no' line to
>> /opt/local/etc/macports/macports.conf
>> with sudo..
>> I cross checked it..it has been updated.
>>
It's been quite some tim
On Wed, 25 Apr 2018 14:40:55 -0500 Ryan Schmidt
wrote:
> On Apr 25, 2018, at 14:14, Perry E. Metzger wrote:
>
> > I don't know that this is needed. As I noted, there are other
> > package systems that just note that they have to rebuild
> > dependents if a package they depend on has a major versi
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 Apr 25 14:44:51, ryandes...@macports.org wrote:
>
> On Apr 25, 2018, at 14:26, Perry E. Metzger wrote:
>
> > So the package in question is "rethinkdb",
>
> > packages.macports.org doesn't seem to show the package there. Does
> > that mean it indeed hasn't built in a long time?
>
> In this ca
On Apr 24 09:31:04, ken.cunningham.web...@gmail.com wrote:
> Portfile authors need to manually "revbump"
> the library's dependent ports when
> supporting libraries change significantly.
> It's not automatically figured out by MacPorts.
Wait, what? I'm still relatively new to MP
and this seems a b
Finally was able to install it.
And successfully run mpstats.
root@vishnupc:~# /opt/local/bin/port content mpstats
Port mpstats contains:
/Library/LaunchDaemons/org.macports.mpstats.plist
/opt/local/etc/LaunchDaemons/org.macports.mpstats/org.macports.mpstats.plist.default
/opt/local/etc/macpo
On Apr 25 10:34:47, ryandes...@macports.org wrote:
>
> On Apr 25, 2018, at 09:02, Perry E. Metzger wrote:
> > On Tue, 24 Apr 2018 09:31:04 -0700 Ken Cunningham wrote:
> >> Portfile authors need to manually "revbump" the library's dependent
> >> ports when supporting libraries change significantly.
On Apr 25 15:14:56, pmetz...@macports.org wrote:
> On Thu, 26 Apr 2018 01:46:27 +1000 Joshua Root
> wrote:
> > On 2018-4-26 01:34 , Ryan Schmidt wrote:
> > >
> > > On Apr 25, 2018, at 09:02, Perry E. Metzger wrote:
> > >> On Tue, 24 Apr 2018 09:31:04 -0700 Ken Cunningham wrote:
> > >>> Portfi
On Apr 25, 2018, at 17:14, Jan Stary wrote:
> On Apr 25 10:34:47, Ryan Schmidt wrote:
>
>> On Apr 25, 2018, at 09:02, Perry E. Metzger wrote:
>>> On Tue, 24 Apr 2018 09:31:04 -0700 Ken Cunningham wrote:
Portfile authors need to manually "revbump" the library's dependent
ports when supp
On Apr 25, 2018, at 16:50, Jan Stary wrote:
> On Apr 25 14:44:51, Ryan Schmidt wrote:
>
>> On Apr 25, 2018, at 14:26, Perry E. Metzger wrote:
>>
>>> So the package in question is "rethinkdb",
>>
>>> packages.macports.org doesn't seem to show the package there. Does
>>> that mean it indeed hasn
It seems that maintainership is regarded as a status symbol in MP:
the guy who sleeps with this Portfile. That's strange.
Anyone can improve a port, be it a typo or a fundamental fix.
Instead, it's supposed to be a responsibility.
Out of all the people who can better this port for fun and profit,
> I test/verify on (currently) 10.5 PPC through 10.13 Intel (actual hardware;
> not just a VM; 10.4 PPC & 10.5 Intel coming soon). Hence I'm very likely to
> find and correct any build issues with my ports (and some others) and provide
> fixes that work across the various OSXs.
Cool. Do you hav
So ... what you're "voting" for here is that -any- change to a port be via a PR
or ticket with patch ... that only maintainers can touch ports they are named
on?
On Wed, Apr 25, 2018, at 6:49 PM, Jan Stary wrote:
> If you have an idea about a port,
> implement it (test it, etc) and propose it.
>
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 2018-04-26 00:11, Jan Stary wrote:
> On Apr 24 09:31:04, ken.cunningham.web...@gmail.com wrote:
>> Portfile authors need to manually "revbump"
>> the library's dependent ports when
>> supporting libraries change significantly.
>> It's not automatically figured out by MacPorts.
>
> Wait, what? I
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
I'm not working on this problem. There are far too many other things that I
already intend to be working on. My questions were just meant to prompt thought
about whether MacPorts currently provides the information required to implement
the feature. My belief is that it does not, but I am not spe
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
Hi Vishnu,
On Thu, Apr 26, 2018 at 3:42 AM, Vishnu wrote:
> Finally was able to install it.
> And successfully run mpstats.
Great to hear that! You are making a good progress. Keep it up.
> root@vishnupc:~# /opt/local/bin/port content mpstats
> Port mpstats contains:
> /Library/LaunchDaemons
Dear Vishnu,
On 26 April 2018 at 06:44, Jackson Isaac wrote:
> On Thu, Apr 26, 2018 at 3:42 AM, Vishnu wrote:
>> Finally was able to install it.
>> And successfully run mpstats.
>
> Great to hear that! You are making a good progress. Keep it up.
>
>> root@vishnupc:~# /opt/local/bin/port content m
On 26 April 2018 at 00:34, Ryan Schmidt wrote:
> On Apr 25, 2018, at 17:14, Jan Stary wrote:
>>
>> Keep a record of what depends on what (as packaging managers do).
>> If A depends on B, and B has been rebuilt, reduild A too.
>> No "revision bump"; port A as such has not changed.
>
> MacPorts does
On Apr 26 03:16:37, rai...@macports.org wrote:
> On 2018-04-26 00:11, Jan Stary wrote:
> > On Apr 24 09:31:04, ken.cunningham.web...@gmail.com wrote:
> >> Portfile authors need to manually "revbump"
> >> the library's dependent ports when
> >> supporting libraries change significantly.
> >> It's no
>
> For comparison, the OpenBSD port system has resigned on upstreams'
> library versioning, and versions the libraries itself. For example,
> in audio/libsndfile (1.0.28):
>
> SHARED_LIBS += sndfile 6.0 # .1.28
>
> and it installs /usr/local/lib/libsndfile.so.6.0.
BTW, what's with t
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, 2018, at 22:48, Jan Stary wrote:
>
> The packages that were installed before get rebuilt
> with port rev-upgrade, automatically,
> without anyone touching their Portfile.
Well the idea is that download a prebuilt packaged binary, not revupgrade and
build them all yourself
K
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
81 matches
Mail list logo
