Re: Wrapping up Bugzilla migration

[Carlos Soriano]

Thanks Bartłomiej for this! And apologies to everyone I couldn't migrate
their BZs in the past.

On Mon, 17 May 2021 at 16:45, Bartłomiej Piotrowski 
wrote:

> Hi all,
>
> I have been looking at Bugzilla migration requests today and have some
> related announcements.
>
> First of all, if for some reason you are still using Bugzilla, you
> should stop and move to GitLab. I hope it's not a surprise to anyone.
>
> Infrastructure team will be accepting bugs migration requests till the
> end of May 2021. After this date, we intend to turn bugzilla.gnome.org
> to static HTML page and decommission its infrastructure. A specific date
> will be announced in June.
>
> I know some of these requests are not resolved for years, but I'm slowly
> going through the queue. Please let me know if we should prioritize
> specific migrations or if you have any questions.
>
> Thanks,
> Bart
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Request For Items: September Monthly GNOME Updates

[Carlos Soriano]

This is an excellent idea, thanks Christopher for putting this together!

On Wed, 2 Sep 2020 at 10:24, Christopher Davis 
wrote:

> This marks the first trial of #71
> 
> for Monthly "What's Happening in GNOME" posts. Here, I'd like to ask the
> developers and maintainers to post information on cool things that have
> been merged throughout the month. All submissions are due by *Wednesday
> September 23rd @ 12AM PT*. All submissions afterward will be pushed to
> the next month's update.
>
> If the submission is for a visual change, screenshots or screencasts would
> be appreciated. Screenshots and screencast should use a default wallpaper
> for the latest stable GNOME release, the Adwaita theme, and be taken in at
> least 1080p.
>
> To submit a change for inclusion, please reply here, on the GitLab issue
> ,
> or on the GNOME Discourse thread
> 
> .
>
> Regards,
>
> Christopher Davis
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix IRC bridge considered harmful

[Carlos Soriano via desktop-devel-list]

Matthew,

On April 19th 2020 we completed the server set up configured as agreed.
After that, we though everything was done and ready, and as you probably
remember we did actually informed the community about the improved services
[0]. That the previous answer to this thread make it sound like it has been
on hold because of us since then is not correct and I believe it has more
drama on it than it needs to be.

We do truly appreciate the services, because you are right that it's
beneficial for both organizations and we want GNOME contributors to have
the best experience regardless of the service they are using. However, I
hope you understand our careful consideration on what steps we follow here,
as we care about not putting the community in a position that would be
difficult to go back from. This is specially true around branding, external
services and official recommendations.

I don't see a reason why we couldn't make the IRC bridge performance ok
with this requirements in place, so let's continue working on making that
happen as we have been doing.

Thanks,
Carlos

[0]
https://mail.gnome.org/archives/desktop-devel-list/2019-March/msg00015.html

On Fri, 14 Feb 2020 at 01:00, Matthew Hodgson via desktop-devel-list <
desktop-devel-list@gnome.org> wrote:

> Hi folks,
>
> Sorry for the delay in response here - the last 24 hours have not been fun.
>
> Trying to address the main bits of feedback here:
>
> 1. The original issue that Michael Catanzaro reported (Matrix->IRC PM
> going missing) was a legitimate bug in the bridge.  The bridge is meant to
> display an error if you try to talk to an absent IRC user; this was fixed
> today and will be deployed tomorrow:
> https://github.com/matrix-org/matrix-appservice-irc/pull/978.  Sorry that
> you got bitten by this :(
>
> 2. In terms of: "We currently have loads of garbage IRC users in the
> channels after the bridge hosted at matrix.org was replaced with one
> hosted at the gnome.org homeserver." - I thought we'd cleared this up in
> the days following the migration, and this is the first I've heard of it
> still being a problem.  It sounds like the old bridge created IRC users on
> the Matrix side, and then the new bridge bridged them back over to IRC.  It
> should be trivial to kick out the old bridge's IRC users - please can you
> give me an example channel/room where this is happening to look at?
>
> 3. In terms of bridge performance: we set up a dedicated bridge and server
> for gnome.org powered by modular.im back in April 2019.  The bridge got
> put live, but the server was never publicised because we never got a
> greenlight to announce its existence (plus the go-live was eclipsed by some
> unrelated security dramas on the matrix.org homeserver).  As a result,
> the majority of users have been using the bridge via the public matrix.org
> server, which is (unfortunately) often overloaded thanks to the exponential
> growth we've been dealing with.  However, if folks were actually using the
> dedicated GNOME server, then it would be an *excellent* experience - much
> like the one that Mozilla is enjoying currently.  It's worth noting that we
> provided the GNOME server for free because we want to support the project,
> but the running costs are significant - it's been very frustrating that the
> server has not been used.  (It seems that some people have found it anyway
> over the course of today, to quote someone in #general:gnome.org: "OMG
> the IRC bridge is SO much faster on this instance.").  I'm hoping that we
> can get a greenlight to point people at the Gnome.org server, as right now
> the situation is indeed terrible and it's hurting Matrix's reputation as
> well as hurting GNOME :((
>
> 4. Mozilla *are* running their homeserver federated (as of this week) -
> c.f. https://twitter.com/littledan/status/1227603567722319873. They're
> countering abuse by using the arsenal of anti-abuse tooling we've been
> working on over the last year as per
> https://matrix.org/docs/guides/moderation/ and
> https://github.com/matrix-org/matrix-doc/blob/msc2313/proposals/2313-moderation-policy-rooms.md
> etc.
>
> You may also be interested that the core Matrix team is starting to look
> seriously at the work going on around Fractal, particularly around E2E
> encryption, to accelerate E2E encryption for Rust clients in general.
> Specifically, we're porting pantalaimon (the Matrix daemon which offloads
> E2E encryption) from Python to Rust, and we hope that the resulting
> official E2EE-capable Matrix Rust SDK will be directly usable by Fractal
> and help the project along massively as a first class native Matrix GTK
> client (assuming they want to use it! :)
>
> So, TL;DR: we've had a solution to much of the Matrix<->IRC problems since
> April 2019, w

Re: Matrix IRC bridge considered harmful

[Carlos Soriano via desktop-devel-list]

Hi folks,

We been in contact with Matthew from Matrix for some time already. I lately
didn't have much time to invest on this, so we had have some delays on
answering. However, it's our expectation that with the set up that we have
right now the IRC bridge should perform as its best, as we are using
servers from modular.im, the company that maintains paid severs with matrix
services on them. We believe our set up is correct, but there might be some
miss configuration somewhere, or the current situation it's already the
best that can be offered.

We'll update you as soon as we have more information.

Cheers,
Carlos

On Thu, 13 Feb 2020 at 17:16, Michael Catanzaro 
wrote:

> On Wed, Feb 12, 2020 at 4:15 pm, Britt Yazel  wrote:
> > Attached is an image of the compact mode + dark theme. Just for the
> > record.
>
> The thing is, it really comes down to personal preference. I suspect we
> have a lot of people who like web clients, and a lot of people who just
> don't. With open protocols like IRC, XMPP, or Matrix, where lots of
> client choice exists, you can use whatever you prefer. It's no problem
> if you don't like any particular client because you can just use a
> different one.
>
> Myself, I like to see GNOME clients: polari, dino, fractal, chatty.
> They look good next to our other apps, and vindicate the potential of
> our desktop platform. But if we're going to have a web client, at the
> very least do it using WebKitGTK, like Revolt does, to stick with GNOME
> technologies and avoid bundling Electron.
>
> I'll also suggest: whatever we use, it'd be nice to select something
> with the potential to become a widely-accepted standard, like IRC used
> to be. Chat has become a failed disaster area of fragmented walled
> gardens, and when we have a choice between an emerging standard and yet
> another silo, I think there's tremendous value in choosing the standard.
>
> Michael
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Windows runner for CI now generally available!

[Carlos Soriano via desktop-devel-list]

On Tue, 19 Nov 2019 at 10:48, Carlos Soriano  wrote:

> Hi everyone,
>
> Good news! Thanks to OpenAtMicrosoft and our staff we have set up a
> Windows runner for the GNOME/ group. Right now it's a single runner with
> the "windows" tag attached, feel free to use it as you see fit.
>
> *How to use it*
> Here's is an example on how to use a specific runner with a tag:
> https://gitlab.gnome.org/GNOME/gtk/blob/master/.gitlab-ci.yml#L43
>
> For the new Windows runner, the CI configuration would be something like:
> windows job:
>   stage:
> - build
>   tags:
> - windows
>
> More documentation about tags:
> https://docs.gitlab.com/ee/ci/yaml/README.html#tags
>
> *A report to Microsoft*
> Part of the the deal for getting the keys is that we will write a report
> to Microsoft. If you start using the runner regularly, could you write to
> me in an email a short summary about how are you using the Windows runner
> and how that benefits us and our users using Windows or Microsoft platforms?
>
> *+ other Microsoft product keys*
> Additional good news is that we also got some Microsoft product keys such
> as Visual Studio Ultimate, Office 365, Office Professional, Outlook, .Net,
> Windows 10, Visio Professional, Visual Basic, Exchange, etc. If you have a
> strong use case that would be of benefit for the GNOME project and
> community please reach out to me so we can discuss it.
>

FYI I didn't receive many requests about these, maybe we can lower the bar
and remove the "strong" from "strong use case" here :) Seriously, don't
hesitate to let me know if any of these would be of interest for you, we
can discuss whether that usage is appropriate or not.


>
> Lastly, let Bartłomiej, Andrea or me know if the runner is working well
> for you.
>
> Cheers,
> Carlos
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Windows runner for CI now generally available!

[Carlos Soriano via desktop-devel-list]

Hi everyone,

Good news! Thanks to OpenAtMicrosoft and our staff we have set up a Windows
runner for the GNOME/ group. Right now it's a single runner with the
"windows" tag attached, feel free to use it as you see fit.

*How to use it*
Here's is an example on how to use a specific runner with a tag:
https://gitlab.gnome.org/GNOME/gtk/blob/master/.gitlab-ci.yml#L43

For the new Windows runner, the CI configuration would be something like:
windows job:
  stage:
- build
  tags:
- windows

More documentation about tags:
https://docs.gitlab.com/ee/ci/yaml/README.html#tags

*A report to Microsoft*
Part of the the deal for getting the keys is that we will write a report to
Microsoft. If you start using the runner regularly, could you write to me
in an email a short summary about how are you using the Windows runner and
how that benefits us and our users using Windows or Microsoft platforms?

*+ other Microsoft product keys*
Additional good news is that we also got some Microsoft product keys such
as Visual Studio Ultimate, Office 365, Office Professional, Outlook, .Net,
Windows 10, Visio Professional, Visual Basic, Exchange, etc. If you have a
strong use case that would be of benefit for the GNOME project and
community please reach out to me so we can discuss it.

Lastly, let Bartłomiej, Andrea or me know if the runner is working well for
you.

Cheers,
Carlos
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

GitLab news & updates

[Carlos Soriano]

Hi everyone,

Just an FYI on latest GitLab news.

   - *Multiple Issue Boards*
   

   is now part of the community edition (despite the documentation saying
   otherwise). If you ever wanted to try a more Agil^W efficient way to handle
   project planning, now is a good moment to give a chance to the GitLab Issue
   Boards.
   - We got an *Azure license *from our colleagues at OpenAtMicrosoft! We
   will use it for our CI on Windows. If you are interested, reach me out at
   GUADEC and we can discuss its set up and usage. I'll send more information
   about how to use it once everything is ready.
   - *Multiple diff discussions*
   

is
   now possible for single lines of code.
   - *Merge requests for confidential issues
   
*
   are now possible. I know in the past we haven't been happy with how we can
   handle security issues, is there anything else remaining here? If so,
   please let me know off-list.
   - Take a look at the *upcoming CI/CD features*
   .
   There are a few things of great value for us, such as multi-project
   pipelines which will allow us to do things like Flatpak nightly builds from
   different projects or CI testing of full GNOME snapshots. Another
   interesting upcoming feature is hybrid directed acyclic graph
   (DAG) pipelines, which basically means CI stages can by bypassed and
   interconnected in more complex ways.
   - We can now pass *environment variables from upstream to downstream
   
*
CI
   pipeline, which are those activated by triggers. This will allow more
   complex cross-project CI builds that I believe some projects have been
   waiting for.
   - *Git object deduplication*
   

is
   now implemented as the first step towards fast forking
   , which is coming
   soon. Hopefully this will fix most of the pain when forking.

Also, Sri will have a talk at GUADEC about GitLab, don't hesitate to attend
to learn more about how GitLab's future could look like for us.

Have a good weekend, and for those attending GUADEC, see you soon.

Carlos
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Please run for the board!

[Carlos Soriano via desktop-devel-list]

And in case you missed it in planet.gnome.org, I made a write up on how the
board works nowadays, why you should and why you definitely can run for the
board, read it!
https://csoriano.pages.gitlab.gnome.org/csoriano-blog/post/2019-05-27-why-you-can-and-should-apply-for-the-board/

On Wed, 29 May 2019 at 11:13, Allan Day  wrote:

> Hi everyone,
>
> In case you didn't notice, we've had to extend the deadline for the GNOME
> Foundation Board of Directors elections, because not enough candidates put
> themselves forward.
>
> Please consider running in the elections. Being on the board is actually
> quite nice. It's also a great way to see the project from a high level, and
> to develop new skills and expertise.
>
> The revised deadline for candidates is 2nd June, and instructions on how
> to put yourself forward can be found here [1].
>
> Thanks,
>
> Allan
> --
> [1]
> https://mail.gnome.org/archives/foundation-announce/2019-April/msg2.html
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Please run for the board!

[Carlos Soriano]

And in case you missed it in planet.gnome.org, I made a write up on how the
board works nowadays, why you should and why you definitely can run for the
board, read it!
https://csoriano.pages.gitlab.gnome.org/csoriano-blog/post/2019-05-27-why-you-can-and-should-apply-for-the-board/

On Wed, 29 May 2019 at 11:13, Allan Day  wrote:

> Hi everyone,
>
> In case you didn't notice, we've had to extend the deadline for the GNOME
> Foundation Board of Directors elections, because not enough candidates put
> themselves forward.
>
> Please consider running in the elections. Being on the board is actually
> quite nice. It's also a great way to see the project from a high level, and
> to develop new skills and expertise.
>
> The revised deadline for candidates is 2nd June, and instructions on how
> to put yourself forward can be found here [1].
>
> Thanks,
>
> Allan
> --
> [1]
> https://mail.gnome.org/archives/foundation-announce/2019-April/msg2.html
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Hickups with GitLab during weekend

[Carlos Soriano]

Hi all,

Just a heads up that we had some upstream issue in GitLab
 that made all events
get stuck during the weekend.

We applied a workaround for it. This means that you will receive now events
that should have been processed on the weekend, and most probably some of
them will fail due to timeouts. Simply trigger them again.

Hope this doesn't affect you much!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GSoC] Time to choose students. Deadline next Tuesday.

[Carlos Soriano]

Hi mentors,

The admins has gone through all the proposals and assigned slots to them if
you marked the proposal with "I want to mentor". Please double check that
everything is in the right place for you and that you can see we assigned
an slot to the proposal. Otherwise contact any of us or send an email to
soc-adm...@gnome.org ASAP.

Cheers

On Thu, 25 Apr 2019 at 16:05, Carlos Soriano  wrote:

> A short follow up, regardless of the deadline do this ASAP.
>
> There are two reasons to do it even today if possible. One is that it's a
> first come first serve system for the majority of processes, and second,
> one day buffer for the admins is not a lot and it's reserved for
> exceptional cases. In the regular case this will be done with more than a
> few days time, even though we sent the email a bit late and that's why we
> extended our internal deadline a bit more.
>
> Thanks!
>
> On Thu, 25 Apr 2019 at 09:56, Carlos Soriano  wrote:
>
>> Hello all,
>>
>> GNOME has been accepted in GSoC one more year! \o/
>>
>> In order to get the students you want in the accepted slots, you need to
>> complete these steps before next *Tuesday 30th April *(with a day for us
>> as a buffer).
>>
>> Go to https://summerofcode.withgoogle.com/ and search for the proposals
>> you want to mentor. Then you need to do the following:
>> - Make sure you have marked all proposals you'd like to accept as "want
>> to mentor". If you have two proposals for the same project, you need to
>> decide which one to take.
>> - Include a score (explanation of score below*) and any comments about
>> your experience mentoring the applicant and how strongly you feel that they
>> should be accepted for the program. Do this in the comments section of the
>> proposal on the Google's website.
>> - In case you selected to mentor more than one student, send us an email
>> at soc-adm...@gnome.org confirming it. Please make sure you will have
>> enough time for two students. It's expected to spend around 10 hours per
>> week per student. Google started to strongly recommend to just accept a
>> single student per mentor, so we need to be careful when accepting these
>> exceptions.
>>
>> *Score scale, half point rankings (i.e. 4.5, 3.5) are ok:
>> 5 = amazing applicant, could become a module maintainer on completing the
>> program, made extensive contributions to GNOME of high quality
>> 4 = strong applicant, will certainly do a good job, made substantial
>> contributions to GNOME of high quality (> ~50 lines of code or equivalent)
>> 3 = good applicant, but is somewhat inexperienced
>> 2 = is unlikely to do a good job
>> 1 = not a good candidate
>>
>> Also remember that when mentoring in GSoC, we expect:
>> - Fill evaluations at least 3 days before the official Google deadline.
>> We need some time to tie up loose ends. Your student will fail and GNOME
>> will get penalized if the evaluation is not filled on time.
>> - Spend around 10h per week with the student; reviewing code, helping
>> him/her, chatting, etc.
>> - Weekly goals and review of the goals in weekly meetings.
>> - Review code submissions of the student thoroughly and in a timely
>> manner.
>> - Communicate regularly with the student.
>> - The student is on planet.gnome.org before the end of the community
>> bonding phase.
>>
>> If you have any questions, please don't hesitate to send us an email to
>> soc-adm...@gnome.org (preferred) or contact one of us on IRC.
>>
>> Have a nice day,
>> GNOME GSoC Admins
>>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GSoC] Time to choose students. Deadline next Tuesday.

[Carlos Soriano]

A short follow up, regardless of the deadline do this ASAP.

There are two reasons to do it even today if possible. One is that it's a
first come first serve system for the majority of processes, and second,
one day buffer for the admins is not a lot and it's reserved for
exceptional cases. In the regular case this will be done with more than a
few days time, even though we sent the email a bit late and that's why we
extended our internal deadline a bit more.

Thanks!

On Thu, 25 Apr 2019 at 09:56, Carlos Soriano  wrote:

> Hello all,
>
> GNOME has been accepted in GSoC one more year! \o/
>
> In order to get the students you want in the accepted slots, you need to
> complete these steps before next *Tuesday 30th April *(with a day for us
> as a buffer).
>
> Go to https://summerofcode.withgoogle.com/ and search for the proposals
> you want to mentor. Then you need to do the following:
> - Make sure you have marked all proposals you'd like to accept as "want to
> mentor". If you have two proposals for the same project, you need to decide
> which one to take.
> - Include a score (explanation of score below*) and any comments about
> your experience mentoring the applicant and how strongly you feel that they
> should be accepted for the program. Do this in the comments section of the
> proposal on the Google's website.
> - In case you selected to mentor more than one student, send us an email
> at soc-adm...@gnome.org confirming it. Please make sure you will have
> enough time for two students. It's expected to spend around 10 hours per
> week per student. Google started to strongly recommend to just accept a
> single student per mentor, so we need to be careful when accepting these
> exceptions.
>
> *Score scale, half point rankings (i.e. 4.5, 3.5) are ok:
> 5 = amazing applicant, could become a module maintainer on completing the
> program, made extensive contributions to GNOME of high quality
> 4 = strong applicant, will certainly do a good job, made substantial
> contributions to GNOME of high quality (> ~50 lines of code or equivalent)
> 3 = good applicant, but is somewhat inexperienced
> 2 = is unlikely to do a good job
> 1 = not a good candidate
>
> Also remember that when mentoring in GSoC, we expect:
> - Fill evaluations at least 3 days before the official Google deadline. We
> need some time to tie up loose ends. Your student will fail and GNOME will
> get penalized if the evaluation is not filled on time.
> - Spend around 10h per week with the student; reviewing code, helping
> him/her, chatting, etc.
> - Weekly goals and review of the goals in weekly meetings.
> - Review code submissions of the student thoroughly and in a timely manner.
> - Communicate regularly with the student.
> - The student is on planet.gnome.org before the end of the community
> bonding phase.
>
> If you have any questions, please don't hesitate to send us an email to
> soc-adm...@gnome.org (preferred) or contact one of us on IRC.
>
> Have a nice day,
> GNOME GSoC Admins
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal: Replace all references to master/slave in GNOME modules

[Carlos Soriano]

Hi,

IMHO an smart stance to take in this topic is to focus on the actual impact
in practice that this change has, and otherwise just do it if a reasonable
amount of people and outside projects think there is a valid reason to do
it - we don't need to understand if the reasons are fully valid or not,
because that's hard to evaluate.

In practical terms, as long as someone takes care of fixing the
technological part I don't see an issue, and I understand that you need to
have some project as a test, so as long as this keeps to Geary only it
seems ok to me.
In terms of getting used to it, it's a matter of remembering just one more
name.
For making this change properly, I have some questions:
- Is there a possibility to redirect master to any other name somehow?
- If Git upstream documentation is not updated, can we hold an organization
wide change until that happens?
- Is there a way to "push to the main branch" that doesn't involve a name
such as master or mainline?
- Is there some consensus on the word replacement apart of the links Daniel
provided? My feeling is that we should wait until there is a common
replacement among projects outside of GNOME.

Also, I think we should try to come with a name we are all comfortable and
use only that one. A discourse topic or a different mail thread just for
that would be helpful.

Cheers

On Thu, 25 Apr 2019 at 13:26, Florian Müllner  wrote:

> On Thu, Apr 25, 2019 at 1:04 PM Bastien Nocera  wrote:
> >
> > FWIW, "master copy" has quite a lot of synonyms that are used in other
> > languages and can be reused here, such as "copy zero", "original
> > (copy)", or in some uses "standard copy".
>
> "Branch zero" has a nice ring to it. (I think it's too cryptic to be
> actually used, but gosh does it sound cool!)
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GSoC] Time to choose students. Deadline next Tuesday.

[Carlos Soriano]

Hello all,

GNOME has been accepted in GSoC one more year! \o/

In order to get the students you want in the accepted slots, you need to
complete these steps before next *Tuesday 30th April *(with a day for us as
a buffer).

Go to https://summerofcode.withgoogle.com/ and search for the proposals you
want to mentor. Then you need to do the following:
- Make sure you have marked all proposals you'd like to accept as "want to
mentor". If you have two proposals for the same project, you need to decide
which one to take.
- Include a score (explanation of score below*) and any comments about your
experience mentoring the applicant and how strongly you feel that they
should be accepted for the program. Do this in the comments section of the
proposal on the Google's website.
- In case you selected to mentor more than one student, send us an email at
soc-adm...@gnome.org confirming it. Please make sure you will have enough
time for two students. It's expected to spend around 10 hours per week per
student. Google started to strongly recommend to just accept a single
student per mentor, so we need to be careful when accepting these
exceptions.

*Score scale, half point rankings (i.e. 4.5, 3.5) are ok:
5 = amazing applicant, could become a module maintainer on completing the
program, made extensive contributions to GNOME of high quality
4 = strong applicant, will certainly do a good job, made substantial
contributions to GNOME of high quality (> ~50 lines of code or equivalent)
3 = good applicant, but is somewhat inexperienced
2 = is unlikely to do a good job
1 = not a good candidate

Also remember that when mentoring in GSoC, we expect:
- Fill evaluations at least 3 days before the official Google deadline. We
need some time to tie up loose ends. Your student will fail and GNOME will
get penalized if the evaluation is not filled on time.
- Spend around 10h per week with the student; reviewing code, helping
him/her, chatting, etc.
- Weekly goals and review of the goals in weekly meetings.
- Review code submissions of the student thoroughly and in a timely manner.
- Communicate regularly with the student.
- The student is on planet.gnome.org before the end of the community
bonding phase.

If you have any questions, please don't hesitate to send us an email to
soc-adm...@gnome.org (preferred) or contact one of us on IRC.

Have a nice day,
GNOME GSoC Admins
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New Matrix IRC bridge server

[Carlos Soriano]

I didn't get a confirmation yet (but I did had an update recently from
Matthew). What you meant is probably that things recovered from the
security issue they had, but not that they have the new server for GNOME
set up yet.

On Mon, 22 Apr 2019 at 08:47, Alberto Fanjul Alonso 
wrote:

> It seems to be working right now!
>
> El vie., 5 abr. 2019 a las 10:11, Carlos Soriano ()
> escribió:
>
>> Hey, not yet, they need some more time.
>>
>> On Thu, 4 Apr 2019 at 15:30, Zeeshan Ali  wrote:
>>
>>> Hi Carlos,
>>>
>>> Is this sorted yet?
>>>
>>> On Tue, 19 Mar 2019, 17:28 Carlos Soriano,  wrote:
>>>
>>>> Whoops, seems this is still not fully set up, stand by for the
>>>> announcement :-)
>>>>
>>>> On Tue, 19 Mar 2019 at 16:02, Carlos Soriano 
>>>> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> As you might know we have IRC bridge for Matrix
>>>>> <https://matrix.org/blog/home/> that we use for newcomers
>>>>> <https://wiki.gnome.org/Newcomers/BeforeWeBegin> and other people of
>>>>> the community in an unofficial way. There has been quite a few complains
>>>>> about the performance of the IRC bridge and messages being dropped, so
>>>>> yesterday Matthew from Matrix kindly spin up a standalone server for our
>>>>> IRC bridge to ensure a better experience with the service.
>>>>>
>>>>> Feel free to send here your feedback about it here. I will send it
>>>>> back to Matthew or he will take a look here.
>>>>>
>>>>> Hope this works better for all of you!
>>>>>
>>>> ___
>>>> desktop-devel-list mailing list
>>>> desktop-devel-list@gnome.org
>>>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>>
>>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] 11.10 is here

[Carlos Soriano]

Hello all,

New version is on our instance, just a few highlights that might be
interesting for us.


   - Link
   

   - You can provide *multi-line suggestions in MRs* now. That is, you can
   propose a suggestion in an MR and click "apply" will create a commit with
   the change.
   - Link
   

   - *Create MR + merge directly from git* when CI passes. For those that
   tend to simply push to master, try out this one, so no more overhead for
   you and still keeping CI on master always green.
   - Link
   

- *Developers can now create projects in groups*. This is disabled for
   the GNOME group as it was the case before. It's however, something we can
   discuss more for other groups, and it also opens the possibility to create
   a different structure.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GSoC] Mentors registration

[Carlos Soriano]

A small correction, the mentor's mailing list changed this year to
https://mail.gnome.org/mailman/listinfo/mentors-list, thanks Alberto Fanjul
for the heads up!

On Tue, 2 Apr 2019 at 08:46, Carlos Soriano  wrote:

> Hello everyone,
>
> It's time for mentors to register for GSoC!
>
> Please fill this form <https://forms.gle/UA5CPqAroRqbS1gW7> and we will
> invite you to the GSoC program in Google's website. It's a Google Form, if
> you want to provide the information in some other way let us know and we
> will figure something out with you.
>
> Also, please subscribe to the mentors mailing list
> <https://mail.gnome.org/mailman/listinfo/soc-mentors-list> if you haven't
> done so yet. We will send required information for mentors in that list.
>
> If you have any question, don't hesitate to contact us at
> soc-adm...@gnome.org or any of us
> <https://wiki.gnome.org/Outreach/SummerOfCode/admins> on IRC.
>
> Have a nice day,
> GSOC admins
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GSoC] Mentors registration

[Carlos Soriano]

Hello all,

This should be done maximum this week so you can take a look at the
students proposals, they are already there.

Potential mentors missing from the form that have accepted ideas are:
- Jens Georg
- Daniel Garcia
- Julian Sparber
- Felipe Borges
- Andrea Veri
- Emmanuele Bassi
- Carlos Garnacho
- Federico Mena Quintero
- Buildstream maintainers?

On Fri, 5 Apr 2019 at 10:14, Carlos Soriano  wrote:

> I worded it wrong, fixed it now. It should be the titles of the ideas,
> feel free to update it :-)
>
> On Thu, 4 Apr 2019 at 15:29, Zeeshan Ali  wrote:
>
>> Hi Carlos,
>>
>> Thanks for letting us know. I wrote "GNOME" under "Project". I hope
>> that's the right string to use.
>>
>> On Tue, 2 Apr 2019, 08:47 Carlos Soriano,  wrote:
>>
>>> Hello everyone,
>>>
>>> It's time for mentors to register for GSoC!
>>>
>>> Please fill this form <https://forms.gle/UA5CPqAroRqbS1gW7> and we will
>>> invite you to the GSoC program in Google's website. It's a Google Form, if
>>> you want to provide the information in some other way let us know and we
>>> will figure something out with you.
>>>
>>> Also, please subscribe to the mentors mailing list
>>> <https://mail.gnome.org/mailman/listinfo/soc-mentors-list> if you
>>> haven't done so yet. We will send required information for mentors in that
>>> list.
>>>
>>> If you have any question, don't hesitate to contact us at
>>> soc-adm...@gnome.org or any of us
>>> <https://wiki.gnome.org/Outreach/SummerOfCode/admins> on IRC.
>>>
>>> Have a nice day,
>>> GSOC admins
>>>
>>> ___
>>> desktop-devel-list mailing list
>>> desktop-devel-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GSoC] Mentors registration

[Carlos Soriano]

I worded it wrong, fixed it now. It should be the titles of the ideas, feel
free to update it :-)

On Thu, 4 Apr 2019 at 15:29, Zeeshan Ali  wrote:

> Hi Carlos,
>
> Thanks for letting us know. I wrote "GNOME" under "Project". I hope that's
> the right string to use.
>
> On Tue, 2 Apr 2019, 08:47 Carlos Soriano,  wrote:
>
>> Hello everyone,
>>
>> It's time for mentors to register for GSoC!
>>
>> Please fill this form <https://forms.gle/UA5CPqAroRqbS1gW7> and we will
>> invite you to the GSoC program in Google's website. It's a Google Form, if
>> you want to provide the information in some other way let us know and we
>> will figure something out with you.
>>
>> Also, please subscribe to the mentors mailing list
>> <https://mail.gnome.org/mailman/listinfo/soc-mentors-list> if you
>> haven't done so yet. We will send required information for mentors in that
>> list.
>>
>> If you have any question, don't hesitate to contact us at
>> soc-adm...@gnome.org or any of us
>> <https://wiki.gnome.org/Outreach/SummerOfCode/admins> on IRC.
>>
>> Have a nice day,
>> GSOC admins
>>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New Matrix IRC bridge server

[Carlos Soriano]

Hey, not yet, they need some more time.

On Thu, 4 Apr 2019 at 15:30, Zeeshan Ali  wrote:

> Hi Carlos,
>
> Is this sorted yet?
>
> On Tue, 19 Mar 2019, 17:28 Carlos Soriano,  wrote:
>
>> Whoops, seems this is still not fully set up, stand by for the
>> announcement :-)
>>
>> On Tue, 19 Mar 2019 at 16:02, Carlos Soriano  wrote:
>>
>>> Hello all,
>>>
>>> As you might know we have IRC bridge for Matrix
>>> <https://matrix.org/blog/home/> that we use for newcomers
>>> <https://wiki.gnome.org/Newcomers/BeforeWeBegin> and other people of
>>> the community in an unofficial way. There has been quite a few complains
>>> about the performance of the IRC bridge and messages being dropped, so
>>> yesterday Matthew from Matrix kindly spin up a standalone server for our
>>> IRC bridge to ensure a better experience with the service.
>>>
>>> Feel free to send here your feedback about it here. I will send it back
>>> to Matthew or he will take a look here.
>>>
>>> Hope this works better for all of you!
>>>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GSoC] Mentors registration

[Carlos Soriano]

Hello everyone,

It's time for mentors to register for GSoC!

Please fill this form  and we will
invite you to the GSoC program in Google's website. It's a Google Form, if
you want to provide the information in some other way let us know and we
will figure something out with you.

Also, please subscribe to the mentors mailing list
 if you haven't
done so yet. We will send required information for mentors in that list.

If you have any question, don't hesitate to contact us at
soc-adm...@gnome.org or any of us
 on IRC.

Have a nice day,
GSOC admins
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] Enabled issue/MR reply and issue/MR creation by email

[Carlos Soriano]

Hello all,

We have just set up (thanks to the foundation staff, Bartolomej and Andrea)
a feature of GitLab that allows to comment on issues/MR by simply replying
to the notification email. It also allows issue and MR creation by sending
an email to a specific address.

Please *read the documentation first, it has some security considerations*:
If the email used by you gets shared publicly anyone could create issues on
your behalf:

   - Documentation to reply by email
   .
   - Documentation to create an issue by email
   

   .
   - Documentation to create a merge request by email
   

   .

Hope it's useful for you all, give us feedback whether this is useful for
you or not or if it doesn't work as expected.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Akismet enabled, report if you get constant ReCaptchas

[Carlos Soriano]

Hey Michael,

Bu... seems Akismet false positives are still there.

Seems pretty stupid/weird to only show recaptcha when editing the first
> comment?


The reason of that it's because spam bots put comments that look valid and
then later on they edit them, so admins or other developers don't catch
them immediately. They are pretty "smart"...

Keep us updated on the regularity you get these recaptchas and if they
become too invasive.

On Sat, 30 Mar 2019 at 19:17, Michael Catanzaro 
wrote:

>
>
> On 03/28/2019 05:45 AM, Carlos Soriano wrote:
> > Hi all,
> >
> > Just a quick heads up, spam bots have started to put comments in
> > issues, so we are trying to enable again a quite strong spam
> > protection called Akismet.
> >
> > In the past we disabled it because false positives fire a ReCaptcha,
> > and for some people those were happening constantly. So now that we
> > have reenabled Akismet, let Andrea Veri or me know if ReCaptchas are
> > being fired for you repetitively.
> >
> > Have a good day!
>
> I'm getting recaptchas whenever I edit the first comment in an issue
> report. That's annoying.
>
> I can edit other comments and can post issues and comments with no
> recaptcha. That's good.
>
> Seems pretty stupid/weird to only show recaptcha when editing the first
> comment?
>
> Michael
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] Akismet enabled, report if you get constant ReCaptchas

[Carlos Soriano]

Hi all,

Just a quick heads up, spam bots have started to put comments in issues, so
we are trying to enable again a quite strong spam protection called Akismet.

In the past we disabled it because false positives fire a ReCaptcha, and
for some people those were happening constantly. So now that we have
reenabled Akismet, let Andrea Veri or me know if ReCaptchas are being fired
for you repetitively.

Have a good day!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] Some changes and updates

[Carlos Soriano]

Hi all,

We have made a few changes recently that might be of interest:

* All GNOME developers (gnomecvs LDAP group) have now reporter access to
Teams/Translation, so you are free to move issues between GNOME/ and
Translation/.

* Abuse reports now go to a shared private mailing list where me and the
CoC committee are part of. Previously they were directed only to me. Note
that this list is only for GitLab abuse reports, and as before I have no
access to anything else from the CoC committee.

* We have cleaned up inactive accounts that never had any activity. From 15
000 users we have reduced to 1, most of the removed accounts were fake,
others unused. This will help us have a smoother tooling in various
automations. If you find something wrong in this clean up contact Andrea
Veri or me, there are back ups ready.

Since Andrea is right now hands on GitLab stuff it's a good time to discuss
any policy change or automation you have in mind, simply let us know about
those and we can discuss them.

Also, later today GitLab 11.9 will be officially announced, so feel free to
keep an eye on https://about.gitlab.com/blog/categories/releases/ to see
the new nice features & fixes coming.

Have a good weekend everyone!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Another batch migration coming this week

[Carlos Soriano]

All done, feel free to reenable your notifications

On Tue, 19 Mar 2019 at 17:20, Carlos Soriano  wrote:

> I forgot an important one, i18n (cced now) and all their products will
> also be migrated.
>
> On Tue, 19 Mar 2019 at 11:17, Carlos Soriano  wrote:
>
>> Hey all,
>>
>> As the subject says, whenever I manage to make the tool work I will do
>> another batch migration. If you want to avoid the mass mailing, feel free
>> to turn off Bugzilla notifications.
>>
>> The projects on the batch are these
>> <https://gitlab.gnome.org/Infrastructure/GitLab/issues?label_name%5B%5D=Migration+request>,
>> except those that have the "need evaluation" label.
>>
>> Cheers
>>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New Matrix IRC bridge server

[Carlos Soriano]

Whoops, seems this is still not fully set up, stand by for the announcement
:-)

On Tue, 19 Mar 2019 at 16:02, Carlos Soriano  wrote:

> Hello all,
>
> As you might know we have IRC bridge for Matrix
> <https://matrix.org/blog/home/> that we use for newcomers
> <https://wiki.gnome.org/Newcomers/BeforeWeBegin> and other people of the
> community in an unofficial way. There has been quite a few complains about
> the performance of the IRC bridge and messages being dropped, so yesterday
> Matthew from Matrix kindly spin up a standalone server for our IRC bridge
> to ensure a better experience with the service.
>
> Feel free to send here your feedback about it here. I will send it back to
> Matthew or he will take a look here.
>
> Hope this works better for all of you!
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Another batch migration coming this week

[Carlos Soriano]

I forgot an important one, i18n (cced now) and all their products will also
be migrated.

On Tue, 19 Mar 2019 at 11:17, Carlos Soriano  wrote:

> Hey all,
>
> As the subject says, whenever I manage to make the tool work I will do
> another batch migration. If you want to avoid the mass mailing, feel free
> to turn off Bugzilla notifications.
>
> The projects on the batch are these
> <https://gitlab.gnome.org/Infrastructure/GitLab/issues?label_name%5B%5D=Migration+request>,
> except those that have the "need evaluation" label.
>
> Cheers
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

New Matrix IRC bridge server

[Carlos Soriano]

Hello all,

As you might know we have IRC bridge for Matrix
 that we use for newcomers
 and other people of the
community in an unofficial way. There has been quite a few complains about
the performance of the IRC bridge and messages being dropped, so yesterday
Matthew from Matrix kindly spin up a standalone server for our IRC bridge
to ensure a better experience with the service.

Feel free to send here your feedback about it here. I will send it back to
Matthew or he will take a look here.

Hope this works better for all of you!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] Another batch migration coming this week

[Carlos Soriano]

Hey all,

As the subject says, whenever I manage to make the tool work I will do
another batch migration. If you want to avoid the mass mailing, feel free
to turn off Bugzilla notifications.

The projects on the batch are these
,
except those that have the "need evaluation" label.

Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Deprecating nautilus-sendto

[Carlos Soriano]

Created also
https://gitlab.gnome.org/GNOME/gnome-build-meta/merge_requests/246

On Wed, 27 Feb 2019 at 13:56, Bastien Nocera  wrote:

> Hey,
>
> 15 years ago, in another age, nautilus-sendto was created so that one
> could easily send files from nautilus via email. Then via email and
> Gaim. Via email, Gaim and Bluetooth. And Gajim. And now Pidgin not
> Gaim. And then Empathy and UPnP servers. And then just email again,
> because the UI was quite frankly absolutely awful.
>
> But nautilus-sendto doesn't work in a sandbox. And there's pretty
> similar but more capable code that can be run in xdg-desktop-portal-
> gtk, the gnome-ish Flatpak/Snap portal.
>
> So I would recommend that applications that use nautilus-sendto right
> now, start using the portal D-Bus API directly instead:
>
> https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.impl.portal.Email.xml
>
> This is an example of using said API:
> https://github.com/flatpak/flatpak-xdg-utils/blob/master/src/xdg-email.c
>
> You could but I would not recommend using xdg-email if your application
> will be used outside of a Flatpak because it will end up running this
> code:
>
> https://gitlab.freedesktop.org/xdg/xdg-utils/blob/master/scripts/xdg-email.in
> which might, or might not work. It's brittle and ugly.
>
> Note the regressions though:
> - Some email clients are not as well supported in xdg-desktop-portal-gtk:
>   https://github.com/flatpak/xdg-desktop-portal-gtk/issues/187
>   https://github.com/flatpak/xdg-desktop-portal-gtk/issues/188
>   https://github.com/flatpak/xdg-desktop-portal-gtk/issues/189
> - There is no support for zipping files up before sending them. This
> was only used by nautilus, and nautilus can replace/enhance this by
> using its native archive support.
>
> Here are a number of issues I filed against applications that use
> nautilus-sendto:
>   https://gitlab.gnome.org/GNOME/shotwell/issues/111
>   https://gitlab.gnome.org/GNOME/evince/issues/1091
>   https://gitlab.gnome.org/GNOME/rhythmbox/issues/1695
>   https://gitlab.gnome.org/GNOME/nautilus/issues/928
>   https://gitlab.gnome.org/GNOME/yelp/issues/141
>   https://gitlab.gnome.org/GNOME/gnome-commander/issues/83
>
> I'll have the code moved to the archives after the 3.32 release, at the
> start of the new development cycle:
> https://gitlab.gnome.org/Infrastructure/GitLab/issues/380
>
> Cheers
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GSoC] Call for ideas

[Carlos Soriano]

Hello all,

Big thanks to all of you for coming with so many ideas in two days, we have
a decent list now so we should be good. Ideas in the wiki can be modified,
so don't hesitate to keep polishing them.

Also, it is encouraged to add more ideas and mentors to the wiki. Feel free
to ask the soc admins at soc-adm...@gnome.org or any of us on irc if you
are unsure about them.

Thanks!

On Tue, 12 Feb 2019 at 12:55, Carlos Soriano  wrote:

> I just realized my second email mentioning the date didn't went through...
>
> So just a heads up, we will need as many ideas as we can by today 15:00
> UTC. So please add them ASAP.
>
> Thanks!
>
> On Sun, 10 Feb 2019 at 09:29, Carlos Soriano  wrote:
>
>> Dear GNOME hackers,
>>
>> It's this time of the year again, GSoC is here!
>>
>> It's time for potential mentors to add their project ideas to the wiki
>> <https://wiki.gnome.org/Outreach/SummerOfCode/2019/Ideas>. Ideally we
>> would have a sensible list of ideas during next week, so Google accept us
>> as an organization for GSoC.
>>
>> The ideas can be drafts, the most important part is the intention on
>> mentorship and number of students you would like to mentor.
>>
>> If you have any questions, please don't hesitate to send us an email to
>> soc-adm...@gnome.org or contact one of us on IRC.
>>
>> Best,
>> GNOME GSoC Admins
>>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GSoC] Call for ideas

[Carlos Soriano]

I just realized my second email mentioning the date didn't went through...

So just a heads up, we will need as many ideas as we can by today 15:00
UTC. So please add them ASAP.

Thanks!

On Sun, 10 Feb 2019 at 09:29, Carlos Soriano  wrote:

> Dear GNOME hackers,
>
> It's this time of the year again, GSoC is here!
>
> It's time for potential mentors to add their project ideas to the wiki
> <https://wiki.gnome.org/Outreach/SummerOfCode/2019/Ideas>. Ideally we
> would have a sensible list of ideas during next week, so Google accept us
> as an organization for GSoC.
>
> The ideas can be drafts, the most important part is the intention on
> mentorship and number of students you would like to mentor.
>
> If you have any questions, please don't hesitate to send us an email to
> soc-adm...@gnome.org or contact one of us on IRC.
>
> Best,
> GNOME GSoC Admins
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GSoC] Call for ideas

[Carlos Soriano]

Dear GNOME hackers,

It's this time of the year again, GSoC is here!

It's time for potential mentors to add their project ideas to the wiki
. Ideally we would
have a sensible list of ideas during next week, so Google accept us as an
organization for GSoC.

The ideas can be drafts, the most important part is the intention on
mentorship and number of students you would like to mentor.

If you have any questions, please don't hesitate to send us an email to
soc-adm...@gnome.org or contact one of us on IRC.

Best,
GNOME GSoC Admins
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.32 milestone review

[Carlos Soriano]

On Wed, 30 Jan 2019 at 10:20, Allan Day  wrote:

> Great initiative, Carlos!
>

Thanks Allan for the answer!


> Carlos Soriano  wrote:
> ...
> > gnome-screenshot, retire app menu - Part of the GNOME initiative to
> remove app menus. There is a MR, needs some review. Deadline 4th February,
> UI freeze.
>
> The thing we're missing here is participation from a maintainer. Is
> gnome-screenshot actually maintained nowadays? If not, can assign a
> new maintainer?
>

Indeed, I think with someone experienced giving some review to the MR would
help moving it forward. If in practice there is no maintainer, maybe it's
okay to merge this one since it goes with a broader plan. What do you think?


>
> Regarding the app menu retirement initiative, the lack of progress on
> Totem [1] is also a concern.
>

Yeah, that's a good one. I chatted with Bastien and he was on top of it, so
I didn't include it.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.32 milestone review

[Carlos Soriano]

Nice, thanks Iñigo!

On Wed, 30 Jan 2019 at 09:40, Iñigo Martínez via desktop-devel-list <
desktop-devel-list@gnome.org> wrote:

> Hi,
>
> Regarding evince's app icon update, the branch in its MR was updated
> yesterday including the missing meson support[0], so it just needs to be
> reviewed and if everything is right merge it. :)
>
> Best regards,
>
> [0] https://gitlab.gnome.org/GNOME/evince/merge_requests/119#note_422389
>
>
> El mié., 30 ene. 2019 a las 9:23, Carlos Soriano ()
> escribió:
>
>> Hi all,
>>
>> We are quite close to 3.32 freezes! I thought it would be helpful for
>> some maintainers and projects to summarize their 3.32 pressing issues that
>> they could do with some help and see if someone in ddl would like to give a
>> hand.
>>
>> I basically went through the 3.32 milestone at GitLab, chatted with their
>> maintainers and ordered these issues from top to bottom based on importance
>> (loosely defined :-)).
>>
>> Evince new icon and Meson
>> <https://gitlab.gnome.org/GNOME/evince/merge_requests/119> - Part of the
>> GNOME initiative for new icons. It's the last core app missing it. The
>> maintainer would appreciate help figuring out how to include the svg icon
>> with Meson. *Deadline 4th February*, UI freeze.
>> gnome-screenshot, retire app menu
>> <https://gitlab.gnome.org/GNOME/gnome-screenshot/issues/15> - Part of
>> the GNOME initiative to remove app menus. There is a MR, needs some review. 
>> *Deadline
>> 4th February*, UI freeze.
>> gjs, common crash on applications
>> <https://gitlab.gnome.org/GNOME/gjs/issues/223> - A regression from
>> previous version, seems to have a wide impact. The maintainer would
>> appreciate help fixing it. Deadline 11th March, code freeze.
>> gnome-build-meta, get rid of python2
>> <https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/103> - Python2
>> support ends soon, this issue should be quite easy to do, it just requires
>> some manpower. Deadline 11th March, code freeze.
>> gnome-calculator, don't connect to internet on startup
>> <https://gitlab.gnome.org/GNOME/gnome-calculator/issues/58> - Calculator
>> connects to internet on startup, which is not welcome by privacy-aware
>> users. The maintainer would appreciate some help working on a solution.
>> Deadline 11th March, code freeze.
>>
>> Any help is appreciated on those issues! Let the maintainer or me know if
>> you have any questions.
>>
>> Cheers
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

GNOME 3.32 milestone review

[Carlos Soriano]

Hi all,

We are quite close to 3.32 freezes! I thought it would be helpful for some
maintainers and projects to summarize their 3.32 pressing issues that they
could do with some help and see if someone in ddl would like to give a hand.

I basically went through the 3.32 milestone at GitLab, chatted with their
maintainers and ordered these issues from top to bottom based on importance
(loosely defined :-)).

Evince new icon and Meson
 - Part of the
GNOME initiative for new icons. It's the last core app missing it. The
maintainer would appreciate help figuring out how to include the svg icon
with Meson. *Deadline 4th February*, UI freeze.
gnome-screenshot, retire app menu
 - Part of the
GNOME initiative to remove app menus. There is a MR, needs some
review. *Deadline
4th February*, UI freeze.
gjs, common crash on applications
 - A regression from
previous version, seems to have a wide impact. The maintainer would
appreciate help fixing it. Deadline 11th March, code freeze.
gnome-build-meta, get rid of python2
 - Python2
support ends soon, this issue should be quite easy to do, it just requires
some manpower. Deadline 11th March, code freeze.
gnome-calculator, don't connect to internet on startup
 - Calculator
connects to internet on startup, which is not welcome by privacy-aware
users. The maintainer would appreciate some help working on a solution.
Deadline 11th March, code freeze.

Any help is appreciated on those issues! Let the maintainer or me know if
you have any questions.

Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab postmortem

[Carlos Soriano]

Now that it has settled down, thanks all for the feedback! It's really
useful for me (and I believe for everyone else) to have a general feeling
and what things are in common as biggest struggles and positives.

Cheers

On Wed, 2 Jan 2019 at 16:22, Germán Poo-Caamaño  wrote:

> On Wed, 2019-01-02 at 15:15 +0100, Milan Crha via desktop-devel-list
> wrote:
> > On Wed, 2018-12-19 at 14:37 +, Philip Withnall wrote:
> > > 3. I’d like to see continued movement towards disallowing direct
> > > pushes to git, and requiring all commits to go through MRs (and
> > > CI).
> >
> >   Hi,
> > I hope this won't go through without a good research and reasoning.
> >
> > Any such requirement would be kind of showstopper for me personally.
> > It would be just double work for me when coding (issue is not merge
> > request), causing awful commit history, resulting in unbelievably
> > harder effort required to produce NEWS file content (yes, I do use
> > commit messages to fill the NEWS files in a semi-automated way saving
> > my time, which I can spend on more productive things). To name a few
> > major obstacles at least.
>
> The history would be the same if you set up the Merge Request for your
> project as "Fast-forward merge".
>
>
>"No merge commits are created and all merges are fast-forwarded,
>which means that merging is only allowed if the branch could be
>fast-forwarded.
>When fast-forward merge is not possible, the user is given the
>option to rebase."
>
> I do also generate the NEWS file from the git history, and it is not
> any different after having that change (which I did as soon as it was
> possible to do).
>
> FWIW, I do both, direct commit and MR. The former for quick commits,
> and the latter if someone can jump in to review them.
>
>
> > I also cannot imagine any such thing enabled for 'work-in-progress'
> > branches. That would be awful for any porting/cleanup/larger efforts.
>
> Try to not break master, and merge once the CI passes. That is the
> point.
>
> I have seen one corner case, which required to update the CI first.
> Also, you can let the CI fail without blocking the MR (exceptionally or
> when it is a secondary issue)
>
> --
> Germán Poo-Caamaño
> http://calcifer.org/
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] What 11.6 brings to us

[Carlos Soriano]

It's all enabled now \m/

Please provide feedback about the duplicate issues feature either to me or
upstream.

On Wed, 2 Jan 2019 at 21:49, Carlos Soriano  wrote:

>
> On Thu, 27 Dec 2018 at 10:04, Abderrahim Kitouni 
> wrote:
>
>> Hi,
>>
>> Le dim. 23 déc. 2018 à 13:36, Carlos Soriano  a
>> écrit :
>> >
>> > 11.6 is here, there are a few nice things for us.
>> >
>> > Run CI/CD for merge requests
>> > CI are not only for branches, but also for MR. Variables, etc. can be
>> put to adjust the CI to do X or Y things on MR or regular branches. This
>> will be very handy if we need to go back to only do fast CI for the GNOME
>> group.
>>
>> Just wanted to point out this wouldn't help much for the "fast CI only
>> for the GNOME group" scenario. The CI for merge requests still runs in
>> the forked projects.
>> See
>> https://docs.gitlab.com/ee/ci/merge_request_pipelines/index.html#important-notes-about-merge-requests-from-forked-projects
>
>
> Ah right, thanks for pointing that out.
>
>
>>
>>
>> > Suggested Changes in MRs
>> > Provide suggested changes in MRs and apply them at merge. This was
>> raised in the postmortem email by a few people, so try it out and let me
>> know how it works for you. AFAIK the implementation is similar to the one
>> in GitHub.
>>
>> It seems this feature isn't enabled for our instance. The
>> documentation says that it "can be enabled for self-hosted GitLab
>> instances using the diff_suggestions feature flag. It will be enabled
>> by default for self-hosted instances in GitLab 11.7."
>>
>
> Right, I sent an email to Andrea, whenever he's available we can enable
> it.
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: EU security bug bounty, anyone has more info or contact?

[Carlos Soriano]

Thanks for the pointer! Will contact her then.

Cheers

On Thu, 3 Jan 2019 at 10:21, Luca Cavalli  wrote:

> Hi Carlos,
>
> you can try to contact Julia Reda, @Senficon on Twitter.
>
> Cheers,
>
> Luca
>
> Il giorno mer 2 gen 2019, 21:46 Carlos Soriano  ha
> scritto:
>
>> Hello all,
>>
>> I just read this post
>> <https://juliareda.eu/2018/12/eu-fossa-bug-bounties/#bugbounty>, seems
>> the EU is putting money on some FOSS software for improving security and
>> finding vulnerabilities through bounties. I was wondering if glib,
>> gnome-keyring, etc. could fall in this programme. Anyone has more info
>> about this or has some connection with someone involved?
>>
>> So far I found the main FOSSA website
>> <https://joinup.ec.europa.eu/collection/eu-fossa-2/about> and some
>> (already finished) process
>> <https://joinup.ec.europa.eu/collection/eu-fossa/implementation> where
>> the chose the projects they will invest on.
>>
>> Cheers
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] What 11.6 brings to us

[Carlos Soriano]

On Thu, 27 Dec 2018 at 10:04, Abderrahim Kitouni  wrote:

> Hi,
>
> Le dim. 23 déc. 2018 à 13:36, Carlos Soriano  a écrit
> :
> >
> > 11.6 is here, there are a few nice things for us.
> >
> > Run CI/CD for merge requests
> > CI are not only for branches, but also for MR. Variables, etc. can be
> put to adjust the CI to do X or Y things on MR or regular branches. This
> will be very handy if we need to go back to only do fast CI for the GNOME
> group.
>
> Just wanted to point out this wouldn't help much for the "fast CI only
> for the GNOME group" scenario. The CI for merge requests still runs in
> the forked projects.
> See
> https://docs.gitlab.com/ee/ci/merge_request_pipelines/index.html#important-notes-about-merge-requests-from-forked-projects


Ah right, thanks for pointing that out.


>
>
> > Suggested Changes in MRs
> > Provide suggested changes in MRs and apply them at merge. This was
> raised in the postmortem email by a few people, so try it out and let me
> know how it works for you. AFAIK the implementation is similar to the one
> in GitHub.
>
> It seems this feature isn't enabled for our instance. The
> documentation says that it "can be enabled for self-hosted GitLab
> instances using the diff_suggestions feature flag. It will be enabled
> by default for self-hosted instances in GitLab 11.7."
>

Right, I sent an email to Andrea, whenever he's available we can enable it.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

EU security bug bounty, anyone has more info or contact?

[Carlos Soriano]

Hello all,

I just read this post
, seems the
EU is putting money on some FOSS software for improving security and
finding vulnerabilities through bounties. I was wondering if glib,
gnome-keyring, etc. could fall in this programme. Anyone has more info
about this or has some connection with someone involved?

So far I found the main FOSSA website
 and some (already
finished) process
 where the
chose the projects they will invest on.

Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] What 11.6 brings to us

[Carlos Soriano]

11.6 is here, there are a few nice things for us.

*Run CI/CD for merge requests
*
CI are not only for branches, but also for MR. Variables, etc. can be put
to adjust the CI to do X or Y things on MR or regular branches. This will
be very handy if we need to go back to only do fast CI for the GNOME group.

*Suggested Changes in MRs
*
Provide suggested changes in MRs and apply them at merge. This was raised
in the postmortem email by a few people, so try it out and let me know how
it works for you. AFAIK the implementation is similar to the one in GitHub.

*Similar issues suggestions when filing a new issue
*
Duplicate issues handling was one of the top priorities for us, so GitLab
has requested our feedback for this new feature. So please try it out and
let me/them know how does it work for you.

Cheers!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: This Week in GNOME

[Carlos Soriano]

>
> Is there a way we (developers) could mark issues/MR to be picked up in
> the weekly report?


FWIW I created "9. Engagement Material" label back then for this use. I
think a good idea would be for us to use a label and his scripts to query
that.

On Thu, 13 Dec 2018 at 13:27, Felipe Borges  wrote:

> Is there a way we (developers) could mark issues/MR to be picked up in
> the weekly report?
> On Thu, Dec 13, 2018 at 12:06 AM Niels De Graef via desktop-devel-list
>  wrote:
> >
> > This looks good already, kind of reminds me KDE's 'This week in
> > Usability & Productivity', so good job! :-)
> >
> > One remark I have is that it might be interesting to see if a
> > maintainer (or heavily involved developer) of a project can give a
> > one-liner (or 2 liner) what the listed MRs are about. I'm afraid that
> > otherwise some MRs with very technical titles will get discarded by
> > the audience, while some MRs with a sensationalist or overexaggerating
> > title  will lead to e.g. false expectations.
> >
> > Cheers,
> > nielsdg
> > On Wed, Dec 12, 2018 at 11:56 PM Sriram Ramkrishna 
> wrote:
> > >
> > > We have a volunteer who is willing to do GNOME summaries every week.
> > > Here is what this week looks like.  I'm looking for some feedback
> > > before we start using our social media outlets to start publishing it.
> > >
> > > https://bloerg.net/2018/12/07/gnome-weekly.html
> > >
> > > Please let me know your feedback.
> > >
> > > Cheers,
> > > sri
> > >
> > > ___
> > > desktop-devel-list mailing list
> > > desktop-devel-list@gnome.org
> > > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

GitLab postmortem

[Carlos Soriano]

Hey,

It has been a few months since we moved to GitLab. Apart of spurious
issues, specific annoyances and frustrations, seems it has been generally
good. I would like to gather some general feeling about it. Things that
really made a constant impact to you and your work, both bad or good. Feel
free to provide feedback about the transition or the administration of
GitLab instance too. Free form.

Please keep the mail chain one way from you towards the world, so we don't
get trapped on specifics, we can address stuff raised here individually out
of list. Personally, I'll ping you on IRC or so if I can do something to
help.

Of course, feel free to msg me directly on IRC/email too.

Thanks all!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: getting commit rights for / maintaining Dia ?

[Carlos Soriano]

FWIW the process will eventually be
https://wiki.gnome.org/AccountsTeam/NewAccounts.

On Thu, 6 Dec 2018 at 10:15, Tomas Pospisek  wrote:

> Am 04.12.18 um 22:53 schrieb mcatanz...@gnome.org:
> > You should have gotten an email about this from Zander. He will help
> > manage this!
> Cool, I'll get in touch with Zander.
>
> Thanks for the pointer Michael and everybody for your support :-)!
> *t
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Fast CI is now available for all projects under gitlab.gnome.org

[Carlos Soriano]

We still have other donations that are very useful to us, as we really
shouldn't rely on a single or only a few sources. So still, many thanks to
GitLab Inc, AWS, Canonical, and the individual contributors with the
Windows and MacOSX machines giving it for free as shared runners.

On Fri, 16 Nov 2018 at 13:24, Carlos Soriano  wrote:

> So that's it, we got fast CI for all projects now, including GNOME/ World/
> and all forks.
>
> This is thanks to donations from Packet.net and Oregon State University
> Open Source Lab. We will check if they want some PR and do so soon. We will
> also update https://wiki.gnome.org/GitLab/CI with the info soon.
>
> Thanks to Rob, Javier and Andrea for the ideas and set up!
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] Fast CI is now available for all projects under gitlab.gnome.org

[Carlos Soriano]

So that's it, we got fast CI for all projects now, including GNOME/ World/
and all forks.

This is thanks to donations from Packet.net and Oregon State University
Open Source Lab. We will check if they want some PR and do so soon. We will
also update https://wiki.gnome.org/GitLab/CI with the info soon.

Thanks to Rob, Javier and Andrea for the ideas and set up!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab minor-reorganization to Community group

[Carlos Soriano]

Yes, Translation are discussing it over now. Not sure what the Foundation
group was about, but for the board we are fine with just a project. Board
will continue as a project, it's what works for us.

On Mon, 24 Sep 2018 at 18:29, Britt Yazel  wrote:

> Carlos,
>
> Excellent! Thank you so much. Under teams the proposal had a few more
> teams listed such as "board" and others. Those have to go through you if
> they want to be added to the "teams" group yes? I don't have anything to do
> with those groups, so I'll let them sort it out, I just want to know for
> clarification
>
> On Mon, Sep 24, 2018 at 9:21 AM Carlos Soriano  wrote:
>
>> This is done now, please check everything is alright.
>>
>> Left to be done:
>> - The translation team, whether they want a group, projects, or something
>> else. To be discussed.
>> - The DeveloperPortal, since they weren't part of the disscussion afaik
>> so I want to double check with them.
>> -  Creating "Marketing" and "Outreach" groups/projects under Engagement.
>> The owners have permissions so they can create them, since I don't know
>> exactly what they will be used for.
>>
>> Cheers
>>
>> On Mon, 24 Sep 2018 at 18:05, Piotr Drąg via desktop-devel-list <
>> desktop-devel-list@gnome.org> wrote:
>>
>>> 2018-09-23 2:52 GMT+02:00 Petr Kovar :
>>> > On Fri, 14 Sep 2018 10:58:30 +0200
>>> > Andre Klapper  wrote:
>>> >
>>> >> [CC'ing gnome-i18n@]
>>> >>
>>> >> On Mon, 2018-09-10 at 11:46 -0600, Britt Yazel wrote:
>>> >> > There's been an ongoing discussion about reorganizing the
>>> "community"
>>> >> > top level group from containing both our community partner repos
>>> >> > (purism, ubuntu, fedora) as well as a myriad of other repositories.
>>> >> > As of right now, the Community top level is somewhat of a catch-all,
>>> >> > and we have proposed a fix to split Community into both 'Community'
>>> >> > and 'Teams' repositories, with the new 'Teams' top level being where
>>> >> > we will organize all of our Foundation teams, i.e. Engagement,
>>> >> > Design, Translation, Events, etc.
>>> >> [...]
>>> >> >
>>> https://gitlab.gnome.org/Infrastructure/GitLab/issues/294#note_280162
>>> >>
>>> >> Re Translation:
>>> >>
>>> >> It's unclear to me where in Gitlab people are supposed to file bug
>>> >> reports against a translation in a specific language, which would
>>> allow
>>> >> translators of a language to get aware of bugs in their translations.
>>> >>
>>> >> There is a "8. Translation" label at
>>> >> https://gitlab.gnome.org/groups/GNOME/-/labels which allows
>>> subscribing
>>> >> but does not allow differentiating per language. It should probably be
>>> >> renamed to "8. Internationalization" and only be about code which does
>>> >> not allow proper translation; the label description could link to
>>> >> https://wiki.gnome.org/TranslationProject/DevGuidelines .
>>> >>
>>>
>>> +1
>>>
>>> >> Currently there is an "L10N" product in GNOME Bugzilla with
>>> >> subcomponents for each language. Each subcomponent can be watched
>>> >> separately by folks interested in that subcomponent (=language).
>>> >>
>>> >> Maybe some Gitlab setup / ideas already exists that I'm not aware of?
>>> >
>>> > Can we use https://gitlab.gnome.org/Community/Translation and set up
>>> > translation teams as issue labels there?
>>> >
>>> > Alternatively, we could make Community/Translation a group and set up
>>> > languages as individual projects within that team. That could give
>>> teams
>>> > a better control over where and how to submit issues against their
>>> language.
>>> >
>>>
>>> I like the second idea. I opened
>>> https://gitlab.gnome.org/Infrastructure/GitLab/issues/341 to
>>> kick-start the process.
>>>
>>> Best regards,
>>>
>>> --
>>> Piotr Drąg
>>> https://piotrdrag.fedorapeople.org
>>> ___
>>> desktop-devel-list mailing list
>>> desktop-devel-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab minor-reorganization to Community group

[Carlos Soriano]

This is done now, please check everything is alright.

Left to be done:
- The translation team, whether they want a group, projects, or something
else. To be discussed.
- The DeveloperPortal, since they weren't part of the disscussion afaik so
I want to double check with them.
-  Creating "Marketing" and "Outreach" groups/projects under Engagement.
The owners have permissions so they can create them, since I don't know
exactly what they will be used for.

Cheers

On Mon, 24 Sep 2018 at 18:05, Piotr Drąg via desktop-devel-list <
desktop-devel-list@gnome.org> wrote:

> 2018-09-23 2:52 GMT+02:00 Petr Kovar :
> > On Fri, 14 Sep 2018 10:58:30 +0200
> > Andre Klapper  wrote:
> >
> >> [CC'ing gnome-i18n@]
> >>
> >> On Mon, 2018-09-10 at 11:46 -0600, Britt Yazel wrote:
> >> > There's been an ongoing discussion about reorganizing the "community"
> >> > top level group from containing both our community partner repos
> >> > (purism, ubuntu, fedora) as well as a myriad of other repositories.
> >> > As of right now, the Community top level is somewhat of a catch-all,
> >> > and we have proposed a fix to split Community into both 'Community'
> >> > and 'Teams' repositories, with the new 'Teams' top level being where
> >> > we will organize all of our Foundation teams, i.e. Engagement,
> >> > Design, Translation, Events, etc.
> >> [...]
> >> > https://gitlab.gnome.org/Infrastructure/GitLab/issues/294#note_280162
> >>
> >> Re Translation:
> >>
> >> It's unclear to me where in Gitlab people are supposed to file bug
> >> reports against a translation in a specific language, which would allow
> >> translators of a language to get aware of bugs in their translations.
> >>
> >> There is a "8. Translation" label at
> >> https://gitlab.gnome.org/groups/GNOME/-/labels which allows subscribing
> >> but does not allow differentiating per language. It should probably be
> >> renamed to "8. Internationalization" and only be about code which does
> >> not allow proper translation; the label description could link to
> >> https://wiki.gnome.org/TranslationProject/DevGuidelines .
> >>
>
> +1
>
> >> Currently there is an "L10N" product in GNOME Bugzilla with
> >> subcomponents for each language. Each subcomponent can be watched
> >> separately by folks interested in that subcomponent (=language).
> >>
> >> Maybe some Gitlab setup / ideas already exists that I'm not aware of?
> >
> > Can we use https://gitlab.gnome.org/Community/Translation and set up
> > translation teams as issue labels there?
> >
> > Alternatively, we could make Community/Translation a group and set up
> > languages as individual projects within that team. That could give teams
> > a better control over where and how to submit issues against their
> language.
> >
>
> I like the second idea. I opened
> https://gitlab.gnome.org/Infrastructure/GitLab/issues/341 to
> kick-start the process.
>
> Best regards,
>
> --
> Piotr Drąg
> https://piotrdrag.fedorapeople.org
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab minor-reorganization to Community group

[Carlos Soriano]

Since there hasn't been any complains I'm going ahead with Britt
reorganizacion proposal.

Let me know if any issue arises. If permissions are the problem, check the
owners of their respective groups/subgroups/projects and check with them or
fallback to contact me or Andrea Veri.

Cheers

On Sun, 23 Sep 2018 at 02:52, Petr Kovar  wrote:

> On Fri, 14 Sep 2018 10:58:30 +0200
> Andre Klapper  wrote:
>
> > [CC'ing gnome-i18n@]
> >
> > On Mon, 2018-09-10 at 11:46 -0600, Britt Yazel wrote:
> > > There's been an ongoing discussion about reorganizing the "community"
> > > top level group from containing both our community partner repos
> > > (purism, ubuntu, fedora) as well as a myriad of other repositories.
> > > As of right now, the Community top level is somewhat of a catch-all,
> > > and we have proposed a fix to split Community into both 'Community'
> > > and 'Teams' repositories, with the new 'Teams' top level being where
> > > we will organize all of our Foundation teams, i.e. Engagement,
> > > Design, Translation, Events, etc.
> > [...]
> > > https://gitlab.gnome.org/Infrastructure/GitLab/issues/294#note_280162
> >
> > Re Translation:
> >
> > It's unclear to me where in Gitlab people are supposed to file bug
> > reports against a translation in a specific language, which would allow
> > translators of a language to get aware of bugs in their translations.
> >
> > There is a "8. Translation" label at
> > https://gitlab.gnome.org/groups/GNOME/-/labels which allows subscribing
> > but does not allow differentiating per language. It should probably be
> > renamed to "8. Internationalization" and only be about code which does
> > not allow proper translation; the label description could link to
> > https://wiki.gnome.org/TranslationProject/DevGuidelines .
> >
> > Currently there is an "L10N" product in GNOME Bugzilla with
> > subcomponents for each language. Each subcomponent can be watched
> > separately by folks interested in that subcomponent (=language).
> >
> > Maybe some Gitlab setup / ideas already exists that I'm not aware of?
>
> Can we use https://gitlab.gnome.org/Community/Translation and set up
> translation teams as issue labels there?
>
> Alternatively, we could make Community/Translation a group and set up
> languages as individual projects within that team. That could give teams
> a better control over where and how to submit issues against their
> language.
>
> My 5¢.
>
> Cheers,
> pk
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Gravatar vs libravatar

[Carlos Soriano]

Apologies, hit reply too fast.

Sure, I’ll get in touch with them to find out what that means.


That would be great, thanks. It's clear that we eventually want to have an
alternative to Gravatar... let Andrea, "wicked" or me know what are your
findings.

Cheers

On Thu, 20 Sep 2018 at 18:03, Carlos Soriano  wrote:

> I'm not sure, contact Andrea Veri for more. We definitely got dissapointed
> by finding this suddenly, and we should have investigated a bit more before
> hand. So for now sysadmins wants it disabled.
>
> On Thu, 20 Sep 2018 at 17:26, Alexandre Franke  wrote:
>
>> On Thu, Sep 20, 2018 at 3:52 PM Carlos Soriano 
>> wrote:
>> > Right we read that too, although it doesn't give very high hopes.
>>
>> How so? The maintainer was alone and wanted to stop so he announced
>> the stop with a few months notice, but many people stepped up and have
>> formed a team. One can read their coordination effort in public
>> meeting minutes on their wiki. So instead of the alarming “the service
>> is shutting down” you reported here, it actually is getting stronger
>> maintainership. If that is not hopeful news, I don’t know what will do
>> it for you.
>>
>> > The main problem is the second point, it just redirects stuff to
>> Gravatar, so not much point (and quite shady imho)
>>
>> That part is indeed concerning and requires clarification.
>>
>> > If someone wants to help with that and contact libravatar developers
>> feel free to do so.
>>
>> Sure, I’ll get in touch with them to find out what that means.
>>
>> Now here’s a question because what happens is not clear to me: did the
>> libravatar call all redirect to gravatar, or just some of them? In the
>> latter case, maybe reverting was a hasty decision as reducing the
>> number of calls, while not as perfect as we expected, is still
>> progress.
>>
>> Cheers,
>>
>> --
>> Alexandre Franke
>> GNOME Hacker
>>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Gravatar vs libravatar

[Carlos Soriano]

I'm not sure, contact Andrea Veri for more. We definitely got dissapointed
by finding this suddenly, and we should have investigated a bit more before
hand. So for now sysadmins wants it disabled.

On Thu, 20 Sep 2018 at 17:26, Alexandre Franke  wrote:

> On Thu, Sep 20, 2018 at 3:52 PM Carlos Soriano  wrote:
> > Right we read that too, although it doesn't give very high hopes.
>
> How so? The maintainer was alone and wanted to stop so he announced
> the stop with a few months notice, but many people stepped up and have
> formed a team. One can read their coordination effort in public
> meeting minutes on their wiki. So instead of the alarming “the service
> is shutting down” you reported here, it actually is getting stronger
> maintainership. If that is not hopeful news, I don’t know what will do
> it for you.
>
> > The main problem is the second point, it just redirects stuff to
> Gravatar, so not much point (and quite shady imho)
>
> That part is indeed concerning and requires clarification.
>
> > If someone wants to help with that and contact libravatar developers
> feel free to do so.
>
> Sure, I’ll get in touch with them to find out what that means.
>
> Now here’s a question because what happens is not clear to me: did the
> libravatar call all redirect to gravatar, or just some of them? In the
> latter case, maybe reverting was a hasty decision as reducing the
> number of calls, while not as perfect as we expected, is still
> progress.
>
> Cheers,
>
> --
> Alexandre Franke
> GNOME Hacker
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Gravatar vs libravatar

[Carlos Soriano]

Right we read that too, although it doesn't give very high hopes.

The main problem is the second point, it just redirects stuff to Gravatar,
so not much point (and quite shady imho)

On Thu, 20 Sep 2018 at 15:50, Matthias Klumpp  wrote:

> Am Do., 20. Sep. 2018 um 15:48 Uhr schrieb Carlos Soriano <
> csori...@gnome.org>:
> >
> > And... we are reverting the change.
> >
> > The service is shutting down and actually any call to their servers is
> redirecting to Gravatar, which is quite shady
> >
> > If someone wants to help with that and contact libravatar developers
> feel free to do so.
>
> The service actually isn't shutting down, see the very first and bold
> message on the blogpost ;-)
>
> https://blog.libravatar.org/posts/Libravatar.org_is_not_going_away/
>
> > On Thu, 20 Sep 2018 at 15:33, Carlos Soriano  wrote:
> >>
> >> Done, enjoy!
> >>
> >> On Thu, 6 Sep 2018 at 10:03, Carlos Soriano  wrote:
> >>>
> >>> There has been indeed many things I didn't realize back then!
> >>>
> >>> This has got an overwhelming positive outcome, so seems replacing
> Gravatar by libravatar is the way forward. We will replace it in two weeks
> if no blocker appears.
> >>>
> >>> Thanks all!
> >>>
> >>> On Tue, 4 Sep 2018 at 18:00, Tobias Mueller 
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> On Tue, 2018-09-04 at 11:24 -0400, Nicolas Dufresne wrote:
> >>>> > I'm surely not
> >>>> > the only one that isn't going that extreme in keeping control over
> >>>> > couple of my pictures flying around and won't go that far.
> >>>> This is much less about you than it is about other people visiting our
> >>>> Web site.  AFAIU, we trick those people into telling a third party
> (i.e.
> >>>> Gravatar) that they are visiting our Web site.  While people can patch
> >>>> their browsers to disable such behaviour, we might feel better when
> not
> >>>> doing that by default. Because.. you know.. we claim to value their
> >>>> privacy.
> >>>>
> >>>> Someone was going wild about the GPDR and claimed that GNOME would be
> >>>> affected. If that's the case then we better not make ship code to our
> >>>> visitors that exposes them to third parties.
> >>>>
> >>>> Cheers,
> >>>>   Tobi
> >>>> ___
> >>>> desktop-devel-list mailing list
> >>>> desktop-devel-list@gnome.org
> >>>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
>
> --
> I welcome VSRE emails. See http://vsre.info/
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Gravatar vs libravatar

[Carlos Soriano]

And... we are reverting the change.

The service is shutting down
<https://blog.libravatar.org/posts/Libravatar.org_is_shutting_down_on_2018-09-01/>
and
actually any call to their servers is redirecting to Gravatar, which is
quite shady

If someone wants to help with that and contact libravatar developers feel
free to do so.

Cheers

On Thu, 20 Sep 2018 at 15:33, Carlos Soriano  wrote:

> Done, enjoy!
>
> On Thu, 6 Sep 2018 at 10:03, Carlos Soriano  wrote:
>
>> There has been indeed many things I didn't realize back then!
>>
>> This has got an overwhelming positive outcome, so seems replacing
>> Gravatar by libravatar is the way forward. We will replace it in two weeks
>> if no blocker appears.
>>
>> Thanks all!
>>
>> On Tue, 4 Sep 2018 at 18:00, Tobias Mueller  wrote:
>>
>>> Hi,
>>>
>>> On Tue, 2018-09-04 at 11:24 -0400, Nicolas Dufresne wrote:
>>> > I'm surely not
>>> > the only one that isn't going that extreme in keeping control over
>>> > couple of my pictures flying around and won't go that far.
>>> This is much less about you than it is about other people visiting our
>>> Web site.  AFAIU, we trick those people into telling a third party (i.e.
>>> Gravatar) that they are visiting our Web site.  While people can patch
>>> their browsers to disable such behaviour, we might feel better when not
>>> doing that by default. Because.. you know.. we claim to value their
>>> privacy.
>>>
>>> Someone was going wild about the GPDR and claimed that GNOME would be
>>> affected. If that's the case then we better not make ship code to our
>>> visitors that exposes them to third parties.
>>>
>>> Cheers,
>>>   Tobi
>>> ___
>>> desktop-devel-list mailing list
>>> desktop-devel-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>>
>>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Gravatar vs libravatar

[Carlos Soriano]

Done, enjoy!

On Thu, 6 Sep 2018 at 10:03, Carlos Soriano  wrote:

> There has been indeed many things I didn't realize back then!
>
> This has got an overwhelming positive outcome, so seems replacing Gravatar
> by libravatar is the way forward. We will replace it in two weeks if no
> blocker appears.
>
> Thanks all!
>
> On Tue, 4 Sep 2018 at 18:00, Tobias Mueller  wrote:
>
>> Hi,
>>
>> On Tue, 2018-09-04 at 11:24 -0400, Nicolas Dufresne wrote:
>> > I'm surely not
>> > the only one that isn't going that extreme in keeping control over
>> > couple of my pictures flying around and won't go that far.
>> This is much less about you than it is about other people visiting our
>> Web site.  AFAIU, we trick those people into telling a third party (i.e.
>> Gravatar) that they are visiting our Web site.  While people can patch
>> their browsers to disable such behaviour, we might feel better when not
>> doing that by default. Because.. you know.. we claim to value their
>> privacy.
>>
>> Someone was going wild about the GPDR and claimed that GNOME would be
>> affected. If that's the case then we better not make ship code to our
>> visitors that exposes them to third parties.
>>
>> Cheers,
>>   Tobi
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Gravatar vs libravatar

[Carlos Soriano]

There has been indeed many things I didn't realize back then!

This has got an overwhelming positive outcome, so seems replacing Gravatar
by libravatar is the way forward. We will replace it in two weeks if no
blocker appears.

Thanks all!

On Tue, 4 Sep 2018 at 18:00, Tobias Mueller  wrote:

> Hi,
>
> On Tue, 2018-09-04 at 11:24 -0400, Nicolas Dufresne wrote:
> > I'm surely not
> > the only one that isn't going that extreme in keeping control over
> > couple of my pictures flying around and won't go that far.
> This is much less about you than it is about other people visiting our
> Web site.  AFAIU, we trick those people into telling a third party (i.e.
> Gravatar) that they are visiting our Web site.  While people can patch
> their browsers to disable such behaviour, we might feel better when not
> doing that by default. Because.. you know.. we claim to value their
> privacy.
>
> Someone was going wild about the GPDR and claimed that GNOME would be
> affected. If that's the case then we better not make ship code to our
> visitors that exposes them to third parties.
>
> Cheers,
>   Tobi
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Gravatar vs libravatar

[Carlos Soriano]

Forgot to mention: The obvious upside of Gravatar is that seems to be used
by lot of people, and those are probably okay with using it. Having faces
in GitLab is nice so people see something more than just nicknames, it
feels more human and welcoming.

On the other hand, if changing to libravatar is well supported by us and we
start using it it looks like an easy win-win for privacy-aware tools and
people.

On Mon, 3 Sep 2018 at 20:13, Carlos Soriano  wrote:

> Hello all,
>
> There is a request to replace Gravatar <https://en.gravatar.com/> by
> libravatar <https://www.libravatar.org/> on our GitLab instance. Both are
> supported in GitLab.
>
> The reasoning to replace it is that Gravatar seems to have privacy issues
> <https://en.gravatar.com/>. So I would like to know if we should replace
> it with libravatar or keep using Gravatar.
>
> If you agree, please upvote on the issue
> <https://gitlab.gnome.org/Infrastructure/GitLab/issues/214>, if not,
> downvote. Apologies for the poll, not sure a better way to do it for this
> since both options look quite balanced to me.
>
> If you have any other comment, feel free to provide it here or in the
> issue.
>
> Have a good day everyone!
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] Gravatar vs libravatar

[Carlos Soriano]

Hello all,

There is a request to replace Gravatar  by
libravatar  on our GitLab instance. Both are
supported in GitLab.

The reasoning to replace it is that Gravatar seems to have privacy issues
. So I would like to know if we should replace it
with libravatar or keep using Gravatar.

If you agree, please upvote on the issue
, if not,
downvote. Apologies for the poll, not sure a better way to do it for this
since both options look quite balanced to me.

If you have any other comment, feel free to provide it here or in the issue.

Have a good day everyone!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Group runners: And why CI is slow in forks

[Carlos Soriano]

Just a short heads up for people following the mail, you can easily set up
your own hardware/laptop or cloud as a runner for projects
<https://docs.gitlab.com/ee/ci/runners/>. On the GUADEC's GitLab workshop
we did in 5 minutes.

However, what we want is to have a consistent and good experience for CI
for the whole GNOME, so that means we need to have them centralized. This
is useful to play with it to see costs and how much donation could be made.

Cheers


On Tue, 24 Jul 2018 at 10:08, Carlos Soriano  wrote:

> That sounds great! Seems you know how to set up this which is wonderufl so
> we can get this going.
>
> Sure, we can make a call, I will follow up off-list.
>
> Cheers
>
> On Tue, 24 Jul 2018 at 09:15, Walter Vargas 
> wrote:
>
>> Hi Carlos,
>>
>> Thank you for your concerns regarding the costs associated with CI
>> infrastructure; the last week I was talking to Emmanuel that I would
>> like to donate CPU capacity of one of my cloud accounts for the
>> runners.
>>
>> Please let me know if we can schedule a quick call this week to discuss
>> that.
>>
>> Additionally, we can create a "Runners Support Program" to allow
>> people to contribute with runners, that will require:
>>   1. An automated mechanism to install the required software.
>>  -  This can be an UserData script or an AMI with all set that we
>> could publish to the AWS Market.
>>   2. Support from the Engagement Team to create a social media strategy,
>> etc.
>>
>> Warm Regards.
>>
>> On Mon, Jul 23, 2018 at 7:28 AM Carlos Soriano 
>> wrote:
>> >
>> > Hello all,
>> >
>> > In case you missed my treasurer report talk at GUADEC, our annual costs
>> for CI is around $22.000. This is okay since we are lucky to have GitLab
>> Inc. as the main sponsor of that. However, we cannot offload all of our
>> needs on them, even more in the long-term. So we need to 1) find sponsors,
>> 2) make sure we spend money on just GNOME software.
>> >
>> > In order to spend money just in GNOME software we restricted the fast
>> runners to the groups GNOME/ and Infrastructure/. The runners in there are
>> AWS and DO in a elastic set up, that means they get spawned dynamically as
>> the load increases and they are quite beefy. Ideally this would be in a
>> wiki page, with the set up and costs explained.
>> >
>> > However there is an issue, forks and MR of forks are no part of this,
>> so they get the local machine we have instead of the fast runners.
>> >
>> > I was surprised this wasn't mentioned before, but fear not, it's the
>> most upvoted issue upstream right now
>> https://gitlab.com/gitlab-org/gitlab-ce/issues/23902.
>> >
>> > Lately, if you think someone could sponsor part of that money or some
>> machine for the rest of the software not in those groups, please reach to
>> me!
>> >
>> > Cheers
>> > ___
>> > desktop-devel-list mailing list
>> > desktop-devel-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Group runners: And why CI is slow in forks

[Carlos Soriano]

That sounds great! Seems you know how to set up this which is wonderufl so
we can get this going.

Sure, we can make a call, I will follow up off-list.

Cheers

On Tue, 24 Jul 2018 at 09:15, Walter Vargas  wrote:

> Hi Carlos,
>
> Thank you for your concerns regarding the costs associated with CI
> infrastructure; the last week I was talking to Emmanuel that I would
> like to donate CPU capacity of one of my cloud accounts for the
> runners.
>
> Please let me know if we can schedule a quick call this week to discuss
> that.
>
> Additionally, we can create a "Runners Support Program" to allow
> people to contribute with runners, that will require:
>   1. An automated mechanism to install the required software.
>  -  This can be an UserData script or an AMI with all set that we
> could publish to the AWS Market.
>   2. Support from the Engagement Team to create a social media strategy,
> etc.
>
> Warm Regards.
>
> On Mon, Jul 23, 2018 at 7:28 AM Carlos Soriano  wrote:
> >
> > Hello all,
> >
> > In case you missed my treasurer report talk at GUADEC, our annual costs
> for CI is around $22.000. This is okay since we are lucky to have GitLab
> Inc. as the main sponsor of that. However, we cannot offload all of our
> needs on them, even more in the long-term. So we need to 1) find sponsors,
> 2) make sure we spend money on just GNOME software.
> >
> > In order to spend money just in GNOME software we restricted the fast
> runners to the groups GNOME/ and Infrastructure/. The runners in there are
> AWS and DO in a elastic set up, that means they get spawned dynamically as
> the load increases and they are quite beefy. Ideally this would be in a
> wiki page, with the set up and costs explained.
> >
> > However there is an issue, forks and MR of forks are no part of this, so
> they get the local machine we have instead of the fast runners.
> >
> > I was surprised this wasn't mentioned before, but fear not, it's the
> most upvoted issue upstream right now
> https://gitlab.com/gitlab-org/gitlab-ce/issues/23902.
> >
> > Lately, if you think someone could sponsor part of that money or some
> machine for the rest of the software not in those groups, please reach to
> me!
> >
> > Cheers
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] Bugs migrations status

[Carlos Soriano]

Just a heads up, for those projects waiting for me to migrate bugs
apologies I have been slow, the baseline time requirement of GitLab as
admin is not trivial yet and real work is knocking the door :)

Said that, I'll try to do a migration batch this week for those projects
without special request and that have insisted few times. Those are GNOME
Commander (Uwe) and Epiphany (Michael). If you have a project that needs
that migration ASAP, please reach to me or comment in the issue.

For those with special requests, we need to get this MR
 moving on the
bztogl tool, since it allows component migrations. Your help reviewing,
testing and fixing that MR will be key to be able to do this earlier.

Cheers

PD: Someone asked the list of projects in the migration queue, here it is

.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] Updated to 11.1

[Carlos Soriano]

*What's important for us?*
- Performance improvements

- Rewrite of the MR backend
.
Should be much smoother and allow to review bigger files.
- Changed MarkDown backend to CommonMark
.
Many of the issues we had before with the MarkDown are now fixed, the
backend is the same as GitHub uses.
- File name filter on search

- Disable 3rd party offerings switch
.
No more Kubernetes ads :)

*Some design changes*
- MR design improvements

- Milestones page improvements

- Groups popover


*WebIDE*
- Manage MRs

- Some commit/stage improvements

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] Group runners: And why CI is slow in forks

[Carlos Soriano]

Hello all,

In case you missed my treasurer report talk at GUADEC, our annual costs for
CI is around $22.000. This is okay since we are lucky to have GitLab Inc.
as the main sponsor of that. However, we cannot offload all of our needs on
them, even more in the long-term. So we need to 1) find sponsors, 2) make
sure we spend money on just GNOME software.

In order to spend money just in GNOME software we restricted the fast
runners to the groups GNOME/ and Infrastructure/. The runners in there are
AWS and DO in a elastic set up, that means they get spawned dynamically as
the load increases and they are quite beefy. Ideally this would be in a
wiki page, with the set up and costs explained.

However there is an issue, forks and MR of forks are no part of this, so
they get the local machine we have instead of the fast runners.

I was surprised this wasn't mentioned before, but fear not, it's the most
upvoted issue upstream right now
https://gitlab.com/gitlab-org/gitlab-ce/issues/23902.

Lately, if you think someone could sponsor part of that money or some
machine for the rest of the software not in those groups, please reach to
me!

Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: CI/CD workshop with GitLab developer

[Carlos Soriano]

Hello,

No, BOF's and workshops weren't recorded.

If you have any specific topicnyounwanted to know more about, feel free to
reach me or Jordan Petridis (alatiera)!

On Tue., 17 Jul. 2018, 17:36 Isaque Galdino,  wrote:

> Hi, is there a video you can share for those who couldn't attend it?
> Thanks.
>
> 2018-06-21 9:16 GMT-03:00 Carlos Soriano :
>
>> Hello all,
>>
>> We will have a workshop with a GitLab developer at GUADEC 9th July about
>> CI/CD. We are creating the agenda, and I would like to ask what points
>> would you like to see?
>>
>> The current agenda is:
>>
>> *Introduction to GitLab CI/CD*
>> - Concepts
>> - Why use GitLab CI/CD?
>> - Overview
>>
>> *Setup CI*
>> - structure of .gitlab-ci.yml file
>> - stages & jobs
>> - using Docker images
>> - services & variables
>> - defining jobs
>> - defining environments
>> - only & except
>> - before & after
>> - caching
>> - artifacts & success
>> - manual triggers
>> - schedules
>> - extras
>>
>> *Runners*
>> - architecture
>> - executors
>> - tagged runners
>> - scaling & performance
>>
>> Hope it's going to be useful for all!
>>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>
>
>
> --
> Isaque Galdino
> "sic enim dilexit Deus mundum ut Filium suum unigenitum daret ut omnis qui
> credit in eum non pereat sed habeat vitam aeternam" -- Iohannes 3:16
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

CI/CD workshop with GitLab developer

[Carlos Soriano]

Hello all,

We will have a workshop with a GitLab developer at GUADEC 9th July about
CI/CD. We are creating the agenda, and I would like to ask what points
would you like to see?

The current agenda is:

*Introduction to GitLab CI/CD*
- Concepts
- Why use GitLab CI/CD?
- Overview

*Setup CI*
- structure of .gitlab-ci.yml file
- stages & jobs
- using Docker images
- services & variables
- defining jobs
- defining environments
- only & except
- before & after
- caching
- artifacts & success
- manual triggers
- schedules
- extras

*Runners*
- architecture
- executors
- tagged runners
- scaling & performance

Hope it's going to be useful for all!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Migration of GNOME to GitLab is now completed

[Carlos Soriano]

Hello all,

I'm glad to announce that the GNOME migration to GitLab is now completed!

Cgit and git.gnome.org are now officially gone. Everyone should be using
GitLab for any new operations, including new bugs and git repositories.
Bugzilla will stay with redirections for new bugs and old bugs will be
still be able to be managed for years to come (some people were confused by
my wording here, feel free to ask me for clarification).

Apart of some hickups with glib-networking and some redirection issues, the
migration went well. Honestly better than expected.

I want to take the opportunity to say thank you all for the effort on this
adventure that we have been working together for 1 year and a half (yeah,
that long!). I'm proud of our community that despite the difficulty of this
kind of change and even if we disagreed here and there, we have put our
shoulders together to move forward until we have achieved it. Again, thanks
all.

Things will be still in a bit of flux, and there are some project that have
special requests for bugs that I'll try to manage on the upcoming month, so
expect still a bit of movement.

Don't hesitate reaching to me if you have any question or thought.

Cheers,
Carlos Soriano
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

IMPORTANT Mass migration to GitLab starts

[Carlos Soriano]

Keep an eye on any error and notify me immediately at csori...@gnome.org or
in irc as csoriano in #gnome-hackers.

The mass migration will last between 2-3 days.

Feel free to disable your email notifications, we cannot disable
notifications on the server side since we would lose some valid mails.

Hope the ride goes well for everyone!

Cheers,
Carlos Soriano
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: IMPORTANT: Mass migration to GitLab update

[Carlos Soriano]

whoops good catch! Thanks Alberto.

On 21 May 2018 at 07:18, Alberto Fanjul Alonso 
wrote:

> Glade is already migrated with bugs https://gitlab.gnome.org/GNOME/glade,
> the pending migration is for glade-web https://gitlab.gnome.org/
> Infrastructure/GitLab/issues/232, which has no bugs on bugzilla but some
> hook to deploy on glade.gnome.org on each commit
>
> I double check on bugzilla and is true found this 10 bugs not migrated
> https://bugzilla.gnome.org/buglist.cgi?quicksearch=product%3A%
> 22glade%22%20_id=311293.
>
> El dom., 20 may. 2018 a las 23:57, Tim-Philipp Müller ()
> escribió:
>
>> Hi Carlos,
>>
>> > Exceptions are possible but discouraged due to overhead, please
>> > contact me if you need it. I remember one project that planned to
>> > switch somewhere else that needed an exception, unfortunately I
>> > cannot find the email anymore. Please contact me again.
>>
>> GStreamer is planning to move from gnome bugzilla to
>> gitlab.freedesktop.org.
>>
>> This is actively being worked on, but may not be ready by 1 July, so in
>> case it's not we would like to keep bugzilla fully functional for us
>> until we are ready to migrate, which will hopefully be in the near
>> future in any case.
>>
>> This also means that there is no need to migrate GStreamer to
>> gitlab.gnome.org of course.
>>
>> Cheers
>>  -Tim
>>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: IMPORTANT: Mass migration to GitLab update

[Carlos Soriano]

Here you are, I created an issue to not forget again
https://gitlab.gnome.org/Infrastructure/GitLab/issues/240.

Thanks for sending a new email!

On 20 May 2018 at 23:17, Tim-Philipp Müller  wrote:

> Hi Carlos,
>
> > Exceptions are possible but discouraged due to overhead, please
> > contact me if you need it. I remember one project that planned to
> > switch somewhere else that needed an exception, unfortunately I
> > cannot find the email anymore. Please contact me again.
>
> GStreamer is planning to move from gnome bugzilla to
> gitlab.freedesktop.org.
>
> This is actively being worked on, but may not be ready by 1 July, so in
> case it's not we would like to keep bugzilla fully functional for us
> until we are ready to migrate, which will hopefully be in the near
> future in any case.
>
> This also means that there is no need to migrate GStreamer to
> gitlab.gnome.org of course.
>
> Cheers
>  -Tim
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

IMPORTANT: Mass migration to GitLab update

[Carlos Soriano]

Hello community,

I spent the weekend on getting things ready for the mass migration. Good
news, *we are ready!*

All projects that created an issue (without special requests) has
successfully passed a test migration
<https://gitlab.gnome.org/Infrastructure/GitLab/issues?label_name%5B%5D=Succesful+test>.
This includes projects as big as Evince, Glib, gdk-pixbuf, etc.



*The plan advances one week*
I know usually these plans get delayed, here is going to be the opposite.
For a few reasons, including marketing and me soon going to have less time
(RHEL development is knocking the door :) ) it's going to be useful to
advance the mass migration one week, so this week we will perform it.

*What does this mean*

- Bugzilla will keep the original plan and will be switched to read-only on
1st July. You can switch your project to "read only" in the meantime if
desired. Remember this is about new bugs, not about bugs already present,
those can still be interacted with.
- cgit projects with any activity in the last two years will migrate thir
repo by this week to GNOME/
- cgit becomes obsolete by this week, other projects will be slowly moved
to some other group like "archive" or something like that. Let me know your
ideas here.
- All new bugs will be reported in GitLab for all projects by this week.
- Projects that created an issue in the GitLab infra project
<https://gitlab.gnome.org/Infrastructure/GitLab/issues?label_name%5B%5D=Migration+request>
that had no special requests will be handled manually and repo + bugs will
be migrated during this week.
- Projects that created an issue in the GitLab infra project
<https://gitlab.gnome.org/Infrastructure/GitLab/issues?label_name%5B%5D=Migration+request>
with special requests will be not part of this week mass migration. I'll
handle them during the next 3 weeks, following the original plan.

Exceptions are possible but discouraged due to overhead, please contact me
if you need it. *I remember one project that planned to switch somewhere
else that needed an exception, unfortunately I cannot find the email
anymore. Please contact me again.*



*I need your help validating what I do*Performing the migration is a big
responsibility. I will be very grateful if you can help me making sure I'm
doing the right steps. Please don't hesitate to contact me to make sure I
remember any concern/question/issue you had and that I'm in the same page
with you and your plans.

On that, I would like to double check these projects and maintainers that I
know and I'm not sure it's their intention to not migrate the bugs of their
projects. *Simply follow the instructions in the issue
<https://gitlab.gnome.org/Infrastructure/GitLab/issues/238> to give me an
ack. *Also, please help me reaching out to their maintainers.

   - evolution
   - gtksourceview
   - gdm
   - sysprof
   - pygobject
   - gvfs
   - gobject-introspection
   - gnome-settings-daemon
   - glade
   - vte
   - gnome-terminal
   - gnome-online-accounts
   - totem
   - rhythmbox
   - cogl

Please let me know any thoughts, questions or concerns you might have!

Cheers,
Carlos Soriano
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: BUG REPROT: Bug tracker URLs not talking with Canonical's Launchpad

[Carlos Soriano]

Hey Jeb,

I'm confident Canonical and Ubuntu are aware of this limitation, they are
also GNOMER's around here. Not sure if they will be able to implement that
feature, but there's nothing we can do from here I'm afraid.

Cheers

On 3 May 2018 at 16:08, Jeb Eldridge  wrote:

> Canonical has not updated their Launchpad site to include Gitlab as a
> valid Bug Tracker URL/ID, making it difficult to properly link a bug on
> Gnome's end with Canonical's system end.
>
> I've posted an official bug report a while ago at the URL below, and I am
> a little bit surprised it hasn't been addressed or fixed yet on their end:
> https://bugs.launchpad.net/launchpad/+bug/1738870
>
> If possible, join the conversation on the official bug report so we can
> help get this problem fixed and mitigate Gnome-related issues reported by
> Ubuntu users.
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Protected branches in GNOME's GitLab

[Carlos Soriano]

A small correction from Florian's asnwer:

We had a period that some branches were protected by default because I
didn't know how to deactivate that. But it shouldn't be the case for new
projects or new migrated projects.

Cheers

On 30 April 2018 at 19:19, Florian Müllner  wrote:

> On Mon, Apr 30, 2018 at 6:30 PM Milan Crha  wrote:
>
> > Does it mean, that an automatically created user in GNOME's GitLab
> > instance, basically a complete stranger, receives the Developer
> > privilege, even when it's a Reporter (in bugzilla terms)?
>
> No. In the GNOME group, only people with GNOME git access have Developer
> privilege (that is, everyone who is allowed to push to git.gnome.org). If
> anyone else wants to contribute changes, they have to fork the project in
> their personal namespace. As they have full ownership of their fork (Master
> privilege), they can push all the changes they want however they see fit
> (but without affecting the original upstream repository of course).
>
> Only when they want their changes to be applied back upstream they open a
> merge request (from some branch in their forked repository to a branch
> (likely master) in the original repo), and someone with Developer privilege
> can then review those changes and merge them once they are happy with the
> result.
>
>
> > Which branches are marked as protected in GNOME's GitLab? The master
> > branch is probably protected by default. Which are the other branches?
>
> None as far as I know.
>
>
> > According to [1] I can mark/unmark branches as protected when I'm at
> > least the Master level of the project, but doing that each six months
> > when branching for stable feels like one more thing to easily forget
> > about, thus it would be nice to have some common "mark-as-protected
> > gnome-X-YZ branches when created"
>
> You can protect multiple branches with a single rule by using a wildcard,
> for example "gnome-*" (to catch all current and future stable branches) or
> "gnome-3-*" (to make unintended matches less likely).
>
> Cheers,
> Florian
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.28.1 tarballs due

[Carlos Soriano]

I'll put a banner in GitLab.

Cheers.

On 7 April 2018 at 19:50,  wrote:

> Hi developers,
>
> It looks like our automated reminder mails are not working properly
> currently. (Does anybody know how to help fix this?) 3.28.1 tarballs are
> due Monday. You all know the drill.
>
> Thanks a bunch,
>
> Michael
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] Duplicates handling, feedback for meeting with GitLab

[Carlos Soriano]

Hello all,

I'm having a meeting with GitLab on Friday about what we are missing for
duplicates handling as part of one of the high priority items
. I identified the
following points (upstream comment
):

* There is no UI for creating duplicates, like a button or so, but rather
is semi-hidden with slash commands.
* There is not clear UI that shows the duplicate status of the bug report
when browsing or searching bug reports, neither indication for to which
report is duplicated to.
* It's not possible to filter out duplicated bug reports when searching
and/or listing.
* There is not clear UI that lists the duplicated bugs linked to a single
report in order for the maintainer and bug triaging team to have a single
source where to look for more comments and cases about that issue.
* There is no duplicate creation prevention, as Bugzilla does providing
possible duplicates when the user tries to create a bug report.

Any other points I should bring up? Thoughts on those listed here?

Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Easter gift, GitLab Pages are now enabled

[Carlos Soriano]

I would like to clarify a bit more,

My intention when I created that Hugo template months ago was for
streamline apps websites if we ever wanted something like that. So you can
see that creating that webpage with the Hugo template I created is a few
lines of content and everything else is managed automatically. For example
one of the sections is simply:

> +++
> date = "2015-07-18T14:08:29+02:00"
> draft = false
> img = "landscape.png"
> weight = 1
> orientation = "center"
> +++
> Nautilus (Files) is a file manager created to fit the GNOME desktop design
> and behavior, giving the user a simple way to navigate and manage files.
>

And you have few of them like this for section separation, as done here
<https://gitlab.gnome.org/csoriano/nautilus-web/tree/master/content/post>.

What I'm not sure about is if this is easier to contribute and maintain
than the wiki, with all the custom styling we do in the wiki I'm starting
to think that it could be. On the other hand it's not very obvious the end
result of the Hugo website is when looking at these templates.

Ultimately it depends on how we see it... the proposal is there.

Cheers


On 30 March 2018 at 12:09, Carlos Soriano <csori...@gnome.org> wrote:

> Hey Xavier,
>
> As I put in my email that websitr is a toy example I played with long ago
> and not something Nautilus plans to add.
>
> Generically for GNOME there were some concerns of creating individual
> pages for projects, however those that already had a website will benefit
> from this feature.
>
> Eventually this is up to the community, certainly there are many new
> features of GitLab like Pages that we can use more commonly, but imho we
> should try to not spread us too thin and end up with websites all around
> with no maintenance if we already have problems to maintain websites as
> important as gnome.org or gtk.org
>
> That's my 2 cents. But again, ultimately up to the community, we now have
> the possibility to do so.
>
> Cheers
>
> On Thu., 29 Mar. 2018, 20:56 , <xclae...@gmail.com> wrote:
>
>> Hi,
>>
>> Does this means we are going to put project's website inside project's
>> git repo? So your nautilus-web example is ultimately going to be merged
>> into nautilus' git repo? Or I didn't understood? That would be awesome!
>>
>> Regards,
>> Xavier Claessens.
>>
>> Le jeudi 29 mars 2018 à 19:54 +0200, Carlos Soriano a écrit :
>> > As the subject says, we have now support for GitLab Pages, thanks to
>> > Andrea.
>> >
>> > Take a look to the example I did for Nautilus with Hugo, which
>> > renders to this result. Gtk+, GIMP, Pitivi and the GUADEC website are
>> > some of the projects that will benefit.
>> >
>> > Feel free to share your feedback in the issue report.
>> >
>> > Happy holidays! 
>> >
>> > PD: The website linked it's a toy, not something we actually plan to
>> > have for Nautilus.
>> > ___
>> > desktop-devel-list mailing list
>> > desktop-devel-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Easter gift, GitLab Pages are now enabled

[Carlos Soriano]

Hey Xavier,

As I put in my email that websitr is a toy example I played with long ago
and not something Nautilus plans to add.

Generically for GNOME there were some concerns of creating individual pages
for projects, however those that already had a website will benefit from
this feature.

Eventually this is up to the community, certainly there are many new
features of GitLab like Pages that we can use more commonly, but imho we
should try to not spread us too thin and end up with websites all around
with no maintenance if we already have problems to maintain websites as
important as gnome.org or gtk.org

That's my 2 cents. But again, ultimately up to the community, we now have
the possibility to do so.

Cheers

On Thu., 29 Mar. 2018, 20:56 , <xclae...@gmail.com> wrote:

> Hi,
>
> Does this means we are going to put project's website inside project's
> git repo? So your nautilus-web example is ultimately going to be merged
> into nautilus' git repo? Or I didn't understood? That would be awesome!
>
> Regards,
> Xavier Claessens.
>
> Le jeudi 29 mars 2018 à 19:54 +0200, Carlos Soriano a écrit :
> > As the subject says, we have now support for GitLab Pages, thanks to
> > Andrea.
> >
> > Take a look to the example I did for Nautilus with Hugo, which
> > renders to this result. Gtk+, GIMP, Pitivi and the GUADEC website are
> > some of the projects that will benefit.
> >
> > Feel free to share your feedback in the issue report.
> >
> > Happy holidays! 
> >
> > PD: The website linked it's a toy, not something we actually plan to
> > have for Nautilus.
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] Easter gift, GitLab Pages are now enabled

[Carlos Soriano]

As the subject says, we have now support for GitLab Pages
, thanks to Andrea.

Take a look to the example I did for Nautilus
 with Hugo,
which renders to this result
. Gtk+, GIMP, Pitivi
and the GUADEC website are some of the projects that will benefit.

Feel free to share your feedback in the issue report
.

Happy holidays! 

PD: The website linked it's a toy, not something we actually plan to have
for Nautilus.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GSoC] Mentors: Time to review students proposals

[Carlos Soriano]

Hello GSoC Mentors,

Students have already added their final proposals to the GSoC website and
we cleaned up everything so you can search for the ones that you are
interested in.

In order to get the students who you want into the accepted slots, go to
https://summerofcode.withgoogle.com/ and search for the proposals that you
want to mentor. Then you need to do the following:
- Make sure you have marked all proposals you'd like to accept as "want to
mentor". If you have multiple proposals for the same project, you need to
pick the one which you want to accept.
- In the comments section of the proposal on the GSoC website, include a
score (explanation of score below*) and any comments about your experience
mentoring the applicant, including how strongly you feel that they should
be accepted for the program.
- If you want to mentor more than one student, send us an email at
soc-adm...@gnome.org to confirm this. Please make sure that you will have
enough time for two students. It's expected that you spend around 10 hours
per week per student. Google  strongly recommends that a mentor accepts
only one student, so we need to be careful when we accept these exceptions.

It is important to do these steps soon - the sooner this is done, the more
likely you are to get the students you want! In any case, do this before
20/04/2018 (2018-04-20 :P )

*Score scale (half point rankings, e.g. 4.5 or 3.5, are ok):
5 = amazing applicant, could become a module maintainer on completing the
program, made extensive contributions to GNOME of high quality
4 = strong applicant, will certainly do a good job, made substantial
contributions to GNOME of high quality (> ~100 lines of code or equivalent)
3 = good applicant, but is somewhat inexperienced
2 = is unlikely to do a good job
1 = not a good candidate

Also remember that when mentoring in GSoC, we expect that you:
- Fill evaluations at least 3 days before the official Google deadline. We
need some time to tie up loose ends. Your student will fail and GNOME will
get penalized if the evaluation is not filled on time.
- Spend around 10h per week with the student on reviewing code, helping
them, chatting, etc.
- Set weekly goals and review the goals in weekly meetings.
- Review code submissions of the student thoroughly and in a timely manner.
- Communicate regularly with the student.
- The student is on planet.gnome.org before the end of the community
bonding phase.

If you have any questions, please don't hesitate to send us an email to
soc-adm...@gnome.org (preferred) or contact one of us on IRC.

Have a nice day,
GSoC Admins
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

> Many users don’t provide traces at first though

To make sure we are in the same page, the current issue template Nautilus
uses does mention how to get a backtrace. Quoting:
# Additional information


> Can templates be used for comments too or are they just for the issue
description?

Just issue and MR descriptions. Not sure I understood your idea though,
what would you put in a comment?

On 24 March 2018 at 14:39, Alexandre Franke <afra...@gnome.org> wrote:

> On Fri, Mar 23, 2018 at 11:56 AM, Carlos Soriano <csori...@gnome.org>
> wrote:
> > Proper formatting from users is what issue templates are for.
>
> Many users don’t provide traces at first though and they only come in
> a later comment. Can templates be used for comments too or are they
> just for the issue description?
>
> --
> Alexandre Franke
> GNOME Hacker & Foundation Director
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

Milan,

Proper formatting from users is what issue templates are for. You can take
a look at the blog post I did where we take into account crashes, and
definitely worth saying "select the backtrace and click the button 'code'"
or similar (which is not in my current proposal, but I
ll add it).

On 23 March 2018 at 11:44, Milan Crha  wrote:

