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,
