---- On Sun, 17 Mar 2019 08:09:51 +0000 Andreas Tille <[email protected]> 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, S. [1] https://med-team.pages.debian.net/policy/#common-git-repository-structures -- http://fam-tille.de
