Hello Mattia,

Thanks for the reply.

I have subscribed to the mailing lists diffoscope and reproducible builds.

After going through the bug log again. I decided I want to work on this
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833697 issue but when I
read the comments , I noticed Chris Lamb says

I will look into
this and come up with something cleaner.

Does this mean he is working on it?

If so then I can work on this


On Fri, Sep 30, 2016 at 1:20 AM, Mattia Rizzolo <mat...@debian.org> wrote:

> On Tue, Sep 27, 2016 at 10:15:54PM +0300, joannah nanjekye wrote:
> > Dear Mattia,
> Hi Joannah,
> sorry for the kinda late reply (I know people tends to like quick
> turnarounds for these subjects).
> Please take care of subscribing to this mailing list.  I expect that
> once you officially apply you will be (but you can avoid it for now, if
> you want to).
> > I like actively being part of ambitious missions and in my view Debian is
> > spot on through the projects currently being worked on and maintained.
> The
> > projects that Debian is undertaking during the internship I believe will
> > greatly shape my career and knowledge in software development.
> Kind words, just I'm not so confident about the "greatly shape my
> career" bit, but for sure some employers appreciate applicants with a
> past of contributions to free software projects.
> > After looking through the skill set needed , I also saw a good fit for me
> > here save for a few other skills I may need to learn through the
> > application process especially getting comfortable with packaging. I will
> > endeavor I polish up before the deadline on some of them.
> I have some troubles understanding what you mean here, especially the
> first sentence.
> Anyway don't care too much about the effort of Debian packaging, we have
> a lot of experts around, and the work there is pretty much done.
> > I was also drawn to Debian pretty much due to the community. It is an
> > engaging and easily accessible one and to me this is very important. I
> was
> > in touch with people in this community even people I decided to apply for
> > outreachy who freely shared what they knew with me. I almost got tempted
> to
> > mention names but I wont:). A big thanks even in their anonymity.
> *These* are very kind words now!  I know a lot of people have/had to
> fight a lot to enter enough within the Debian community to feel part of
> it.  Some areas of Debian used to (still are?) hard to get it.
> > I have an idea on concurrent programming much using .net where I used to
> > write banking programs that would run simultaneously in windows services.
> > Jobs like unattended running of end of day processes for applications
> that
> > ran on top of core banking, automated end of day and bank statement
> > transmission through sending transaction files to utility companies on a
> > daily basis. These programs ran at the same time and simultaneously and
> > were self starting.
> This is nice, but I fear our case is quite different; we would like
> diffoscope to e.g. walk directories in parallel, and down that road.
> > I would like to begin by working on this
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814057 bug.
> That bug is part of a bigger picture where diffoscope would be able to
> hide difference (or even better: don't even compute them if not needed)
> as requested by the user.  See this wiki page for more information:
> https://wiki.debian.org/ReproducibleBuilds/HideProfilesSpecification
> Hence I suggest against trying to start with such a thing, but rather
> try to fix a simpler thing, like a crash, or tests failures.  Goal of
> the first phase should be to get accustomed to the codebase, tackling
> such bug would be way over that goal.
> > You can walk
> > me through how I can own a bug so that I don't work on the same bug with
> > some one else unknowingly
> https://www.debian.org/Bugs/Developer#owner
> https://www.debian.org/Bugs/server-control#owner
> > links to the general work flow guidelines of
> > submitting a patch the Debian way if there are any things I need to note.
> The usual way is to send a patch as an attachment to a bug report.
> Though considering that you'd be contributing code to a "native"
> package, and that that package is maintained in git, the preferred form
> of sending patches would be to attach them as produced by
>     git format-patch
> or by using
>     git send-email
> (but this one requires a bit of set up), as they are easier to
> incorporate.
> --
> regards,
>                         Mattia Rizzolo
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
> more about me:  https://mapreri.org                             : :'  :
> Launchpad user: https://launchpad.net/~mapreri                  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Joannah Nanjekye
F : Nanjekye Captain Joannah
S : joannah.nanjekye
T : @captainjoannah
SO : joannah

*"You think you know when you learn, are more sure when you can write, even
more when you can teach, but certain when you can program." Alan J. Perlis*
Reproducible-builds mailing list

Reply via email to