[Libre-soc-dev] git.libre-soc.org mesa repo branch

Luke Kenneth Casson Leighton lkcl at lkcl.net
Thu Sep 10 06:11:23 BST 2020

On Thursday, September 10, 2020, vivek pandya <vivekvpandya at gmail.com>

> On Wed, Sep 9, 2020 at 10:49 PM Luke Kenneth Casson Leighton <
> lkcl at lkcl.net>
> wrote:
> > On Wed, Sep 9, 2020 at 5:47 PM vivek pandya <vivekvpandya at gmail.com>
> > wrote:
> > >
> > > I think we should have waited a little bit.
> >
> > the transparency requirements of NLnet's "Privacy and Enhanced Trust"
> > Grant need to be met, Vivek.  plus if someone else joins you and
> > wishes to help out, "waiting" actively prevents and prohibits them
> > from doing that, doesn't it?
> >
> > I agree, but I am bit nervous. The reason is writing a SW renderer
> through
> a JIT is not as easy as writing a toy language JIT for CPU.
> There is lots of work yet remaining so this "Initial" driver.

indeed. so getting some extra help and support for you would be a good
thing :)

> >
> >
> > > Everything is visible and
> > > accessible on
> > > https://gitlab.freedesktop.org/vivekvpandya/mesa/-/tree/libresoc_dev
> > > Until I don't get LLVM jit wrangled all work is mostly labor, nothing
> > much
> > > smart.
> >
> > please understand: the "quality" or "status" should in no way be
> > considered a deciding factor as to whether code should or should not
> > be made available.  it should *always* be made available.   if code is
> > not "pushed" within a few minutes of it being written and tested, this
> > should be considered a "red flag".
> >
> I do push as soon as I get enough confidence about the code after testing.
> Even after working ~7 hours on Saturdays and Sundays , for such a policy my
> work is considered a "red flag" then that is a little discouraging.

ah you misunderstand, or have an accidental correlation: the procedures are
in no way a reflection on the value of the work itself.

you say "my work is red flagged" where i said "if the *procedures* are not
followed that is a red flag" (associated with the *procedures* not the work
or its quality).

huge difference :)

to give you an example of why committing and pushing is so important: only
last week i lost git commits not once but TWICE due to a faulty laptop PSU.

i had run "git commit" but not push.  2 minutes later i ran a simulation
which used 100% CPU enough to flatten the battery, and also generated
enough SSD traffic to cause the SSD to not be able to save to NAND right as
the battery died.

when i investigated i found that although the .py files in the git repo
were fine the git objects under .git/objects were totally corrupted.

this happened not once bit twice!

if only i had done "git push" straight away i would not have lost time.

if on Friday your machine has a similar data corruption you could also lose
time and work.

having these procedures and also full replicable test environments is for
your own benefit as much as it is for anyone else.

look up the story of the freedombox project some time.  the key (sole)
developer lost an ENTIRE YEAR of work because he had zero backups and had
not committed - ever - to an offsite repository.

> >
> > i've documented this on the HDL_workflow "development practices" page
> > https://libre-soc.org/HDL_workflow/
> >
> >
> > > Is anyone planning to add any code?
> >
> > if we can find other people to help, yes.  i'm doing two conference
> > presentations on LibreSOC for next week so it is likely to happen
> > soon.
> >
> All the best for conference.

thank you

>  It will be really helpful if someone will be
> happy to work with us.
> Please make sure things are explicitly communicate through bug or this
> mailing list (add me to "To") so that I don't endup doing duplicate work.


i will definitely keep the bugreports updated and will add you as a cc to
anything relevant.

btw one reason for having a libresoc wiki home page is so it has a link to
search "bugs related to me" on it.  then it is real quick and easy for you
to find and review.

> I hope I have write/read access to this git repo so that I can push my
> commits and people don't have to merge from gitlab repo.

yesyes of course.  when you do that "ssh -v -p922
gitolite3 at git.libre-soc.org" command you should see "RW mesa" in the
console output. this says you have read and write access to that repo.

if you don't please let me know straight away and i will fix it.


crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

More information about the Libre-soc-dev mailing list