Re: new contributor

[Kai via meld-list]

On Sat, 15 Aug 2020 at 06:05, Vasily Galkin  wrote:

> Logically, after merging 61 to master the your MR should become green to.
>
> However, technically I'm not sure that gitlab reruns CI the merge-target
> branch changes.
>

Sadly, it doesn't (or at least it's not configured to do so... not sure
which). However, both MRs have been merged now, so we're all good! Thanks
to you both.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: new contributor

[Adam Antium via meld-list]

Ah got it, it wants the imports in alphabetical order haha.

Ok thanks!

Regards,
Adam

On Fri, Aug 14, 2020 at 9:05 PM Vasily Galkin  wrote:

> > I've submitted the merge-request, the fix seems to work as expected,
> however I noticed that the pipeline failed, even though it seems to be the
> same code as the forked repo. Is there some setting up in gitlab I needed
> to do for that to work?
> >
> > Regards,Adam
>
> Looking into https://gitlab.gnome.org/adam0antium/meld/-/jobs/855727
> ```meld/task.py:144:1
> :
> I001 isort found an import in the wrong position```
> I think that it is caused by some auto-updating of linter code or linter
> rules.
>
> Currently meld's CI uses "auto-updating" linter, so sometimes new failures
> appears without chnaging code, but after just re-running check later.
>
> In this case it seems that linter introduces sorting check for non-top
> imports.
>
> Just cretaed PR with a trivial fix
> https://gitlab.gnome.org/GNOME/meld/-/merge_requests/61
>
> Logically, after merging 61 to master the your MR should become green to.
>
> However, technically I'm not sure that gitlab reruns CI the merge-target
> branch changes.
> --
> Best regards, Vasily
>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: new contributor

[Vasily Galkin via meld-list]

> I've submitted the merge-request, the fix seems to work as expected, however 
> I noticed that the pipeline failed, even though it seems to be the same code 
> as the forked repo. Is there some setting up in gitlab I needed to do for 
> that to work?
> 
> Regards,Adam

Looking into https://gitlab.gnome.org/adam0antium/meld/-/jobs/855727
```meld/task.py:144:1: I001 isort found an import in the wrong position```
I think that it is caused by some auto-updating of linter code or linter rules. 

Currently meld's CI uses "auto-updating" linter, so sometimes new failures 
appears without chnaging code, but after just re-running check later.

In this case it seems that linter introduces sorting check for non-top imports.

Just cretaed PR with a trivial fix 
https://gitlab.gnome.org/GNOME/meld/-/merge_requests/61

Logically, after merging 61 to master the your MR should become green to.

However, technically I'm not sure that gitlab reruns CI the merge-target branch 
changes.
--
Best regards, Vasily
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: new contributor

[Adam Antium via meld-list]

I've submitted the merge-request, the fix seems to work as expected,
however I noticed that the pipeline failed, even though it seems to be the
same code as the forked repo. Is there some setting up in gitlab I needed
to do for that to work?

Regards,
Adam

On Fri, Aug 14, 2020 at 1:30 AM Kai  wrote:

> On Fri, 14 Aug 2020 at 06:11, Adam Antium via meld-list <
> meld-list@gnome.org> wrote:
>
>> I have a simple fix for issue #354, I posted a comment on the issue page.
>>
>> Are there some basic guidelines for testing code changes? How much
>> checking should I be doing of, for example, path formats and stuff like
>> that?
>>
>
> For cases like this issue where there's not really much risk of unexpected
> interactions with other functionality, I wouldn't worry too much about it.
> Specifically in your case here, I'd probably just... check that
> os.startfile does the right thing for folders, text files and "other" files
> (which are the three clear cases that that code needs to handle) and that's
> enough.
>
> Also I am a bit unsure about the cleanest way to do a code submission
>> after a fix, should I check out a whole new clean source to make the
>> changes in to avoid polluting it with random stuff?
>>
>
> While the instructions are based around GNOME tools, there's a guide at
> https://wiki.gnome.org/Newcomers/SubmitContribution that covers the basic
> process. In short, make a fork on GNOME gitlab (where you already have an
> account), clone that locally, make your changes, push a branch with your
> change and create a merge request.
>
> When you create the MR you can see what changes you're proposing, so
> that's a good time to double-check that there's nothing extraneous there.
> If you have issues or questions, I'm happy to try to help out. Also don't
> worry if the MR isn't perfect! It's all easy enough to change after the
> fact.
>
> cheers,
> Kai
>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: new contributor

[Adam Antium via meld-list]

Great, thanks for your help, I will do that.

Regards,
Adam

On Fri, Aug 14, 2020 at 1:30 AM Kai  wrote:

> On Fri, 14 Aug 2020 at 06:11, Adam Antium via meld-list <
> meld-list@gnome.org> wrote:
>
>> I have a simple fix for issue #354, I posted a comment on the issue page.
>>
>> Are there some basic guidelines for testing code changes? How much
>> checking should I be doing of, for example, path formats and stuff like
>> that?
>>
>
> For cases like this issue where there's not really much risk of unexpected
> interactions with other functionality, I wouldn't worry too much about it.
> Specifically in your case here, I'd probably just... check that
> os.startfile does the right thing for folders, text files and "other" files
> (which are the three clear cases that that code needs to handle) and that's
> enough.
>
> Also I am a bit unsure about the cleanest way to do a code submission
>> after a fix, should I check out a whole new clean source to make the
>> changes in to avoid polluting it with random stuff?
>>
>
> While the instructions are based around GNOME tools, there's a guide at
> https://wiki.gnome.org/Newcomers/SubmitContribution that covers the basic
> process. In short, make a fork on GNOME gitlab (where you already have an
> account), clone that locally, make your changes, push a branch with your
> change and create a merge request.
>
> When you create the MR you can see what changes you're proposing, so
> that's a good time to double-check that there's nothing extraneous there.
> If you have issues or questions, I'm happy to try to help out. Also don't
> worry if the MR isn't perfect! It's all easy enough to change after the
> fact.
>
> cheers,
> Kai
>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: new contributor

[Kai via meld-list]

On Fri, 14 Aug 2020 at 06:11, Adam Antium via meld-list 
wrote:

> I have a simple fix for issue #354, I posted a comment on the issue page.
>
> Are there some basic guidelines for testing code changes? How much
> checking should I be doing of, for example, path formats and stuff like
> that?
>

For cases like this issue where there's not really much risk of unexpected
interactions with other functionality, I wouldn't worry too much about it.
Specifically in your case here, I'd probably just... check that
os.startfile does the right thing for folders, text files and "other" files
(which are the three clear cases that that code needs to handle) and that's
enough.

Also I am a bit unsure about the cleanest way to do a code submission after
> a fix, should I check out a whole new clean source to make the changes in
> to avoid polluting it with random stuff?
>

While the instructions are based around GNOME tools, there's a guide at
https://wiki.gnome.org/Newcomers/SubmitContribution that covers the basic
process. In short, make a fork on GNOME gitlab (where you already have an
account), clone that locally, make your changes, push a branch with your
change and create a merge request.

When you create the MR you can see what changes you're proposing, so that's
a good time to double-check that there's nothing extraneous there. If you
have issues or questions, I'm happy to try to help out. Also don't worry if
the MR isn't perfect! It's all easy enough to change after the fact.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: new contributor

[Adam Antium via meld-list]

Hey,

I have a simple fix for issue #354, I posted a comment on the issue page.

Are there some basic guidelines for testing code changes? How much checking
should I be doing of, for example, path formats and stuff like that?

Also I am a bit unsure about the cleanest way to do a code submission after
a fix, should I check out a whole new clean source to make the changes in
to avoid polluting it with random stuff?

Regards,
Adam

On Wed, Aug 5, 2020 at 4:10 PM Adam Antium  wrote:

> Hi Vasily,
>
> Great instructions, thanks a lot! It's all working, I will start playing
> around with the code and check out some of the open issues.
>
> Regards,
> Adam
>
> On Wed, Aug 5, 2020 at 2:54 PM Vasily Galkin  wrote:
>
>> Hello!
>> In short: to get dependencies install Msys2 on windows and install its
>> packages:
>>
>> pacman -S mingw-w64-i686-python3-cx_Freeze mingw-w64-i686-python3-gobject
>> mingw-w64-i686-python3-pytest mingw-w64-i686-gtksourceview4
>> mingw-w64-i686-gsettings-desktop-schemas glib2-devel intltool
>>
>> In more deatils: the best-tested way to create meld build environment on
>> windows is creating environment similar to the one created by the gitlab CI
>> system.
>> It is defined in
>> https://gitlab.gnome.org/GNOME/meld/-/blob/master/.gitlab-ci.yml
>>
>> Meld works & builds fine not only on mingw-w64 32bit, but also on
>> mingw-w64 64bit.
>> Such builds are already performed in gitlab CI, but not published.
>> So the .gitlab-ci.yml is a bit non-linear since it describes both 64-bit
>> and 32-bit builds.
>>
>> The desctiption below is interactive-usage adaptation of the
>> .gitlab-ci.yml
>>
>> For beginning developing meld on windows these are typical steps (for
>> 32bit; 64-bit is similar):
>> * Install msys2 from https://www.msys2.org/
>> * update it to latest versions of all components: pacman -S --refresh
>> --sysupgrade
>> * install dependencies for developing meld: pacman -S
>> mingw-w64-i686-python3-gobject mingw-w64-i686-python3-pytest
>> mingw-w64-i686-gtksourceview4 mingw-w64-i686-gsettings-desktop-schemas
>> glib2-devel intltool git
>> ** note: there is meld package in msys2 repos. It is fine, but if you
>> planning to develop meld itself  - do NOT install (or uninstall if already
>> installed) mingw-w64-i686-meld3 package, otherwise sometimes files can be
>> used inconsistently (some from dev. copy and some from that package)
>> ** you may also want to install mingw-w64-x86_64-gedit - it uses
>> gtksourceview, so for some issues sometimes its useful to compare meld &
>> gedit behaviours.
>>
>> * Simplest meld execution:
>> * open mingw32 shell
>> * clone meld repo and cd to its root
>> * from there run: bin/meld
>> ** meld should open its window and running fine without any errors. If it
>> failed for some reason - the later steps would not work too, so in such
>> case stop here for investigation
>> ** runing this way is the fastest way to develop and 80% of issues
>> not-related-to freezing and system specifics can be developed this way
>> ** to test this mode integration with external programs lke TortoiseSVN
>> the similar run-meld.cmd can be helpful:
>>D:\apps\msys2\mingw64\bin\python3.exe D:\apps\meld-git\bin\meld %*
>>
>> * For building msi installer run:
>> ** glib-compile-schemas data
>> ** python3 setup_win32.py bdist_msi
>> *** it can be quite slow, 1-5 minutes preparing + 1-5 minutes to install
>> msi (upgrading msi is a LOT slower that first install due to uninstalling
>> lots of adwaita icons)
>>
>> * For faster build that produces result folder similar to installation
>> result without actually slow-packing+slow-unpacking msi, run:
>> ** python3 setup_win32.py install --prefix $(pwd)/some-folder >
>> install-output
>> ** this is very similar to actual msi install, the known differences are:
>> folder path (with/without spaces), start menu icon, and (nearly-unused)
>> registry values
>> ** so 99% of issues can be developed this way
>> ** there is a known behaviour difference on runing Meld.exe from msys2
>> shell (with MSYSTEM variable) and from any shell without MSYSTEM variable,
>> like explorer. Some changes require testing both cases.
>>
>> melds' gitlab CI also has some python lint (some coding style etc)
>> automatic check.
>> I think it can be configured to run locally on msys2, but actually I
>> never did it (was looking to lint failures only after pushing to my fork...)
>> --
>> Regards,
>> Vasily
>>
>> > Hey,Thanks to Heikki for his suggestion.
>> > I'm currently trying to run a windows build, however it's turning out
>> to be a bit complicated setting up the requirements, is there a preferred
>> method for installing all of that? And a preferred source for all of the
>> packages?
>> > Regards,
>> > Adam
>> >
>> > On Tue, Aug 4, 2020 at 7:17 PM Heikki Ketoharju <
>> heikki.ketoha...@iki.fi> wrote:
>> >
>> >> Hello!
>> >>
>> >> I wondered the same thing two years ago and it turned out there's a
>> "Newcomers" label in Gitlab issues. I picked one from 

Re: new contributor

[Adam Antium via meld-list]

Hi Vasily,

Great instructions, thanks a lot! It's all working, I will start playing
around with the code and check out some of the open issues.

Regards,
Adam

On Wed, Aug 5, 2020 at 2:54 PM Vasily Galkin  wrote:

> Hello!
> In short: to get dependencies install Msys2 on windows and install its
> packages:
>
> pacman -S mingw-w64-i686-python3-cx_Freeze mingw-w64-i686-python3-gobject
> mingw-w64-i686-python3-pytest mingw-w64-i686-gtksourceview4
> mingw-w64-i686-gsettings-desktop-schemas glib2-devel intltool
>
> In more deatils: the best-tested way to create meld build environment on
> windows is creating environment similar to the one created by the gitlab CI
> system.
> It is defined in
> https://gitlab.gnome.org/GNOME/meld/-/blob/master/.gitlab-ci.yml
>
> Meld works & builds fine not only on mingw-w64 32bit, but also on
> mingw-w64 64bit.
> Such builds are already performed in gitlab CI, but not published.
> So the .gitlab-ci.yml is a bit non-linear since it describes both 64-bit
> and 32-bit builds.
>
> The desctiption below is interactive-usage adaptation of the
> .gitlab-ci.yml
>
> For beginning developing meld on windows these are typical steps (for
> 32bit; 64-bit is similar):
> * Install msys2 from https://www.msys2.org/
> * update it to latest versions of all components: pacman -S --refresh
> --sysupgrade
> * install dependencies for developing meld: pacman -S
> mingw-w64-i686-python3-gobject mingw-w64-i686-python3-pytest
> mingw-w64-i686-gtksourceview4 mingw-w64-i686-gsettings-desktop-schemas
> glib2-devel intltool git
> ** note: there is meld package in msys2 repos. It is fine, but if you
> planning to develop meld itself  - do NOT install (or uninstall if already
> installed) mingw-w64-i686-meld3 package, otherwise sometimes files can be
> used inconsistently (some from dev. copy and some from that package)
> ** you may also want to install mingw-w64-x86_64-gedit - it uses
> gtksourceview, so for some issues sometimes its useful to compare meld &
> gedit behaviours.
>
> * Simplest meld execution:
> * open mingw32 shell
> * clone meld repo and cd to its root
> * from there run: bin/meld
> ** meld should open its window and running fine without any errors. If it
> failed for some reason - the later steps would not work too, so in such
> case stop here for investigation
> ** runing this way is the fastest way to develop and 80% of issues
> not-related-to freezing and system specifics can be developed this way
> ** to test this mode integration with external programs lke TortoiseSVN
> the similar run-meld.cmd can be helpful:
>D:\apps\msys2\mingw64\bin\python3.exe D:\apps\meld-git\bin\meld %*
>
> * For building msi installer run:
> ** glib-compile-schemas data
> ** python3 setup_win32.py bdist_msi
> *** it can be quite slow, 1-5 minutes preparing + 1-5 minutes to install
> msi (upgrading msi is a LOT slower that first install due to uninstalling
> lots of adwaita icons)
>
> * For faster build that produces result folder similar to installation
> result without actually slow-packing+slow-unpacking msi, run:
> ** python3 setup_win32.py install --prefix $(pwd)/some-folder >
> install-output
> ** this is very similar to actual msi install, the known differences are:
> folder path (with/without spaces), start menu icon, and (nearly-unused)
> registry values
> ** so 99% of issues can be developed this way
> ** there is a known behaviour difference on runing Meld.exe from msys2
> shell (with MSYSTEM variable) and from any shell without MSYSTEM variable,
> like explorer. Some changes require testing both cases.
>
> melds' gitlab CI also has some python lint (some coding style etc)
> automatic check.
> I think it can be configured to run locally on msys2, but actually I never
> did it (was looking to lint failures only after pushing to my fork...)
> --
> Regards,
> Vasily
>
> > Hey,Thanks to Heikki for his suggestion.
> > I'm currently trying to run a windows build, however it's turning out to
> be a bit complicated setting up the requirements, is there a preferred
> method for installing all of that? And a preferred source for all of the
> packages?
> > Regards,
> > Adam
> >
> > On Tue, Aug 4, 2020 at 7:17 PM Heikki Ketoharju 
> wrote:
> >
> >> Hello!
> >>
> >> I wondered the same thing two years ago and it turned out there's a
> "Newcomers" label in Gitlab issues. I picked one from there, solved it and
> it was fun! Also it felt good to see my commit approved later on.
> >>
> >> Here you can find the labelled issues. I warmly recommend!
> >>
> >>
> https://gitlab.gnome.org/GNOME/meld/-/issues?label_name%5B%5D=4.+Newcomers
> >>
> >> kind regards,
> >> Heikki Ketoharju
> >> (another newcomer, and currently just a passive contributor)
> >>
> >> On Tue, 4 Aug 2020 at 18:16, Adam Antium via meld-list <
> meld-list@gnome.org> wrote:
> >>
> >>> Hey,
> >>> I'm interested in making some contributions to the project.
> >>>
> >>> I don't have any experience with open source work but I like Meld and
> I'd 

Re: new contributor

[Vasily Galkin via meld-list]

Hello!
In short: to get dependencies install Msys2 on windows and install its packages:

pacman -S mingw-w64-i686-python3-cx_Freeze mingw-w64-i686-python3-gobject 
mingw-w64-i686-python3-pytest mingw-w64-i686-gtksourceview4 
mingw-w64-i686-gsettings-desktop-schemas glib2-devel intltool

In more deatils: the best-tested way to create meld build environment on 
windows is creating environment similar to the one created by the gitlab CI 
system.
It is defined in 
https://gitlab.gnome.org/GNOME/meld/-/blob/master/.gitlab-ci.yml

Meld works & builds fine not only on mingw-w64 32bit, but also on mingw-w64 
64bit.
Such builds are already performed in gitlab CI, but not published.
So the .gitlab-ci.yml is a bit non-linear since it describes both 64-bit and 
32-bit builds.

The desctiption below is interactive-usage adaptation of the  .gitlab-ci.yml

For beginning developing meld on windows these are typical steps (for 32bit; 
64-bit is similar):
* Install msys2 from https://www.msys2.org/
* update it to latest versions of all components: pacman -S --refresh 
--sysupgrade
* install dependencies for developing meld: pacman -S 
mingw-w64-i686-python3-gobject mingw-w64-i686-python3-pytest 
mingw-w64-i686-gtksourceview4 mingw-w64-i686-gsettings-desktop-schemas 
glib2-devel intltool git
** note: there is meld package in msys2 repos. It is fine, but if you planning 
to develop meld itself  - do NOT install (or uninstall if already installed) 
mingw-w64-i686-meld3 package, otherwise sometimes files can be used 
inconsistently (some from dev. copy and some from that package)
** you may also want to install mingw-w64-x86_64-gedit - it uses gtksourceview, 
so for some issues sometimes its useful to compare meld & gedit behaviours.

* Simplest meld execution:
* open mingw32 shell
* clone meld repo and cd to its root
* from there run: bin/meld
** meld should open its window and running fine without any errors. If it 
failed for some reason - the later steps would not work too, so in such case 
stop here for investigation
** runing this way is the fastest way to develop and 80% of issues 
not-related-to freezing and system specifics can be developed this way
** to test this mode integration with external programs lke TortoiseSVN the 
similar run-meld.cmd can be helpful:
   D:\apps\msys2\mingw64\bin\python3.exe D:\apps\meld-git\bin\meld %*

* For building msi installer run:
** glib-compile-schemas data
** python3 setup_win32.py bdist_msi
*** it can be quite slow, 1-5 minutes preparing + 1-5 minutes to install msi 
(upgrading msi is a LOT slower that first install due to uninstalling lots of 
adwaita icons)

