Re: Outreachy Questions
Hi Saira,
did you considered my answers as helpful? Do you need further help?
I'm back from vac now and I'd be happy to guide you kindly into any
problem you might have (since we have now more official mentors please
always stick to the list if possible).
Kind regards
Andreas.
On Wed, May 29, 2019 at 11:38:39PM +0200, Andreas Tille wrote:
> Hi Saira,
>
> On Wed, May 29, 2019 at 04:06:46PM +0100, Saira Hussain wrote:
> > 1. I've seen in other projects in Gitlab, that are organised in subgroups. Debian-Med is a sub-group of Debian Salsa but then all the individual packages are under it. Wouldn't it make more sense to have sub-sub-groups? e.g. bioinformaticsTools, imagingTools, etc? If not, why is that? Is there another level or structure somewhere else? E.G. a CI/CD? If so, can you point me there so that I understand and learn more about it?
>
> We habe a flat structure for all Debian Med packages since there is no
> visible advantage to create sub-sub-groups. If we would invent
> sub-sub-groups it would always a question into what sub-sub-group a
> package should go. This question is easy to avoid by just having all
> packages in the same hierarchy.
>
> > 2. Tests. I know that's a big one but if someone can break it down for me it would be awesome. I am checking older packages, with existing tests to learn more about what's the best way to do it. Some of them, just have sanity checks (i.e. a help message is displayed when there's no argument), some include basic functionality and some are much more detailed. Which is a good level for a test definition to close one of the already existing/open bugs? How do I learn more about system testing? I can't seem to find anything good on bibliography, especially about package/system testing. Everything seems to be about Selenium/hipster-web-tests and blog articles :) Can I add some sample test files if I need int the package? E.g. fasta/sequence files etc. and if so, is there any size constraint?
>
> The tests usually depend from the knowledge and effort the developer who
> wrote the test and what possibilities the software itself leaves. For
> instance sometimes only primitive tests make sense in case of programs
> that might require a GUI. A rule of thumb would be: Just craft the test
> in a way you want to have a program that you want to use yourself is
> tested. Please also consider a test as an usage example at the same
> time.
>
> > Thanks for your time!
>
> You are welcome and I hope this is answering your questions
>
> Andreas.
>
>
> --
> http://fam-tille.de
>
>
--
http://fam-tille.de
Reply to: