FreeBSD Cert

[Aryeh Friedman]

On Sat, May 30, 2020 at 9:42 PM Ralf Mardorf via freebsd-questions <
freebsd-questions at freebsd.org> wrote:

> On Sat, 30 May 2020 23:03:59 +0000, Brandon helsley wrote:
> >So to find out the legality of licensing to port a program to freebsd
> >do all I have to do is contact that programs website. And then source
> >code is quite easy to obtain I see. It would just be on git hub right.
>
> Not necessarily on Microsoft's hosting service GitHub. There are
> SourceForge, GitLab a zillion other and some developers simply use
> their own homepage to provide the source code.
>
> >For the executable script and profiles and config files l, I guessing
> >the porters handbook is how you fashion those in working order?
>
> I don't know if the hanbook mentions the following, too. Often it's
> wiser to get in touch with upstream, to ask them to fix an issue, than
> to fix an issue by a FreeBSD port (or any other operating system's
> repository).
>

Depends on how active the upstream is and how critical the fix is.   For
example on the port I maintain the original developer (upstream) passed
away from complications of cancer in 2014 and thus there is no upstream,
yet since I use the port as a critical component in my daily work I have
kept it in good working order with patches on FreeBSD.   Now the question
is why do I continue to use devel/aegis instead of switching over to svn or
git?   Real simple aegis enforces a more robust development model then
either svn or git (non-working code is almost impossible to add to the
repo/baseline until you prove/make it work).  I also use devel/cook from
the same original developer for similar reasons over make (see "Recursive
Make Considered Harmful").

The aside on why I use aegis is to show even if a port has no upstream if
it still provides real value to the users of it you should still maintain
it and make the needed patches to keep it in good working order as the
FreeBSD base system evolves.


> Often just reporting a bug correctly is the best thing to do. Go to the
> issue tracker and describe an issue. What happens? What should happen
> instead? Post the output you get by a terminal, strace, gdb a log
> file... Describe the steps to reproduce the issue.
>

One way of gaining is to volunteer to be a pre-port commit tester.


>
> The developer probably will reply and give you pointers in helping
> troubleshooting. So you will learn a lot you might need the day you
> become a port maintainer. Maybe before maintaining a port, you will use
> your skills to help maintaining Wikis, so you would help FLOSS
> communities and get more skills yourself.
>

How does maintaining a wiki in and upon itself help any community?


> Now that you know the procedures, it makes more sense to read the
> FreeBSD handbooks and Wikis that are not necessarily related to
> FreeBSD only, on how to do things, such as maintaining a port, debugging
> or even how to do interleaved posting when replying to a mailing list
> thread. etc. and after that, if still necessary, to ask for help on a
> mailing list.
>

Just a general comment on the "no top posting" "rule" that FreeBSD has no
one else has such a rule and many mail clients do top posting by default
and make interleaving non-trivial (such OP's it appears).  Additionally
there is enough top posting being done on today's Internet that everyone
should be familiar with it and know how to read it in context.    So we
might want to recommend interleaving but it should not be some rule set in
stone that will get any newbie flamed for not using it, talk about one way
to turn people off to FreeBSD quickly.
-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org