Re: [PATCH 0-10 of 16 v2 4/8] meta: conf: use bitbake.conf from bitbake and apply local changes

[Baurzhan Ismagulov <ibr@radix50.net>]

On Tue, Aug 22, 2017 at 08:55:54PM +0200, Henning Schild wrote:
> Ok, understood. I think using issues as reminder list might shine the
> wrong light on the project, but that is a personal feeling.

This is a good point. At least small stuff like two lines of docs would really
be better to do immediately and not to postpone.

Bigger stuff like upstream bitbake changes would still exist. One approach
could be to distinguish between user bugs and project own TODOs (not offered by
GitHub). We've discussed this with Alex; ATM, we'd prefer to stick to the
existing infrastructure, at least till the development is streamlined.
Internally, we have an even longer list of issues and plan to move them to
GitHub for now as well.


> We can proceed in this way or stick to the original plan. Or use one
> where both sides modify the patches, depending on the change that needs
> to be made.
> But if anyone substancially changes a patch it has to be reviewed
> again.

The original plan was supposed to be faster due to quick fixes without later
review. Since we want a final review of changes, let's switch back to the
classic process.


> Or at least end up in "the official" next branch where it will
> sit for a few days for everyone to look at.

Ok, we've discussed this with Alex and would like to introduce next.

Currently, we are checking whether we still need asmirnov/next, and what
implications that would have on the maintainer process.


We also have some wishes:

* When submitting patches, considering the stuff from CONTRIBUTING would help
  us to review them, especially w.r.t. communicating the background /
  motivation / intention to work at something early in the process.

* We'll comment on the desired formatting. CodingStyle is on my TODO.

* If there is a problem, please articulate expectations; that would allow us to
  address them (unlike e.g. just a request to revert).

* We've looked at the apt implementations and currently tend towards the
  existing one, as it supports binary package caching and is shared with the
  Deby project. Regarding reprepro, we'd like to keep it because dropping it
  would mean re-implementing that in Isar and keeping up with possible Debian
  archive structure changes in the future.


With kind regards,
Baurzhan.