* For faster build that produces result folder similar to installation result 
without actually slow-packing+slow-unpacking msi, run:
** python3 setup_win32.py install --prefix $(pwd)/some-folder > install-output
** this is very similar to actual msi install, the known differences are: 
folder path (with/without spaces), start menu icon, and (nearly-unused) 
registry values
** so 99% of issues can be developed this way
** there is a known behaviour difference on runing Meld.exe from msys2 shell 
(with MSYSTEM variable) and from any shell without MSYSTEM variable, like 
explorer. Some changes require testing both cases.

melds' gitlab CI also has some python lint (some coding style etc) automatic 
check.
I think it can be configured to run locally on msys2, but actually I never did 
it (was looking to lint failures only after pushing to my fork...)
--
Regards,
Vasily

> Hey,Thanks to Heikki for his suggestion.
> I'm currently trying to run a windows build, however it's turning out to be a 
> bit complicated setting up the requirements, is there a preferred method for 
> installing all of that? And a preferred source for all of the packages?
> Regards,
> Adam
> 
> On Tue, Aug 4, 2020 at 7:17 PM Heikki Ketoharju  
> wrote:
> 
>> Hello!
>>
>> I wondered the same thing two years ago and it turned out there's a 
>> "Newcomers" label in Gitlab issues. I picked one from there, solved it and 
>> it was fun! Also it felt good to see my commit approved later on.
>>
>> Here you can find the labelled issues. I warmly recommend!
>>
>> https://gitlab.gnome.org/GNOME/meld/-/issues?label_name%5B%5D=4.+Newcomers
>>
>> kind regards,
>> Heikki Ketoharju
>> (another newcomer, and currently just a passive contributor)
>>
>> On Tue, 4 Aug 2020 at 18:16, Adam Antium via meld-list  
>> wrote:
>>
>>> Hey,
>>> I'm interested in making some contributions to the project.
>>>
>>> I don't have any experience with open source work but I like Meld and I'd 
>>> like to help, any suggestions on where to start?
>>>
>>> Regards,
>>> Adam
>>>
>>> ___
>>>
>>> meld-list mailing list
>>>
>>> meld-list@gnome.org
>>>
>>> https://mail.gnome.org/mailman/listinfo/meld-list
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: new contributor

[Adam Antium via meld-list]

Hey,
Thanks to Heikki for his suggestion.
I'm currently trying to run a windows build, however it's turning out to be
a bit complicated setting up the requirements, is there a preferred method
for installing all of that? And a preferred source for all of the packages?
Regards,
Adam

On Tue, Aug 4, 2020 at 7:17 PM Heikki Ketoharju 
wrote:

> Hello!
>
> I wondered the same thing two years ago and it turned out there's a
> "Newcomers" label in Gitlab issues. I picked one from there, solved it and
> it was fun! Also it felt good to see my commit approved later on.
>
> Here you can find the labelled issues. I warmly recommend!
> https://gitlab.gnome.org/GNOME/meld/-/issues?label_name%5B%5D=4.+Newcomers
>
> kind regards,
> Heikki Ketoharju
> (another newcomer, and currently just a passive contributor)
>
> On Tue, 4 Aug 2020 at 18:16, Adam Antium via meld-list <
> meld-list@gnome.org> wrote:
>
>> Hey,
>>
>> I'm interested in making some contributions to the project.
>>
>> I don't have any experience with open source work but I like Meld and I'd
>> like to help, any suggestions on where to start?
>>
>> Regards,
>> Adam
>> ___
>> meld-list mailing list
>> meld-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/meld-list
>>
>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: new contributor

[Heikki Ketoharju]

Hello!

I wondered the same thing two years ago and it turned out there's a
"Newcomers" label in Gitlab issues. I picked one from there, solved it and
it was fun! Also it felt good to see my commit approved later on.

Here you can find the labelled issues. I warmly recommend!
https://gitlab.gnome.org/GNOME/meld/-/issues?label_name%5B%5D=4.+Newcomers

kind regards,
Heikki Ketoharju
(another newcomer, and currently just a passive contributor)

On Tue, 4 Aug 2020 at 18:16, Adam Antium via meld-list 
wrote:

> Hey,
>
> I'm interested in making some contributions to the project.
>
> I don't have any experience with open source work but I like Meld and I'd
> like to help, any suggestions on where to start?
>
> Regards,
> Adam
> ___
> meld-list mailing list
> meld-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/meld-list
>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list