> On Fri, 2018-03-23 at 11:04 +0100, Mattias Bengtsson wrote:
> > > https://gitlab-test.gnome.org/mcrha/test/issues/4
> >
> > It's markdown formatted like most of GitLab. So just ask your users
> > to wrap
> > their backtraces in code blocks, like this:
> >
> > ```
> > Your Backtrace
> > ```
>
> Hi,
> I know it's a markdown, I'm just trying to learn it right now :)
>
> I did notice the "Insert code" button above the comment entry, which I
> though is what I've been looking for, but it added only `` and trying
> to write anything in between those didn't result in anything feasible.
>
> Yours triple-` works too and it looks differently than the 
> (I added it to the above issue). It still means to either teach the
> users something (times it, I do not know, say by thousands) or edit
> their comments (which I disagree with), but it's just the price for
> other benefits GitLab instance can/will bring, thus no big deal as
> such.
>
> Definitely once I get use to it it'll be just a piece of cake.
> Thanks and bye,
> Milan
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] We are on GitLab Libre 10.6

[Carlos Soriano]

Short update: We are now on GitLab Libre (renamed from CE) 10.6, and
therefore now we can rebase and modify non-dev branches
, make sure to ask
contributors to enable that.

Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

Oh got it Phillip, apologies for the noise, I'm starting to forget the
details here and there...

On 21 March 2018 at 22:49, Alexandre Franke  wrote:

> On Wed, Mar 21, 2018 at 10:37 PM, Shaun McCance  wrote:
> > And in constructing this example for this email, I discovered that this
> > redirect ALREADY WORKS. Nevermind me. Carry on being awesome.
>
> And https://git.gnome.org/browse/nautilus/commit/?id=
> 99fa9e298b289b643aab14286479676ec85dfd24
> redirects to https://gitlab.gnome.org/GNOME/nautilus/commit/
> 99fa9e298b289b643aab14286479676ec85dfd24
> which is even more awesome. ☺
>
> --
> Alexandre Franke
> GNOME Hacker & Foundation Director
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Migration of non-core apps Was: Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

Whops sorry, your comment in the issue slipped my inbox.

gnome-commander is not migrated. bugzilla-migration is an admin user that
is used for testing migrations. My comment
https://gitlab.gnome.org/Infrastructure/GitLab/issues/83#note_24426 still
stands, there is a bug that needs fixing before a migration can happen.

Cheers

On 21 March 2018 at 22:49, Uwe Scholz <u.schol...@gmx.de> wrote:

> Hi Carlos and all the others,
>
> you migrated *Gnome Commander* to Gitlab some time ago, which isn't a
> core app of Gnome. I am the maintainer of this software and I see that
> the GitLab link to the project currently is:
>
> https://gitlab.gnome.org/bugzilla-migration/gnome-commander
>
> I am not sure about it, so I am asking it here: Will this be the final
> link? Or is there the possibility to change "bugzilla-migration" to
> something like my user name or a group, i.e. "non-core" or whatever? As
> I don't know how non-core apps will be handled in the future I am asking
> this here. I am not so deeply informed about the plans about the Gnome
> infrastructure. Maybe the answer you give is of interest for others.
>
> And I still have a problem in pushing commits to the new repository,
> I think because I am not set to the maintainer of the repository. See my
> last comment at issue #83:
> https://gitlab.gnome.org/Infrastructure/GitLab/issues/83
>
> Do I have to apply for becoming the maintainer of the Gnome Commander
> repo at GitLab somewhere?
>
> Best wishes and thank you for all your efforts so far!
> Uwe
>
> Am Tue, 20 Mar 2018 18:01:35 +0100 schrieb Carlos Soriano:
> > Hello community,
> >
> > After a few months of manually migrating projects we have moved
> > already over 60, most of them were core modules to make sure the most
> > important projects were migrated before the mass migration happens.
> > We are now at the point where a mass migration makes more sense than
> > continuing handling migrations one by one, in part also because of
> > the increasing amount of requests.
> >
> > [...]
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

Regarding the impersonation, it was me being cautious, I didn't do any
consultation or something like that.

My take is that the consequences of X threshold of people complaining about
that would be a major issue, including possible requests for deleting all
the issues migrated that contain the impersonation, and I don't want to
find myself in that situation. If that surprises you, I suggest to take a
moment and think again about how many different people our community have
:). On the other hand, less legible text of migrated issues doesn't strike
me as a major problem.

For practical reason I personally prefer the result of the migration with
impersonation too.

Anyway, Philip let's go with impersonation, would you be able to take care
of that?

On 21 March 2018 at 21:52, Carlos Soriano <csori...@gnome.org> wrote:

> Hey Shaun,
>
> It wouldn't be a problem per se, actually we were doing it before.
> However, if we do that GitLab hooks are not triggered, and we rely on them.
> So the only way forward is for everyone to start using the new repos.
>
> Sorry!
>
> On 21 March 2018 at 21:44, Shaun McCance <sha...@gnome.org> wrote:
>
>> On Tue, 2018-03-20 at 18:01 +0100, Carlos Soriano wrote:
>> > - Cgit will be phased out and removed by June 1st 2018.
>>
>> How tremendously difficult would it be to set up 302 redirects so that
>> links to commits/branches/etc go to the right place in GitLab? I don't
>> want to add to your workload. You all are already doing incredible work
>> with a very big job. But it would be kind of nice.
>>
>> --
>> Shaun
>>
>>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

Hey Shaun,

It wouldn't be a problem per se, actually we were doing it before. However,
if we do that GitLab hooks are not triggered, and we rely on them. So the
only way forward is for everyone to start using the new repos.

Sorry!

On 21 March 2018 at 21:44, Shaun McCance <sha...@gnome.org> wrote:

> On Tue, 2018-03-20 at 18:01 +0100, Carlos Soriano wrote:
> > - Cgit will be phased out and removed by June 1st 2018.
>
> How tremendously difficult would it be to set up 302 redirects so that
> links to commits/branches/etc go to the right place in GitLab? I don't
> want to add to your workload. You all are already doing incredible work
> with a very big job. But it would be kind of nice.
>
> --
> Shaun
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

Just a very quick thing, please don't rename projects :D

We have git management on disk, not only in GitLab. Not sure if our hooks
would protect against that, but better to not test them for now...

On Wed., 21 Mar. 2018, 17:57 Mathieu Bridon via desktop-devel-list, <
desktop-devel-list@gnome.org> wrote:

> On Wed, 2018-03-21 at 11:22 +0100, Arnaud Bonatti wrote:
> > Hi Milan,
> >
> > 2018-03-21 8:53 UTC+01:00, Milan Crha :
> > > Your module rename may mean also renaming in distributions, thus it
> > > should not be done in a rush and "just because we can". At least
> > > from my point of view. You also lose some kind of mind share with
> > > the rename, because existing users know what it is called now, but
> > > will be lost when you rename the module […]
> >
> > I completely agree with you, the renaming of an old and known
> > application is always a hard thing to decide and to do, and that’s
> > why it definitively needs discussions. Note that I don’t feel any
> > hurry here (in fact, I’m talking here and there about this renaming
> > since two years…), but depending on how hard it looks like to do the
> > renaming *after* the Gitlab migration,
>
> Renaming in Gitlab is trivial: in the project settings you can just
> rename the project, and Gitlab will set up redirections so that old
> URLs keep working. (at least that happened on other Gitlab instances, I
> see no reason why that wouldn't work on GNOME's)
>
>
> --
> Mathieu
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

It could be that's a solution, could someone check?

For context, my plan is to modify the migration tool as soon as possible to
not require admin access for running it (but admin access will still be
required for the actual migration) so everyone can help me with the whole
thing by testing their own modules and reporting issues.

On 21 March 2018 at 09:27, Germán Poo-Caamaño <g...@gnome.org> wrote:

> On Wed, 2018-03-21 at 08:53 -0400, Carlos Soriano wrote:
> > > Should issues be filed against Infrastructure/GitLab?
> >
> > Yeah please
> >
> > > which Andre already raised. His proposal to send the announcement
> >
> > Maybe yeah, I have no idea how to do that or extract this information
> > though. Feel free to send me the list of projects/contacts and I can
> > definitely can send an email.
> >
> > > I really don’t think it is a big deal, especially if this is
> > publicly
> > announced
> >
> > It's not about if admins have powers or not, is about the fact of
> > impersonating a user in comments. It's true that publicly announcing
> > could
> > be enough.
>
> AFAIU, it is only data migration, you are not doing anything extra that
> was not in the user's intention.
>
> > However the other big issue is that notifications would be send
> > massively, and I don't know how to prevent that. So that's basically
> > a no-no from the start. Maybe some trick can be done, but no idea.
>
> Cannot you disable the email notifications during the migration?
>
> I mean, when you create a project, set the notification to 'disabled',
> and enable them after the migration finishes.
>
> https://docs.gitlab.com/ee/api/notification_settings.html#doc-nav
>
> --
> Germán Poo-Caamaño
> http://calcifer.org/
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

> Should issues be filed against Infrastructure/GitLab?

Yeah please

> which Andre already raised. His proposal to send the announcement

Maybe yeah, I have no idea how to do that or extract this information
though. Feel free to send me the list of projects/contacts and I can
definitely can send an email.

> I really don’t think it is a big deal, especially if this is publicly
announced

It's not about if admins have powers or not, is about the fact of
impersonating a user in comments. It's true that publicly announcing could
be enough.

However the other big issue is that notifications would be send massively,
and I don't know how to prevent that. So that's basically a no-no from the
start. Maybe some trick can be done, but no idea.


On 21 March 2018 at 07:07, Alexandre Franke <afra...@gnome.org> wrote:

> On Wed, Mar 21, 2018 at 11:28 AM, Carlos Soriano <csori...@gnome.org>
> wrote:
> > Could you create an issue for those you know so I can evaluate them one
> by one?
> > Ideally with a way to contact their maintainers.
>
> I don’t know of other projects from the top of my head and reviewing
> the list at https://bugzilla.gnome.org/page.cgi?id=browse.html;
> classification=__all
> is probably the only way, but that would require quite an investment
> of time. I can’t take on that task right now and would appreciate
> anyone volunteering to do it. This could be split amongst several
> people.
>
> Should issues be filed against Infrastructure/GitLab?
>
> > In general I think these projects should decide themselves where they
> want
> > to live, and move either to one place or the other altogether.
>
> Sure, but they are unlikely to read d-d-l and similar lists as they
> have little interaction with our community, which Andre already
> raised. His proposal to send the announcement (amended with a note for
> non-GNOME project that they can elect to migrate outside of the GNOME
> infrastructure) sounds like a great idea.
>
> >> Any chance of getting https://gitlab.gnome.org/
> Incubator/bztogl/issues/7
> >> fixed before then?
> >
> > Not sure, I think impersonating is still something some people don't
> agree
> > with.
>
> With the kinds of power admins already have, I really don’t think it
> is a big deal, especially if this is publicly announced. Did you
> actually have people express concerns or are you just assuming like
> you were in the first place? You already got positive feedback when
> that was discussed last time.
>
> The legibility gain on the other hand *is* a big deal.
>
> >> Can we make a pass of archiving before that?
> >
> > That was my desire too, but the agreement seems to be on the opposite and
> > have all the projects even for historical reasons. We could have a
> subgroup
> > for those though.
>
> Yes, a GNOME/Archives/ subgroup sounds good.
>
> > The work load for migrating git repositories is not an issue, on the
> other
> > hand migrating bugs is a big work load.
>
> Fair enough, archiving before migration and then moving them to the
> GNOME/Archives/ subgroup would still make it easier to find stuff once
> on Gitlab. Also archiving helps with translations and bugzilla.
>
> --
> Alexandre Franke
> GNOME Hacker & Foundation Director
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

> What will happen to non-GNOME/third party products that we have on
Bugzilla?

Yeah, not knowing these special cases make me anxious. Could you create an
issue for those you know so I can evaluate them one by one? Ideally with a
way to contact their maintainers.

In general I think these projects should decide themselves where they want
to live, and move either to one place or the other altogether.

> Any chance of getting https://gitlab.gnome.org/Incubator/bztogl/issues/7
fixed before then?

Not sure, I think impersonating is still something some people don't agree
with.

> Can we make a pass of archiving before that?

That was my desire too, but the agreement seems to be on the opposite and
have all the projects even for historical reasons. We could have a subgroup
for those though.

The work load for migrating git repositories is not an issue, on the other
hand migrating bugs is a big work load.

On 21 March 2018 at 05:50, Alexandre Franke <afra...@gnome.org> wrote:

> On Tue, Mar 20, 2018 at 6:01 PM, Carlos Soriano <csori...@gnome.org>
> wrote:
> > Hello community,
>
> Hi,
>
> > After a few months of manually migrating projects we have moved already
> over
> > 60, most of them were core modules to make sure the most important
> projects
> > were migrated before the mass migration happens.
>
> Congratulations on that achievement.
>
> > Proposed plan and timeline for mass migration
>
> What will happen to non-GNOME/third party products that we have on
> Bugzilla? The example that comes to mind is Doxygen as it’s quite
> visible (in the top 10 when looking at weekly reports). They use
> Bugzilla but not git.gnome.org. For this specific case, they could
> move their issues to Github where their repository already is
>
> There are probably other similar cases, I seem to remember some
> projects using Launchpad for code but our Bugzilla for bug reports.
>
> In any case those probably shouldn’t be moved to the GNOME group on
> Gitlab, right?
>
> > - Projects that want their bugs migrated will create an issue in our
> > infrastructure similar to this over the next two months. These project
> bugs
> > will be migrated to GitLab issues between June 1st and June 15th 2018.
> [0]
>
> Any chance of getting
> https://gitlab.gnome.org/Incubator/bztogl/issues/7 fixed before then?
> It was supposedly blocked because you thought people would be against
> the script impersonating them, but it turned out not to be an issue so
> I guess nothing is blocking it anymore. That would vastly improve
> legibility and usefulness of migrating issues.
>
> > - Projects that doesn't create an issue for bug migration will migrate
> only
> > the repository, also by June 1st 2018.
>
> Can we make a pass of archiving before that? Several repos haven’t had
> any activity at all (not even translations) for 2, 3, … up to
> 8 years. There’s not much sense migrating those. A cleanup would
> reduce the work load.
>
> Cheers,
>
> --
> Alexandre Franke
> GNOME Hacker & Foundation Director
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

Hey all,

Tim-Philipp I'll discuss today with Andrea what to do here, in any case
don't worry, we will find a solution with either staying in Bugzilla or
making sure you can migrate to fdo (I'll run a migration test).

Arnaud, if you want a rename it's totally doable, several modules already
took this opportunity and requested this. The migration is done by us, so
no worries about that. Do please create issues in our GitLab infra product
stating these renames.

Andre, that's very helpful, thanks! Setting a banner in Bugzilla sounds the
best approach, could you do that?

Cheers

On 21 March 2018 at 03:53, Milan Crha  wrote:

> On Wed, 2018-03-21 at 07:56 +0100, Arnaud Bonatti wrote:
> > the future name of ‘dconf-editor’ needs discussions (‘Registry’ and
> > ‘Tinkerings’ are the best I came with
>
> Hi,
> may I ask why? What is the reasoning about changing the name of the
> dconf-editor? You want to rename a reversi game to reflect what it is
> (I had no idea what 'iagno' is until now), then you want to do
> something opposite for the dconf-editor? That looks odd. With
> 'Registry', well, it's too generic and I'd say "Hello Windows" when I
> see it anywhere on Linux. Does dconf-editor talk only to DConf, or it's
> available for any GSettings backend? If the later, then the most
> accurate (but maybe not the nicest) name would be "gsettings-editor".
> Otherwise I'd really keep the connection to DConf as obvious as it is
> now.
>
> The GConf editor currently identifies itself as "Configuration Editor"
> and the dconf-editor as "dconf Editor" in the Applications menu, both
> with the same icon. I do have both of them installed here.
>
> Your module rename may mean also renaming in distributions, thus it
> should not be done in a rush and "just because we can". At least from
> my point of view. You also lose some kind of mind share with the
> rename, because existing users know what it is called now, but will be
> lost when you rename the module (and the packages will be renamed, and
> the .desktop files will be renamed, and the application will be
> identified differently, and so on). I know that many application names
> in GNOME (and elsewhere) do not reflect what they actually do. Either
> one lives with what the decision makers decided at the beginning, or...
>
> A good example is Epiphany. I asked a user to test something with it
> recently. He installed it, but he could not find it in the
> Applications. It's not "Epiphany" there, it's just "Web". I know it,
> but for him it was a surprise and a source of confusion.
>
> Just my thoughts.
> Bye,
> Milan
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

By request, cc'ing this list.

On 20 March 2018 at 18:01, Carlos Soriano <csori...@gnome.org> wrote:

> Hello community,
>
> After a few months of manually migrating projects we have moved already
> over 60, most of them were core modules to make sure the most important
> projects were migrated before the mass migration happens. We are now at the
> point where a mass migration makes more sense than continuing handling
> migrations one by one, in part also because of the increasing amount of
> requests.
>
> *Proposed plan and timeline for mass migration*
>
> - Projects that want their bugs migrated will create an issue in our
> infrastructure similar to this
> <https://gitlab.gnome.org/Infrastructure/GitLab/issues/172> over the next
> two months. These project bugs will be migrated to GitLab issues between
> June 1st and June 15th 2018. [0]
> - Individual projects that it's important for them to move to GitLab
> sooner (i.e. GSoC projects, core modules, etc.) can still do so with the
> same procedure as before. Feel free to ping me regularly about those.
> - Projects that doesn't create an issue for bug migration will migrate
> only the repository, also by June 1st 2018.
> - Projects that didn't opt in to migrating bugs can still do so while
> Bugzilla is not phased out, however timing will be different and the issues
> will be migrated in batches once every two months or so.
> - Bugzilla will only allow comments by June 1st 2018. Reporting new bugs
> on Bugzilla will be disabled. New issues will be reported and managed in
> GNOME's GitLab.
> - Bugzilla will be phased out and much likely converted into a static
> website by February 2020 (the proposed date may vary as we're still
> evaluating all the possible solutions to make sure all the bugs will remain
> available in read-only mode after Bugzilla's service decommission). We'll
> still evaluating possible ways of keeping old bugs available for historical
> reasons.
> - Cgit will be phased out and removed by June 1st 2018.
>
> The goal is to have all GNOME projects moved to GitLab by GUADEC 2018; I
> left some time for eventual issues between 15th June and 6th July.
>
> If you are a maintainer and you consider some issue in the migration
> process or GitLab itself a big problem for your project, please take a look
> if we are tracking it already in the upstream priorities for GNOME
> <https://gitlab.com/gitlab-org/gitlab-ce/issues/43566>. If we do so,
> consider those are ongoing effort items and hopefully there will be some
> progress in the upcoming months. If we don't track it, either create an
> issue in our infrastructure (preferred, so others can comment too) with the
> link to the upstream report or contact me in IRC or email and we can
> discuss if it should be considered part of our GNOME priorities.
>
> Feel free to share your thoughts and comments about the proposal and I
> hope the timeline fits well with your activities.
>
> *General update*
>
> - GitLab worked upstream
> <https://gitlab.com/gitlab-org/gitlab-ce/issues/22292> on *being able to
> rebase and modify non-dev* (from forks) MR/branches as we requested
> recently and the feature will be available on the 22nd of this month. Let
> me share our thanks to them for taking quick action.
> - Issues with *login/register raising 500 errors *due to Google's
> ReCAPTCHA are now fixed.
> - Amazon AWS for *CI on-demand* is set up and available to use, CI should
> be fast and scalable. This is being possible thanks to the help of
> sponsors, stay tuned for the actual announcements.
>
> [0] This is because it's not feasible to migrate all the issues from
> Bugzilla for several technical details, and from what we experienced with
> other projects the migration of bugs don't achieve as much as was thought.
> Projects can take this as an opportunity to start using new features of
> GitLab to be more efficient towards issue management.
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

Hello community,

After a few months of manually migrating projects we have moved already
over 60, most of them were core modules to make sure the most important
projects were migrated before the mass migration happens. We are now at the
point where a mass migration makes more sense than continuing handling
migrations one by one, in part also because of the increasing amount of
requests.

*Proposed plan and timeline for mass migration*

- Projects that want their bugs migrated will create an issue in our
infrastructure similar to this
 over the next
two months. These project bugs will be migrated to GitLab issues between
June 1st and June 15th 2018. [0]
- Individual projects that it's important for them to move to GitLab sooner
(i.e. GSoC projects, core modules, etc.) can still do so with the same
procedure as before. Feel free to ping me regularly about those.
- Projects that doesn't create an issue for bug migration will migrate only
the repository, also by June 1st 2018.
- Projects that didn't opt in to migrating bugs can still do so while
Bugzilla is not phased out, however timing will be different and the issues
will be migrated in batches once every two months or so.
- Bugzilla will only allow comments by June 1st 2018. Reporting new bugs on
Bugzilla will be disabled. New issues will be reported and managed in
GNOME's GitLab.
- Bugzilla will be phased out and much likely converted into a static
website by February 2020 (the proposed date may vary as we're still
evaluating all the possible solutions to make sure all the bugs will remain
available in read-only mode after Bugzilla's service decommission). We'll
still evaluating possible ways of keeping old bugs available for historical
reasons.
- Cgit will be phased out and removed by June 1st 2018.

The goal is to have all GNOME projects moved to GitLab by GUADEC 2018; I
left some time for eventual issues between 15th June and 6th July.

If you are a maintainer and you consider some issue in the migration
process or GitLab itself a big problem for your project, please take a look
if we are tracking it already in the upstream priorities for GNOME
. If we do so,
consider those are ongoing effort items and hopefully there will be some
progress in the upcoming months. If we don't track it, either create an
issue in our infrastructure (preferred, so others can comment too) with the
link to the upstream report or contact me in IRC or email and we can
discuss if it should be considered part of our GNOME priorities.

Feel free to share your thoughts and comments about the proposal and I hope
the timeline fits well with your activities.

*General update*

- GitLab worked upstream
 on *being able to
rebase and modify non-dev* (from forks) MR/branches as we requested
recently and the feature will be available on the 22nd of this month. Let
me share our thanks to them for taking quick action.
- Issues with *login/register raising 500 errors *due to Google's ReCAPTCHA are
now fixed.
- Amazon AWS for *CI on-demand* is set up and available to use, CI should
be fast and scalable. This is being possible thanks to the help of
sponsors, stay tuned for the actual announcements.

[0] This is because it's not feasible to migrate all the issues from
Bugzilla for several technical details, and from what we experienced with
other projects the migration of bugs don't achieve as much as was thought.
Projects can take this as an opportunity to start using new features of
GitLab to be more efficient towards issue management.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GSoC] Call for ideas

[Carlos Soriano]

There has been some reports that the email field errors with "Valid
email address required" for the phone number field. Reloading the page
seems to fix it, unfortunately I cannot see anything wrong with the
form from my side.

For those that do not want to use Google docs, sending an email to
soc-adm...@gnome.org with the info should be fine too, although it
will require us to write down the info in the form ourselves, so it's
an overhead for us (alternative suggestions for next year are more
than welcome). The information you need to send is: irc nick, irc
channel, GMail email, alternative email for communication (optional)
and phone number.
Carlos Soriano
GNOME Board of Directors


On 12 March 2018 at 09:38, Carlos Soriano <csori...@gnome.org> wrote:
> Hello all,
>
> As you may know GNOME was again accepted for GSoC!
>
> Thanks to the mentors who've already listed GSoC project ideas! There is
> still time to add more ideas and they are more than welcome.
>
> If you are interested, please add your idea to the wiki. If you are
> interested but don't have any ideas, contact us at soc-adm...@gnome.org or
> one of the admins on IRC and we will help you find some.
>
> For mentors whose ideas are triaged, it's time to register with us. Fill
> this form and we will invite you to the GSoC program in Google's website.
> Also, please subscribe to the mentors list if you haven't done so yet. We
> will send required information for mentors to that list.
>
> If you have any question, don't hesitate to contact us at
> soc-adm...@gnome.org or any of us on IRC.
>
> Have a nice day,
> GSOC GNOME admins
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GSoC] Call for ideas

[Carlos Soriano]

Hello all,

As you may know GNOME was again accepted for GSoC!

Thanks to the mentors who've already listed GSoC project ideas! There is
still time to add more ideas and they are more than welcome.

If you are interested, please add your idea to the wiki
. If you are
interested but don't have any ideas, contact us at soc-adm...@gnome.org or
one of the admins  on
IRC and we will help you find some.

For mentors whose ideas are triaged, it's time to register with us. Fill
this form

and we will invite you to the GSoC program in Google's website. Also,
please subscribe to the mentors list
 if you haven't
done so yet. We will send required information for mentors to that list.

If you have any question, don't hesitate to contact us at
soc-adm...@gnome.org or any of us
 on IRC.

Have a nice day,
GSOC GNOME admins
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Projects moved, general comments, tips of the week, question of the week

[Carlos Soriano]

> I apologize, if I sounded inappropriate earlier.

No worries, it was fine. I probably wasn't clear in the past what people
need to do to discuss these priorities and it's a very valid question.

Cheers

Carlos Soriano
GNOME Board of Directors

On 28 February 2018 at 17:38, Milan Crha <mc...@redhat.com> wrote:

> On Wed, 2018-02-28 at 15:39 +0100, Carlos Soriano wrote:
> > Hope this was useful and clarified any doubt you might have, it
> > certainly took some time to write.
>
> Hi,
> thanks for the explanation. It was definitely useful for me. I agree
> it's not simple to evaluate the priority. The "once per two months" can
> change once everyone will start use the tool, but that's only another
> nitpick from my side.
>
> Again, thanks a lot for sharing all of that. I apologize, if I sounded
> inappropriate earlier.
> Thanks and bye,
> Milan
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Projects moved, general comments, tips of the week, question of the week

[Carlos Soriano]

t longer edit an issue or put a
task as completed. This could block the developer into working on something
for hours. Could forgot about what needed to be done once it's fixed.
- What are the solutions? Admins check the issue and mark it as non-spam
- How the dev performance was impacted? Blocking work on that issue, if
repeated, potentially be reason to be annoyed enough to stop using the
tool, since the tool is going against their willing. PD: that's why we
disabled Akismet in the past, we got requests and feedback about this.
- Is it a big impact in the whole GNOME that affects their workflow in a
considerate way? Up to some point, taking into account all, it's "minor"
but more than being pinged once every two months.
- Does it fit upstream vision?: Yes, it's just a bug in their spam
protection.

Now here it's missing the big picture, which is certainly not easy to write
it down. Also, keep in mind that the more items we add to the list, and the
more higher priority we make them, the more diluted our leverage is to make
them actually happen.

Hope this was useful and clarified any doubt you might have, it certainly
took some time to write.

> By the way, how does that
https://gitlab.com/gitlab-org/gitlab-ce/issues/43566 work? Once the
"High" section is done all left GNOME projects will be migrated to
GNOME's gitlab instance and bugzilla will be switched to read-only
mode, or?

The plan is to migrate already, our blockers were fixed in the past
already. And yeah, after mass migration BZ will be put into read-only mode.

Best,
Carlos Soriano

On 28 February 2018 at 14:16, Andre Klapper <ak...@gmx.net> wrote:

> On Wed, 2018-02-28 at 14:06 +0100, Milan Crha wrote:
> > But seriously, my main point is that not every developer follows issues
> > filled in GNOME infrastructure gitlab issue tracker, thus even it's a
> > public place, it doesn't reach the group of people whose the decision
> > will influence the most.
>
> What's the difference to "not everybody follows activity in Bugzilla /
> IRC / mailing lists" and how's that a new problem specific to GitLab?
>
> I'm afraid I still don't understand the problem.
>
> andre
> --
> Andre Klapper  |  ak...@gmx.net
> http://blogs.gnome.org/aklapper/
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Projects moved, general comments, tips of the week, question of the week

[Carlos Soriano]

Hey Milan,

This is what we do already... no? We discuss it in public and evaluate
what's important, then I try to take all this stuff into account, look at
the big picture, and come up with some specific list to GitLab upstream.

There is no subset of people in GNOME's GitLab issue tracker, you all can
comment there, that's why it's public :)

Cheers

On 28 February 2018 at 13:03, Milan Crha <mc...@redhat.com> wrote:

> On Fri, 2018-02-23 at 21:40 +0100, Carlos Soriano wrote:
> > If you have some issue or feature request that might impact GNOME as
> > a whole and you think it's important for GNOME create an issue in our
> > infra project and we can discuss if we should add it as priority for
> > GNOME.
>
> Hi,
> I'm wondering, would it be better to have the potential issues
> discussed more in public, like here, thus the GNOME
> community/developers can decide which issues are important to them and
> which not, instead of keeping the last word on a small subset of people
> in some group in the GNOME's GitLab issue tracker? I do not expect
> anyone periodically check whether any interesting topic wasn't added
> there and eventually rise his/her voice there. And as always, different
> people have different opinions, different priorities, different point
> of view, different...
> Thanks and bye,
> Milan
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's kill gnome-common!

[Carlos Soriano]

Thanks Bastien.

> Or better port to meson.

Yeah that sounds like a better task.

Carlos Soriano
GNOME Board of Directors

On 13 February 2018 at 10:20, Bastien Nocera <had...@hadess.net> wrote:

> On Tue, 2018-02-13 at 10:08 +0100, Carlos Soriano wrote:
> > Hi Michael,
> >
> > Could you give some context and explanation on this? I could take the
> > gnome-autoar, but need to know why this is wanted and the alternative
> > to gnome-common.
>
> When the wiki comes back:
> https://wiki.gnome.org/Projects/GnomeCommon/Migration
>
> Discussion dates back from May 2015.
>
> Or better port to meson.
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's kill gnome-common!

[Carlos Soriano]

Hi Michael,

Could you give some context and explanation on this? I could take the
gnome-autoar, but need to know why this is wanted and the alternative to
gnome-common.

Cheers

On 13 February 2018 at 02:08,  wrote:

> Hi,
>
> I want to remove gnome-common from our BuildStream projects, but a few
> modules are still depending on it: gcr, gnome-autoar, libnotify,
> adwaita-icon-theme, gnome-menus, and gsettings-desktop-schemas.
>
> If you help fix these sad modules, you'll earn the right to say that you
> helped fix these sad modules.
>
> Thanks,
>
> Michael
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list