Fwd: [GSoC Mentors] Announcing GSoC 2021 with a few changes

[Mojca Miklavec]

-- Forwarded message -

Hello GSoC Mentors and Org Admins,

We are pleased to announce Google Summer of Code 2021 <http://g.co/gsoc>,
the 17th consecutive year of the program!

As many of you might have heard if you attended the Mentor Summit a couple
of weeks ago (or chatted with someone who did) we are making a few changes
for the 2021 program. We’ve spent a lot of time evaluating the GSoC program
and have been looking at where we can make some changes to help meet the #1
goal of GSoC - bring new, diverse contributors into your communities that
stay in your communities after their GSoC program ends. And with the
challenges of the pandemic and the strains it has put on everyone’s time
(students, mentors and org admins alike) we are looking to provide more
flexibility in 2021.

What are the changes for 2021 from 2020?

   1. *Smaller project size** - *all students participating in the 2021
   program will be working on a 175 hour project (instead of a 350 hr
   project). This change will also result in a few other changes including the
   student stipend being cut in half.


   - Currently we are missing out on many wonderful students who could
   never commit to such a huge project and time commitment but would be great
   contributors to your community. This is a significant change as we now are
   no longer strongly encouraging students to focus only on GSoC over their
   summer. Students have many other responsibilities especially during the
   pandemic that make it hard for them to spend 30 hours a week on a project.
   - We realize this is going to require all of you to think about smaller
   projects and update your project ideas which is why we wanted to give you
   3+ months to start talking it through with your communities.
   - The mentor stipends will be adjusted to $400 per student mentored. In
   feedback from the mentor summit it was pointed out that the effort from
   mentors will not be half as much even though the project size is cut in
   half so we adjusted from $250 to $400.


   1. *Shortened coding period* - the *coding period will be 10 weeks* with
   a lot more flexibility for the mentor and student to decide together how
   they want to spread the work out over the summer. Some folks may choose to
   stick to a 17-18 hour a week schedule with their students, others may
   factor in a couple of breaks during the program (for student and mentor)
   and some may have students focus 30 hours a week on their project so they
   wrap up in 6 weeks. This also makes it a lot easier for students with
   finals or other commitments (weddings, etc.) to adjust their schedules.
   2.

   *2 evaluations  (instead of 3)* - There will be an evaluation after 5
   weeks and the final evaluation will take place after the 10th week. We are
   also no longer requiring students complete their first evaluation (though
   we encourage them to do so), so if a student doesn’t complete the first
   evaluation they will not automatically be removed from the program. They
   are still required to complete the final evaluation.
   3.

   *Eligibility requirements* - In 2020 there are many ways students are
   learning and we want to acknowledge that so we will be allowing students
   who are 18 years old AND currently enrolled (or accepted into) a
   post-secondary academic program as of May 17, 2021 or have graduated from a
   post-secondary academic program between December 1, 2020 and May 17, 2021
   to apply to the GSoC program.


   - What this means is that now the program will be open to folks
   participating in a variety of different academic programs, not just
   accredited university programs. This includes licensed coding camps,
   community colleges, and many other programs that may not be accredited yet
   but are post-secondary academic programs.

These changes were made to help find more diverse students who we hope will
stay involved in your communities after their GSoC ends. We look forward to
these changes and will definitely be getting feedback from all of you as
the 2021 program goes on to see what is working and what we should consider
adjusting for any possible future program.

The program announcement
<https://opensource.googleblog.com/2020/10/google-summer-of-code-2021-is-bringing.html>
, timeline <https://developers.google.com/open-source/gsoc/timeline>,
marketing materials
<https://developers.google.com/open-source/gsoc/resources/marketing> (slide
deck, flyers), FAQs <https://developers.google.com/open-source/gsoc/faq>,
and short videos <https://developers.google.com/open-source/gsoc/videos>
with tips for mentors and students are all available. You'll also notice
the 2020 program has now been archived
<https://summerofcode.withgoogle.com/archive/2020/organizations/>.

*Organizations* -- If you would like to apply for the 2021 program please
start thinking about the ~175 hr projects you would like students to work
on and also 

GSOC 2020 & web app improvements

[Mojca Miklavec]

Dear Arjun, dear MacPorters,

I would like to congratulate Arjun for being accepted into GSOC 2020
with the project of improving the ports.macports.org website. He has
already been with us last year and made an awesome tool which he's
about to improve this year. We are also enormously helpful to have an
external expert on board, Amar Takhar, who volunteered to mentor the
project and without whom we really couldn't have done this, along with
Rajdeep who participated as a student last year.

Due to specific situation this year and the uncertainty of the
government and university rescheduling the semester, Arjun already
started working at full speed while at home, so the summer might end
up a bit earlier than officially scheduled.

The code is being developed inside the existing repository
https://github.com/macports/macports-webapp/
The temporary site will run at
http://macports.silentfox.tech/
In addition to the communication via the mailing list we'll try using
the real-time chat at
https://chat.macports.org/channel/webapp
I'll ask Arjun to keep the list up-to-date with at least bi-weekly
emails, but feel free to join the chat or ask further questions at any
time.

The initial phase mostly concentrates on refactoring, speeding up and
cleaning up the code, also in order to make it easier for others to
contribute new code, while new features will be added once the code
base gets solid.

We received five proposals in total. I would like to thank all the
other students who applied this year. We were slightly more
conservative with the selection this year than we usually are,
partially due to the uncertain circumstances. We are still willing to
help you and work with you outside of the official GSOC program, so if
you would like to proceed with the projects, we will gladly help you
on the way.

Also a big thanks to all the volunteer mentors and org admin.

Mojca

Re: GSoC Proposal: Rewrite key parts of MacPorts in Python

[Ralph Seichter]

* Mojca Miklavec:

> I would not dismiss the initial effort as a GSOC project as long as
> the student can prove the competence to do some good work and
> reasonable potential to stick with the project afterwards.

The way I understand GSoC projects is that smaller, self-contained work
is preferred. Rewriting MacPorts is way out of scope for that. It is too
big a task for a "summer" project, requires solid knowledge about the
existing MacPorts environment and experience in software design. I would
not entrust a student with that type of work.

-Ralph

Re: GSoC Proposal: Rewrite key parts of MacPorts in Python

[Mojca Miklavec]

Hi,

On Thu, 2 Apr 2020 at 20:37, Joshua Root wrote:
>
> I would say it's OK for a GSoC project to be completely original and
> never discussed before; the problem with this one is just the scope. You
> would need to spend the entire summer (if not more) just doing design in
> order to do it right, but the primary assessable output of the project
> is code. Naturally you need to do some design before you code, and other
> tasks like documentation of the code, but you need to write the code.
>
> It's also OK for a GSoC project to have research elements. A successful
> project may produce code that never actually gets put into production --
> maybe in the course of implementation it becomes clear that the entire
> approach is flawed. Learning that is still valuable.
>
> In this particular case, if the student can suggest a subset of the
> project with a small enough scope to be completed over the summer, that
> will still produce working code, it could be considered. I have no idea
> what that would look like, but it may be possible. As Ryan implied, an
> important question is "Which parts should be rewritten in Python, and why?"
>
> - Josh

I just want to say that I completely agree with Josh here.

I would love to see MacPorts (re)written in Python, this has been my
wish since years, but I realize that I neither have sufficient
expertise nor time to do it (I guess I could gain the expertise, but
that would again require insane amounts of time). And it's not like we
have an army of developers willing to do this at this very moment, but
if it was written in Python (in a nicely structured way), I guess that
the number of contributors to base would grow quite a bit.

I would say that the main reason why this hasn't been discussed (loud)
before is that developers understand how much work this is, and it
takes quite some expertise and quite some work to get it done right.
And rewriting is probably even more challenging than writing it from
scratch, since one would want to keep compatibility with the existing
packages, and ideally reproduce the exact same results. (We did in
fact discuss this during the last meeting, but not as realistic to
happen any time soon.)

But it's not entirely impossible to do it either. I mean ... MacPorts
base has been written at some point. HomeBrew has been written at some
point. Plenty of other package managers have been written from scratch
at some point. I would not dismiss the initial effort as a GSOC
project as long as the student can prove the competence to do some
good work and reasonable potential to stick with the project
afterwards. GSOC could be done partially as a research project. But
it's of course critical to have a very good student working on this.

If we would ever want to have the base rewritten (independent of
whether or not it happens in the scope of GSOC) and not want to end up
with yet another competitor to MacPorts, we would want to keep the
Portfile syntax working (one could later remove some hard-core tcl
from ports if there was an alternative to achieve the same). One could
potentially start with using Python to add useful new functionality
that's still missing and is either very annoying to write in Tcl, or
has a bigger contributor potential if written in Python; we could for
example support something like "port health " that would
fetch the data from the web api and report to the user whether the
port and its dependencies are know to build or break, whether there
are any critical bugs open in Trac, ... (just as a random example).
Some further action could later be replaced step by step, and in
parallel some bottom-up design would need to be built in Python to
slowly migrate over. (I'm not competent enough to mentor such a
project though.)

It's definitely not an easy task, but if the student can prove
competence to solve some problems in a superior way ...

Mojca

Re: GSoC Proposal: Rewrite key parts of MacPorts in Python

[Joshua Root]

On 2020-4-3 04:52 , Jackson Isaac wrote:
> Hi Ryan,
> 
> Thanks for your valuable insights and I really appreciate the detailed
> feedback. I didn't realize these things before and the efforts that
> went into creating and maintaining such a great project.
> 
> I sincerely apologize to the community and also to the student for my
> ignorance and the fact that I didn't discuss this before in detail on
> the mailing list and understand the implications that it would make
> before putting anything on the ideas page.
> 
> It was a pre-mature action from my side, and my intention was not to
> hurt anyone. This was also a learning for me personally to not put
> things in place without much thought, discussion and understanding.

I would say it's OK for a GSoC project to be completely original and
never discussed before; the problem with this one is just the scope. You
would need to spend the entire summer (if not more) just doing design in
order to do it right, but the primary assessable output of the project
is code. Naturally you need to do some design before you code, and other
tasks like documentation of the code, but you need to write the code.

It's also OK for a GSoC project to have research elements. A successful
project may produce code that never actually gets put into production --
maybe in the course of implementation it becomes clear that the entire
approach is flawed. Learning that is still valuable.

In this particular case, if the student can suggest a subset of the
project with a small enough scope to be completed over the summer, that
will still produce working code, it could be considered. I have no idea
what that would look like, but it may be possible. As Ryan implied, an
important question is "Which parts should be rewritten in Python, and why?"

- Josh

Re: GSoC Proposal: Rewrite key parts of MacPorts in Python

[Jackson Isaac]

Hi Ryan,

On Thu, Apr 2, 2020 at 3:44 AM Ryan Schmidt  wrote:
>
> On Apr 1, 2020, at 18:20, Ryan Schmidt wrote:
>
> > On Mar 31, 2020, at 16:14, Alex Ionkov wrote:
> >
> >> I submitted a proposal this year for rewriting parts of MacPorts in 
> >> Python. The eventual goal is to rewrite all of MacPorts in Python to 
> >> increase modularity and make integration of other APIs with MacPorts 
> >> easier.
> >
> > Is this an idea you just came up with or has there been some discussion of 
> > this before? I didn't see this idea on our GSoC page [1] and it comes as a 
> > surprise to me.
> >
> > [1] https://trac.macports.org/wiki/SummerOfCode#Projects
>
> I see now that it is actually on the list, as just a one-line item:
>
> https://trac.macports.org/wiki/SummerOfCode?action=diff=337_version=336
>
> So then my comments are not so much about your proposal, Alex, as it is about 
> the fact that this item got onto the list at all.
>
>
> MacPorts has 18 years worth of Tcl code which not even us long-time MacPorts 
> developers fully understand. It works as is, and in the spirit of not 
> modifying a working system, my inclination would be not to change it. I may 
> not know where everything is or how everything works in MacPorts base, but I 
> know where many things are and how many things work, and I fear that 
> knowledge would be lost if it were rewritten.  Certainly we should fix bugs. 
> Certainly we should make incremental improvements like whatever is necessary 
> to allow us to update to Tcl 8.6 (i.e. fix the "catch" problem). But 
> rewriting MacPorts wholesale in another programming language seems completely 
> infeasible to me.
>
> I'm sure that rewriting MacPorts base would introduce new bugs, and I'm not 
> confident that our existing test suite would be adequate to catch them. In 
> fact, our test suite is written in Tcl, so there's double the possibility of 
> missing bugs: either because the test suite didn't cover a particular 
> scenario or because rewriting the test suite in Python introduced new bugs 
> into it.
>
> It's not just rewriting MacPorts base either. The more than 10,000 portfiles 
> and the portgroups are also written in Tcl. Should they all be rewritten in 
> Python as well? Doing that manually would take colossal effort, and doing it 
> automatically would require writing a fairly full-featured Tcl-to-Python 
> converter. Or if you propose that the portfiles should be kept in Tcl, then 
> that means Python would have to launch Tcl to interpret each portfile, which 
> seems unnecessarily more complex than what we have now. Using yet another 
> programming language in MacPorts makes it that much harder for new developers 
> to get up to speed.
>
> Note that Tcl was deliberately chosen because of its simple syntax. If we 
> convert portfiles to Python, would that make basic everyday usage more 
> verbose and if so do we really want that? As one specific example, setting 
> the name of a port to "foo" is currently as simple as writing:
>
> name foo
>
> If portfiles become Python files, I am guessing that would have to be 
> rewritten as:
>
> name = 'foo'
>
> and that kind of superfluous punctuational verbosity is what the original 
> designers of MacPorts were trying to avoid.
>
> There are also a lot of little utilities in the macports-contrib repository 
> that hook into MacPorts via Tcl. Our buildbot setup uses several more such 
> scripts developed just for that purpose. All of these would then need to be 
> rewritten in Python.
>
> Needless to say, this also requires a thorough understanding of Python, both 
> to perform this massive one-time conversion and then on an ongoing basis by 
> all MacPorts developers and maintainers. Maybe many people are already 
> familiar with Python, but some MacPorts developers like myself are more 
> familiar with Tcl at this point. Perhaps we could all retrain ourselves to 
> learn Python. But I can't help but recall how four years ago we undertook the 
> massive conversion of our source code from Subversion to GitHub, from which I 
> still haven't fully recovered; I still can't contribute to MacPorts as 
> effectively anymore as I did when we used Subversion. I'm probably in the 
> minority there as other developers were already familiar with git at the 
> time, and if everybody else wants MacPorts rewritten in Python and it can be 
> done then I won't stand in the way.
>
> I don't recall any of this discussion occurring on the mailing list before. I 
> usually stay away from Google Summer of Code issues, but I would have hoped 
> that GSoC would be used as an opportunity for us to finally implement changes 
> th

Re: GSoC Proposal: Rewrite key parts of MacPorts in Python

[Ralph Seichter]

* Ryan Schmidt:

> [...] I would have hoped that GSoC would be used as an opportunity for
> us to finally implement changes that we have wanted to do for years
> but never got around to doing, rather than to propose new projects
> whose ramifications have never been discussed before.

Quite so. Not meaning any disrespect to Alex (I have never seen any of
his code), but if the developer team would actually let him have a shot
at rewriting parts of MacPorts in Python, I'd look for ways to sever my
connections with MacPorts. Homebrew seems nice.

My own experience in software development spans more than 35 years, some
of them focused on Python, and think that rewriting significant aspects
of MacPorts in Python is neither desirable nor an achievable goal for a
"summer of code". Proper design alone with all its necessary peer review
stages could take months.

My advice to GSoC participants: Choose a smallish task with clearly
defined goals that can be completed and documented in the alotted time.
Work to meet the highest quality standards, and actually make life a
little better for end users. Don't aim for the stars. MacPorts devs
have spent many, many years on the existing ecosystem, and while there
is of course room for improvement, proposing a rewrite is, as far as I
am personally concerned, a mere demonstration of bravado that does not
inspire confidence in me.

-Ralph

Re: GSoC Proposal: Rewrite key parts of MacPorts in Python

[Ryan Schmidt]

On Apr 1, 2020, at 18:20, Ryan Schmidt wrote:

> On Mar 31, 2020, at 16:14, Alex Ionkov wrote:
> 
>> I submitted a proposal this year for rewriting parts of MacPorts in Python. 
>> The eventual goal is to rewrite all of MacPorts in Python to increase 
>> modularity and make integration of other APIs with MacPorts easier. 
> 
> Is this an idea you just came up with or has there been some discussion of 
> this before? I didn't see this idea on our GSoC page [1] and it comes as a 
> surprise to me.
> 
> [1] https://trac.macports.org/wiki/SummerOfCode#Projects

I see now that it is actually on the list, as just a one-line item:

https://trac.macports.org/wiki/SummerOfCode?action=diff=337_version=336

So then my comments are not so much about your proposal, Alex, as it is about 
the fact that this item got onto the list at all.


MacPorts has 18 years worth of Tcl code which not even us long-time MacPorts 
developers fully understand. It works as is, and in the spirit of not modifying 
a working system, my inclination would be not to change it. I may not know 
where everything is or how everything works in MacPorts base, but I know where 
many things are and how many things work, and I fear that knowledge would be 
lost if it were rewritten.  Certainly we should fix bugs. Certainly we should 
make incremental improvements like whatever is necessary to allow us to update 
to Tcl 8.6 (i.e. fix the "catch" problem). But rewriting MacPorts wholesale in 
another programming language seems completely infeasible to me.

I'm sure that rewriting MacPorts base would introduce new bugs, and I'm not 
confident that our existing test suite would be adequate to catch them. In 
fact, our test suite is written in Tcl, so there's double the possibility of 
missing bugs: either because the test suite didn't cover a particular scenario 
or because rewriting the test suite in Python introduced new bugs into it.

It's not just rewriting MacPorts base either. The more than 10,000 portfiles 
and the portgroups are also written in Tcl. Should they all be rewritten in 
Python as well? Doing that manually would take colossal effort, and doing it 
automatically would require writing a fairly full-featured Tcl-to-Python 
converter. Or if you propose that the portfiles should be kept in Tcl, then 
that means Python would have to launch Tcl to interpret each portfile, which 
seems unnecessarily more complex than what we have now. Using yet another 
programming language in MacPorts makes it that much harder for new developers 
to get up to speed.

Note that Tcl was deliberately chosen because of its simple syntax. If we 
convert portfiles to Python, would that make basic everyday usage more verbose 
and if so do we really want that? As one specific example, setting the name of 
a port to "foo" is currently as simple as writing:

name foo

If portfiles become Python files, I am guessing that would have to be rewritten 
as:

name = 'foo'

and that kind of superfluous punctuational verbosity is what the original 
designers of MacPorts were trying to avoid.

There are also a lot of little utilities in the macports-contrib repository 
that hook into MacPorts via Tcl. Our buildbot setup uses several more such 
scripts developed just for that purpose. All of these would then need to be 
rewritten in Python.

Needless to say, this also requires a thorough understanding of Python, both to 
perform this massive one-time conversion and then on an ongoing basis by all 
MacPorts developers and maintainers. Maybe many people are already familiar 
with Python, but some MacPorts developers like myself are more familiar with 
Tcl at this point. Perhaps we could all retrain ourselves to learn Python. But 
I can't help but recall how four years ago we undertook the massive conversion 
of our source code from Subversion to GitHub, from which I still haven't fully 
recovered; I still can't contribute to MacPorts as effectively anymore as I did 
when we used Subversion. I'm probably in the minority there as other developers 
were already familiar with git at the time, and if everybody else wants 
MacPorts rewritten in Python and it can be done then I won't stand in the way.

I don't recall any of this discussion occurring on the mailing list before. I 
usually stay away from Google Summer of Code issues, but I would have hoped 
that GSoC would be used as an opportunity for us to finally implement changes 
that we have wanted to do for years but never got around to doing, rather than 
to propose new projects whose ramifications have never been discussed before.

Re: GSoC Proposal: Rewrite key parts of MacPorts in Python

[Ryan Schmidt]

On Mar 31, 2020, at 16:14, Alex Ionkov wrote:

> I submitted a proposal this year for rewriting parts of MacPorts in Python. 
> The eventual goal is to rewrite all of MacPorts in Python to increase 
> modularity and make integration of other APIs with MacPorts easier. 

Is this an idea you just came up with or has there been some discussion of this 
before? I didn't see this idea on our GSoC page [1] and it comes as a surprise 
to me.

[1] https://trac.macports.org/wiki/SummerOfCode#Projects

Re: GSoC Proposal: Rewrite key parts of MacPorts in Python

[Ruben Di Battista]

I have no experience to gave you any valuable help on this Alex, just wanted to 
drop some ideas I have in mind. 

I work in the frame of HPC computing and I’m a heavy user of spack 
(https://spack.readthedocs.io/en/latest/). It’s a package manager tailored for 
HPC that shares more than few features and design approach with Macports.
 
- It compiles for Unixes on different architectures (Including Power) and on 
Mac.
- has lots of optimized packages for specific architectures 
- Isolated spack environments and filesystem views

I would argue is a bit less stable for daily use as we do with Macports, but I 
find the packages very pleasant to write and the community is vibrant. So I 
would like to tell you to consider, maybe, to base your eventual work on that. 
Maybe making Macports packages compatible with their API or also using their 
infrastructure and strip most of the HPC-related features replacing them with 
the few, unique, feature Macports provides. Maybe discussing with them on the 
best approach to use their work in order to avoid to reinvent the wheel could 
be beneficial. I think the approach would be probably based on their spack 
environments/view (https://spack.readthedocs.io/en/latest/environments.html).

One of the proposed issues over there is to turn the actual spack “binary” into 
a library that other projects can leverage. Could it be feasible way to 
integrate a mature ecosystem with Macports? Maybe other people from the 
community could give it a look and express their opinion on that. 

Good luck! 

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is

On 31 March 2020 at 23:15:02, Alex Ionkov (aion...@gmail.com) wrote:

Dear MacPorts community, 

I submitted a proposal this year for rewriting parts of MacPorts in Python. The 
eventual goal is to rewrite all of MacPorts in Python to increase modularity 
and make integration of other APIs with MacPorts easier. 

I've attached my proposal. As for some edits that have already been recommended 
to me for more measurable goals, by each evaluation I would want to have 
rewritten an X amount of functions or functionality. 

What I would request from the community is advice on which functions would be 
the most valuable and useful and how to split them among the evaluation 
periods. Some recommendations that I have received already include getting 
information from the webapp to implement functionality that is not yet 
available and also rewriting functions such as fetch, dependency calculation, 
livecheck and install.

I'm currently working on integrating a small Python script which tells you the 
latest successful build of a port with the Tcl source as a proof of concept.

Thank you very much for your time,
Alex Ionkov

signature.asc
Description: Message signed with OpenPGP using AMPGpg

GSoC Proposal: Rewrite key parts of MacPorts in Python

[Alex Ionkov]

Dear MacPorts community,

I submitted a proposal this year for rewriting parts of MacPorts in Python.
The eventual goal is to rewrite all of MacPorts in Python to increase
modularity and make integration of other APIs with MacPorts easier.

I've attached my proposal. As for some edits that have already been
recommended to me for more measurable goals, by each evaluation I would
want to have rewritten an X amount of functions or functionality.

What I would request from the community is advice on which functions would
be the most valuable and useful and how to split them among the evaluation
periods. Some recommendations that I have received already include getting
information from the webapp to implement functionality that is not yet
available and also rewriting functions such as fetch, dependency
calculation, livecheck and install.

I'm currently working on integrating a small Python script which tells you
the latest successful build of a port with the Tcl source as a proof of
concept.

Thank you very much for your time,
Alex Ionkov


MacPorts Summer Of Code Application.pdf
Description: Adobe PDF document

Thank you for applying for GSOC @ MacPorts

[Mojca Miklavec]

Dear students,

(I have put everyone in Bcc just in case, even though you are
generally encouraged to use public communication.)

I would like to thank each and every one of you for applying for the
GSOC 2020. We have received 5 applications this year (I'm sorry for my
own absence during this period), and the mentors are expected to
review them in the following days. The official results about the
selection process will be revealed on the 4th of May. The students are
encouraged to stay involved with the community both before and after
the official coding time.

While the official deadline for submission of the proposals is now
over, I would like to stress out that apart from the proposals
themselves, by far the most important criteria for selecting the
candidates will be showcasing your skillset through some
proof-of-concept code or via pull requests, depending on what project
you are targeting and in coordination with mentors. Last year most of
the activity happened already during the proposal submissions (I would
say that most of the last year's students contributed enough to get
them passed through the 1st evaluation before the coding even began
:), while many proposals arrived much later this year, so we would be
willing to give everyone cca. 2 weeks extra time to showcase your
work. Some projects are pretty demanding, so we would like to make
sure that the candidates can cope with all the challenges.

For Buildbot the contact persons are Povilas, Pierre & Amar (but maybe
use #buildbot on IRC and the buildbot mailing list), for MacPorts
base/core the contact persons are Marcus & Sat, for Django it is Amar
& Rajdeep (& me). Jackson serves as the admin. Again, I believe that
the mailing list might be more suitable than private emails if you
want to get more feedback from the community.

Mojca

GSoC Proposal: Enhancing the webapp

[Arjun Salyan]

Dear Macports community,

Last year during GSoC 19, I wrote the ports webapp under the mentorship of
Mojca and Umesh, we had a functional app by the end of the GSoC period. The
app still needs a lot of improvements- codebase needs to be improved so
that new maintainers can start quickly, more features have to be added,
page load time needs to be taken care of, API and documentation also need
to be completed.

I am also planning to deploy Buildbot 2 to carry out real builds as a part
of this project. The main priority of the project would be to have a robust
webapp by the end of the period. My familiarity with the codebase could be
helpful.

I have shared the draft proposal through the GSoC portal and also attaching
the link below. Any feedback would be constructive- the deadline is
tomorrow (31st March, 18:00 UTC).

https://docs.google.com/document/d/1gFxE-8fhZUm98IZ4R0X0Q6-BkHiYG0R4xj3WtKLbt8E/edit?usp=sharing

Thank You

Re: Submitted the GSoC Proposal

[Vibhansh Gupta]

Here's the link to the document by the way :
A
https://docs.google.com/document/d/1c2DkaHLueqMrY66n-l3nvHecVgsezD2XOR8iaF-kkH4/edit?usp=drivesdk

On Tue, Mar 24, 2020, 4:04 AM Vibhansh Gupta  wrote:

> Hey everyone !
>
> I finally submitted my proposal on the Google Sumer of Code website.
> Please do let me know your thoughts on it, either on the Google Doc as
> comments or via mail.
>
> Either way, I will be grateful for any and for all of your thoughts and
> advice on it. I am super pumped to work and hope you like the ideas I’ve
> presented. Any additional ideas are of course always welcome.
>
> PS, should I attach the link to the Document or upload the PDF here?
>
> Hoping to Hear from you super soon,
> Vibhansh.

[GSoC 2020] Student Application Deadline (Was: Application Template for aspiring students)

[Jackson Isaac]

Dear Aspiring GSoC Students,

Hope you all are doing well. This is a friendly reminder for the
Student Application deadline i.e., 31st March 2020 1800 UTC.

Make sure you submit your 'Final' proposal to the portal, in order to
be eligible for GSoC, before the deadline.

I hope you have been in contact with potential mentors and have
already received feedback.

Feel free to reach out to me if you need any guidance.

On Fri, Mar 20, 2020 at 7:49 AM Jackson Isaac  wrote:
>
> Dear Aspiring GSoC Students,
>
> The application period has begun on GSoC portal. There is less than 2
> weeks left for the student application deadline (31st March 2020).
>
> We recommend to add your draft proposals on the portal as early as
> possible, so you can get feedback from potential mentors on questions
> or suggestions to improve the proposal further.
>
> To help you get started, here[1] is a GSoC application template that
> we have used in previous years as well, feel free to use it, add or
> remove (sub-)sections.
>
> Also, a guideline on what we expect from a project application [2].
>
> [1] https://trac.macports.org/wiki/SummerOfCodeApplicationTemplate
> [2] 
> https://trac.macports.org/wiki/SummerOfCode#Whatweexpectfromstudentsfortheirapplications
>
> Hope this helps. Please feel free to contact us if you have any questions.
>

Stay safe,
Jackson Isaac

Submitted the GSoC Proposal

[Vibhansh Gupta]

Hey everyone !

I finally submitted my proposal on the Google Sumer of Code website. Please do 
let me know your thoughts on it, either on the Google Doc as comments or via 
mail.

Either way, I will be grateful for any and for all of your thoughts and advice 
on it. I am super pumped to work and hope you like the ideas I’ve presented. 
Any additional ideas are of course always welcome.

PS, should I attach the link to the Document or upload the PDF here?

Hoping to Hear from you super soon,
Vibhansh.

Re: GSoC 2020 (Samartha S M)

[Rajdeep Bharati]

Hi Samartha,
IMHO the proposal looks good. I guess it would help if you also add a
protocol specification in the proposal.
Also, you could play with the master-worker API
<https://docs.buildbot.net/latest/developer/master-worker.html> to
understand it better. @Povilas Kanapickas  is it feasible
to build a POC in the next few weeks?

Thanks & Regards
Rajdeep

On Fri, Mar 20, 2020 at 3:12 PM Samartha S M 
wrote:

> I've uploaded draft proposal in GSoC proposal submission portal also.
>
> Please give inputs from your side, so that I can improve my proposal.
>
> Thanks and regards
> Samartha S M
>
> On Fri 20 Mar, 2020, 12:08 PM Samartha S M, 
> wrote:
>
>> I've attached draft proposal. PFA
>>
>> On Fri 20 Mar, 2020, 12:05 PM Samartha S M, 
>> wrote:
>>
>>> Hello Buildbot community,
>>>
>>> I'm really excited to work with you on this project.
>>>
>>> I've attached a draft proposal for this project.
>>> I would request you to review it and suggest any improvements to it.
>>>
>>> I would request anyone to share their instance messaging id, so that I
>>> can be in touch and it would be easy to communicate faster.
>>>
>>> Thanks and regards
>>> Samartha S M
>>>
>>> On Thu 19 Mar, 2020, 6:28 PM Povilas Kanapickas, 
>>> wrote:
>>>
>>>> Hi Samartha,
>>>>
>>>> Great to hear you have interest in BuildBot.
>>>>
>>>> To answer your questions, the project is indeed only about implementing
>>>> the worker in C++. The project is roughly four parts:
>>>>
>>>>  - Investigating a protocol to use for communication between worker and
>>>> master. I've already looked into this in the past and recommend
>>>> MessagePack.
>>>>
>>>>  - Creating a protocol specification looking into what types of messages
>>>> go between master and worker.
>>>>
>>>>  - Adapting both worker and master to this new protocol. This is needed
>>>> so that we don't depend on C++ part to run tests for example.
>>>>
>>>>  - Implementing the worker in C++ for this new protocol.
>>>>
>>>> Regarding the proposal I think you could find plenty of information
>>>> around the internet about how a successful GSoC proposal could look like
>>>> and what actions could be done to increase chances of successful
>>>> selection. These go much more in depth compared to what I could advise
>>>> in a reasonably short email.
>>>>
>>>> Regards,
>>>> Povilas
>>>>
>>>> On 3/19/20 2:26 PM, Rajdeep Bharati wrote:
>>>> >
>>>> >
>>>> > On Thu, Mar 19, 2020 at 5:30 PM <
>>>> macports-dev-requ...@lists.macports.org
>>>> > <mailto:macports-dev-requ...@lists.macports.org>> wrote:
>>>> >
>>>> > Send macports-dev mailing list submissions to
>>>> > macports-dev@lists.macports.org
>>>> > <mailto:macports-dev@lists.macports.org>
>>>> >
>>>> > To subscribe or unsubscribe via the World Wide Web, visit
>>>> > https://lists.macports.org/mailman/listinfo/macports-dev
>>>> > or, via email, send a message with subject or body 'help' to
>>>> > macports-dev-requ...@lists.macports.org
>>>> > <mailto:macports-dev-requ...@lists.macports.org>
>>>> >
>>>> > You can reach the person managing the list at
>>>> > macports-dev-ow...@lists.macports.org
>>>> > <mailto:macports-dev-ow...@lists.macports.org>
>>>> >
>>>> > When replying, please edit your Subject line so it is more
>>>> specific
>>>> > than "Re: Contents of macports-dev digest..."
>>>> >
>>>> >
>>>> > Today's Topics:
>>>> >
>>>> >1. Re: GSoC 2020 (Jackson Isaac)
>>>> >2. Re: GSoC web-app query (Jackson Isaac)
>>>> >3. Re: Saying Hello :) (Jackson Isaac)
>>>> >4. Re: GSoC 2020 (Samartha S M)
>>>> >5. Re: GSoC 2020 (Jackson Isaac)
>>>> >
>>>> >
>>>> >
>>>>  --
>>>> >
>>>> >

Re: Request for Information : GSoC 2020 Aspirant

[Jackson Isaac]

On Fri, Mar 20, 2020 at 8:40 PM SAPTARSHI MUKHERJEE
 wrote:
>
> Hi Sir,
>
> Thanks a lot for the info provided. I've started working on the document. 
> Having developed some understanding and interest in the language TCL, I'm in 
> the process of figuring out ways of Improving the Command Line Tool UX, and 
> am enthusiastic to share the same by means of draft proposals. May kindly let 
> me know the best way to share the same; should I maintain a Google Doc 
> restricting the access to selected people and share over mail publicly, or 
> should I use a different platform for submission.
>

You may submit the draft on the GSoC portal.

For more info check out [1]


> Also if you would like me to try out some related issues and submit some pull 
> requests, may please let me know; I'll be glad in trying them out.
>

Take a look at our trac for open issues[2], you may start with easy
tasks something like port update[3].

[1] https://lists.macports.org/pipermail/macports-dev/2020-March/041732.html
[2] https://trac.macports.org/wiki/Tickets
[3] 
https://trac.macports.org/query?status=!closed=update=ports=1=time

--
Jackson Isaac

Re: Request for Information : GSoC 2020 Aspirant

[SAPTARSHI MUKHERJEE]

Hi Sir,

Thanks a lot for the info provided. I've started working on the document.
Having developed some understanding and interest in the language TCL, I'm
in the process of figuring out ways of *Improving the Command Line Tool
UX, *and am enthusiastic to share the same by means of *draft proposals*.
May kindly let me know the *best way to share* the same; should I maintain
a Google Doc restricting the access to selected people and share over mail
publicly, or should I use a different platform for submission.

Also if you would like me to try out some *related issues* and submit
some *pull
requests*, may please let me know; I'll be glad in trying them out.

Thanks and Regards,
Yours Sincerely,
*Saptarshi Mukherjee,*
*Chairperson, Students' Senate,*
*IIT Bhilai.*


On Thu, Mar 19, 2020 at 12:36 PM Jackson Isaac 
wrote:

> Hi Saptarshi,
>
> On Wed, Mar 18, 2020 at 11:08 PM SAPTARSHI MUKHERJEE
>  wrote:
> >
> > Dear Sir/Ma'am,
> >
> > I shortly started voyaging through the documentation on MacPorts, which
> seemed quite interesting to me. I'm Saptarshi Mukherjee, a 3rd Year
> Undergraduate at IIT Bhilai in Computer Science and Engineering, and an
> enthusiast to contribute to MacPorts in GSoC 2020.
>
> Welcome to The MacPorts Project!
>
> >
> > In the first place, I'm absolutely new to tcl and am feeling a need to
> know the language so as to have a clear understanding of the open-source
> codes. Having confessed that, I'd however add that I've looked at some
> files, acquired some overview, and then read some info about the issue
> concerning "port reclaim". Having got some understanding of the current
> requirement in that context, I hereby express my interest to contribute to
> that issue. I could perceive the need to retain the build-related ports
> which are currently being overlooked by the reclaim.tcl code, when checking
> for leaves. Apart from that, the task of "Improving the Command Line UX"
> was also interesting and seized my attention to try my hands on.
>
> You may also look at our introductory video on code base[1] for some
> more insights.
>
> >
> > Considering the fact that time is quite short with only 9-10 days
> remaining for the application, I'd sincerely request for some directions on
> how I should get going; whether I should read about tcl and revert with a
> concrete understanding of the code, or I should try crafting and suggesting
> innovative solutions (related to known data structures and relevant
> architectural models) and pseudo-codes for implementations of the
> aforementioned tasks. Any guidance would be highly appreciated.
> >
>
> If you already have a good understanding of the code and have ideas,
> feel free to already draft the application and submit in the portal,
> in this way you can get early feedback from the (potential) mentors.
>
> [1] https://www.youtube.com/watch?v=46qshiDskrM
>
> --
> Jackson Isaac
>

Re: GSoC 2020 (Samartha S M)

[Samartha S M]

I've uploaded draft proposal in GSoC proposal submission portal also.

Please give inputs from your side, so that I can improve my proposal.

Thanks and regards
Samartha S M

On Fri 20 Mar, 2020, 12:08 PM Samartha S M, 
wrote:

> I've attached draft proposal. PFA
>
> On Fri 20 Mar, 2020, 12:05 PM Samartha S M, 
> wrote:
>
>> Hello Buildbot community,
>>
>> I'm really excited to work with you on this project.
>>
>> I've attached a draft proposal for this project.
>> I would request you to review it and suggest any improvements to it.
>>
>> I would request anyone to share their instance messaging id, so that I
>> can be in touch and it would be easy to communicate faster.
>>
>> Thanks and regards
>> Samartha S M
>>
>> On Thu 19 Mar, 2020, 6:28 PM Povilas Kanapickas, 
>> wrote:
>>
>>> Hi Samartha,
>>>
>>> Great to hear you have interest in BuildBot.
>>>
>>> To answer your questions, the project is indeed only about implementing
>>> the worker in C++. The project is roughly four parts:
>>>
>>>  - Investigating a protocol to use for communication between worker and
>>> master. I've already looked into this in the past and recommend
>>> MessagePack.
>>>
>>>  - Creating a protocol specification looking into what types of messages
>>> go between master and worker.
>>>
>>>  - Adapting both worker and master to this new protocol. This is needed
>>> so that we don't depend on C++ part to run tests for example.
>>>
>>>  - Implementing the worker in C++ for this new protocol.
>>>
>>> Regarding the proposal I think you could find plenty of information
>>> around the internet about how a successful GSoC proposal could look like
>>> and what actions could be done to increase chances of successful
>>> selection. These go much more in depth compared to what I could advise
>>> in a reasonably short email.
>>>
>>> Regards,
>>> Povilas
>>>
>>> On 3/19/20 2:26 PM, Rajdeep Bharati wrote:
>>> >
>>> >
>>> > On Thu, Mar 19, 2020 at 5:30 PM <
>>> macports-dev-requ...@lists.macports.org
>>> > <mailto:macports-dev-requ...@lists.macports.org>> wrote:
>>> >
>>> > Send macports-dev mailing list submissions to
>>> > macports-dev@lists.macports.org
>>> > <mailto:macports-dev@lists.macports.org>
>>> >
>>> > To subscribe or unsubscribe via the World Wide Web, visit
>>> > https://lists.macports.org/mailman/listinfo/macports-dev
>>> > or, via email, send a message with subject or body 'help' to
>>> > macports-dev-requ...@lists.macports.org
>>> > <mailto:macports-dev-requ...@lists.macports.org>
>>> >
>>> > You can reach the person managing the list at
>>> > macports-dev-ow...@lists.macports.org
>>> > <mailto:macports-dev-ow...@lists.macports.org>
>>> >
>>> > When replying, please edit your Subject line so it is more specific
>>> > than "Re: Contents of macports-dev digest..."
>>> >
>>> >
>>> > Today's Topics:
>>> >
>>> >1. Re: GSoC 2020 (Jackson Isaac)
>>> >2. Re: GSoC web-app query (Jackson Isaac)
>>> >3. Re: Saying Hello :) (Jackson Isaac)
>>> >4. Re: GSoC 2020 (Samartha S M)
>>> >5. Re: GSoC 2020 (Jackson Isaac)
>>> >
>>> >
>>> >
>>>  --
>>> >
>>> > Message: 1
>>> > Date: Thu, 19 Mar 2020 08:30:13 +0100
>>> > From: Jackson Isaac >> > <mailto:ijack...@macports.org>>
>>> > To: Samartha S M >> > <mailto:samarthamah...@gmail.com>>
>>> > Cc: MacPorts Dev >> > <mailto:macports-dev@lists.macports.org>>
>>> > Subject: Re: GSoC 2020
>>> > Message-ID:
>>> >
>>> > >> fth1vb...@mail.gmail.com
>>> > <mailto:fth1vb...@mail.gmail.com>>
>>> > Content-Type: text/plain; charset="UTF-8"
>>> >
>>> > Hi Samartha.
>>> >
>>> > On Wed, Mar 18, 2020 at 8:19 AM Samartha S M
>>> > mailto:samart

[GSoC 2020] Application Template for aspiring students

[Jackson Isaac]

Dear Aspiring GSoC Students,

The application period has begun on GSoC portal. There is less than 2
weeks left for the student application deadline (31st March 2020).

We recommend to add your draft proposals on the portal as early as
possible, so you can get feedback from potential mentors on questions
or suggestions to improve the proposal further.

To help you get started, here[1] is a GSoC application template that
we have used in previous years as well, feel free to use it, add or
remove (sub-)sections.

Also, a guideline on what we expect from a project application [2].

[1] https://trac.macports.org/wiki/SummerOfCodeApplicationTemplate
[2] 
https://trac.macports.org/wiki/SummerOfCode#Whatweexpectfromstudentsfortheirapplications

Hope this helps. Please feel free to contact us if you have any questions.

Stay safe,
Jackson Isaac

Re: GSoC 2020 (Samartha S M)

[Samartha S M]

Hello Buildbot community,

I'm really excited to work with you on this project.

I've attached a draft proposal for this project.
I would request you to review it and suggest any improvements to it.

I would request anyone to share their instance messaging id, so that I can
be in touch and it would be easy to communicate faster.

Thanks and regards
Samartha S M

On Thu 19 Mar, 2020, 6:28 PM Povilas Kanapickas,  wrote:

> Hi Samartha,
>
> Great to hear you have interest in BuildBot.
>
> To answer your questions, the project is indeed only about implementing
> the worker in C++. The project is roughly four parts:
>
>  - Investigating a protocol to use for communication between worker and
> master. I've already looked into this in the past and recommend
> MessagePack.
>
>  - Creating a protocol specification looking into what types of messages
> go between master and worker.
>
>  - Adapting both worker and master to this new protocol. This is needed
> so that we don't depend on C++ part to run tests for example.
>
>  - Implementing the worker in C++ for this new protocol.
>
> Regarding the proposal I think you could find plenty of information
> around the internet about how a successful GSoC proposal could look like
> and what actions could be done to increase chances of successful
> selection. These go much more in depth compared to what I could advise
> in a reasonably short email.
>
> Regards,
> Povilas
>
> On 3/19/20 2:26 PM, Rajdeep Bharati wrote:
> >
> >
> > On Thu, Mar 19, 2020 at 5:30 PM  > <mailto:macports-dev-requ...@lists.macports.org>> wrote:
> >
> > Send macports-dev mailing list submissions to
> > macports-dev@lists.macports.org
> > <mailto:macports-dev@lists.macports.org>
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.macports.org/mailman/listinfo/macports-dev
> > or, via email, send a message with subject or body 'help' to
> > macports-dev-requ...@lists.macports.org
> > <mailto:macports-dev-requ...@lists.macports.org>
> >
> > You can reach the person managing the list at
> > macports-dev-ow...@lists.macports.org
> > <mailto:macports-dev-ow...@lists.macports.org>
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of macports-dev digest..."
> >
> >
> > Today's Topics:
> >
> >1. Re: GSoC 2020 (Jackson Isaac)
> >2. Re: GSoC web-app query (Jackson Isaac)
> >3. Re: Saying Hello :) (Jackson Isaac)
> >4. Re: GSoC 2020 (Samartha S M)
> >5. Re: GSoC 2020 (Jackson Isaac)
> >
> >
> >
>  ------
> >
> > Message: 1
> > Date: Thu, 19 Mar 2020 08:30:13 +0100
> > From: Jackson Isaac  > <mailto:ijack...@macports.org>>
> > To: Samartha S M  > <mailto:samarthamah...@gmail.com>>
> > Cc: MacPorts Dev  > <mailto:macports-dev@lists.macports.org>>
> > Subject: Re: GSoC 2020
> > Message-ID:
> >
> >  > <mailto:fth1vb...@mail.gmail.com>>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > Hi Samartha.
> >
> > On Wed, Mar 18, 2020 at 8:19 AM Samartha S M
> > mailto:samarthamah...@gmail.com>> wrote:
> > >
> > > I've not installed MacPorts yet. Is it compatible with Linux
> > systems as I have Linux based Ubuntu system?
> > >
> >
> > It is possible to setup macports on linux, although it might not
> > completely work correctly (had tried it long time ago, though).
> >
> > > Surely, I'll go through all resources which you have sent.
> > >
> >
> > You may also look at the Buildbot project idea.
> >
> > --
> > Jackson Isaac
> >
> >
> > --
> >
> > Message: 2
> > Date: Thu, 19 Mar 2020 08:37:15 +0100
> > From: Jackson Isaac  > <mailto:ijack...@macports.org>>
> > To: Jackson Isaac  ijack...@macports.org>>
> > Cc: "macports-dev@lists.macports.org
> > <mailto:macports-dev@lists.macports.org>"
> >  > <mailto:macports-dev@lists.macports.org>>
> > Subject: Re: GSoC web-app query
> > Message-ID:
> >
> >  >  cajo0vxpdppecurdqnxkbtmtamskjm1eeyannyis7dw

