[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [GSoC] Rewriting tasks.py to exclusively use UDD

Hi Akshita,

On Sat, Jun 06, 2015 at 06:58:47PM +0530, Akshita Jha wrote:
> Hi,
> I have written the pseudo code for blendstasktools.py to use UDD. I have
> also started rewriting the actual code for blendstasktools.py.


> Should I
> keep committing/pushing this partially written code to the repo ? Or is it
> better to complete rewriting the entire module and then commit the new file
> ?

Any commit to the master branch of the remote repository will be
automatically pulled by a cron job on blends.debian.{org,net} so we need
to make sure that we will not break the production system.  Since I
would prefer to check and test your current work we have two options:
You create a new branch (gsoc, udd, whateveryouwant) or you choose a
temporary new name.  WHen I started rewriting bugs.py I ave choosen
bugs_udd.py.  The advantage of the later method is that you can test
both in parallel on the production systems if you also use a different
output directory as long as we are in development (.../tasks_udd or so)

If you consider the later as an advantage yourself than lets do it this
way.  Otherwise you might like to convince me about a different branch
if you have some good reasons. :-)

> > Yes, this can be done (while the direct use of the config files in the
> > tasks pages creation would not really harm since it is in the same Git -
> > I was mainly concerned about the other Blends data).
> I have kept this in mind and am using the ReadConfig() directly for reading
> the <blend-name>.conf files.

Never change a running system. ;-)

> > There is a UDD gatherer that fetches the data from Git/SVN and moves the
> > (largest part of) the data into UDD.  For a start we should use the data
> > available in this table, yes.
> So, FetchTaskFiles() will not be needed anymore. This function basically
> checkouts svn or git repo, creating a tasks or debian folder and storing
> all the checked out files here. This function then returns the path to the
> tasks directory. Since, we have to use UDD, we will not need to check out
> using svn or git. Am I right ?

Yes, you are right.

> > There are some extra data not yet imported into UDD which is:
> >
> >  1. prospective package data - here we should enhance the UDD gatherer
> >     to take this over as well (but this has no priority in the first
> >     stage)
> Noted.
> >  2. publication data - I have sent several warnings that specifying
> >     publication data in the tasks files is deprecated and should be done
> >     in debian/upstream/metadata of the packages in question.  My opinion
> >     is that we should rather *delete* these data from tasks files than
> >     fiddling around with it.  The publication data belong to a *package*
> >     and not to a task and we should not help people undermining this
> >     principle.
> So this means we will not be needing SetPublications() in class
> DependantPackage anymore.

Yes, that's my aim.

> > > 4. class DependantPackage holds information about a package that is in
> > > dependency list. In UDD, the table blends_prospectivepackages holds this
> > > information.
> >
> > Not only in blends_prospective packages but also in the packages and
> > new_packages.  All tables have basically the same structure and contain
> > different "types" of dependencies:  Those who can be resolved inside
> > Debian (=in packages ... the "green" section on the tasks pages), those
> > that will be resolved soon (=new_packages ... the yellow section below
> > the green one) and the blends_prospectivepackages which are only in VCS
> > (also in yellow).  The "red" section on the tasks pages is currently not
> > in UDD and it is IMHO fine to ignore these for the moment.  They can be
> > put into another structural equivalent table later.
> GetTaskDependencies() in class TaskDependency reads the tasks files and is
> parsed using deb822.Sources.iter_paragraphs(). Since, we donot have these
> task files anymore, as you already mentioned we will need to use the tables
> packages, new_packages and blends_prospectivepackages from UDD to obtain
> the data.

... and some joins to bibref etc.
> I have a couple of questions:
> 1. We are not checking out from svn or git anymore. All the information
> present in the tasks files in tasks folder is also availbale in UDD. But
> what about the debian folder that is created ?

The debian/ folder that is fetched for Blends that are maintained in SVN
contains some metadata that should be in UDD as well.  Please have a
short look into the code what exactly is used - I'm to lazy to do this
in my vacation. :-)
> 2. One of the files in debian folder is control.stub which is used in
> blend-get-names to obtain prefix of a metapackage in a blend. Wyy do we
> need blend-get-names to get the prefix? Can't we just use something like
> "prefix = blendname.split('-')[1] + '-' " as the prefix for :
>     i) debian-science -> science-
>     ii) debian-junior -> junior-
>     iii) debian-ezgo -> ezgo-

I admit this code exists a long time and I do not remember exactly why
it was done this way.  I'd suggest you do as proposed and we'll see if
this works out for all Blends as expected.  I think this is nothing that
can't be fixed later.

I hope I answered all questions properly.

Kind regards


Reply to: