Re: About your live-build contributions

[jnqnfe@gmail.com]

Hi Raphael,

I understand. Just to summarise before I expand on things, I
contributed a lot of work on LB back around 2015 which never made it
into master, and this is a resubmission (partial so far) of that work,
because I'd like to see it merged rather than gone to waste. :)

I'll try to be brief in explaining...

History
-------

Back around late 2014 / early 2015 I first discovered and used LB which
led to familiarising myself with much/most of the codebase and starting
to make contributions. Over the months I worked on LB I accumulated a
sizable number of commits across multiple branches as I worked towards
goals such as resolving the unathenticated-wget-downloads issue, lack
of EFI support, fixing various bugs that I discovered as I worked on
things and otherwise improving the codebase in general. I put a lot of
time and effort into improving the project's code. However, whilst I
felt that the old maintainer of the time, Daniel B., did not object to
my doing this work, and odd patches got merged, the bulk of my work
suffered from lack of movement on his part. I had hoped at some point
that he might well see benefit of granting me commit access to at least
just push the smaller changes myself, but I never asked and then, well,
life happens and in the middle of working on EFI support I got diverted
away from the project. As you'll no doubt be aware, Daniel moved on
from it also. He did leave some of my work on a temporary branch though
- tmp-jnqnfe.

A little more of the work that I had submitted has been picked up and
merged by yourself some time ago after you took over, but otherwise
much of it has just remained abandoned. You did I previously noted make
the effort to take a brief look at both of the two larger bits of
submitted work, leaving a review comment on the wget stuff that you
were not entirely satisfied with certain aspects of the solution, and
with another chunk of work that it was by then in need of rebasing and
breaking up into separate bug reports however.

You also commented that the project was in low maintenance and
refactoring type patches were of little/no interest at that time.

At least once in the time since 2015 I've needed an updated live disc
and had to fudge together a combination of sorts of the official
version and my old work in order to use it securely with public mirrors
(due to that wget issue).

My return
---------

Just recently this has been the case again, and I decided that it was
time to properly rebase my old work on master to pick up the
improvements that have been made there. I'd also tidy things up and try
and resubmit it for merging.

I was planning to just have it all put together on a single branch of a
public repo on github/gitlab/whatever (a single branch because it had
become a nightmare previously not knowing which stuff would get merged
by Daniel first as things backed up and built on top of each other and
such), and then send you an email explaining this situation and giving
you the link, asking for you to check it out and merge it when you
found the time, or at least start cherry-picking what you were happy
with and we'd see where we'd end up.

I jumped the gun a little however. I've been spending time for the past
weeks on rebasing, reorganising and reworking all of that old work of
mine; There are still a few important chunks unfinished, but there were
a large number of commits of the small and simple kind that I had
accumulated on my submission prep branch and I decided on Sunday to
just get them sent off then and there; it'd be a bit of weight off my
shoulders I thought, and I'd see what you'd make of things if you found
any time at all for it, whilst I got on with working on what remains,
and it might make further submissions easier having those secured in
master.

I ditched the original plan of just sending one email in part because I
recalled one of your reviews of an old 2015 submission asking for
individual bug reports for individual bugs if resubmitting a rebased
copy in the future (I'd previously tried simplifying things with Daniel
by trying to minimised things, sending large collections of commits as
collections and such). I did not particularly want to spend time on
dozens of bug report filings, but on Sunday, contemplating going ahead
with submitting some stuff that day, I thought what the hell if it
pleased you to do it that way (though they did not all receive the same
amount of care to describe as I might typically give, due to the
quantity, but I knew that the commits and their messages speak well
enough for themselves and the reports were in part just to temporarily
to get bug numbers for things, and to leave something in the bug
tracker if it were that none of this would receive attention from
anyone for a long time).

I also partially ditched the one-email plan because I discovered that I
could make an account for myself on salsa and thus use the lovely
gitlab facilities.

resubmission notes
------------------

In preparing things for resubmission I have been doing a lot of
reordering of commits in order to keep the most simple and straight
forward and unobjectionable changes first, with the bigger stuff (which
I've not submitted yet) coming after this. I hoped that this would help
ensure that at least a good chunk of fixes could get pulled straight in
first then leaving the larger stuff to consider after.

I have dropped some bits of refactoring work here and there, but some
remains. It is just too much of a shame to throw it all away, and a lot
of it is very straightforward.

All of the commits for the MR submissions started off living together
on my single submission prep branch. This is the master branch on my
public salsa repo, where you can see all of the submitted work, along
with a chunk on top for which no MRs have been created yet. The
unfinished stuff I still need to work on is not yet public.

I submitted MRs following the order of the stack of commits this branch
piles onto origin/master. I.e, the MRs map in this sort of way:

<jnqnfe/master>
...
<commit #5> -> MR #4
<commit #4> -> MR #3
<commit #3>
<commit #2> -> MR #2
<commit #1> -> MR #1
<origin/master>

For submission of each MR I created a new branch encompassing the
portion of my prep branch that encompassed the relevant commits, then
rebased this to remove all other commits below them down to
origin/master that could be removed without a conflict issue. Thus you
will find that the earliest MRs only contain the commits relevant to
them, and thus being free from conflicting with each other should also
mean that you should actually be free to merge them in any order. With
some of the later MRs however, as noted in them, there were conflicts
that required one or more commits below them in the branch needing to
be bundled into the MR. If you work through the MRs from earliest
submitted to last, everything should apply cleanly (or I'd hope they
would, maybe those with the extra commits might fail trying to reapply
those commits, but that's easy to sort out, and I can always rebase
those MRs when you get to them if you need).

So...
-----

So as I say, the sudden chunk of bug and MR filings is due to
resubmission of a chunk of (mostly) old work that I've been rebasing,
reworking, tweaking and otherwise preparing for handing over for fresh
consideration.

It terms of order for tackling the MRs, earliest first, and as above,
things should all merge as they all are on my master.

I am pleasantly surprised that you have responded so promptly. I feared
that it could be at least weeks before seeing any movement at all, if
at all. :)

There's no pressure at all on my part for a particularly prompt turn
around on all of this. I do not wish to be a pain or source of stress.
I just hope that all my hard work does not end up ultimately being for
nought.


Regards,
Lyndon

On Tue, 2020-03-03 at 09:58 +0100, Raphael Hertzog wrote:
> Hello,
> 
> I'm sorry, you are probably well-meaning, but submitting so many bugs
> and so many merge requests in a such a small timeframe is counter
> productive.
> 
> I feel overwhelmed and instead of gradually building a trust
> relationship,
> I'm putting the review work on the side because there's too much of
> it.
> 
> Can you highlight a few of the bugs/MR that you submitted that should
> be
> reviewed first and that ideally prove your skills and knowledge of
> live-build?
> 
> Cheers,