Re: GSoC 2020 (Samartha S M)

[Rajdeep Bharati]

On Thu, Mar 19, 2020 at 5:30 PM 
wrote:

> Send macports-dev mailing list submissions to
> macports-dev@lists.macports.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.macports.org/mailman/listinfo/macports-dev
> or, via email, send a message with subject or body 'help' to
> macports-dev-requ...@lists.macports.org
>
> You can reach the person managing the list at
> macports-dev-ow...@lists.macports.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of macports-dev digest..."
>
>
> Today's Topics:
>
>1. Re: GSoC 2020 (Jackson Isaac)
>2. Re: GSoC web-app query (Jackson Isaac)
>3. Re: Saying Hello :) (Jackson Isaac)
>4. Re: GSoC 2020 (Samartha S M)
>5. Re: GSoC 2020 (Jackson Isaac)
>
>
> --
>
> Message: 1
> Date: Thu, 19 Mar 2020 08:30:13 +0100
> From: Jackson Isaac 
> To: Samartha S M 
> Cc: MacPorts Dev 
> Subject: Re: GSoC 2020
> Message-ID:
>  fth1vb...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Samartha.
>
> On Wed, Mar 18, 2020 at 8:19 AM Samartha S M 
> wrote:
> >
> > I've not installed MacPorts yet. Is it compatible with Linux systems as
> I have Linux based Ubuntu system?
> >
>
> It is possible to setup macports on linux, although it might not
> completely work correctly (had tried it long time ago, though).
>
> > Surely, I'll go through all resources which you have sent.
> >
>
> You may also look at the Buildbot project idea.
>
> --
> Jackson Isaac
>
>
> --
>
> Message: 2
> Date: Thu, 19 Mar 2020 08:37:15 +0100
> From: Jackson Isaac 
> To: Jackson Isaac 
> Cc: "macports-dev@lists.macports.org"
> 
> Subject: Re: GSoC web-app query
> Message-ID:
> <
> cajo0vxpdppecurdqnxkbtmtamskjm1eeyannyis7dwrhtq9...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> Small correction below,
>
> On Thu, Mar 19, 2020 at 8:26 AM Jackson Isaac 
> wrote:
> >
> > Hi Dandamudi,
> >
> > Welcome to The MacPorts Project!
> >
> > Apologies for the late reply.
> >
> > On Wed, Mar 18, 2020 at 1:18 PM DANDAMUDI ROHIT
> >  wrote:
> > >
> > > Hello all,
> > >
> > > It seems the mentors alloted for web-app are busy,  is there any other
> project idea I can take on?
> >
> > Unfortunately, our web-app mentors cannot continue due to the current
> > situation, and we support them in their decision.
> >
> > Currently we have mentors for the following projects (If I understand
> > correctly from Ideas list):
> > - Buildbot
> > - MacPorts base
>
> See ideas [1] where potential mentors are satraul or mcalhoun :)
>
> >
> > To get a better understanding of macports-base you may also see our
> > introductory video at [3].
> >
>
> [1] https://trac.macports.org/wiki/SummerOfCode
> [3] https://www.youtube.com/watch?v=46qshiDskrM
>
>
> --
> Jackson Isaac
>
>
> --
>
> Message: 3
> Date: Thu, 19 Mar 2020 08:38:06 +0100
> From: Jackson Isaac 
> To: Mohammed Rabeeh 
> Cc: MacPorts Dev 
> Subject: Re: Saying Hello :)
> Message-ID:
> <
> cajo0vxokjo18stamqrvxwi-ev8dki_i8gfjf_5fec13_j9v...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Mohammed Rabeeh,
>
> Welcome to The MacPorts Project!
>
> Apologies for the late response.
>
> On Fri, Feb 21, 2020 at 9:11 AM Mohammed Rabeeh 
> wrote:
> >
> > Hello,
> >
> > My name is Mohammed Rabeeh. I'm a sophomore at the College of
> Engineering, Trivandrum, India pursuing Computer Science & Engineering. I
> came across MacPorts when I was going through the organization list and it
> caught my eye. I have recently switched to Mac and my experience with it
> has been great. I would love to contribute to MacPorts for GSoC '20.
> >
> > I have a lot of experience with web. I have been building web
> applications for around 5 years now. I have good knowledge of Javascript,
> PHP, and Django. I have built APIs in Django and attended a lot of
> hackathons were Django was extensively used as the backend.
> >
> > I would like to work on mainly two projects,
> >
> > 1) The Django Web Application
> > 2) Improving MacPorts documentation, website and trac system
> >
> > I belie

Re: GSoC 2020

[Jackson Isaac]

Hi Samartha,

On Thu, Mar 19, 2020 at 12:01 PM Samartha S M  wrote:
>
> Hello Jackson Isaac
>
> I went through Buildbot project ideas for GSoC 2020 and this project idea 
> caught my attention 'Add support for running worker on non-python platforms'. 
> I have good experience with python and C++.

Great!

> I went through the project idea abstract, but still I would like to request 
> more resources.
> Is the project about implementing only worker in C++ ?
> What steps do I need to take further for a successful project proposal?
>

I would request the Buildbot mentors to respond to you on this :)

In the meantime, you may also look at the macports-dev archive, you
can find similar gsoc questions and answers [1].

[1] https://lists.macports.org/pipermail/macports-dev/2020-March/041711.html

-- 
Jackson Isaac

Re: GSoC 2020

[Samartha S M]

Hello Jackson Isaac

I went through Buildbot project ideas for GSoC 2020 and this project idea
caught my attention 'Add support for running worker on non-python
platforms'. I have good experience with python and C++.
I went through the project idea abstract, but still I would like to request
more resources.
Is the project about implementing only worker in C++ ?
What steps do I need to take further for a successful project proposal?

Thanks and regards
Samartha S M

On Thu 19 Mar, 2020, 1:00 PM Jackson Isaac,  wrote:

> Hi Samartha.
>
> On Wed, Mar 18, 2020 at 8:19 AM Samartha S M 
> wrote:
> >
> > I've not installed MacPorts yet. Is it compatible with Linux systems as
> I have Linux based Ubuntu system?
> >
>
> It is possible to setup macports on linux, although it might not
> completely work correctly (had tried it long time ago, though).
>
> > Surely, I'll go through all resources which you have sent.
> >
>
> You may also look at the Buildbot project idea.
>
> --
> Jackson Isaac
>

Re: GSoC web-app query

[Jackson Isaac]

Hi,

Small correction below,

On Thu, Mar 19, 2020 at 8:26 AM Jackson Isaac  wrote:
>
> Hi Dandamudi,
>
> Welcome to The MacPorts Project!
>
> Apologies for the late reply.
>
> On Wed, Mar 18, 2020 at 1:18 PM DANDAMUDI ROHIT
>  wrote:
> >
> > Hello all,
> >
> > It seems the mentors alloted for web-app are busy,  is there any other 
> > project idea I can take on?
>
> Unfortunately, our web-app mentors cannot continue due to the current
> situation, and we support them in their decision.
>
> Currently we have mentors for the following projects (If I understand
> correctly from Ideas list):
> - Buildbot
> - MacPorts base

See ideas [1] where potential mentors are satraul or mcalhoun :)

>
> To get a better understanding of macports-base you may also see our
> introductory video at [3].
>

[1] https://trac.macports.org/wiki/SummerOfCode
[3] https://www.youtube.com/watch?v=46qshiDskrM


-- 
Jackson Isaac

Re: GSoC 2020

[Jackson Isaac]

Hi Samartha.

On Wed, Mar 18, 2020 at 8:19 AM Samartha S M  wrote:
>
> I've not installed MacPorts yet. Is it compatible with Linux systems as I 
> have Linux based Ubuntu system?
>

It is possible to setup macports on linux, although it might not
completely work correctly (had tried it long time ago, though).

> Surely, I'll go through all resources which you have sent.
>

You may also look at the Buildbot project idea.

-- 
Jackson Isaac

Re: GSoC web-app query

[Jackson Isaac]

Hi Dandamudi,

Welcome to The MacPorts Project!

Apologies for the late reply.

On Wed, Mar 18, 2020 at 1:18 PM DANDAMUDI ROHIT
 wrote:
>
> Hello all,
>
> It seems the mentors alloted for web-app are busy,  is there any other 
> project idea I can take on?

Unfortunately, our web-app mentors cannot continue due to the current
situation, and we support them in their decision.

Currently we have mentors for the following projects (If I understand
correctly from Ideas list):
- Buildbot
- MacPorts base (Improving the Command Line Tool UX [1])
- MacPorts base (Update Orphaned Ports [2])

To get a better understanding of macports-base you may also see our
introductory video at [3].

[1] https://trac.macports.org/wiki/SummerOfCode#color
[2] https://trac.macports.org/wiki/SummerOfCode#orphanports
[3] https://www.youtube.com/watch?v=46qshiDskrM

-- 
Jackson Isaac

Re: Request for Information : GSoC 2020 Aspirant

[Jackson Isaac]

Hi Saptarshi,

On Wed, Mar 18, 2020 at 11:08 PM SAPTARSHI MUKHERJEE
 wrote:
>
> Dear Sir/Ma'am,
>
> I shortly started voyaging through the documentation on MacPorts, which 
> seemed quite interesting to me. I'm Saptarshi Mukherjee, a 3rd Year 
> Undergraduate at IIT Bhilai in Computer Science and Engineering, and an 
> enthusiast to contribute to MacPorts in GSoC 2020.

Welcome to The MacPorts Project!

>
> In the first place, I'm absolutely new to tcl and am feeling a need to know 
> the language so as to have a clear understanding of the open-source codes. 
> Having confessed that, I'd however add that I've looked at some files, 
> acquired some overview, and then read some info about the issue concerning 
> "port reclaim". Having got some understanding of the current requirement in 
> that context, I hereby express my interest to contribute to that issue. I 
> could perceive the need to retain the build-related ports which are currently 
> being overlooked by the reclaim.tcl code, when checking for leaves. Apart 
> from that, the task of "Improving the Command Line UX" was also interesting 
> and seized my attention to try my hands on.

You may also look at our introductory video on code base[1] for some
more insights.

>
> Considering the fact that time is quite short with only 9-10 days remaining 
> for the application, I'd sincerely request for some directions on how I 
> should get going; whether I should read about tcl and revert with a concrete 
> understanding of the code, or I should try crafting and suggesting innovative 
> solutions (related to known data structures and relevant architectural 
> models) and pseudo-codes for implementations of the aforementioned tasks. Any 
> guidance would be highly appreciated.
>

If you already have a good understanding of the code and have ideas,
feel free to already draft the application and submit in the portal,
in this way you can get early feedback from the (potential) mentors.

[1] https://www.youtube.com/watch?v=46qshiDskrM

-- 
Jackson Isaac

Request for Information : GSoC 2020 Aspirant

[SAPTARSHI MUKHERJEE]

Dear Sir/Ma'am,

I shortly started voyaging through the documentation on MacPorts, which
seemed quite interesting to me. I'm Saptarshi Mukherjee, a 3rd Year
Undergraduate at IIT Bhilai in Computer Science and Engineering, and an
enthusiast to contribute to MacPorts in *GSoC 2020. *

In the first place, I'm absolutely new to tcl and am feeling a need to know
the language so as to have a clear understanding of the open-source codes.
Having confessed that, I'd however add that I've looked at some files,
acquired some overview, and then read some info about the issue
concerning "*port
reclaim*". Having got some understanding of the current requirement in
that context, I hereby express my interest to contribute to that issue. I
could perceive the need to retain the build-related ports which are
currently being overlooked by the reclaim.tcl code, when checking for
leaves. Apart from that, the task of "*Improving the Command Line UX*" was
also interesting and seized my attention to try my hands on.

Considering the fact that time is quite short with only 9-10 days remaining
for the application, I'd sincerely request for some directions on how I
should get going; whether I should read about tcl and revert with a
concrete understanding of the code, or I should try crafting and suggesting
innovative solutions (related to known data structures and relevant
architectural models) and pseudo-codes for implementations of the
aforementioned tasks. Any guidance would be highly appreciated.

Thanks and Regards,
Yours Sincerely,
*Saptarshi Mukherjee,*
*IIT Bhilai.*

Re: GSoC web-app query

[DANDAMUDI ROHIT]

Hello all,

It seems the mentors alloted for web-app are busy,  is there any other project 
idea I can take on?

I went through macports base and understood how it works and installed it in my 
mac as well as learnt basic tcl.

Regards,
Dandamudi Rohit

Regards,
Dandamudi Rohit


From: macports-dev  on behalf of 
DANDAMUDI ROHIT 
Sent: Sunday, March 15, 2020 10:30:51 AM
To: macports-dev@lists.macports.org 
Subject: GSoC web-app query

Hello everyone!

I am currently pursuing my undergrad in India. As I mentioned my interest to 
work on web-app project before, I went ahead and did some PRs and went through 
all the current issues and got more understanding of the project. I would like 
to draft my application for the same, where should I send my draft for review 
and further discussion.

Regards,
Dandamudi Rohit

Re: GSoC 2020

[Samartha S M]

I've not installed MacPorts yet. Is it compatible with Linux systems as I
have Linux based Ubuntu system?

Surely, I'll go through all resources which you have sent.

Happy to work with you

Thanks and Regards

On Wed 18 Mar, 2020, 12:40 PM Jackson Isaac,  wrote:

> Hi Samartha,
>
> Welcome to The MacPorts Project!
>
> On Wed, Mar 18, 2020 at 6:20 AM Samartha S M 
> wrote:
> >
> > Hello macports,
> >
> > I'm interested in contributing to your open source project under GSoC
> 2020.
> > I would like to learn more about the organization and projects so that I
> can start preparing my proposals for the project ideas listed under GSoC
> 2020.
> >
>
> Do you already have MacPorts installed on your system ?
>
> You can find the guide at [1]. The Idea list can be found at [2].
>
> You can either start with contributing to the core behind macports
> i.e., macports-base[3] or add/update existing portfiles (recipes to
> install packages) i.e., macports-ports[4].
>
> To get started with contributing to macports-base, we have an
> introductory video[5] which will explain about the codebase very well.
>
> To jump into creating or working on existing portfile, our guide on
> portfile development[6] is a good starting point. You may also read
> existing portfile in our macports-ports repository[4].
>
> Links:
> [1] https://guide.macports.org/
> [2] https://trac.macports.org/wiki/SummerOfCode#Projects
> [3] https://github.com/macports/macports-base/
> [4] https://github.com/macports/macports-ports/
> [5] https://www.youtube.com/watch?v=46qshiDskrM
> [6] https://guide.macports.org/#development
>
> --
> Jackson Isaac
>

Re: GSoC 2020

[Jackson Isaac]

Hi Samartha,

Welcome to The MacPorts Project!

On Wed, Mar 18, 2020 at 6:20 AM Samartha S M  wrote:
>
> Hello macports,
>
> I'm interested in contributing to your open source project under GSoC 2020.
> I would like to learn more about the organization and projects so that I can 
> start preparing my proposals for the project ideas listed under GSoC 2020.
>

Do you already have MacPorts installed on your system ?

You can find the guide at [1]. The Idea list can be found at [2].

You can either start with contributing to the core behind macports
i.e., macports-base[3] or add/update existing portfiles (recipes to
install packages) i.e., macports-ports[4].

To get started with contributing to macports-base, we have an
introductory video[5] which will explain about the codebase very well.

To jump into creating or working on existing portfile, our guide on
portfile development[6] is a good starting point. You may also read
existing portfile in our macports-ports repository[4].

Links:
[1] https://guide.macports.org/
[2] https://trac.macports.org/wiki/SummerOfCode#Projects
[3] https://github.com/macports/macports-base/
[4] https://github.com/macports/macports-ports/
[5] https://www.youtube.com/watch?v=46qshiDskrM
[6] https://guide.macports.org/#development

-- 
Jackson Isaac

GSoC 2020

[Samartha S M]

Hello macports,

I'm interested in contributing to your open source project under GSoC 2020.
I would like to learn more about the organization and projects so that I
can start preparing my proposals for the project ideas listed under GSoC
2020.

Thanks and regards

-- 
Samartha S M
IIIT Hyderabad

Re: Introduction for GSoC - Darsh

[Rajdeep Bharati]

Hi Darsh

There are quite a few small tasks pending in the build infrastructure
project from last year.

I guess the first thing you can do is set up a buildbot instance (refer
docs: https://docs.buildbot.net/latest/), and also read up a bit on how
buildbot works.

The latest buildmaster configuration (2.x) is available here:
https://github.com/macports-gsoc/macports-buildbot.

The custom views plugin is available at
https://github.com/macports/buildbot-macports-custom-views and you can use
it in your buildbot instance.

Some issues need to be fixed in the buildbot codebase:
https://github.com/buildbot/buildbot/issues?q=is%3Aopen+is%3Aissue+label%3Agsoc2019
(these
are mainly concerned with making the UI more scalable).

I'm afraid someone else would have to help with the vulnerability detection
project.

Cheers,
Rajdeep

On Sat, Mar 14, 2020 at 5:30 PM 
wrote:

> Send macports-dev mailing list submissions to
> macports-dev@lists.macports.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.macports.org/mailman/listinfo/macports-dev
> or, via email, send a message with subject or body 'help' to
> macports-dev-requ...@lists.macports.org
>
> You can reach the person managing the list at
> macports-dev-ow...@lists.macports.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of macports-dev digest..."
>
>
> Today's Topics:
>
>1. Introduction for GSoC - Darsh (Darsh Patel)
>
>
> --
>
> Message: 1
> Date: Fri, 13 Mar 2020 23:58:10 +0530
> From: Darsh Patel 
> To: macports-dev@lists.macports.org
> Subject: Introduction for GSoC - Darsh
> Message-ID:
> <
> caow6-bgamcysidzagayb8n18r-5qsd1efm2s_q6z9vxvkkm...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello everyone!
>I'm Darsh, I'm 19 and I'm a Computer science undergrad. I'll give a
> super short introduction in the and talk about my ideas for MacPorts,
>
> I'm currently working part-time for a LegalTech Startup ( for free, no
> obligations per se) as a DevOps and Backend Lead. I've been into tech since
> a very young age, put on paper ( literally ) by this article in Times
> <
> https://timesofindia.indiatimes.com/home/science/Robotics-enthusiast-creates-genie-for-self/articleshow/48232997.cms?from=mdr
> >
> of India
> <
> https://timesofindia.indiatimes.com/home/science/Robotics-enthusiast-creates-genie-for-self/articleshow/48232997.cms?from=mdr
> >about
> a smart home project I built when I was 14.
> I'm primarily a backend developer, but I'm competent with the rest of the
> stack too.  I also have a background in CyberSecurity ( I have a CEH
> Certification too ). Here's my CV <http://bit.ly/csv-darsh> in case you
> want to know more
>
> *My Project idea for GSoC: *I'd like to help implement
> vulnerability scanning and audit for ports, Similar to npm's "audit"
> feature. I was also looking into writing scripts to help current ports
> follow better security practices and enforce them.
> Also, is there a need/plan to change the build infrastructure? I'd love to
> help with that in any way I can, helping with improving logging / more
> efficient package builds, etc.
>
> I'm all ears for feedback and suggestions for my ideas,
>
> Super Excited,
> Darsh
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.macports.org/pipermail/macports-dev/attachments/20200313/7e328973/attachment-0001.html
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> macports-dev mailing list
> macports-dev@lists.macports.org
> https://lists.macports.org/mailman/listinfo/macports-dev
>
> --
>
> End of macports-dev Digest, Vol 163, Issue 8
> 
>

Re: Introduction for GSoC - Darsh

[Darsh Patel]

Greetings Marcus,
Let me put some light on what I'm trying to accomplish here, npm is
basically a dependency manager for NodeJS, it allows users to quickly
install libraries and dependencies for their NodeJS Projects. NPM now
provides 'npm audit' which reports vulnerabilities to the user and also
updates to patched versions of those dependencies with 'npm audit --fix',
I've attached a sample report for reference.
[image: npm_audit.png]
The vulnerability information is mostly crowdsourced from
npmjs.com/advisories 

Now coming back to MacPorts, multiple organizations publish CVEs ( Common
Vulnerabilities and Exposures ) which are linked to CPEs
What are CPEs?
CPE stands for Common Platform Enumeration and is "a standardized method of
describing and identifying classes of applications, operating systems, and
hardware devices present among an enterprise's computing assets"
Currently, the US Government maintains a searchable index of CPEs as a part
of NIST.

SInce CPEs come in a standard format   cpe:/ {part} : {vendor} : {product}
: {version} : {update} : {edition} : {language}
for example, a CPE published
on
1password cpe:/a:agilebits:1password:3.0:-:~~~
Can be used to identify that the package 1password
 is vulnerable ( current
portfile on macports isn't installing the vulnerable pckage )

We can either mirror the database or use the API at nvd.nist.gov to look
for vulnerable ports ( I'd suggest the former ).
Crowdsourcing the data is another way to identify vulnerabilities in
packages, I'd be happy to develop the full stack of a vulnerability
advisory for MacPorts but I believe it would put more pressure on the
maintainers to also moderate the vulnerability advisory.

~Darsh

GSoC web-app query

[DANDAMUDI ROHIT]

Hello everyone!

I am currently pursuing my undergrad in India. As I mentioned my interest to 
work on web-app project before, I went ahead and did some PRs and went through 
all the current issues and got more understanding of the project. I would like 
to draft my application for the same, where should I send my draft for review 
and further discussion.

Regards,
Dandamudi Rohit

Re: Introduction for GSoC - Darsh

[Marcus Calhoun-Lopez]

Greetings Darsh,

We are glad to hear about your interest in the MacPorts project.

I am afraid I do not know much about the npm audit feature (or npm for that 
matter).
How do you propose to determine that a security vulnerability exists?
If a vulnerability is identified, what would your project propose to do about 
it?

As for helping with the build infrastructure, I am afraid others will have to 
chime in with suggestions.

-Marcus

> On Mar 13, 2020, at 11:28 AM, Darsh Patel  wrote:
> 
> Hello everyone! 
>I'm Darsh, I'm 19 and I'm a Computer science undergrad. I'll give a super 
> short introduction in the and talk about my ideas for MacPorts, 
> 
> I'm currently working part-time for a LegalTech Startup ( for free, no 
> obligations per se) as a DevOps and Backend Lead. I've been into tech since a 
> very young age, put on paper ( literally ) by this article in Times of India 
> about a smart home project I built when I was 14. 
> I'm primarily a backend developer, but I'm competent with the rest of the 
> stack too.  I also have a background in CyberSecurity ( I have a CEH 
> Certification too ). Here's my CV in case you want to know more
> 
> My Project idea for GSoC: I'd like to help implement vulnerability scanning 
> and audit for ports, Similar to npm's "audit" feature. I was also looking 
> into writing scripts to help current ports follow better security practices 
> and enforce them. 
> Also, is there a need/plan to change the build infrastructure? I'd love to 
> help with that in any way I can, helping with improving logging / more 
> efficient package builds, etc. 
> 
> I'm all ears for feedback and suggestions for my ideas, 
> 
> Super Excited, 
> Darsh 
> 
> 

Introduction for GSoC - Darsh

[Darsh Patel]

Hello everyone!
   I'm Darsh, I'm 19 and I'm a Computer science undergrad. I'll give a
super short introduction in the and talk about my ideas for MacPorts,

I'm currently working part-time for a LegalTech Startup ( for free, no
obligations per se) as a DevOps and Backend Lead. I've been into tech since
a very young age, put on paper ( literally ) by this article in Times
<https://timesofindia.indiatimes.com/home/science/Robotics-enthusiast-creates-genie-for-self/articleshow/48232997.cms?from=mdr>
of India
<https://timesofindia.indiatimes.com/home/science/Robotics-enthusiast-creates-genie-for-self/articleshow/48232997.cms?from=mdr>about
a smart home project I built when I was 14.
I'm primarily a backend developer, but I'm competent with the rest of the
stack too.  I also have a background in CyberSecurity ( I have a CEH
Certification too ). Here's my CV <http://bit.ly/csv-darsh> in case you
want to know more

*My Project idea for GSoC: *I'd like to help implement
vulnerability scanning and audit for ports, Similar to npm's "audit"
feature. I was also looking into writing scripts to help current ports
follow better security practices and enforce them.
Also, is there a need/plan to change the build infrastructure? I'd love to
help with that in any way I can, helping with improving logging / more
efficient package builds, etc.

I'm all ears for feedback and suggestions for my ideas,

Super Excited,
Darsh

Re: GSoC

[Vibhansh Gupta]

This is great, thank you so much!

On Sun, Mar 8, 2020, 9:06 AM Marcus Calhoun-Lopez 
wrote:

> Greetings Vibhansh,
>
> We are glad to hear about your interest in the MacPorts project.
>
> A few questions.
> Are you familiar with Tcl?
> It is not mandatory, you can pick up what you need fairly quickly.
> Are you familiar with MacPorts?
> Again, it is not mandatory, it just helps to know how much vocabulary we
> can initially use.
>
> I think the best advice I can give at this point is to develop a history
> of code, reliability, and working with other developers.
> Some possible suggestions to get you started:
>
> * You said you were invested in improving the Command Line Tool UX.
>Perhaps take *one* aspect of that and see if you (with help from other
> developers) can implement it.
>For example, just adding color (red for errors, yellow for warnings,
> etc.) might be a reasonable place to start.
>
> *  Choose some outdated ports and try to update them [1].
>Running “port livecheck maintainer:nomaintainer” give a (very long)
> list of outdated unmaintained port.
>You could try to update a few of them.
>This would also get you a little more acquainted with Tcl if you are
> not already.
>
> *  Choose some tickets [2] and try to fix them.
>Some tickets are open for a long time because they are difficult.
>However, some tickets are still open just because no-one has put any
> effort into fixing them.
>For example, “Base should know the installed version of the command
> line tools” [3] is fairly easy to fix.
>There is a PortGroup that already does much of the heavy lifting [4].
>I just have not gotten around to incorporating the PortGroup into the
> base code.
>
> There are just a few possible options.
> Feel free to contribute your own ideas.
>
> -Marcus
>
> [1] https://trac.macports.org/wiki/SummerOfCode#orphanports
> [2] https://trac.macports.org/report/1?sort=created=0=1
> [3] https://trac.macports.org/ticket/56318
> [4]
> https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/cltversion-1.0.tcl
>
> > On Mar 7, 2020, at 3:23 PM, Vibhansh Gupta  wrote:
> >
> > Hi there !
> >
> > I’m Vibhansh. A Tech Enthusiast who has become very interested, after
> reading through the project description and requirements, to work towards
> to goal, "Improving the Command Line Tool UX” (in GSoC 2020 for MacPorts
> and perhaps even further down the road).
> >
> > As for my experience and programming skills, I am glad to inform you
> that I have been working thoroughly in Python for over 2 years now. I know
> that there will be many candidates showing an interest to aim for improving
> the UX but I would like to point out why I would be the better choice. Yes,
> it will probably be true that I may not be the best programmer but why I’d
> be specifically the best choice for this project can be explained in
> twofolds :
> > 1. I am very fluent with understanding code. I pick up coding terms
> quicker than most and can see the structure as well as the code to come to
> the conclusion about what parts are relating to which feature. I think this
> will help me identify the relevant parts for the UX editing.
> > 2. In any project that I pursue, I give the utmost emphasis on creating
> the best User Experience or if it is a Web-based project, I give User
> Interface the most priority. It’s an obsession, really. With that in mind,
> I would like to point out that I will be more than happy to undertake any
> sort of User Experience improvement project for the MacPorts Community.
> >
> > A few tips of guidance would be deeply appreciated as I try to step
> forth and (hopefully) contribute toward’s your goal.
> >
> > Sincerely,
> > Vibhansh.
>
>

Re: GSoC

[Marcus Calhoun-Lopez]

Greetings Vibhansh,

We are glad to hear about your interest in the MacPorts project.

A few questions.
Are you familiar with Tcl?
It is not mandatory, you can pick up what you need fairly quickly.
Are you familiar with MacPorts?
Again, it is not mandatory, it just helps to know how much vocabulary we can 
initially use.

I think the best advice I can give at this point is to develop a history of 
code, reliability, and working with other developers.
Some possible suggestions to get you started:

* You said you were invested in improving the Command Line Tool UX.
   Perhaps take *one* aspect of that and see if you (with help from other 
developers) can implement it.
   For example, just adding color (red for errors, yellow for warnings, etc.) 
might be a reasonable place to start.

*  Choose some outdated ports and try to update them [1].
   Running “port livecheck maintainer:nomaintainer” give a (very long) list of 
outdated unmaintained port.
   You could try to update a few of them.
   This would also get you a little more acquainted with Tcl if you are not 
already.

*  Choose some tickets [2] and try to fix them.
   Some tickets are open for a long time because they are difficult.
   However, some tickets are still open just because no-one has put any effort 
into fixing them.
   For example, “Base should know the installed version of the command line 
tools” [3] is fairly easy to fix.
   There is a PortGroup that already does much of the heavy lifting [4].
   I just have not gotten around to incorporating the PortGroup into the base 
code.

There are just a few possible options.
Feel free to contribute your own ideas.

-Marcus

[1] https://trac.macports.org/wiki/SummerOfCode#orphanports
[2] https://trac.macports.org/report/1?sort=created=0=1
[3] https://trac.macports.org/ticket/56318
[4] 
https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/cltversion-1.0.tcl

> On Mar 7, 2020, at 3:23 PM, Vibhansh Gupta  wrote:
> 
> Hi there !
> 
> I’m Vibhansh. A Tech Enthusiast who has become very interested, after reading 
> through the project description and requirements, to work towards to goal, 
> "Improving the Command Line Tool UX” (in GSoC 2020 for MacPorts and perhaps 
> even further down the road).
> 
> As for my experience and programming skills, I am glad to inform you that I 
> have been working thoroughly in Python for over 2 years now. I know that 
> there will be many candidates showing an interest to aim for improving the UX 
> but I would like to point out why I would be the better choice. Yes, it will 
> probably be true that I may not be the best programmer but why I’d be 
> specifically the best choice for this project can be explained in twofolds :
> 1. I am very fluent with understanding code. I pick up coding terms quicker 
> than most and can see the structure as well as the code to come to the 
> conclusion about what parts are relating to which feature. I think this will 
> help me identify the relevant parts for the UX editing.
> 2. In any project that I pursue, I give the utmost emphasis on creating the 
> best User Experience or if it is a Web-based project, I give User Interface 
> the most priority. It’s an obsession, really. With that in mind, I would like 
> to point out that I will be more than happy to undertake any sort of User 
> Experience improvement project for the MacPorts Community.
> 
> A few tips of guidance would be deeply appreciated as I try to step forth and 
> (hopefully) contribute toward’s your goal.
> 
> Sincerely,
> Vibhansh.

GSoC

[Vibhansh Gupta]

Hi there !

I’m Vibhansh. A Tech Enthusiast who has become very interested, after reading 
through the project description and requirements, to work towards to goal, 
"Improving the Command Line Tool UX” (in GSoC 2020 for MacPorts and perhaps 
even further down the road).

As for my experience and programming skills, I am glad to inform you that I 
have been working thoroughly in Python for over 2 years now. I know that there 
will be many candidates showing an interest to aim for improving the UX but I 
would like to point out why I would be the better choice. Yes, it will probably 
be true that I may not be the best programmer but why I’d be specifically the 
best choice for this project can be explained in twofolds :
1. I am very fluent with understanding code. I pick up coding terms quicker 
than most and can see the structure as well as the code to come to the 
conclusion about what parts are relating to which feature. I think this will 
help me identify the relevant parts for the UX editing.
2. In any project that I pursue, I give the utmost emphasis on creating the 
best User Experience or if it is a Web-based project, I give User Interface the 
most priority. It’s an obsession, really. With that in mind, I would like to 
point out that I will be more than happy to undertake any sort of User 
Experience improvement project for the MacPorts Community.

A few tips of guidance would be deeply appreciated as I try to step forth and 
(hopefully) contribute toward’s your goal.

Sincerely,
Vibhansh.

GSoC applicant introduction

[DANDAMUDI ROHIT]

Hello all,

I am currently pursuing my bachelors in Computer Science in CBIT Hyderabad, 
India.

I am interested to contribute to MacPorts as a part of GSoC 2020. After going 
through the projects ideas list, I got more interested in macports-webapp 
project as a mac user and web dev enthusiast. Having some experience in Django 
and Python web development, I would like to work on this project and get to 
know more about it.

Regards,
D. Rohit

[GSoC 2020] The MacPorts Project is Participating

[Jackson Isaac]

Hi,

I am happy to announce that The MacPorts Project has been accepted as
an organization for Google Summer of Code 2020.

Interested Mentors can reach out to mojca or ijackson (@macports.org),
so that we send out the invites.

Also, interested students can start working on idea proposals and
interacting with potential mentors and the dev community for any help
they might require.

Ideas list: https://trac.macports.org/wiki/SummerOfCode#Projects

P.S.: Start early, share early, ask for feedback :)

-- 
Jackson Isaac

Re: GSOC 20

[Marcus Calhoun-Lopez]

Greetings Pavitra,

The MacPorts GSoC wiki page is good place to start 
(https://trac.macports.org/wiki/SummerOfCode).

-Marcus

> On Feb 7, 2020, at 11:46 AM, Pavitra Behre  wrote:
> 
> Hello,
> I'm Pavitra, Pre-final year student of B.Tech - Computer Science & 
> Engineering.
> I'm very much interested in contributing to MacPorts under GSOC 20.
> Kindly guide me on the How-Tos.
> A little bit about myself: I've been coding for approximately 7 years now and 
> my primary domain used to be web development and backend development. But for 
> past year or two, I'e switched to python and MacOs. Been using UNIX based 
> systems for more than half a decade. 
> Hoping to hear soon,
> Thank you,
> Pavitra Behre

GSOC 20

[Pavitra Behre]

Hello,
I'm Pavitra, Pre-final year student of B.Tech - Computer Science &
Engineering.
I'm very much interested in contributing to MacPorts under GSOC 20.
Kindly guide me on the How-Tos.
A little bit about myself: I've been coding for approximately 7 years now
and my primary domain used to be web development and backend development.
But for past year or two, I'e switched to python and MacOs. Been using UNIX
based systems for more than half a decade.
Hoping to hear soon,
Thank you,
Pavitra Behre

Re: GSOC mentor candidates

[Satryaji Aulia]

Yes, I’d like to mentor too. Count me in 

Sat

> On 31 Jan 2020, at 09.29, Marcus Calhoun-Lopez  wrote:
> 
> Yes, I would be willing to be a mentor.
> 
> -Marcus
> 
>> On Jan 28, 2020, at 10:20 AM, Mojca Miklavec  wrote:
>> 
>> Hi,
>> 
>> In order to apply for GSOC we need to publish an up-to-date idea list.
>> 
>> MacPorts base make a significant (80%?) portion of the ideas list, so
>> it would be nice if we could make it clear as soon as possible whether
>> we have ideally two mentors willing to mentor base projects.
>> 
>> Marcus, Sat, or anyone else: please raise your hands if you would be
>> willing to participate this year as mentors, else we need to archive
>> those ideas and only leave a much shorter list.
>> 
>> Thanks in advance,
>>   Mojca
> 

Re: GSOC mentor candidates

[Marcus Calhoun-Lopez]

Yes, I would be willing to be a mentor.

-Marcus

> On Jan 28, 2020, at 10:20 AM, Mojca Miklavec  wrote:
> 
> Hi,
> 
> In order to apply for GSOC we need to publish an up-to-date idea list.
> 
> MacPorts base make a significant (80%?) portion of the ideas list, so
> it would be nice if we could make it clear as soon as possible whether
> we have ideally two mentors willing to mentor base projects.
> 
> Marcus, Sat, or anyone else: please raise your hands if you would be
> willing to participate this year as mentors, else we need to archive
> those ideas and only leave a much shorter list.
> 
> Thanks in advance,
>Mojca

Re: GSOC mentor candidates

[Mihir Luthra]

Hi,


> In order to apply for GSOC we need to publish an up-to-date idea list.
>
> MacPorts base make a significant (80%?) portion of the ideas list, so
> it would be nice if we could make it clear as soon as possible whether
> we have ideally two mentors willing to mentor base projects.
>
> Marcus, Sat, or anyone else: please raise your hands if you would be
> willing to participate this year as mentors, else we need to archive
> those ideas and only leave a much shorter list.
>
>
I am willing to help with the following 2 as a co-mentor if needed:

1) Fakeroot Functionality
<https://trac.macports.org/wiki/SummerOfCode#fakeroot>
2) Auto detection of build dependencies
<https://trac.macports.org/wiki/SummerOfCode#dependencies-gen>

Mihir

GSOC mentor candidates

[Mojca Miklavec]

Hi,

In order to apply for GSOC we need to publish an up-to-date idea list.

MacPorts base make a significant (80%?) portion of the ideas list, so
it would be nice if we could make it clear as soon as possible whether
we have ideally two mentors willing to mentor base projects.

Marcus, Sat, or anyone else: please raise your hands if you would be
willing to participate this year as mentors, else we need to archive
those ideas and only leave a much shorter list.

Thanks in advance,
Mojca

Re: Fwd: [GSoC Mentors] GSoC 2020 Organization Applications are now open (and close on February 5th)

[Clemens Lang]

Hi,

On Wed, Jan 15, 2020 at 07:28:37AM +0100, Jackson Isaac wrote:
> GSoC 2020 org applications are now open.
> 
> Let's participate again this year, we have some ideas on wiki, maybe they
> need some refinement ? Also, buildbot mentors are happy to collaborate
> again this year with us.

JFYI, I won't have time to mentor this year. Last year was already quite
the stretch, and I'd rather reserve time and do things right than feel
like I'm not giving it the attention it needs.

-- 
Clemens

Fwd: [GSoC Mentors] GSoC 2020 Organization Applications are now open (and close on February 5th)

[Jackson Isaac]

Hi,

GSoC 2020 org applications are now open.

Let's participate again this year, we have some ideas on wiki, maybe they
need some refinement ? Also, buildbot mentors are happy to collaborate
again this year with us.

If any of the previous year students want to become the Org Admin/Mentor,
let us know :)

Regards,
Jackson Isaac




-- Forwarded message -
From: 'sttaylor' via Google Summer of Code Mentors List <
google-summer-of-code-mentors-l...@googlegroups.com>
Date: Tue 14 Jan, 2020, 23:22
Subject: [GSoC Mentors] GSoC 2020 Organization Applications are now open
(and close on February 5th)
To: Google Summer of Code Mentors List <
google-summer-of-code-mentors-l...@googlegroups.com>


*Open Source Organizations* that wish to be mentoring orgs for GSoC 2020
can now apply. Orgs please remember the organization application period
will close on Wednesday, February 5th. You can go to g.co/gsoc to complete
your organization's application.

*Students*- if you are interested in participating in GSoC 2020 *s**tudent
applications open March 16-31*.

The GSoC 2020 program announcement
<https://opensource.googleblog.com/2019/12/announcing-google-summer-of-code-2020.html>
, timeline <https://developers.google.com/open-source/gsoc/timeline>, marketing
materials
<https://developers.google.com/open-source/gsoc/resources/marketing> (slide
deck, flyers), FAQs <https://developers.google.com/open-source/gsoc/faq>,
and short videos <https://developers.google.com/open-source/gsoc/videos>
about the program and tips for mentors and students are all available.

Thinking about being a mentor for GSoC 2020? Reach out to the organization
you'd like to work with in the next couple of months and let them know, I'm
sure they'd be thrilled to have you as a mentor!

We are looking forward to another exciting year of GSoC.

For any questions about the programs please email us at
gsoc-supp...@google.com

Best,

Stephanie Taylor

-- 
You received this message because you are subscribed to the Google Groups
"Google Summer of Code Mentors List" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-summer-of-code-mentors-list+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-summer-of-code-mentors-list/7ea5c97b-7467-4787-82af-5cb8c425f5d5%40googlegroups.com
<https://groups.google.com/d/msgid/google-summer-of-code-mentors-list/7ea5c97b-7467-4787-82af-5cb8c425f5d5%40googlegroups.com?utm_medium=email_source=footer>
.

Re: GSOC 2020

[Mojca Miklavec]

Dear Pierre,

On Tue, 7 Jan 2020 at 18:47, Pierre Tardy wrote:
>
> Hi,
>
> GSOC 2020 has been announced, I haven't seen a thread yet on macports being 
> an org.

We last discussed GSOC during the MacPorts meeting in Bohinj in
October where we went through the ideas list.

> We discussed the topic within Buildbot community, and we think we don't have 
> enough of our users as student, and are not attractive enough to be effective.
> But last years experience partnering with Macports was great, and we would 
> like to renew it.
>
> I don't know if this still makes sense for you to have a CI-dedicated GSOC 
> project idea, but Buildbot team will be officially happy to help with 
> mentoring of such project.

I'm still a bit afraid about our mentor forces, but I believe we will apply.
I'm a bit ashamed for not having deployed the setup yet, but
independent of there:
- there is still a number of issues which haven't been addressed last
year, for example the waterfall hasn't been completed / fully polished
yet for our needs
- there is still a lot to be done on the basic configuration for our
needs (including potentially working on VMs)

I would be in favour of publishing one project similar to last year's
one which would continue building on where we left off last year.
We would need to go through the feature requests / bug reports from
buildbot again and potentially (re)tag them properly. Plenty of them
already contain the GSOC tag.
But we would also need to check those few PRs that haven't been merged
yet (I believe there is still some small number there which
occasionally gets attacked by the stale bot).

What we need to do better this year is make it clear in advance where
the communication will happen as IRC didn't always work for everyone.
Aljaž has set up Rocket.chat on a private server (so hopefully no
issues with corporate and country firewalls; you were not the only one
blocked from Discord), and we could probably add IRC mirroring there
and allow reading the discussion with greater eas.

I wanted to attend the meeting on Tuesday, but I managed to notice I
missed it only after I received the email with the minutes.
(I'm also a bit confused about the timing which kind of shifts between
16 and 17 UTC, but not entirely consistent with daylight saving time
changes.)

Mojca

Re: GSOC 2020

[Ken Cunningham]

I would be very curious to see if a buildbot project might sort out how to 
test-build all the dependents of a suggested upgrade to a library for breakage.

I recall hearing about one of the unix variants that had figured out how to do 
that.

K

GSOC 2020

[Pierre Tardy]

Hi,

GSOC 2020 has been announced, I haven't seen a thread yet on macports being
an org.

We discussed the topic within Buildbot community, and we think we don't
have enough of our users as student, and are not attractive enough to be
effective.
But last years experience partnering with Macports was great, and we would
like to renew it.

I don't know if this still makes sense for you to have a CI-dedicated GSOC
project idea, but Buildbot team will be officially happy to help with
mentoring of such project.

Regards,
Pierre

Re: [GSOC] Request for feedback for the new web application

[Dmitri Zaitsev]

Feedback posted here:
https://github.com/macports/macports-webapp/issues/51

On Sun, Jul 28, 2019 at 4:24 AM Mojca Miklavec  wrote:

> Dear MacPorts users and developers,
>
> As most of you probably know already, we have 4 GSOC projects this
> year, one of them for a web application.
>
> The application written by Arjun made a decent progress so far and is
> available under a temporary URL:
> http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/
>
> We would be extremely happy for any feedback you might have, either
> here or under
> https://github.com/macports/macports-webapp/issues
> so that we can make the application better and more useful while Arjun
> is still working on it full time.
>
> You are also invited to opt-in to statistics submission by running
> sudo port install mpstats-gsoc
>
> Samples of statistics collected in the last two months can be seen
> here, for example:
> http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/statistics/
>
> http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/port/wget/?tab=stats
> Thank you very much to everyone who is participating.
>
> Thank you very much,
> Mojca
>


-- 
Dmitri Zaitsev
School of Mathematics
Trinity College Dublin

WWW:  http://www.maths.tcd.ie/~zaitsev/

Re: [GSOC] Request for feedback for the new web application

[Clemens Lang]

Hi,

On Sat, Jul 27, 2019 at 11:24:23PM +0200, Mojca Miklavec wrote:
> The application written by Arjun made a decent progress so far and is
> available under a temporary URL:
> http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/
> 
> We would be extremely happy for any feedback you might have, either
> here or under
> https://github.com/macports/macports-webapp/issues
> so that we can make the application better and more useful while Arjun
> is still working on it full time.

Thanks, showing tickets and build statistics next to a port's general
information is immensely helpful! I've noticed an issue with how the
webapp finds tickets associated with a port and have filed a ticket
about this at
  https://github.com/macports/macports-webapp/issues/50

> You are also invited to opt-in to statistics submission by running
>     sudo port install mpstats-gsoc

Done.

-- 
Clemens

[GSOC] Request for feedback for the new web application

[Mojca Miklavec]

Dear MacPorts users and developers,

As most of you probably know already, we have 4 GSOC projects this
year, one of them for a web application.

The application written by Arjun made a decent progress so far and is
available under a temporary URL:
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/

We would be extremely happy for any feedback you might have, either
here or under
https://github.com/macports/macports-webapp/issues
so that we can make the application better and more useful while Arjun
is still working on it full time.

You are also invited to opt-in to statistics submission by running
sudo port install mpstats-gsoc

Samples of statistics collected in the last two months can be seen
here, for example:
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/statistics/
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/port/wget/?tab=stats
Thank you very much to everyone who is participating.

Thank you very much,
Mojca

Re: Phase Out Xcode Dependency GSOC Project Update

[Satryaji Aulia]

Hi all,

We've solved all known existing problems in macports-base master
relating to the Xcode changes.
1. Ports use Xcode's SDK when we want to prefer CLT instead
We now check first for CLT SDKs if port isn't Xcode-dependent. CLT
SDKs for macOS mirror the ones shipped with Xcode.

2. Ports in `xcodversion 1.0` PortGroup were failing to install
We explicitly set Xcode dependency using `use_xcode yes` for that
PortGroup. This assumes all `xcodeversion` ports need Xcode.

3. Ports with `system -W` calls use Xcode binaries when want to prefer
CLT instead
We now export the needed environment variable specific to those { } blocks.
We had to set the global Tcl env array since the { } blocks don't run
using the normal environment set by MacPorts. This solution is new
(cmiiw) so maybe it can solve some other problems related to
environment variables.

I'm doing some additional testing to discover any more problems if any.

Sat

On Fri, Jul 19, 2019 at 2:13 AM Clemens Lang  wrote:
>
> Hi,
>
> On Wed, Jul 17, 2019 at 01:03:26PM +0700, Satryaji Aulia wrote:
> > There’s no existing code in port 1.0 that accesses a PortGroup
> > (besides lint which parses the file) so I assume that change needs to
> > be for macports-ports right? When do we make this change?
>
> Correct. We can make the change in a forward-compatible manner by first
> checking whether use_xcode exists, similar to what I've done with the
> code snippet that checks for the existence of configure.developer_dir.
>
> > Also I’ve submitted the PRs for the previous problems. The second
> > one’s a draft PR since it doesn’t work yet. [1,2]
> > Please take a look.
>
> Done, please address Joshua's comments in #135, then it would be good to
> go from my PoV.
>
> --
> Clemens

Re: Phase Out Xcode Dependency GSOC Project Update

[Clemens Lang]

Hi,

On Wed, Jul 17, 2019 at 01:03:26PM +0700, Satryaji Aulia wrote:
> There’s no existing code in port 1.0 that accesses a PortGroup
> (besides lint which parses the file) so I assume that change needs to
> be for macports-ports right? When do we make this change?

Correct. We can make the change in a forward-compatible manner by first
checking whether use_xcode exists, similar to what I've done with the
code snippet that checks for the existence of configure.developer_dir.

> Also I’ve submitted the PRs for the previous problems. The second
> one’s a draft PR since it doesn’t work yet. [1,2]
> Please take a look.

Done, please address Joshua's comments in #135, then it would be good to
go from my PoV.

-- 
Clemens

Re: Phase Out Xcode Dependency GSOC Project Update

[Satryaji Aulia]

Hi,

Clemens Lang  wrote:

As a consequence I would say that the xcodeversion PortGroup should set
use_xcode yes.



There’s no existing code in port 1.0 that accesses a PortGroup (besides  
lint which parses the file) so I assume that change needs to be for  
macports-ports right? When do we make this change?


Also I’ve submitted the PRs for the previous problems. The second one’s a  
draft PR since it doesn’t work yet. [1,2]

Please take a look.

[1] https://github.com/macports/macports-base/pull/135
[2] https://github.com/macports/macports-base/pull/136

- Sat

Re: Phase Out Xcode Dependency GSOC Project Update

[Clemens Lang]

Hi Sat,

On Tue, Jul 16, 2019 at 10:57:41PM +0700, Satryaji Aulia wrote:
> We haven't discussed whether or not the `xcodeversion` PortGroup
> should be included. We also **restrict** Xcode in tracemode if not
> needed. An exception if is CLT isn't installed.

The xcodeversion PortGroup says it determines the version of Xcode from
/usr/bin/xcodebuild -version. Running that with DEVELOPER_DIR set to the
command line tools seems to fail:

$> DEVELOPER_DIR=/Library/Developer/CommandLineTools xcodebuild -version
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer 
directory '/Library/Developer/CommandLineTools' is a command line tools instance

As a consequence I would say that the xcodeversion PortGroup should set
use_xcode yes. I am aware that we have previously used this to blacklist
specific compiler versions installed by older Xcode versions due to know
problems, but this should nowadays be seldom since we introduced
compiler.blacklist.

HTH,
Clemens

Re: Phase Out Xcode Dependency GSOC Project Update

[Satryaji Aulia]

To say it more explicitly:

Besides removing the messages revolving Xcode, the latest changes in
macports-base now **force** MacPorts to use CommandLineTools instead
of Xcode.app for common tools like make, clang etc. This is to make every
build reproducible and force ports to explicitly declare Xcode dependency
if they need it by setting `use_xcode yes` or be in the `xcode 1.0` PortGroup.
We haven't discussed whether or not the `xcodeversion` PortGroup should be
included. We also **restrict** Xcode in tracemode if not needed. An exception
if is CLT isn't installed.

Within the next week there should be 2 more PRs about some problems
that we've encountered surrounding this change:

1. `system -W` calls not respecting DEVELOPER_DIR
About 60 ports use system -W with varying degree to call `/usr/bin/make`,
`/usr/bin/gnumake`, etc. which doesn't respect the macports environment
variables. These binaries will then resolve to Xcode's make, gnumake etc
which we don't want. Xcode-independent ports like libnetpbm that do this
will now fail to install in tracemode since we restrict Xcode when not
needed.
As Josh (jmroot) said, it should be the caller's responsibility to set
the environment if they're using `system`, but I'm working on an alternative
solution besides of patching those 60 something ports that use system -W.
If we go down the patch route, here's an example patch by Clemens. [1]

2. sdkroot pointing to Xcode's sdkroot instead of CLT's
Some ports explicitly call ${sdkroot} which point to Xcode's SDK when CLT's
can be used instead. Some ports like gmp fail in tracemode because of this.
The solution is to modify the proc which sets the sdkroot variable to point to
CLT's SDK by running xcrun --show-sdk-path with DEVELOPER_DIR set
and moving it to the top (previously, xcrun was the final fallback). [2]
The proc should be functionally the same with maybe a slight performance hit.

Please voice your concerns/input if any. Thanks.

[1] https://paste.macports.org/fc84fb351e73
[2] 
https://github.com/macports/macports-base/blob/31e0c5619836ebfc23c812b2d9f65d3c98938efa/src/port1.0/portconfigure.tcl#L500-L511

- Sat

On Tue, Jul 16, 2019 at 6:41 AM Satryaji Aulia  wrote:
>
> To update from last month about phasing out Xcode,
>
> 1. What has changed from last time
> The warnings that Xcode should be installed has been removed.
> DEVELOPER_DIR is now universally exported for every command (build,
> destroot, autotools, etc.).
>
> 2. The effects of the changes
> Right now, we’re testing to use see if the changes work as expected. [1]
> Ports like iTerm2 now intendedly fail because it calls `xcodebuild` without
> specifying Xcode dependency. The solution would be to add `use_xcode yes`
> to the Portfile, or add the `xcodeversion` portgroup to the Xcode-dependent
> list.
> Ports like libnetpbm unintendedly fail in tracemode because it calls
> `system -W something /usr/bin/gnumake` which problem was described in
> pull#134 but not solved yet. [2]
>
> More problems/solutions are being discovered, any input is appreciated.
> Thanks.
>
> [1]
> https://docs.google.com/spreadsheets/d/1NYmJsedVFLn7PeYFB08gCimqYANsbv7xwd78k4yaQPs/edit#gid=0
> [2] https://github.com/macports/macports-base/pull/134
>
> - Sat
>
> Satryaji Aulia  wrote:
>
> > Hi all,
> >
> > I'd like to write about what we've accomplished so far in this project,
> > with my mentors Marcus (mcalhoun) and Clemens (cal/neverpanic).
> > The project's focus is to provide a smoother experience of using MacPorts
> > without Xcode.
> >
> > 1. Opened PR for better handling of Xcode dependency [1]
> > In addition to the port 1.0 PortGroup, maintainers can declare Xcode
> > dependency using a new Portfile option use_xcode. Unless ports declare
> > Xcode dependency:
> > - Prefer Command Line Tools instead of Xcode by setting the DEVELOPER_DIR
> > environment.
> > - Hide the Xcode installation when building with trace mode, so MacPorts
> > can fail builds for ports that actually need Xcode but are not declared as
> > such. This will help maintainers identify Xcode dependency.
> > Also, error out when users try to install Xcode-dependent ports without
> > installing Xcode.
> >
> > 2. New command `port bump` to easily bump checksums of a port [2,3]
> > More features are planned such as @version, --livecheck, and Git actions
> >
> > Please check it out, any input is appreciated. Shoutout to my mentors (and
> > Mojca for reminding me to write to the mailing list).
> >
> > Thank you.
> >
> > [1] https://github.com/macports/macports-base/pull/130
> > [2] https://github.com/macports/macports-base/pull/120
> > [3] https://github.com/macports/macports-base/pull/127

Re: Phase Out Xcode Dependency GSOC Project Update

[Satryaji Aulia]

To update from last month about phasing out Xcode,

1. What has changed from last time
The warnings that Xcode should be installed has been removed.
DEVELOPER_DIR is now universally exported for every command (build,  
destroot, autotools, etc.).


2. The effects of the changes
Right now, we’re testing to use see if the changes work as expected. [1]
Ports like iTerm2 now intendedly fail because it calls `xcodebuild` without  
specifying Xcode dependency. The solution would be to add `use_xcode yes`  
to the Portfile, or add the `xcodeversion` portgroup to the Xcode-dependent  
list.
Ports like libnetpbm unintendedly fail in tracemode because it calls  
`system -W something /usr/bin/gnumake` which problem was described in  
pull#134 but not solved yet. [2]


More problems/solutions are being discovered, any input is appreciated.  
Thanks.


[1]  
https://docs.google.com/spreadsheets/d/1NYmJsedVFLn7PeYFB08gCimqYANsbv7xwd78k4yaQPs/edit#gid=0

[2] https://github.com/macports/macports-base/pull/134

- Sat

Satryaji Aulia  wrote:


Hi all,

I'd like to write about what we've accomplished so far in this project,
with my mentors Marcus (mcalhoun) and Clemens (cal/neverpanic).
The project's focus is to provide a smoother experience of using MacPorts
without Xcode.

1. Opened PR for better handling of Xcode dependency [1]
In addition to the port 1.0 PortGroup, maintainers can declare Xcode
dependency using a new Portfile option use_xcode. Unless ports declare
Xcode dependency:
- Prefer Command Line Tools instead of Xcode by setting the DEVELOPER_DIR
environment.
- Hide the Xcode installation when building with trace mode, so MacPorts
can fail builds for ports that actually need Xcode but are not declared as
such. This will help maintainers identify Xcode dependency.
Also, error out when users try to install Xcode-dependent ports without
installing Xcode.

2. New command `port bump` to easily bump checksums of a port [2,3]
More features are planned such as @version, --livecheck, and Git actions

Please check it out, any input is appreciated. Shoutout to my mentors (and
Mojca for reminding me to write to the mailing list).

Thank you.

[1] https://github.com/macports/macports-base/pull/130
[2] https://github.com/macports/macports-base/pull/120
[3] https://github.com/macports/macports-base/pull/127

Re: [GSoC 2019] Web App Project Update

[Arjun Salyan]

Dear all,

This is another update regarding the Webapp GSoC'19 project. We are now in
the second month of coding. The project is going nearly at same pace as
scheduled in the proposal [1].

The demo of the app has been moved to an EC2 instance where it is running
in a Docker container:
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com. The app fetches
build history from buildbot at intervals of 1 hour and updates port
information at intervals of 3 hours.

We solved the problem of updating port information incrementally (mentioned
in previous email) by using git commit hashes to find which paths have been
updated and then extract related info from PortIndex.

The port-detail page has been improved and now makes use of tabs to show
various details of the port [2]. The port health section gives idea about
the latest builds on each builder.

More charts have been added to the installation statistics section. Overall
statistics are available here: [3] and stats related to specific ports can
be seen on the port-detail page [4]. I would like to use this opportunity
to thank everyone for showing interest in submitting statistics by
installing the port: mpstats-gsoc. We already have a good number of users
submitting stats.

And a big thanks to my mentors: Mojca and Umesh for wonderful guidance and
support.

The app should soon be available on a MacPorts subdomain.

Please try visiting the demo app and provide feedback about the project, it
would very valuable to the project.

Thank You

[1]:
https://docs.google.com/document/d/198Ivygxb2NJQz_sqzDrbDPVEYZ5Ye5Yw0LV6Bt2QmG4/edit?usp=sharing
[2]:
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/port/sqlite3/?tab=summary
(for
example)
[3]: http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/statistics/
[4]:
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/port/youtube-dl/?tab=stats

[GSoC] Staying Connected on IRC - Workaround

[Jackson Isaac]

Hi All, especially GSoC students and aspiring GSoCers,

TLDR; Stay connected on IRC forever:
https://vijaikumar.in/keeping-your-irccloud-client-always-connected-for-free-82db71b3cff3

As we all know that this is that time of year, when students and
mentors work on GSoC projects, it is very important to have a proper
channel for communication with the community.

This year, we are evaluating different platforms like Zulip, Discord,
Gitter, etc. so that students and mentors are able to see the chat
history (unlike IRC, where only chats while connected are seen),
github sync, and other cool features without premium memberships or
shelling out $$$.

At the same time, we don't want this to create communication gap,
since not everyone are active and are on these new platforms.

As a workaround, to stay connected, you may use IRCCloud, which keeps
you connected for few hours after you disconnect. To stay connected
forever, there is detailed steps at [1].

[1] 
https://vijaikumar.in/keeping-your-irccloud-client-always-connected-for-free-82db71b3cff3

-- 
Jackson Isaac

Phase Out Xcode Dependency GSOC Project Update

[Satryaji Aulia]

Hi all,

I'd like to write about what we've accomplished so far in this project,  
with my mentors Marcus (mcalhoun) and Clemens (cal/neverpanic).
The project's focus is to provide a smoother experience of using MacPorts  
without Xcode.


1. Opened PR for better handling of Xcode dependency [1]
In addition to the port 1.0 PortGroup, maintainers can declare Xcode  
dependency using a new Portfile option use_xcode. Unless ports declare  
Xcode dependency:
- Prefer Command Line Tools instead of Xcode by setting the DEVELOPER_DIR  
environment.
- Hide the Xcode installation when building with trace mode, so MacPorts  
can fail builds for ports that actually need Xcode but are not declared as  
such. This will help maintainers identify Xcode dependency.
Also, error out when users try to install Xcode-dependent ports without  
installing Xcode.


2. New command `port bump` to easily bump checksums of a port [2,3]
More features are planned such as @version, --livecheck, and Git actions

Please check it out, any input is appreciated. Shoutout to my mentors (and  
Mojca for reminding me to write to the mailing list).


Thank you.

[1] https://github.com/macports/macports-base/pull/130
[2] https://github.com/macports/macports-base/pull/120
[3] https://github.com/macports/macports-base/pull/127

Re: [GSoC 2019] Web App Project Update

[Mojca Miklavec]

Hi,

This is just to say a huge thank you to everyone who volunteered to
contribute. In just a week we collected statistics from nearly half as
many machines compared to our existing (semi-official) site. At the
moment the site is only showing OS version distribution, but we expect
other data to be shown soon (ideally in about two weeks).

Thank you very much,
Mojca

(And of course feel free to provide feedback about the rest of the site.)

On Sat, 8 Jun 2019 at 14:52, Mojca Miklavec wrote:
>
> Dear MacPorts users,
>
> I would warmly welcome everyone to check what has been done so far,
> provide feedback, but in particular volunteer to run
> sudo port install mpstats-gsoc
> to help us get more statistics ready by the time Arjun starts working
> on that part (about two weeks from now; it would be really cool to
> have more than one month worth of statistics from a sufficient number
> of users well before the GSOC ends to be able to know whether we'll be
> heading in the right direction).
>
> The detailed statistics is not there yet, but you can probably guess
> whether your statistics submission has been successful by checking the
> following page:
> https://frozen-falls-98471.herokuapp.com/statistics/
> right before and after you install the port. You can also manually run
> /opt/local/libexec/mpstats-gsoc submit
> or
> /opt/local/libexec/mpstats-gsoc show
> if you just want to see what gets submitted.
>
> Thank you very much,
> Mojca
>
> (I CC-ed macports-users to get some more visibility and hopefully get
> more volunteers to submit their statistics, but any further discussion
> probably only makes sense on macports-dev. Even though ... one of the
> student contributors complained that we didn't post anything about
> GSOC to the macports-announce ...)
>
> On Fri, 7 Jun 2019 at 22:21, Arjun Salyan wrote:
> >
> > Hi,
> >
> > I am working on the web app to collect build and installation statistics 
> > and show information about ports, maintainers etc.
> >
> > Repository: https://github.com/macports/macports-webapp
> >
> > We have deployed a demo on Heroku: https://frozen-falls-98471.herokuapp.com 
> > . Any feedback and feature requests on this are very welcome.
> >
> > Currently we are working on build history and port information. Port 
> > information is fetched from Portindex after converting it to JSON using 
> > portindex2json.tcl and build history is fetched from JSON API of buildbot, 
> > it is planned to be kept updated using HttPStatusPush reporter on Buildbot.
> >
> > Keeping the port informtation up-to-date is a challenge given the large 
> > size of the portindex. We are looking at two aspects:
> > - Incremental updates using difference between two port indices [1]
> > - Full updates to completely sync the database with latest portindex
> >
> > Full updates are dead slow on an Amazon RDS free tier instance, and 
> > probably it won't be feasible on any externally hosted database. On a local 
> > database, full updates take more than 5 minutes.
> >
> > For installation statistics, we have setup a temporary port (mpstats-gsoc) 
> > which would submit stats to the demo app. This is important becuase it 
> > would give us enough data to write proper views and do testing. Please 
> > consider installing mpstats-gsoc.
> >
> > We are looking to deploy the app on MacPorts' server and host it on a 
> > macports.org subdomain using Docker.
> >
> > Thank you for your time, any suggestions would be very helpful.
> >
> > [1] https://github.com/macports/macports-base/pull/121
> >
> > Arjun

Re: Slack-like chat (also for GSOC)

[Jackson Isaac]

On Sat, Jun 15, 2019 at 2:03 PM Rainer Müller  wrote:
>
> On 14.06.19 13:01, Nils Breunese wrote:
> >
> > Chris jones wrote:
> >
> >> ( The main problem I have, is not something specific to Riot or whatever 
> >> forum we use, but more we need to perhaps give some thought to the 
> >> channels. Currently there is really only one, which gets (some) chat but 
> >> also messages for each and every commit. I don't think the average user 
> >> needs to see each and every commit. I think we probably need to split 
> >> these, for instance into Dev and User channels, to match the mailing lists 
> >> perhaps. )
> >
> > I’d go even more granular: create a dedicated channel for commits and 
> > everyone can decide whether to follow that or not.
> I am not sure how useful such a dedicated channel would be if only
> automated messages will be posted and no discussion takes place.
> Sometimes the mplog messages are even used during conversations, like
> "see this commit, now it is fixed".
>
> For those that really do not want to see these messages, I would
> recommend to add mplog to their your ignore list. That works in IRC
> clients and also in Riot.
>
> The bot is operated by me, but if others also think that the bot is
> annoying, I do not insist on keeping it running or moving it to another
> channel.

I like the mplog on #macports. If someone doesn't like it, I would say
they put it in their ignore list.

IIRC, we did try to create a separate channel for #macports-gsoc but
then after some time we ended up in #macports, because there were more
users out their who could and would like to share ideas.

Splitting of channels, IMHO, might not be a good idea. It works fine
as a separate Mailing list, but maybe not on IRC.

I do agree, that one might get lost in all the chatter that might
happen all at one place, but yeah that is same in most of the
platforms, at least the ones that I have used. I do like the idea of
threads (in slack), maybe we need to look if they are in some
libre/open-source alternative ?

-- 
Jackson Isaac

Re: Slack-like chat (also for GSOC)

[Rainer Müller]

On 14.06.19 13:01, Nils Breunese wrote:
> 
> Chris jones wrote:
> 
>> ( The main problem I have, is not something specific to Riot or whatever 
>> forum we use, but more we need to perhaps give some thought to the channels. 
>> Currently there is really only one, which gets (some) chat but also messages 
>> for each and every commit. I don't think the average user needs to see each 
>> and every commit. I think we probably need to split these, for instance into 
>> Dev and User channels, to match the mailing lists perhaps. )
> 
> I’d go even more granular: create a dedicated channel for commits and 
> everyone can decide whether to follow that or not.
I am not sure how useful such a dedicated channel would be if only
automated messages will be posted and no discussion takes place.
Sometimes the mplog messages are even used during conversations, like
"see this commit, now it is fixed".

For those that really do not want to see these messages, I would
recommend to add mplog to their your ignore list. That works in IRC
clients and also in Riot.

The bot is operated by me, but if others also think that the bot is
annoying, I do not insist on keeping it running or moving it to another
channel.

Rainer

Re: Slack-like chat (also for GSOC)

[Rainer Müller]

