[PULL] [L/unstable] merge configs into annotations

[Andrea Righi]

On Tue, Dec 06, 2022 at 11:42:46AM +0900, Masahiro Yamada wrote:
> Hi Andrea,
> 
> 
> On Mon, Dec 5, 2022 at 5:10 PM Andrea Righi <andrea.righi at canonical.com> wrote:
> > > --query requires a config option __without__ 'CONFIG_' prefix
> > > but --write requires __with__ 'CONFIG' prefix.
> > >
> > > This is really confusing. The policy should be consistent.
> > >
> > > Or, you can support both ways.
> > >
> > >
> > > args.config if args.config.startswith('CONFIG') else 'CONFIG_' + args.config.
> > >
> > >
> > > FWIW, the upstream scripts/config supports with/without 'CONFIG_' prefix:
> > >
> > >   https://github.com/torvalds/linux/blob/v6.0/scripts/config#L60
> >
> > Done.
> >
> > Changed in linux-unstable to support both formats (w/wo CONFIG_ prefix),
> > so we are consistent with upstream.
> 
> 
> Thanks for the improvement.
> 
> You can do it in the main() function to deduplicate the code.
> Please see the attachment.

Definitely. Applied, thanks!

> 
> 
> I did not fix up do_source() because I could not understand the
> point of the --source option.
> 
> 
> The --source option does not get access to the annotation database.
> 
> 
> "annotations --source --config RUST" is just an alias of
> "vim -t CONFIG_RUST".
> 
> It forks more processes, and makes the user type more chars.
> That's it.

Yeah, I have to say that your point makes sense, the idea of --source
was to be able to use either CONFIG_<option> or just <option> to
directly jump to the definition of <option> in the source code (just by
doing a copy/paste of the <option> name when doing an updateconfigs),
maybe it's not a big improvement... I'll probably drop it.

> 
> 
> 
> 
> 
> 
> 
> >
> > BTW, I'm also maintaining the annotations script in a separate git repo
> > (git.launchpad.net/~arighi/+git/annotations-tools), so it's easy to
> > review/keep track of the latest changes across all kernels.
> 
> 
> Ah, OK.
> 
> BTW, where is our central repository for developing the debian/ directory?
> 
> 
> Ubuntu maintains the debianized-kernel tree (kernel + debian/ directory)
> in the same git repository.
> We do this for more than 50 kernel trees.
> I have no idea how diverged the debian/ is among different kernel trees.
> 
> In contrast, the Debian kernel maintains debian/ directory by git.
> (https://salsa.debian.org/kernel-team/linux.git)
> They track diffs from the upstream code.
> 
> 
> How do we do this?
> Commit [Packaging] patches to lunar/unstable, then
> port them to older stable kernels as needed?

We don't have a central repository to maintain debian/, we try to move
the common scripts as much as possible to kteam-tools (see
cranky/fixes.d/). Personally I'm not a big fan of this solution, I'd
rather prefer to keep debian/ as uniform as possible across all kernels
and maintain it in a centralized git repo (following the Debian way).

For the annotations scripts I applied those to lunar only, because we
want to experiment this refactoring only with the lunar kernels for now,
but I expect at some point the "official" annotations scripts will be
merged into kteam-tools and cranky fix would automatically keep them
in sync inside each kernel.

-Andrea