Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.)

From: Mehmet Erol Sanliturk <m.e.sanliturk_at_gmail.com>
Date: Fri, 14 Nov 2014 04:06:12 -0800
On Fri, Nov 14, 2014 at 3:38 AM, Mark Saad <nonesuch_at_longcount.org> wrote:

>
>
> > On Nov 14, 2014, at 4:27 AM, Peter Pentchev <roam_at_ringlet.net> wrote:
> >
> >> On Thu, Nov 13, 2014 at 07:55:16PM -0800, Rui Paulo wrote:
> >>> On Nov 13, 2014, at 17:40, Luigi Rizzo <rizzo_at_iet.unipi.it> wrote:
> >>> But please nuke the current list -- it is completely inadequate
> >>> for the code-in candidates and misleading for whoever wants to
> >>> suggest new tasks. Again i am not saying that the projects
> >>> suggested there are not important, just belong somewhere else
> >>> e.g. gsoc.
> >>
>
> I have a few ideas for younger and or less experienced google code in
> people
>
> 1. Analyze the CD/USB  install process .
> Does the actual process match the guide and or general docs .
>
> 2. Analyze / comment on the automated install process "jumpstart ". Does
> the guide and general docs match the actual process .
>
> 3. Test the virtual machine images as vagrant box images , and create
> vagrant box images from the official vm images .
>
> 4. Create a script for the installer "bsd install" to use glabel to label
> gparts slices as /dev/label/$NAME
>
> 5. Test the ami images , again can the docs be improved are they accurate .
>
> The
>
> Now let me preface the docs tasks , by no means am I saying that the docs
> team has made lots of mistakes and their work needs to be rechecked . The
> tasks are small enough that most high school aged people could grasp the
> issue, with out any prior experience in BSD world . Rechecking the docs is
> always a good idea .
>
> They should allow the code in members to make some good contributions ;
> and maybe even some good improvements .
>
> >> I refrained from voicing my opinion while the call for help was going
> >> on, but I completely agree that the target age of this Google initiative
> >> is inadequate to FreeBSD.  The target population is 13 years to 17 years
> >> old and I cannot even imagine a 13 year old knowing what FreeBSD is.
> >
> > ...and yet there was pat_at_ becoming a ports committer at the age of 16
> > and chris_at_ becoming a docs committer at the age of 14 :)  I think hmp_at_,
> > alepulver_at_, issyl0_at_ and jmallett_at_ were pretty young when they joined,
> > too.
> >
> > Just an observation, I know that one or two isolated cases do not prove
> > a point :)
> >
> > G'luck,
> > Peter
> >
> > --
> > Peter Pentchev  roam_at_ringlet.net roam_at_FreeBSD.org p.penchev_at_storpool.com
> > PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
> > Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
>
> Mark saad | mark.saad_at_longcount.org
>



One important program class for the less experienced people ( as users and
programmers ) would be the following :


(1)


For the command line operating system programs , mostly it is necessary to
give parameters on command line .

For example :

$ ifconfig

displays the NIC information .

To apply some operations , it is necessary to give parameters :

$ ifconfig -... ... .... ... ...

To give these parameters even by using man pages are very difficult even
for the experienced users .

Task :

By using for selected OS programs , write a routine to the following :

When a user enters only program name , display a form to get parameters for
execution ( this requires some changes to programs doing operations just by
giving its name by specifying a parameter for such cases ) in such a way
that get parameters in an order by supplying form parts with respect to
previously given parameter values , i.e. , do not present all of the items
, let the user some values , and smash the user that such parameters are
given incorrectly .

Manual pages may be used , but sometimes it is necessary to read the source
code of the program to isolate error cases and dependencies .


(2)

Some programs may use many parameters and every time giving them as command
line parameters or by filling forms may not be a very convenient way .

By using Expat libraries ( or any other suitable library ) , write a
routine for a selected command line program to enter parameters from an XML
file with the following structure :


$ program_name  _at_XML_parameters file_name


Such a result may be obtained by using scripts for executing the programs
with specific parameters , but using the above structure may be more
convenient usage and they may be used in testing also more easily because
some files may be output of other programs .


(3)

Many OS programs are given their outputs in an arbitrary text form .
For automated tests , or input to other programs , these outputs are very
difficult to use .

For selected OS programs , give all of the output in XML ( or any other
selected structured form ) .which
they can be processed by using Expat library .

To process these outputs , also write a routine by using Expat library to
load it into a tree .

Thank you very much .


Mehmet Erol Sanliturk
Received on Fri Nov 14 2014 - 11:06:13 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:54 UTC