On 14.06.19 11:10, Chris Jones wrote:
> ( The main problem I have, is not something specific to Riot or whatever
> forum we use, but more we need to perhaps give some thought to the
> channels. Currently there is really only one, which gets (some) chat but
> also messages for each and every commit. I don't think the average user
> needs to see each and every commit. I think we probably need to split
> these, for instance into Dev and User channels, to match the mailing
> lists perhaps. )

I would be afraid that by removing the development discussions, the
channel would appear mostly dead. The traffic is already quite low.

If at all, I would keep #macports as user channel and create another
#macports-dev for deeper discussions of internals.

However, development discussions happen rarely and are usually started
by something that would rather be categorized as a user question. Which
means we would have to force ourselves to move the discussion to another
channel as soon as it gets to a development topic...

Rainer

Re: Slack-like chat (also for GSOC)

[Nils Breunese]

Chris jones wrote:

> ( The main problem I have, is not something specific to Riot or whatever 
> forum we use, but more we need to perhaps give some thought to the channels. 
> Currently there is really only one, which gets (some) chat but also messages 
> for each and every commit. I don't think the average user needs to see each 
> and every commit. I think we probably need to split these, for instance into 
> Dev and User channels, to match the mailing lists perhaps. )

I’d go even more granular: create a dedicated channel for commits and everyone 
can decide whether to follow that or not.

Nils.

Re: Slack-like chat (also for GSOC)

[Chris Jones]

I would say we can try Riot (also mentioned earlier by Rainer), as I
see lot of pros put up for it in [1]. We can also explore discord as
an option. If none works, we can stick to IRC.


I've been trying Riot out for a bit now, since this discussion started. 
Its not bad I would say..


( The main problem I have, is not something specific to Riot or whatever 
forum we use, but more we need to perhaps give some thought to the 
channels. Currently there is really only one, which gets (some) chat but 
also messages for each and every commit. I don't think the average user 
needs to see each and every commit. I think we probably need to split 
these, for instance into Dev and User channels, to match the mailing 
lists perhaps. )


Chris

Re: Slack-like chat (also for GSOC)

[Jackson Isaac]

On Thu, Jun 13, 2019 at 8:04 AM Mojca Miklavec  wrote:
>
> Hi,
>
> As a quick feedback: Gitter doesn't seem to be mature enough, so that
> those of us who kept testing it (for about three weeks) would want to
> use it in the long run.
>
> * The Android app constantly keeps crashing.
> * Even if it is not crashing, I wasn't able to configure it to get
> notifications when a new message arrived that I would want to see it.
> * Browser updates sometimes work, sometimes not. Very often one needs
> to keep refreshing the browser and hope that something works
> (sometimes the contents disappears completely).
> * Channels are very tightly bound to git repositories, but unless you
> sell your soul to the plugin, it seems hard to configure it properly,
> and we never got it working once we migrated the github repository to
> a different address (not that we tried that hard, but we did try).
> * Functionality is very limited.
> * No topics.
> * I was subscribed to another channel with heavy traffic that I'm not
> really interested in that much other than maybe checking it once per
> week. Once I allowed notifications from the app (I did that under
> Windows) to be able to respond to the student faster, I started being
> bombarded with messaged from the other channel, and I was unable to
> silence them until I completely removed the channel. And even then I
> kept getting email two days later about the new posts in that channel.
> * Receiving a bunch of emails reminding me of content that I have
> already read two days ago.
>
> While it is very easy to initially set up, it is just not yet worth
> considering as a serious platform to "replace" our official
> communication channel.
>
> What should we try next?
>

Alternatives to IRC that I use (at work and tried at other projects)
are Discord, Slack and MS Teams. Not too many options that I have
explored, so did a quick google and found [1].

I would say we can try Riot (also mentioned earlier by Rainer), as I
see lot of pros put up for it in [1]. We can also explore discord as
an option. If none works, we can stick to IRC.

[1] https://www.slant.co/options/4557/alternatives/~irc-alternatives

-- 
Jackson Isaac

Re: Slack-like chat (also for GSOC)

[Mojca Miklavec]

Hi,

As a quick feedback: Gitter doesn't seem to be mature enough, so that
those of us who kept testing it (for about three weeks) would want to
use it in the long run.

* The Android app constantly keeps crashing.
* Even if it is not crashing, I wasn't able to configure it to get
notifications when a new message arrived that I would want to see it.
* Browser updates sometimes work, sometimes not. Very often one needs
to keep refreshing the browser and hope that something works
(sometimes the contents disappears completely).
* Channels are very tightly bound to git repositories, but unless you
sell your soul to the plugin, it seems hard to configure it properly,
and we never got it working once we migrated the github repository to
a different address (not that we tried that hard, but we did try).
* Functionality is very limited.
* No topics.
* I was subscribed to another channel with heavy traffic that I'm not
really interested in that much other than maybe checking it once per
week. Once I allowed notifications from the app (I did that under
Windows) to be able to respond to the student faster, I started being
bombarded with messaged from the other channel, and I was unable to
silence them until I completely removed the channel. And even then I
kept getting email two days later about the new posts in that channel.
* Receiving a bunch of emails reminding me of content that I have
already read two days ago.

While it is very easy to initially set up, it is just not yet worth
considering as a serious platform to "replace" our official
communication channel.

What should we try next?

Mojca

On Wed, 15 May 2019 at 01:54, Umesh Singla wrote:
>
> I remember seeing Gitter.im being used by more than a usual number of open 
> source communities in the past. While I am personally fine with Github 
> Issues/PRs and emails, a chat-like application does come in handy for quick 
> replies.
>
> I logged in just now to my old account from over 2 years back and I see no 
> limits on the messages. You can sign in with Github/Twitter. There is this 
> idea of community and rooms like IRC, and while anyone can read the community 
> messages by visiting the link, one needs to sign in to talk. It's linked to a 
> Github organization and owners of the organization act like admins. It also 
> allows for one-on-one conversations and rooms where only invited users can 
> join.
>
> An example would be: https://gitter.im/coala/coala
>
> @Mojca would you be willing to give this https://gitter.im/macports-gsoc a 
> try? I tried creating one suitable for us. Let me know if you are able to see 
> the secret room. :)
>
> Thanks,
> Umesh

Re: [GSoC 2019] Web App Project Update

[Mojca Miklavec]

Dear Arjun,

Thanks a lot for sending out the report.

Dear MacPorts users,

I would warmly welcome everyone to check what has been done so far,
provide feedback, but in particular volunteer to run
sudo port install mpstats-gsoc
to help us get more statistics ready by the time Arjun starts working
on that part (about two weeks from now; it would be really cool to
have more than one month worth of statistics from a sufficient number
of users well before the GSOC ends to be able to know whether we'll be
heading in the right direction).

The detailed statistics is not there yet, but you can probably guess
whether your statistics submission has been successful by checking the
following page:
https://frozen-falls-98471.herokuapp.com/statistics/
right before and after you install the port. You can also manually run
/opt/local/libexec/mpstats-gsoc submit
or
/opt/local/libexec/mpstats-gsoc show
if you just want to see what gets submitted.

Thank you very much,
Mojca

(I CC-ed macports-users to get some more visibility and hopefully get
more volunteers to submit their statistics, but any further discussion
probably only makes sense on macports-dev. Even though ... one of the
student contributors complained that we didn't post anything about
GSOC to the macports-announce ...)

On Fri, 7 Jun 2019 at 22:21, Arjun Salyan wrote:
>
> Hi,
>
> I am working on the web app to collect build and installation statistics and 
> show information about ports, maintainers etc.
>
> Repository: https://github.com/macports/macports-webapp
>
> We have deployed a demo on Heroku: https://frozen-falls-98471.herokuapp.com . 
> Any feedback and feature requests on this are very welcome.
>
> Currently we are working on build history and port information. Port 
> information is fetched from Portindex after converting it to JSON using 
> portindex2json.tcl and build history is fetched from JSON API of buildbot, it 
> is planned to be kept updated using HttPStatusPush reporter on Buildbot.
>
> Keeping the port informtation up-to-date is a challenge given the large size 
> of the portindex. We are looking at two aspects:
> - Incremental updates using difference between two port indices [1]
> - Full updates to completely sync the database with latest portindex
>
> Full updates are dead slow on an Amazon RDS free tier instance, and probably 
> it won't be feasible on any externally hosted database. On a local database, 
> full updates take more than 5 minutes.
>
> For installation statistics, we have setup a temporary port (mpstats-gsoc) 
> which would submit stats to the demo app. This is important becuase it would 
> give us enough data to write proper views and do testing. Please consider 
> installing mpstats-gsoc.
>
> We are looking to deploy the app on MacPorts' server and host it on a 
> macports.org subdomain using Docker.
>
> Thank you for your time, any suggestions would be very helpful.
>
> [1] https://github.com/macports/macports-base/pull/121
>
> Arjun

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Ryan Schmidt]

On Jun 3, 2019, at 15:51, Mojca Miklavec wrote:
> 
> On Sun, 2 Jun 2019 at 18:46, Ryan Schmidt wrote:
> 
>> Buildbot is a program that we want to use for its own sake, so its port name 
>> should not begin with "py-" and it should be in a primary category that 
>> reflects its use. Look at the existing buildbot port. In fact, update that 
>> port instead of creating a new one.
> 
> But just to make sure: do you want that exact same layout for all of
> the dependencies of buildbot as well? (waterfall view, console view,
> etc.)

I don't know. Buildbot 0.8 didn't have those as separate packages, and I 
haven't taken a look at them.

Will we ever want to include waterfall view, console view, etc. in any port 
other than buildbot? I would guess not, in which case there's no need to use 
the py- prefix.



On Jun 3, 2019, at 16:02, Mojca Miklavec wrote:
> 
> But now Ryan opened
>https://github.com/macports/macports-ports/pull/4518
> and if you update your PR now, it will conflict as soon as we merge
> Ryan's one (unless the two get combined).

I don't see any need to combine them. I suggest to merge my PR first. That will 
give users a little time to upgrade to that. Then the other one can be rebased.


> (I still suspect some users will run into problems if they
> accidentally skip the update path from buildbot to buildbot-0.8, as we
> would not give them the usual one year grace period, but that's not my
> call to make.)

Or I could change my PR so that it does not change the buildbot and 
buildbot-slave ports at all, and just let Rajdeep's PR update them later. Users 
who wish to stay on 0.8 can discover the *-0.8 ports on their own.


> I have one further question for Ryan though. I think that waterfall
> view, console view etc. depend on having buildbot installed before
> installing the view.

Do they?

> On the other hand I would want to say "port
> install buildbot" and get all the three views installed automatically.
> How do you want to address that one? Note that buildbot 2 is split
> into many packages.

If so, then we may need a metaport (perhaps "buildbot-master") that installs 
only a README file, and it would depend on buildbot and all of its extra ports, 
and the extra ports can depend on buildbot as well.

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Mojca Miklavec]

On Sun, 2 Jun 2019 at 18:30, Rajdeep Bharati  wrote:
> On Sun, Jun 2, 2019 at 9:45 PM Ryan Schmidt  wrote:
>
> Got it, thanks for your help. One thing is that when I install the new 
> py37-buildbot, the command that I get to use is `buildbot-3.7`.
> What changes do I need to make in the port to use the command `buildbot`?

See the existing port
devel/buildbot

Basically I think that you only need to drop the py- prefix from the
port name (and then as a consequence move the port from python/ to
devel/ or something).

But now Ryan opened
https://github.com/macports/macports-ports/pull/4518
and if you update your PR now, it will conflict as soon as we merge
Ryan's one (unless the two get combined).

I have one further question for Ryan though. I think that waterfall
view, console view etc. depend on having buildbot installed before
installing the view. On the other hand I would want to say "port
install buildbot" and get all the three views installed automatically.
How do you want to address that one? Note that buildbot 2 is split
into many packages.

(I still suspect some users will run into problems if they
accidentally skip the update path from buildbot to buildbot-0.8, as we
would not give them the usual one year grace period, but that's not my
call to make.)

Mojca

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Mojca Miklavec]

Hi,

In this case I have a feature request for Karan ...

On Sun, 2 Jun 2019 at 18:46, Ryan Schmidt wrote:
> On Jun 2, 2019, at 11:30, Rajdeep Bharati wrote:
>
> > One thing is that when I install the new py37-buildbot, the command that I 
> > get to use is `buildbot-3.7`.
> > What changes do I need to make in the port to use the command `buildbot`?
>
> As Rainer explained in https://github.com/macports/macports-ports/pull/4489, 
> the ports should not be named with the "py-" prefix and should not be in the 
> primary category "python". That's for Python modules that should be made 
> available in multiple Python versions so that other ports can use them.
>
> But that's not what buildbot is. Buildbot is a program that we want to use 
> for its own sake, so its port name should not begin with "py-" and it should 
> be in a primary category that reflects its use. Look at the existing buildbot 
> port. In fact, update that port instead of creating a new one.

But just to make sure: do you want that exact same layout for all of
the dependencies of buildbot as well? (waterfall view, console view,
etc.)

> The python 1.0 portgroup adds the "-3.7" (or whatever version number) suffix 
> for programs installed by Python module ports, since it assumes they will be 
> provided in multiple Python versions and we don't want them to conflict. If 
> the port name does not begin with "py-" the python portgroup won't do that. 
> It can be overridden on a port by port basis but in this case the correct 
> thing to do is to fix the name of the port.

Karan (& Renee), could we perhaps support a special flag when creating
ports, so that pypi backend could also be able to create (and later
update) "regular ports"? They use the same sources, the python
portgroup etc., they just lack the "py-" prefix and get put to a
different category.

Mojca

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Rajdeep Bharati]

Thank you for the clarification. I will update the old buildbot.

Regards
Rajdeep

On Sun, Jun 2, 2019 at 10:16 PM Ryan Schmidt 
wrote:

>
>
> On Jun 2, 2019, at 11:30, Rajdeep Bharati wrote:
>
> > One thing is that when I install the new py37-buildbot, the command that
> I get to use is `buildbot-3.7`.
> > What changes do I need to make in the port to use the command `buildbot`?
>
> As Rainer explained in
> https://github.com/macports/macports-ports/pull/4489, the ports should
> not be named with the "py-" prefix and should not be in the primary
> category "python". That's for Python modules that should be made available
> in multiple Python versions so that other ports can use them.
>
> But that's not what buildbot is. Buildbot is a program that we want to use
> for its own sake, so its port name should not begin with "py-" and it
> should be in a primary category that reflects its use. Look at the existing
> buildbot port. In fact, update that port instead of creating a new one.
>
> The python 1.0 portgroup adds the "-3.7" (or whatever version number)
> suffix for programs installed by Python module ports, since it assumes they
> will be provided in multiple Python versions and we don't want them to
> conflict. If the port name does not begin with "py-" the python portgroup
> won't do that. It can be overridden on a port by port basis but in this
> case the correct thing to do is to fix the name of the port.
>
>

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Ryan Schmidt]

On Jun 2, 2019, at 11:30, Rajdeep Bharati wrote:

> One thing is that when I install the new py37-buildbot, the command that I 
> get to use is `buildbot-3.7`. 
> What changes do I need to make in the port to use the command `buildbot`?

As Rainer explained in https://github.com/macports/macports-ports/pull/4489, 
the ports should not be named with the "py-" prefix and should not be in the 
primary category "python". That's for Python modules that should be made 
available in multiple Python versions so that other ports can use them.

But that's not what buildbot is. Buildbot is a program that we want to use for 
its own sake, so its port name should not begin with "py-" and it should be in 
a primary category that reflects its use. Look at the existing buildbot port. 
In fact, update that port instead of creating a new one.

The python 1.0 portgroup adds the "-3.7" (or whatever version number) suffix 
for programs installed by Python module ports, since it assumes they will be 
provided in multiple Python versions and we don't want them to conflict. If the 
port name does not begin with "py-" the python portgroup won't do that. It can 
be overridden on a port by port basis but in this case the correct thing to do 
is to fix the name of the port.

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Ryan Schmidt]

On May 29, 2019, at 13:29, Mojca Miklavec wrote:

> As an intermezzo I want to explain one thing. Initially we had one single job 
> (which could run for days), and it built all the ports in a single job. 
> However one could not infer any information about what worked and what failed 
> without downloading logs first, which could have reached hundreds of 
> megabytes each. We wanted to rewrite it with a custom number of steps, so 
> that a build of 100 ports would contain 100 steps (probably more like a few 
> times hundred; with "clean", "build dependencies", "build port", "upload 
> port", ... for each of the ports individually). The reason for creating port 
> watcher and port builder as separate entities was used as a workaround for 
> lack of functionality in buildbot 0.8, which is no longer the case in the 
> latest buildbot. So maybe it's even time to revise this decision and figure 
> out if there's a better way to organize port watcher/builder into a single 
> builder.

Having a portwatcher and a portbuilder for each OS version causes many 
problems. I'm all for combining them. We already discussed my proposal for 
doing that:

https://lists.macports.org/pipermail/macports-dev/2018-March/037577.html


> One problem with current setup is that it may happen that one presses the 
> "rebuild" button and starts building a port on the portbuilder at the same 
> time as portindex is being regenerated, or macports is being updated in the 
> portwatcher. These two actions should not happen at the same time.

This is not a problem currently because each portwatcher build waits for all of 
its portbuilder builds to finish. It is only currently a problem when there is 
a power outage or a buildworker crashes. It is annoying when that happens and I 
have to monitor the builds after everything is back up and usually reschedule 
some builds that failed because a portindex was being synced during a build, 
but fortunately it doesn't happen often.


> Another problem is that, say, a perl version increase may result in 
> rebuilding a few thousand ports. Buildbot 0.8 usually choked and became 
> uselessly slow (with builders idling for as long as an hour just to get the 
> next job assigned).

This was only a problem because our buildmaster's disk is slow and our buildbot 
cache settings were too low. We increased the cache sizes so that the pending 
builds can all be kept in RAM, so this isn't really a problem anymore, as far 
as I know.


> Before that rewrite, when everything ran as a single job, we would sometimes 
> schedule builds of all ports. With current setup it's more of a mission 
> impossible to imagine that. I have no idea how buildbot 2.x can handle builds 
> with tens of thousands of steps.

I touched on the problem of occasional huge numbers of builds in my combining 
proposal above. Builds of huge numbers of ports (whether forced or via a mass 
commit) could receive a "lesser priority" so that subsequent "normal" commits 
of one or a small number of ports could receive the normal "higher priority" 
and "skip the queue" and go first.

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Rajdeep Bharati]

On Sun, Jun 2, 2019 at 9:45 PM Ryan Schmidt  wrote:

>
>
> On May 31, 2019, at 17:27, Rajdeep Bharati wrote:
>
> > On Sat, Jun 1, 2019 at 2:01 AM Mojca Miklavec wrote:
> >
> >> What does
> >> port installed '*buildbot*'
> >> say?
> >
> > It's giving None of the specified ports are installed.
>
> It should show you all ports that are installed whose names contain the
> string "buildbot" *and are in the PortIndex*. If they aren't in the index,
> they won't be shown.
>
> If you want to show all ports that are installed whose names contain the
> string "buildbot" *regardless of whether they are in the PortIndex* then
> you can use:
>
> port installed | grep buildbot
>
> Got it, thanks for your help. One thing is that when I install the new
py37-buildbot, the command that I get to use is `buildbot-3.7`.
What changes do I need to make in the port to use the command `buildbot`?

Regards
Rajdeep

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Ryan Schmidt]

On May 31, 2019, at 17:27, Rajdeep Bharati wrote:

> On Sat, Jun 1, 2019 at 2:01 AM Mojca Miklavec wrote:
> 
>> What does
>> port installed '*buildbot*'
>> say?
> 
> It's giving None of the specified ports are installed.

It should show you all ports that are installed whose names contain the string 
"buildbot" *and are in the PortIndex*. If they aren't in the index, they won't 
be shown.

If you want to show all ports that are installed whose names contain the string 
"buildbot" *regardless of whether they are in the PortIndex* then you can use:

port installed | grep buildbot

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Rajdeep Bharati]

On Sat, Jun 1, 2019 at 2:01 AM Mojca Miklavec  wrote:

> Dear Rajdeep,
>
> I'm sorry, I somewhat missed this one particular error.
>
> You need to install py37-buildbot rather than py-buildbot, same for
> py37-buildbot-pkg and mock (probably py37-mock).
>
> Yes I installed the one with py37-*.

> One problem is that apparently proper dependency specifications for
> buildbot-www are lacking, something that should have probably been fixed in
> packaging of buildbot on pypi, but you should be able to circumvent the
> problem by installing the dependencies manually, or by adding them manually
> to the list of dependencies.
>
> What does
> port installed '*buildbot*'
> say?
>
It's giving None of the specified ports are installed.


> I also create the package with upt, initially got the same problem
> (missing dependencies), but it worked after I installed the individual
> dependencies first (or put them in the Portfile).
>
> Are you referring to the dependencies specified by upt?

> Regarding the problems in master setup: using your repository I'm still
> getting a bunch of issues with names of workers and builders. The problem
> is that new worker names no longer allow dots and underscores, but the old
> logic was relying on the fact that builder name would be composed out of
> worker name, and now I probably need to change those names at various
> places. I disabled the part with production/uploading files etc. by merely
> removing it from the yaml file. I need some more time to figure out what
> other problems were.
>
> I still wonder why the dots and underscores are no longer allowed.
>
> Mojca
>
> On Wed, 29 May 2019 at 14:37, Rajdeep Bharati 
> wrote:
>
>>
>> Simply making those portfiles with upt-macports isn't helping.
>> When I try to install them using `sudo port -vst install`, it shows:
>>
>> --->  Building py37-buildbot-www
>>
>> Executing:  cd
>> "/opt/local/var/macports/build/_Users_rajdeep_portfiles_python_py-buildbot-www/py37-buildbot-www/work/buildbot-www-2.3.1"
>> &&
>> /opt/local/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7
>> setup.py --no-user-cfg build
>>
>> Please install buildbot, buildbot_pkg, and mock modules in order to
>> install that package, or use the pre-build .whl modules available on pypi
>>
>> Command failed:  cd
>> "/opt/local/var/macports/build/_Users_rajdeep_portfiles_python_py-buildbot-www/py37-buildbot-www/work/buildbot-www-2.3.1"
>> &&
>> /opt/local/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7
>> setup.py --no-user-cfg build
>>
>> Exit code: 1
>>
>> Warning: The following existing file was hidden from the build system by
>> trace mode:
>>
>>   /var/db/timezone/zoneinfo/Asia/Kolkata
>>
>> Error: Failed to build py37-buildbot-www: command execution failed
>>
>> Error: See
>> /opt/local/var/macports/logs/_Users_rajdeep_portfiles_python_py-buildbot-www/py37-buildbot-www/main.log
>> for details.
>>
>> Error: Follow https://guide.macports.org/#project.tickets to report a
>> bug.
>>
>> Error: Processing of port py-buildbot-www failed
>>
>> Note that py-buildbot and py-buildbot-pkg have been installed before
>> running this command.
>> Getting similar errors for py-buildbot-waterfall,console,etc.
>>
>>
>>>
>> >
>>> > (3) I assume I don't have permissions to do any changes on the project
>>> > (https://github.com/buildbot/buildbot/projects/4)
>>> > I also don't know if such a project can work with multiple
>>> > repositories (my guess is not). For example, is it possible to add
>>> > https://github.com/macports/macports-ports/pull/4489
>>> > to that list? It would be nice to fill the project with most TODO
>>> > items that are expected to be finished during the summer and attach
>>> > some kind of milestones. It would be nice to have everything collected
>>> > at a single place, but if it doesn't work ... well ...
>>>
>>> I added you and rajdeep as a triage collaborator. Please let me know
>>> what is working in this mode
>>>
>>> >
>>> > (4) Unrelated to Rajdeep's project: do you have any experience with
>>> > making and deploying docker containers? And if so, would you be
>>> > willing to give us some completely general advice about the proper
>>> > approach to deploy another student's code as a docker image?
>>>
>>> I can help, but I would need a bit more context.
>>> What is the kind of app? where do you want to deploy it?
>>> There are tons of options to manage and deploy docker containers.
>>> I mostly use kubernetes. It is very powerful for medium to large
>>> complexity deployments.
>>> You can also run simple docker apps using standard system tool like
>>> systemd or launchd os macos.
>>>
>>> Regards
>>> Pierre
>>>
>>
I'm writing the JS view (I've set up the modal, with the date range). Some
work is left (creating routes and the algorithm to find all builds
corresponding to a particular change). I will most probably complete a
working prototype tomorrow.

Rajdeep

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Mojca Miklavec]

On Thu, 30 May 2019 at 16:43, Rajdeep Bharati wrote:
>
> How do we decide which ports are supposed to be built? Is it only the ports 
> (files) that are affected by a particular `change`?

We fetch a list of modified directories.
Then a bash script from mpbb runs though all of the ports in those
directories and creates a list of candidate ports.
The next step checks whether any of those ports already exist as a
binary package (for that particular version and revision). If it does,
the port is removed from the list.

The remaining ports get built.

> Assume that I made a change to py-django port. Which ports should be built in 
> the following situations:
>
> Version of py-django is updated (no other changes)

We start the builds for the following ports: py-django, py27-django,
py37-django (or whatever other subports are there, I didn't check). If
you only change the version of django 2 (py27-django is kept back at
django 1), then py27-django might be skipped as it already existed
before.

Any of those three builds will also install the dependencies as part
of the build process. Generally the dependencies are already present,
but let's say that one of dependencies was broken before, or that we
just set up a new builder for macOS 10.15, the dependencies would be
built and uploaded to the server (from within the "install
dependencies of pyXY-django" step) and not reported as a separate
build.

> Version of py-django is updated, new dependency added

Same as above.

> Version of py-django is updated, dependencies' ports also updated

This would update more that one folder, so the commit would report
both python/py-django and python/py-foo, and the list would contain
py-django, py27-django, py37-django, py-foo, py27-foo, py36-foo,
py37-foo.
mpbb would first sort the list, so that dependencies would be built
first and shown as standalone builds.

> Does any port depending on py-django also be built in any of these situations?

No.
In the long term it would probably make sense to set up also something
like that, probably just on a single builder, and make sure that no
dependent port breaks or changes, and report in case something like
that happens.

In theory you need to revbump all dependent ports if you expect those
ports to change as a consequence of py-django update, and then all
those ports would be rebuilt, but of course developers forget etc.,
and it would be nice to have some automation to assist with that
process.

Fixing it immediately would be a bit of a too heavy task on one hand,
but it would also require more resources on the other hand. The
powerpc builder can hardly handle the traffic it gets right now.
Adding additional builds would kill it. We would also want to perform
slightly different steps when checking dependent ports.

> Which dependencies are built along with py-django?

All dependencies get installed. Most of them would only get activated
(if present on the worker) or fetched from the mirror (if present
there). If not present, they would be built and at the end uploaded to
the server in the last uploading step.

Mojca

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Rajdeep Bharati]

On Wed, May 29, 2019 at 11:59 PM Mojca Miklavec  wrote:

> (CC-ing Arjun as parts of this might be of interest for the app as well,
> and the general mailing list as they might provide further feedback.)
>
> On Wed, 29 May 2019 at 08:57, Rajdeep Bharati 
> wrote:
>
>> Hi,
>> I wanted to be sure about one thing:
>> In view #2
>>  Screenshot 2019-05-29 at 12.21.13 PM.png
>> 
>> do you want me to put information about
>> 1) only the builds
>> 2) builds as well as commits
>> I assume that the table (as shown in the screenshot) would have info of
>> the
>> builds and their results on every port and OS version.
>>
>
> For anyone reading the mailing list, we are talking about
> https://trac.macports.org/ticket/55978
>
> I would primarily like to see the commits (as well as potentially forced
> builds, but those with a somewhat lower priority; forced builds could be
> discussed later; as I understand one cannot even trigger builds at the same
> time on multiple builders without modifying configuration).
>
> The builds by themselves are hardly useful. My primary goal for this is as
> follows. Let's say that I know that I changed the python37 port in commit
> X. Two months later I want to know on which workers the build failed and on
> which ones it succeeded. With the existing build.macports.org this info
> is literally impossible to find unless you write a bot that fetches json
> data from the builds as far back as you can get (maybe doing some bisection
> or so). And once you find the relevant build 13584 for Mac OS X 10.6, you
> need to repeat the exercise for 10.7, 10.8, ... 10.14 all from scratch.
>
> With the new buildbot the console view partially does what I would like to
> see. Take a look at
> https://nine.buildbot.net/#/console
> If you ignore the bug with "unknow revision x-y" and scroll down to
> something like a pull request or an actual commit, you can extend the view
> and get something like this:
>
> [image: image.png]
>
> We would like to be able to browse commits (that's why we talked about
> "calendar widget"), click on a commit of interest and get to a page with
> information for that commit (group) only. Mostly because there will be so
> much information that a table like this might be simply too crowdy, but
> also because it would be nice to have a link that can be shared, I'm not
> sure if you can share a link to the screenshot I sent above. Having a
> single page is not a strict requirement though. With some folding it could
> be ok to have it implemented in a similar way as on the above screenshot.
>
> The screenshot above already contains a lot of information that we want to
> have:
>
>- author name & timestamp are already there
>- (committer name & timestamp are already on your short-term TODO list)
>- commit message is already there
>- link to github is already there
>- (link to trac tickets could be extracted from commit message; it's
>already in URL form if present, it's just a matter of making it active,
>i.e. adding "a href" around it)
>- (link to the PR that resulted in that commit might need to be added;
>or maybe it's there already, but I cannot see it on this view anyway)
>- (I forgot to mention, but probably the list of files modified would
>be useful as well, and maybe it's there already, at least it says "No
>files" in the view above.)
>
> The console also shows a nice view of the results across different
> builders.
>
> What's special about the way ports are built for MacPorts is that one
> commit (or rather: one build potentially encompassing multiple subsequent
> commits) triggers the builds of an arbitrary number of ports. And the
> information about whether that build in total (one single job on port
> watcher) passed or not is useless if it is not split into multiple ports.
> We want to make some kind of equivant of the above console view, but the
> view needs to contain a table of all the ports that were built as part of
> that "port watcher" job or "port builders".
>
> How do we decide which ports are supposed to be built? Is it only the
ports (files) that are affected by a particular `change`?
Also, I guess it would be better to have a separate view for each `change`.
One option would be implementing it as a modal in view #1 (for each change).
(I'll check if there's a way to create link to modal in Vue). Otherwise it
can be a different route.

As an intermezzo I want to explain one thing. Initially we had one single
> job (which could run for days), and it built all the ports in a single job.
> However one could not infer any information about what worked and what
> failed without downloading logs first, which could have reached hundreds of
> megabytes each. We wanted to rewrite it with a custom number of steps, so
> that a build of 100 ports would contain 100 steps (probably more like a few
> times hundred; with "clean", 

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Mojca Miklavec]

(CC-ing Arjun as parts of this might be of interest for the app as well,
and the general mailing list as they might provide further feedback.)

On Wed, 29 May 2019 at 08:57, Rajdeep Bharati 
wrote:

> Hi,
> I wanted to be sure about one thing:
> In view #2
>  Screenshot 2019-05-29 at 12.21.13 PM.png
> 
> do you want me to put information about
> 1) only the builds
> 2) builds as well as commits
> I assume that the table (as shown in the screenshot) would have info of
> the
> builds and their results on every port and OS version.
>

For anyone reading the mailing list, we are talking about
https://trac.macports.org/ticket/55978

I would primarily like to see the commits (as well as potentially forced
builds, but those with a somewhat lower priority; forced builds could be
discussed later; as I understand one cannot even trigger builds at the same
time on multiple builders without modifying configuration).

The builds by themselves are hardly useful. My primary goal for this is as
follows. Let's say that I know that I changed the python37 port in commit
X. Two months later I want to know on which workers the build failed and on
which ones it succeeded. With the existing build.macports.org this info is
literally impossible to find unless you write a bot that fetches json data
from the builds as far back as you can get (maybe doing some bisection or
so). And once you find the relevant build 13584 for Mac OS X 10.6, you need
to repeat the exercise for 10.7, 10.8, ... 10.14 all from scratch.

With the new buildbot the console view partially does what I would like to
see. Take a look at
https://nine.buildbot.net/#/console
If you ignore the bug with "unknow revision x-y" and scroll down to
something like a pull request or an actual commit, you can extend the view
and get something like this:

[image: image.png]

We would like to be able to browse commits (that's why we talked about
"calendar widget"), click on a commit of interest and get to a page with
information for that commit (group) only. Mostly because there will be so
much information that a table like this might be simply too crowdy, but
also because it would be nice to have a link that can be shared, I'm not
sure if you can share a link to the screenshot I sent above. Having a
single page is not a strict requirement though. With some folding it could
be ok to have it implemented in a similar way as on the above screenshot.

The screenshot above already contains a lot of information that we want to
have:

   - author name & timestamp are already there
   - (committer name & timestamp are already on your short-term TODO list)
   - commit message is already there
   - link to github is already there
   - (link to trac tickets could be extracted from commit message; it's
   already in URL form if present, it's just a matter of making it active,
   i.e. adding "a href" around it)
   - (link to the PR that resulted in that commit might need to be added;
   or maybe it's there already, but I cannot see it on this view anyway)
   - (I forgot to mention, but probably the list of files modified would be
   useful as well, and maybe it's there already, at least it says "No files"
   in the view above.)

The console also shows a nice view of the results across different builders.

What's special about the way ports are built for MacPorts is that one
commit (or rather: one build potentially encompassing multiple subsequent
commits) triggers the builds of an arbitrary number of ports. And the
information about whether that build in total (one single job on port
watcher) passed or not is useless if it is not split into multiple ports.
We want to make some kind of equivant of the above console view, but the
view needs to contain a table of all the ports that were built as part of
that "port watcher" job or "port builders".

As an intermezzo I want to explain one thing. Initially we had one single
job (which could run for days), and it built all the ports in a single job.
However one could not infer any information about what worked and what
failed without downloading logs first, which could have reached hundreds of
megabytes each. We wanted to rewrite it with a custom number of steps, so
that a build of 100 ports would contain 100 steps (probably more like a few
times hundred; with "clean", "build dependencies", "build port", "upload
port", ... for each of the ports individually). The reason for creating
port watcher and port builder as separate entities was used as a workaround
for lack of functionality in buildbot 0.8, which is no longer the case in
the latest buildbot. So maybe it's even time to revise this decision and
figure out if there's a better way to organize port watcher/builder into a
single builder.

One problem with current setup is that it may happen that one presses the
"rebuild" button and starts building a port on the portbuilder at the same
time as portindex 

GSOC 2019 Coding period starts tomorrow

[Mojca Miklavec]

Dear Students, Mentors & others,

We are all enthusiastic about the most productive part of the GSOC
that's officially about to start tomorrow.

We have so many projects this year that it became non-trivial to keep
all the relevant URLs in the memory. Please check if I got all the
details right:
https://trac.macports.org/wiki/SummerOfCode/2019
(and feel free to do any corrections).

I expect that any project would have weekly meetings with the student
and mentors, solving some more challenging technical details and
planning together etc.

Just curious: would the others find it helpful to have some very very
short weekly(?) meeting with all of the projects together (probably in
written form rather than audio) and any other interested developers?
I'm not even sure if we could find a suitable time slot, it would not
be absolutely necessary to have everyone present every single week,
but it could help boost some motivation, give rise to new ideas when
exchanging experience, sharing progress (and challenges) together etc.

In any case I would like to encourage the students to keep an eye on
each other's project and potentially help with feedback, testing, code
reviews etc.

(For the webapp we'll be provisionally testing gitter for real-time
communication for now. That doesn't mean that we won't decide to
switch later on, I just didn't have time to actually test all the
alternatives, and this will be the first test, as we needed to start
with something quickly.)

I'm looking forward to the summer experience and all the nice products ...

Mojca

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Pierre Tardy]

I re-up buildbot.buildbot.net

But the console view is broken.
https://github.com/buildbot/buildbot/issues/4777

Can you also have a look at this?

I can also see that buildbot_travis do not build anymore
https://github.com/buildbot/buildbot/issues/4778

probably I did merge the webpack PR a bit too early :)

Regards
Pierre

Le mar. 21 mai 2019 à 16:33, Rajdeep Bharati
 a écrit :
>
> Done.
>
> On Tue, May 21, 2019 at 7:54 PM Pierre Tardy  wrote:
>>
>> Can you please make a PR?
>>
>> Thanks
>> Pierre
>>
>> Le mar. 21 mai 2019 à 16:21, Rajdeep Bharati
>>  a écrit :
>> >
>> > There's a bug in 
>> > https://github.com/buildbot/buildbot/blob/master/www/base/src/app/app.module.js
>> > Changes haven't been `require`d.
>> > These lines need to be added:
>> > require('./changes/changes.controller.js');
>> > require('./changes/changes.route.js');
>> > It's working after adding them
>> >
>> > Rajdeep
>> >
>> > On Tue, May 21, 2019 at 7:33 PM Pierre Tardy  wrote:
>> >>
>> >> Ouch, and we have https://buildbot.buildbot.net/ which is down
>> >> (probably because of that )
>> >>
>> >> looking at it..
>> >> Pierre
>> >>
>> >> Le mar. 21 mai 2019 à 15:57, Rajdeep Bharati
>> >>  a écrit :
>> >> >
>> >> > Hi
>> >> >
>> >> > I am having one issue with the buildbot (I think it's happening after 
>> >> > the new webpack PR, but not sure).
>> >> > In the navigation menu, `Last Changes` isn't displayed. I have used the 
>> >> > same buildmaster that I was using before
>> >> > (also tried polling different repositories).
>> >> >
>> >> > Could you tell me whether everything is okay on my side?
>> >> >
>> >> > Thanks
>> >> > Rajdeep
>> >> >
>> >> > On Sat, May 18, 2019 at 1:32 PM Rajdeep Bharati 
>> >> >  wrote:
>> >> >>
>> >> >> Thank you. Now it's working
>> >> >>
>> >> >> Rajdeep
>> >> >>
>> >> >> On Sat, May 18, 2019 at 12:29 PM Pierre Tardy  wrote:
>> >> >>>
>> >> >>> Hi,
>> >> >>>
>> >> >>> The buildbot_badges plugin is using cairo. You can try to uninstall
>> >> >>> that to move forward
>> >> >>> Pierre
>> >> >>>
>> >> >>> Le sam. 18 mai 2019 à 07:58, Rajdeep Bharati
>> >> >>>  a écrit :
>> >> >>> >
>> >> >>> > Hi,
>> >> >>> > I was trying out the webpack PR. Here's what I did:
>> >> >>> >
>> >> >>> > clone the branch git clone --single-branch --branch www-webpack 
>> >> >>> > https://github.com/p12tic/buildbot.git buildbotwebpack
>> >> >>> > cd, make virtualenv, activate
>> >> >>> > make frontend
>> >> >>> > Then outside the directory, I did:
>> >> >>> >
>> >> >>> > buildbot create-master wpmaster
>> >> >>> >
>> >> >>> > Now I got the following error:
>> >> >>> >
>> >> >>> > raise OSError("dlopen() failed to load a library: %s" % ' / 
>> >> >>> > '.join(names))
>> >> >>> >
>> >> >>> > OSError: dlopen() failed to load a library: cairo / cairo-2 / 
>> >> >>> > cairo-gobject-2 / cairo.so.2
>> >> >>> >
>> >> >>> > This is the full stack trace: https://pastebin.com/eDk9GVRK
>> >> >>> > There are some answers on SO, but they are using homebrew python 
>> >> >>> > (I'm using macports py). I guess that's why they didn't work?
>> >> >>> > Could you please help?
>> >> >>> >
>> >> >>> > Thank you.
>> >> >>> > Rajdeep
>> >> >>> >
>> >> >>> > On Wed, May 15, 2019 at 5:20 PM Rajdeep Bharati 
>> >> >>> >  wrote:
>> >> >>> >>
>> >> >>> >> Ok cool!
>> >> >>> >>
>> >> >>> >> Thanks
>> >> >>> >> Rajdeep
>> >> >>> >>
>> >> >>> >> On Wed, May 15, 2019 at 1:29 PM Pierre Tardy  
>> >> >>> >> wrote:
>> >> >>> >>>
>> >> >>> >>> Hi Rajdeep,
>> >> >>> >>>
>> >> >>> >>> Buildbot calculates the version number based on tags. You you 
>> >> >>> >>> have to
>> >> >>> >>> fetch all the tags so that the version is correctly calculated.
>> >> >>> >>>
>> >> >>> >>> git fetch --tags --all
>> >> >>> >>>
>> >> >>> >>> then you can re-do the make virtualenv
>> >> >>> >>>
>> >> >>> >>> Regards
>> >> >>> >>> Pierre
>> >> >>> >>>
>> >> >>> >>> Le mar. 14 mai 2019 à 11:39, Rajdeep Bharati
>> >> >>> >>>  a écrit :
>> >> >>> >>> >
>> >> >>> >>> > Thanks for the feedback!
>> >> >>> >>> >
>> >> >>> >>> > I had a doubt in buildbot:
>> >> >>> >>> > When I install buildbot from source (github), then why is it 
>> >> >>> >>> > showing version 2.1.1dev... installed? Shouldn't it show the 
>> >> >>> >>> > latest version (2.3.0)? It is up to date with the master branch.
>> >> >>> >>> >
>> >> >>> >>> > Thank you.
>> >> >>> >>> > Rajdeep
>> >> >>> >>> >
>> >> >>> >>> > On Fri, May 10, 2019 at 3:17 AM Mojca Miklavec 
>> >> >>> >>> >  wrote:
>> >> >>> >>> >>
>> >> >>> >>> >> On Wed, 8 May 2019 at 21:00, Rajdeep Bharati wrote:
>> >> >>> >>> >> >
>> >> >>> >>> >> > Hi,
>> >> >>> >>> >> >
>> >> >>> >>> >> > I created some issues and found some which would be relevant 
>> >> >>> >>> >> > for the project (as discussed in the IRC meeting):
>> >> >>> >>> >> >
>> >> >>> >>> >> > https://github.com/buildbot/buildbot/issues/4760
>> >> >>> >>> >> > https://github.com/buildbot/buildbot/issues/4761
>> >> >>> >>> >> > https://github.com/buildbot/buildbot/issues/4709
>> >> >>> >>> >> > 

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Pierre Tardy]

Can you please make a PR?

Thanks
Pierre

Le mar. 21 mai 2019 à 16:21, Rajdeep Bharati
 a écrit :
>
> There's a bug in 
> https://github.com/buildbot/buildbot/blob/master/www/base/src/app/app.module.js
> Changes haven't been `require`d.
> These lines need to be added:
> require('./changes/changes.controller.js');
> require('./changes/changes.route.js');
> It's working after adding them
>
> Rajdeep
>
> On Tue, May 21, 2019 at 7:33 PM Pierre Tardy  wrote:
>>
>> Ouch, and we have https://buildbot.buildbot.net/ which is down
>> (probably because of that )
>>
>> looking at it..
>> Pierre
>>
>> Le mar. 21 mai 2019 à 15:57, Rajdeep Bharati
>>  a écrit :
>> >
>> > Hi
>> >
>> > I am having one issue with the buildbot (I think it's happening after the 
>> > new webpack PR, but not sure).
>> > In the navigation menu, `Last Changes` isn't displayed. I have used the 
>> > same buildmaster that I was using before
>> > (also tried polling different repositories).
>> >
>> > Could you tell me whether everything is okay on my side?
>> >
>> > Thanks
>> > Rajdeep
>> >
>> > On Sat, May 18, 2019 at 1:32 PM Rajdeep Bharati 
>> >  wrote:
>> >>
>> >> Thank you. Now it's working
>> >>
>> >> Rajdeep
>> >>
>> >> On Sat, May 18, 2019 at 12:29 PM Pierre Tardy  wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> The buildbot_badges plugin is using cairo. You can try to uninstall
>> >>> that to move forward
>> >>> Pierre
>> >>>
>> >>> Le sam. 18 mai 2019 à 07:58, Rajdeep Bharati
>> >>>  a écrit :
>> >>> >
>> >>> > Hi,
>> >>> > I was trying out the webpack PR. Here's what I did:
>> >>> >
>> >>> > clone the branch git clone --single-branch --branch www-webpack 
>> >>> > https://github.com/p12tic/buildbot.git buildbotwebpack
>> >>> > cd, make virtualenv, activate
>> >>> > make frontend
>> >>> > Then outside the directory, I did:
>> >>> >
>> >>> > buildbot create-master wpmaster
>> >>> >
>> >>> > Now I got the following error:
>> >>> >
>> >>> > raise OSError("dlopen() failed to load a library: %s" % ' / 
>> >>> > '.join(names))
>> >>> >
>> >>> > OSError: dlopen() failed to load a library: cairo / cairo-2 / 
>> >>> > cairo-gobject-2 / cairo.so.2
>> >>> >
>> >>> > This is the full stack trace: https://pastebin.com/eDk9GVRK
>> >>> > There are some answers on SO, but they are using homebrew python (I'm 
>> >>> > using macports py). I guess that's why they didn't work?
>> >>> > Could you please help?
>> >>> >
>> >>> > Thank you.
>> >>> > Rajdeep
>> >>> >
>> >>> > On Wed, May 15, 2019 at 5:20 PM Rajdeep Bharati 
>> >>> >  wrote:
>> >>> >>
>> >>> >> Ok cool!
>> >>> >>
>> >>> >> Thanks
>> >>> >> Rajdeep
>> >>> >>
>> >>> >> On Wed, May 15, 2019 at 1:29 PM Pierre Tardy  wrote:
>> >>> >>>
>> >>> >>> Hi Rajdeep,
>> >>> >>>
>> >>> >>> Buildbot calculates the version number based on tags. You you have to
>> >>> >>> fetch all the tags so that the version is correctly calculated.
>> >>> >>>
>> >>> >>> git fetch --tags --all
>> >>> >>>
>> >>> >>> then you can re-do the make virtualenv
>> >>> >>>
>> >>> >>> Regards
>> >>> >>> Pierre
>> >>> >>>
>> >>> >>> Le mar. 14 mai 2019 à 11:39, Rajdeep Bharati
>> >>> >>>  a écrit :
>> >>> >>> >
>> >>> >>> > Thanks for the feedback!
>> >>> >>> >
>> >>> >>> > I had a doubt in buildbot:
>> >>> >>> > When I install buildbot from source (github), then why is it 
>> >>> >>> > showing version 2.1.1dev... installed? Shouldn't it show the 
>> >>> >>> > latest version (2.3.0)? It is up to date with the master branch.
>> >>> >>> >
>> >>> >>> > Thank you.
>> >>> >>> > Rajdeep
>> >>> >>> >
>> >>> >>> > On Fri, May 10, 2019 at 3:17 AM Mojca Miklavec 
>> >>> >>> >  wrote:
>> >>> >>> >>
>> >>> >>> >> On Wed, 8 May 2019 at 21:00, Rajdeep Bharati wrote:
>> >>> >>> >> >
>> >>> >>> >> > Hi,
>> >>> >>> >> >
>> >>> >>> >> > I created some issues and found some which would be relevant 
>> >>> >>> >> > for the project (as discussed in the IRC meeting):
>> >>> >>> >> >
>> >>> >>> >> > https://github.com/buildbot/buildbot/issues/4760
>> >>> >>> >> > https://github.com/buildbot/buildbot/issues/4761
>> >>> >>> >> > https://github.com/buildbot/buildbot/issues/4709
>> >>> >>> >> > https://github.com/buildbot/buildbot/issues/3471
>> >>> >>> >> > https://github.com/buildbot/buildbot/issues/3470
>> >>> >>> >> > https://github.com/buildbot/buildbot/issues/4750
>> >>> >>> >>
>> >>> >>> >> Thank you.
>> >>> >>> >> (Nice to see that I'm not the first one requesting these :)
>> >>> >>> >>
>> >>> >>> >> I assume that we'll also want to add other items for the rest of 
>> >>> >>> >> the
>> >>> >>> >> summer to that list?
>> >>> >>> >>
>> >>> >>> >> > @Mojca Miklavec Yesterday you mentioned:
>> >>> >>> >> >>
>> >>> >>> >> >> 16:33:15  regarding the features of the default 
>> >>> >>> >> >> waterfall view, another problem I saw was that unless one of 
>> >>> >>> >> >> the builds was done recently, the builder doesn't even show in 
>> >>> >>> >> >> waterfall; for example, there is no texlive or pplib displayed 
>> >>> >>> >> >> on https://build.contextgarden.net/#/waterfall

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Pierre Tardy]

Ouch, and we have https://buildbot.buildbot.net/ which is down
(probably because of that )

looking at it..
Pierre

Le mar. 21 mai 2019 à 15:57, Rajdeep Bharati
 a écrit :
>
> Hi
>
> I am having one issue with the buildbot (I think it's happening after the new 
> webpack PR, but not sure).
> In the navigation menu, `Last Changes` isn't displayed. I have used the same 
> buildmaster that I was using before
> (also tried polling different repositories).
>
> Could you tell me whether everything is okay on my side?
>
> Thanks
> Rajdeep
>
> On Sat, May 18, 2019 at 1:32 PM Rajdeep Bharati  
> wrote:
>>
>> Thank you. Now it's working
>>
>> Rajdeep
>>
>> On Sat, May 18, 2019 at 12:29 PM Pierre Tardy  wrote:
>>>
>>> Hi,
>>>
>>> The buildbot_badges plugin is using cairo. You can try to uninstall
>>> that to move forward
>>> Pierre
>>>
>>> Le sam. 18 mai 2019 à 07:58, Rajdeep Bharati
>>>  a écrit :
>>> >
>>> > Hi,
>>> > I was trying out the webpack PR. Here's what I did:
>>> >
>>> > clone the branch git clone --single-branch --branch www-webpack 
>>> > https://github.com/p12tic/buildbot.git buildbotwebpack
>>> > cd, make virtualenv, activate
>>> > make frontend
>>> > Then outside the directory, I did:
>>> >
>>> > buildbot create-master wpmaster
>>> >
>>> > Now I got the following error:
>>> >
>>> > raise OSError("dlopen() failed to load a library: %s" % ' / '.join(names))
>>> >
>>> > OSError: dlopen() failed to load a library: cairo / cairo-2 / 
>>> > cairo-gobject-2 / cairo.so.2
>>> >
>>> > This is the full stack trace: https://pastebin.com/eDk9GVRK
>>> > There are some answers on SO, but they are using homebrew python (I'm 
>>> > using macports py). I guess that's why they didn't work?
>>> > Could you please help?
>>> >
>>> > Thank you.
>>> > Rajdeep
>>> >
>>> > On Wed, May 15, 2019 at 5:20 PM Rajdeep Bharati 
>>> >  wrote:
>>> >>
>>> >> Ok cool!
>>> >>
>>> >> Thanks
>>> >> Rajdeep
>>> >>
>>> >> On Wed, May 15, 2019 at 1:29 PM Pierre Tardy  wrote:
>>> >>>
>>> >>> Hi Rajdeep,
>>> >>>
>>> >>> Buildbot calculates the version number based on tags. You you have to
>>> >>> fetch all the tags so that the version is correctly calculated.
>>> >>>
>>> >>> git fetch --tags --all
>>> >>>
>>> >>> then you can re-do the make virtualenv
>>> >>>
>>> >>> Regards
>>> >>> Pierre
>>> >>>
>>> >>> Le mar. 14 mai 2019 à 11:39, Rajdeep Bharati
>>> >>>  a écrit :
>>> >>> >
>>> >>> > Thanks for the feedback!
>>> >>> >
>>> >>> > I had a doubt in buildbot:
>>> >>> > When I install buildbot from source (github), then why is it showing 
>>> >>> > version 2.1.1dev... installed? Shouldn't it show the latest version 
>>> >>> > (2.3.0)? It is up to date with the master branch.
>>> >>> >
>>> >>> > Thank you.
>>> >>> > Rajdeep
>>> >>> >
>>> >>> > On Fri, May 10, 2019 at 3:17 AM Mojca Miklavec  
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> On Wed, 8 May 2019 at 21:00, Rajdeep Bharati wrote:
>>> >>> >> >
>>> >>> >> > Hi,
>>> >>> >> >
>>> >>> >> > I created some issues and found some which would be relevant for 
>>> >>> >> > the project (as discussed in the IRC meeting):
>>> >>> >> >
>>> >>> >> > https://github.com/buildbot/buildbot/issues/4760
>>> >>> >> > https://github.com/buildbot/buildbot/issues/4761
>>> >>> >> > https://github.com/buildbot/buildbot/issues/4709
>>> >>> >> > https://github.com/buildbot/buildbot/issues/3471
>>> >>> >> > https://github.com/buildbot/buildbot/issues/3470
>>> >>> >> > https://github.com/buildbot/buildbot/issues/4750
>>> >>> >>
>>> >>> >> Thank you.
>>> >>> >> (Nice to see that I'm not the first one requesting these :)
>>> >>> >>
>>> >>> >> I assume that we'll also want to add other items for the rest of the
>>> >>> >> summer to that list?
>>> >>> >>
>>> >>> >> > @Mojca Miklavec Yesterday you mentioned:
>>> >>> >> >>
>>> >>> >> >> 16:33:15  regarding the features of the default waterfall 
>>> >>> >> >> view, another problem I saw was that unless one of the builds was 
>>> >>> >> >> done recently, the builder doesn't even show in waterfall; for 
>>> >>> >> >> example, there is no texlive or pplib displayed on 
>>> >>> >> >> https://build.contextgarden.net/#/waterfall
>>> >>> >>
>>> >>> >> And later Pierre said this was a feature :)
>>> >>> >>
>>> >>> >> > However, I am unable to find this problem in 
>>> >>> >> > https://nine.buildbot.net/#/waterfall (it's showing the builders 
>>> >>> >> > not having recent builds). I'm not sure (it might have been 
>>> >>> >> > configured in that manner in nine.buildbot, and not present by 
>>> >>> >> > default).
>>> >>> >> >
>>> >>> >> > I will try to replicate this issue in my local setup.
>>> >>> >>
>>> >>> >> If you look at
>>> >>> >> https://build.contextgarden.net/#/console
>>> >>> >> you can see that there is a huge number of "fake commits" from one
>>> >>> >> project (from periodic scheduler) after the last build of another
>>> >>> >> project was done. Maybe there's a setting which tells you how many
>>> >>> >> latest builds / commits to fetch when drawing the waterfall view. I

Re: Slack-like chat (also for GSOC)

[Rainer Müller]

On 18.05.19 00:04, Rainer Müller wrote:
> On 17.05.19 23:54, Umesh Singla wrote:
>> I tried setting one up. Well, it only takes one to sign up (email
>> optional) and create rooms. Please give it
>> a try: https://riot.im/app/#/room/#macports-public:matrix.org. This
>> one's a public room, you can see the messages but not talk until you
>> sign up. 
> 
> You do not need to create a new room. Please just join the existing
> #freenode_#macports:matrix.org, which is bridged to our IRC channel.>
> I think this is the best approach, because we already have a large user
> base in the IRC channel. The Matrix bridge is ideal for those who wish
> to use a more mordern client or do not want to run their own bouncer to
> always stay connected.

I noticed now that only users registered with NickServ where allowed to
speak on the IRC channel. This might also have prevented new users
connected via Matrix to speak, unless you also registered with NickServ.
In case you could join the channel but were unable to send messages,
please try again now.

We had enabled this due to a spam wave a few months ago. I hope we can
relax this limitation now without getting the spam bots again. Sorry, I
had not thought of disabling this before.

Rainer

Re: GSOC 2019 project: Improvements of Buildbot views (@ MacPorts)

[Pierre Tardy]

Hi,

The buildbot_badges plugin is using cairo. You can try to uninstall
that to move forward
Pierre

Le sam. 18 mai 2019 à 07:58, Rajdeep Bharati
 a écrit :
>
> Hi,
> I was trying out the webpack PR. Here's what I did:
>
> clone the branch git clone --single-branch --branch www-webpack 
> https://github.com/p12tic/buildbot.git buildbotwebpack
> cd, make virtualenv, activate
> make frontend
> Then outside the directory, I did:
>
> buildbot create-master wpmaster
>
> Now I got the following error:
>
> raise OSError("dlopen() failed to load a library: %s" % ' / '.join(names))
>
> OSError: dlopen() failed to load a library: cairo / cairo-2 / cairo-gobject-2 
> / cairo.so.2
>
> This is the full stack trace: https://pastebin.com/eDk9GVRK
> There are some answers on SO, but they are using homebrew python (I'm using 
> macports py). I guess that's why they didn't work?
> Could you please help?
>
> Thank you.
> Rajdeep
>
> On Wed, May 15, 2019 at 5:20 PM Rajdeep Bharati  
> wrote:
>>
>> Ok cool!
>>
>> Thanks
>> Rajdeep
>>
>> On Wed, May 15, 2019 at 1:29 PM Pierre Tardy  wrote:
>>>
>>> Hi Rajdeep,
>>>
>>> Buildbot calculates the version number based on tags. You you have to
>>> fetch all the tags so that the version is correctly calculated.
>>>
>>> git fetch --tags --all
>>>
>>> then you can re-do the make virtualenv
>>>
>>> Regards
>>> Pierre
>>>
>>> Le mar. 14 mai 2019 à 11:39, Rajdeep Bharati
>>>  a écrit :
>>> >
>>> > Thanks for the feedback!
>>> >
>>> > I had a doubt in buildbot:
>>> > When I install buildbot from source (github), then why is it showing 
>>> > version 2.1.1dev... installed? Shouldn't it show the latest version 
>>> > (2.3.0)? It is up to date with the master branch.
>>> >
>>> > Thank you.
>>> > Rajdeep
>>> >
>>> > On Fri, May 10, 2019 at 3:17 AM Mojca Miklavec  wrote:
>>> >>
>>> >> On Wed, 8 May 2019 at 21:00, Rajdeep Bharati wrote:
>>> >> >
>>> >> > Hi,
>>> >> >
>>> >> > I created some issues and found some which would be relevant for the 
>>> >> > project (as discussed in the IRC meeting):
>>> >> >
>>> >> > https://github.com/buildbot/buildbot/issues/4760
>>> >> > https://github.com/buildbot/buildbot/issues/4761
>>> >> > https://github.com/buildbot/buildbot/issues/4709
>>> >> > https://github.com/buildbot/buildbot/issues/3471
>>> >> > https://github.com/buildbot/buildbot/issues/3470
>>> >> > https://github.com/buildbot/buildbot/issues/4750
>>> >>
>>> >> Thank you.
>>> >> (Nice to see that I'm not the first one requesting these :)
>>> >>
>>> >> I assume that we'll also want to add other items for the rest of the
>>> >> summer to that list?
>>> >>
>>> >> > @Mojca Miklavec Yesterday you mentioned:
>>> >> >>
>>> >> >> 16:33:15  regarding the features of the default waterfall 
>>> >> >> view, another problem I saw was that unless one of the builds was 
>>> >> >> done recently, the builder doesn't even show in waterfall; for 
>>> >> >> example, there is no texlive or pplib displayed on 
>>> >> >> https://build.contextgarden.net/#/waterfall
>>> >>
>>> >> And later Pierre said this was a feature :)
>>> >>
>>> >> > However, I am unable to find this problem in 
>>> >> > https://nine.buildbot.net/#/waterfall (it's showing the builders not 
>>> >> > having recent builds). I'm not sure (it might have been configured in 
>>> >> > that manner in nine.buildbot, and not present by default).
>>> >> >
>>> >> > I will try to replicate this issue in my local setup.
>>> >>
>>> >> If you look at
>>> >> https://build.contextgarden.net/#/console
>>> >> you can see that there is a huge number of "fake commits" from one
>>> >> project (from periodic scheduler) after the last build of another
>>> >> project was done. Maybe there's a setting which tells you how many
>>> >> latest builds / commits to fetch when drawing the waterfall view. I
>>> >> didn't try to investigate what limits the number of displayed
>>> >> builders.
>>> >>
>>> >> Now: for me by far more important missing feature is in fact support
>>> >> for filtering on both console and waterfall. Once filtering and
>>> >> removal of old builders gets implemented, this particular issue will
>>> >> be less important.
>>> >>
>>> >> Mojca

Re: GSoC 2019 [Collect build statistics]

[Umesh Singla]

Nice. Makes testing a lot easier now. It would be great if you could push
the Dockerfile as well.

Also, I am not liking conversing on these multiple broken threads very
much. I'll try to setup Matrix (have absolutely no idea about it yet) today
so that we can compare gitter and matrix and move ahead.

Umesh

On Sat, May 18, 2019 at 2:19 AM Mojca Miklavec  wrote:

> On Fri, 17 May 2019 at 20:00, Arjun Salyan wrote:
> >
> > Hi Mojca and Umesh,
> >
> > I have now spent some time with docker. I have also dockerised the web
> app.
>
> Wonderful news!
>
> Let us know where we could fetch it from, so that we can test it and
> one of the infra team can put it on the server.
>
> I need to ship something until Monday. I'll be somewhat more relaxed
> after that. (PS: Clemens, do you happen to go to the automotive fair
> in Stuttgart next week?)
>
> Mojca
>

Re: Slack-like chat (also for GSOC)

[Mojca Miklavec]

On Thu, 16 May 2019 at 19:47, Rainer Müller wrote:
>
> I am really confused what you want to set up for Matrix?

If you are asking me ...

I don't know, I never used it and I never took a closer look, so I'm
not sure how it works.
I assumed that someone needs to configure something somewhere to
properly connect everything and to "meet at the same place" for
MacPorts.

Mojca

Re: Slack-like chat (also for GSOC)

[Ruben Di Battista]

If you want I can try to setup the Community and the IRC bridge...

On Thu, 16 May 2019, 08:31 Ruben Di Battista, 
wrote:

> I would like to stress once again about Matrix.
>
> If we setup Matrix, we can bridge the channels with whatever service you
> might need. First of all IRC, so people that like to keep hanging out there
> can still do it with the additional benefits of having more people to talk
> with.
>
> These other people would access the same chat stream from whatever client
> they want to (we might need to setup self hosted bridges for them...). That
> means potentially you can have bridges from Gitter, Rocket.Chat, Slack or
> even WhatsApp if you like so, altogether working bijectively.
>
> I would strongly consider it since this way we are not stuck with a
> specific service but you can merge them together if you wish so...
>
> I would propose to setup a Matrix community for Macports and bridge its
> channels with the IRC ones. This does not need any self hosting capability.
>
> As a step two we might also want to experiment with the Gitter bridge
> since someone else already configured a channel there...
>
> What do you think?
>
>
>
>
> On Thu, 16 May 2019, 08:21 Rainer Müller,  wrote:
>
>> On 2019-05-14 18:11, Rainer Müller wrote:
>> > For the self-hosted options, Rocket Chat would be an option. However,
>> > when we used it at work, after a while I started to miss some kind of
>> > threading for longer conversations. Although we also usually do not
>> > have
>> > long conversations or that much activity on IRC, so maybe this is not
>> > that important here.
>>
>> Turns out the newest version of Rocket Chat already has
>> "sub-discussions" for this, so my point above is not fully valid. I have
>> not worked with the latest version, so my experience with Rocket Chat
>> might be more limited than I thought.
>>
>> Rainer
>>
>

Re: Slack-like chat (also for GSOC)

[Ruben Di Battista]

I would like to stress once again about Matrix.

If we setup Matrix, we can bridge the channels with whatever service you
might need. First of all IRC, so people that like to keep hanging out there
can still do it with the additional benefits of having more people to talk
with.

These other people would access the same chat stream from whatever client
they want to (we might need to setup self hosted bridges for them...). That
means potentially you can have bridges from Gitter, Rocket.Chat, Slack or
even WhatsApp if you like so, altogether working bijectively.

I would strongly consider it since this way we are not stuck with a
specific service but you can merge them together if you wish so...

I would propose to setup a Matrix community for Macports and bridge its
channels with the IRC ones. This does not need any self hosting capability.

As a step two we might also want to experiment with the Gitter bridge since
someone else already configured a channel there...

What do you think?




On Thu, 16 May 2019, 08:21 Rainer Müller,  wrote:

> On 2019-05-14 18:11, Rainer Müller wrote:
> > For the self-hosted options, Rocket Chat would be an option. However,
> > when we used it at work, after a while I started to miss some kind of
> > threading for longer conversations. Although we also usually do not
> > have
> > long conversations or that much activity on IRC, so maybe this is not
> > that important here.
>
> Turns out the newest version of Rocket Chat already has
> "sub-discussions" for this, so my point above is not fully valid. I have
> not worked with the latest version, so my experience with Rocket Chat
> might be more limited than I thought.
>
> Rainer
>

Re: Slack-like chat (also for GSOC)

[Rainer Müller]

On 2019-05-14 22:32, Mojca Miklavec wrote:

On Tue, 14 May 2019 at 18:11, Rainer Müller wrote:

>>> Would it be realistic to install such a service on breaburn if needed?
>>> (Or is it too complex / too much work?)
>>
>> I'd prefer a SaaS offering here. Self-hosting just increases the
>> maintenance burden and I don't think we need the configurability.

For the self-hosted options, Rocket Chat would be an option. However,
when we used it at work, after a while I started to miss some kind of
threading for longer conversations. Although we also usually do not 
have

long conversations or that much activity on IRC, so maybe this is not
that important here.


I don't have any experience with Matrix, but I maybe I should try it 
once.


I'm not familiar with Rocket Chat either, but if you missed a feature,
I trust your opinion.

I do believe that longer conversations are important. Think of GSOC,
where the same project runs for 5 months or longer. It does make sense
to keep it well-organised.

Zulip offers topics (which they heavily advertise as one of their
"superpowers") which I find to be quite a nice "substitute" for
threads like those in emails. If we pick that one, I would certainly
go for GitHub OAuth and IRC mirror.

I would discard the idea of using Slack. Based on general feedback
that probably leaves the following top candidates?
- Matrix (might work without self-hosting)
- Zulip
- Mattermost

Rainer, you did not answer about whether you would be willing to try
to install / maintain one of those on the server if we wanted to
self-host the chat?


Of course, I would be in favor of something where we do not need to do 
the maintenance. But if there is no option that is free and offers all 
features we want, it would be possible to host it on our server. 
Preferably with authentication with GitHub to ease administration of 
groups and privileges.


Regarding Matrix: is anyone willing to set up one ("in the cloud") for 
testing?


You could just use the matrix.org as a homeserver, which is open for 
registrations by all. The best client I am aware of would be 
https://riot.im, which uses matrix.org as default and can register new 
accounts. It offers a solution for all of Web/Desktop/Mobile. Joining 
the FreeNode IRC Bridge should be possible from all homeservers and with 
any client though, via a special channel name.


https://github.com/matrix-org/matrix-appservice-irc/wiki/Bridged-IRC-networks

Rainer

Re: Slack-like chat (also for GSOC)

[Rainer Müller]

On 2019-05-14 18:11, Rainer Müller wrote:

For the self-hosted options, Rocket Chat would be an option. However,
when we used it at work, after a while I started to miss some kind of
threading for longer conversations. Although we also usually do not 
have

long conversations or that much activity on IRC, so maybe this is not
that important here.


Turns out the newest version of Rocket Chat already has 
"sub-discussions" for this, so my point above is not fully valid. I have 
not worked with the latest version, so my experience with Rocket Chat 
might be more limited than I thought.


Rainer