Re: Outreachy current

---- On Sun, 17 Mar 2019 08:09:51 +0000 Andreas Tille <andreas@an3as.eu> wrote ----

On Sat, Mar 16, 2019 at 10:51:57PM +0000, Saira Hussain wrote:
> > OK, seems to be close enough for non-delayed communication. ;-)
>
> Awesome!

:-)

> That's is very useful indeed. The problem I have till this day with the Debian documentation is that albeit very detailed
> it's vast!! I never know where to search (and yes I am starting with Google) but it seems there's always a more recent/updated/better
> version somewhere, where I didn't look.

I fully agree with you that it is really hard to assemble the right
pieces of documentation. I'm absolutely not proud about the
documentation we have and agree that its a challenge to fight the way
through. Sorry for that.

Are there any efforts toward that? That could be a nice outreachy project, to create a better landing page

(and search engine) for all the Debian documentation.

> Oh right. When we did dev work before for some Uni projects we were always creating
> an extra branched that was automatically deleted when the merged was performed (and squashed).

I'm afraid something went wrong with the merge request. I didn't got
any information about a merge request but rather a new branch right in
the glam2 repository. I've subscribed the commit list (for historical
reasons - probably no modern way to deal with Gitlab) and got these
mails:

Oh I see. That may be because I first pushed the branch without any commits (and I added the commits a couple of hours

later when I realised that)! Ups.

https://alioth-lists.debian.net/pipermail/debian-med-commit/2019-March/090936.html
https://alioth-lists.debian.net/pipermail/debian-med-commit/2019-March/090937.html

Since you expected the branch to be deleted after merging I did so now.

> I suppose your proposal sounds good. Is there any standard that you're following or personal
> experience?

Just commit to master. That's fine. Usually our repositories have three
branches

Oh right, that sounds great!

master: upstream + debian/ packaging dir
upstream: upstream source as found in imported tarballs
pristine-tar: metainformation to recreate upstream tarball

This is in line with the git-buildpackage layout (see also Debian Med
Group policy[1])

> > I found out that your second command line was lacking the alphabet
> > option (which I found out quickly by running run-unit-test on my local
> > system after sneaking a "set -x" in). The program runs if I set 'p' for
> > proteins as alphabet - please confirm that this is correct.
> >
> Yes, indeed forgot to add this! Thanks :)

You are welcome. I hope 'p' is correct (and not 'n').

It is fine indeed (actually for sanity check it works for both).

> Thanks for quick help and ideas

You are welcome. I try to be quick in general to keep your motivation
high. :-)

I've just uploaded your changes which means you now have a first Debian
archive with your name in the archive and fixed your first bug.
Congratulations. :-)

Oh that's great! I read on some other documentation that you achieve this through the --author tag?

So is author me in that case?

Kind regards

Andreas.

PS: I've checked your mails in the web archive where these are looking
nicely formatted. However, I'm working with mutt which does only text
mode and there your mails are looking quite strangely formatted. In
case your mail client (probably web based) enables sending plain text
mails this would be more convenient.

Unfortunately zoho doesn't have such an option (my other email client did). It formats by default

in UTF-8 and supports 'inline HTML' but that's it. Now there's an option called 'clear formatting'

that I just chose after selecting all the text. Let me know if it looks different now.

A last question. I saw that you send very quickly different commits and you saw that you had to

rename my file to unit-test etc etc. Could you talk me through your process and workflow? Do you do

everything from the command line? Or do you get the email notification for my commit? Which tools

or commands are you using? e.g. tree or git diff to see differences or ...? :) I would like to learn the whole

though process as for me that's a very important step that I am missing (and I believe most people when

going from the knowledge of tools or programming or a proccess to getting a more insiders experience!)

Thanks again,

[1] https://med-team.pages.debian.net/policy/#common-git-repository-structures

--
http://fam-tille.de