Re: [gentoo-dev] Deprecating repoman

[Joshua Kinard]

On 3/10/2022 14:59, Alec Warner wrote:
> On Thu, Mar 10, 2022 at 10:28 AM Joshua Kinard <kumba@g.o> wrote:
>>
>> On 3/9/2022 16:47, Matt Turner wrote:
>>> On Wed, Mar 9, 2022 at 1:37 PM Matthias Maier <tamiko@g.o> wrote:
>>>>
>>>>
>>>> Just a quick though:
>>>>
>>>> Looking at the man page of repoman it doesn't look to difficult to
>>>> replicate the behavior with pkgcheck. Meaning, we could think of
>>>> creating a drop-in replacement for "repoman [full]" (which would just
>>>> call pkgcheck) and "repoman commit" which actually does much more than
>>>> just prepending the git commit summary line: repoman commit does
>>>>
>>>>    - update the manifest
>>>>    - bail out if files are not correctly "git add"ed
>>>>    - add the output of [pkgcheck] as a comment to the git commit
>>>>      description
>>>
>>> I wouldn't block anyone from doing this, but it's not something I'm
>>> personally interested in pursuing. I see very little value here.
>>
>> First, you're trying to justify replacing repoman on an entirely subjective
>> opinion of "I think <foo> is superior", then when you get feedback on the
>> idea, you dismiss that feedback with more opinion.
>>
>> Why do you not see value here?  The actions described are actually quite a
>> few useful steps in the process of checking a change into the tree.  If you
>> expect developers to do those steps on their own, that increases, not
>> decreases, the chances of making a mistake.  Or are these steps already
>> handled by one of the other scripts in the replacement packages you propose?
>>  If so, please say so and identify which one(s).
>>
>> My opinion is that any tool that replaces repoman should, at a minimum,
>> replace like functionality with like functionality, plus benefits or
>> enhancements.  This looks more like a step backwards, not a step forwards.
>
> I'd be interested in hearing your workflow, so we can capture it in
> the table (mentioned earlier) so its clear how your existing workflow
> will work with the new tools (or perhaps there is a gap, or we need to
> craft / add additional tools?) I agree on the face it may not be
> obvious what workflows look like.

My workflow is really rather standard when working in the tree itself.  I
work one package directory at a time, apply changes that I've tested outside
of the tree in my local repo, eyeball everything a second time to make sure
I didn't miss something, regenerate the manifest, git add, run 'repoman full
-d -x', fix any issues it finds (if any) and manifest/git add again, then
'repoman commit' and supply a commit message with sign-off.  Lather, rinse,
repeat for other packages.

This is more or less how the dev manual and git for developers guide says we
should be doing it.  Since git is atomic, limit commits to one package at a
time, then, when ready, push the changes in a single batch after rebasing
(to pickup other dev's changes).

If I'm doing something wrong, yell at me in e-mail, open a bug, or call me
out on the mailing list and serve me some crow pie.  That's how I learn not
to repeat it.  So far, though, this process has worked well for me for a
very long time and I've only had to make minor adjustments at key points,
like switching from CVS to git.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@g.o
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic