Maintenance of Python tools

Maintenance of Python tools

[Simon Glass]

Hi,

Tom has indicated that he would like Patman to move out of his tree. I
suggested on another thread[1] that I maintain it in my 'sjg' tree, so
here is a new thread to discuss this.

I have already done this for the qemu/efi/coreboot scripts as Tom has
NAK'ed patches for those.

For the other tools there is going to be quite a bit of churn, as I
would like to resolve most of the many Python warnings.

Given the shared source between the tools, it would be easier for me
to do the same for buildman, binman and qconfig. I am thinking that I
might try a move to allow Gitlab pull-requests for reviews on these as
well as the mailing list, if that is useful.

For tools which need to sync back to Tom's tree (i.e. not patman), I
or Tom could do a pull request every now and then, omitting any
changes that relate to pylint.

Please let me know your thoughts. The timing is good as I am going to
be sending out a new Patman feature in the next few weeks and it is a
few thousand more lines of code.

Regards,
Simon

[1] https://lore.kernel.org/u-boot/CAFLszTg7-yM0L8uuJyN7Jpsb1LbvOYO76cUWj+H719mfc97mMQ@mail.gmail.com/

Re: Maintenance of Python tools

[Mattijs Korpershoek]

Hi Simon,

On mar., avril 22, 2025 at 17:39, Simon Glass <sjg@chromium.org> wrote:

> Hi,
>
> Tom has indicated that he would like Patman to move out of his tree. I
> suggested on another thread[1] that I maintain it in my 'sjg' tree, so
> here is a new thread to discuss this.
>
> I have already done this for the qemu/efi/coreboot scripts as Tom has
> NAK'ed patches for those.
>
> For the other tools there is going to be quite a bit of churn, as I
> would like to resolve most of the many Python warnings.
>
> Given the shared source between the tools, it would be easier for me
> to do the same for buildman, binman and qconfig. I am thinking that I
> might try a move to allow Gitlab pull-requests for reviews on these as
> well as the mailing list, if that is useful.
>
> For tools which need to sync back to Tom's tree (i.e. not patman), I
> or Tom could do a pull request every now and then, omitting any
> changes that relate to pylint.
>
> Please let me know your thoughts. The timing is good as I am going to
> be sending out a new Patman feature in the next few weeks and it is a
> few thousand more lines of code.

I have a preference for binman staying in the U-Boot upstream (Tom's)
tree. AFAIK, binman is used by the CI and is also very useful for composing
"complex" bootloader images (For example for the TI k3 architecture).
I don't know a good replacement of binman and I'm afraid that people
will go back to ad-hoc scripts if binman gets removed from the tree :(

On the other hand, patman is a workflow tool that's not (I think) that
specific to U-Boot and is (to me) replaceable by b4.

I understand that code sharing makes it more difficult to only move
buildman out of upstream, but in a perfect world, I'd like binman to
stay in upstream.

Thanks,
Mattijs

>
> Regards,
> Simon
>
> [1] https://lore.kernel.org/u-boot/CAFLszTg7-yM0L8uuJyN7Jpsb1LbvOYO76cUWj+H719mfc97mMQ@mail.gmail.com/

Re: Maintenance of Python tools

[Simon Glass]

Hi Mattijs,

On Wed, 23 Apr 2025 at 01:07, Mattijs Korpershoek
<mkorpershoek@kernel.org> wrote:
>
> Hi Simon,
>
> On mar., avril 22, 2025 at 17:39, Simon Glass <sjg@chromium.org> wrote:
>
> > Hi,
> >
> > Tom has indicated that he would like Patman to move out of his tree. I
> > suggested on another thread[1] that I maintain it in my 'sjg' tree, so
> > here is a new thread to discuss this.
> >
> > I have already done this for the qemu/efi/coreboot scripts as Tom has
> > NAK'ed patches for those.
> >
> > For the other tools there is going to be quite a bit of churn, as I
> > would like to resolve most of the many Python warnings.
> >
> > Given the shared source between the tools, it would be easier for me
> > to do the same for buildman, binman and qconfig. I am thinking that I
> > might try a move to allow Gitlab pull-requests for reviews on these as
> > well as the mailing list, if that is useful.
> >
> > For tools which need to sync back to Tom's tree (i.e. not patman), I
> > or Tom could do a pull request every now and then, omitting any
> > changes that relate to pylint.
> >
> > Please let me know your thoughts. The timing is good as I am going to
> > be sending out a new Patman feature in the next few weeks and it is a
> > few thousand more lines of code.
>
> I have a preference for binman staying in the U-Boot upstream (Tom's)
> tree. AFAIK, binman is used by the CI and is also very useful for composing
> "complex" bootloader images (For example for the TI k3 architecture).
> I don't know a good replacement of binman and I'm afraid that people
> will go back to ad-hoc scripts if binman gets removed from the tree :(
>
> On the other hand, patman is a workflow tool that's not (I think) that
> specific to U-Boot and is (to me) replaceable by b4.
>
> I understand that code sharing makes it more difficult to only move
> buildman out of upstream, but in a perfect world, I'd like binman to
> stay in upstream.

Just to clarify this, I'm not suggesting removing binman. It's just
the maintenance and development of new features that I'm referring to.
We would still sync source back to Tom's tree.

Regards,
SImon

> > [1] https://lore.kernel.org/u-boot/CAFLszTg7-yM0L8uuJyN7Jpsb1LbvOYO76cUWj+H719mfc97mMQ@mail.gmail.com/

Re: Maintenance of Python tools

[Mattijs Korpershoek]

Hi Simon,

On mer., avril 23, 2025 at 06:28, Simon Glass <sjg@chromium.org> wrote:

> Hi Mattijs,
>
> On Wed, 23 Apr 2025 at 01:07, Mattijs Korpershoek
> <mkorpershoek@kernel.org> wrote:
>>
>> Hi Simon,
>>
>> On mar., avril 22, 2025 at 17:39, Simon Glass <sjg@chromium.org> wrote:
>>
>> > Hi,
>> >
>> > Tom has indicated that he would like Patman to move out of his tree. I
>> > suggested on another thread[1] that I maintain it in my 'sjg' tree, so
>> > here is a new thread to discuss this.
>> >
>> > I have already done this for the qemu/efi/coreboot scripts as Tom has
>> > NAK'ed patches for those.
>> >
>> > For the other tools there is going to be quite a bit of churn, as I
>> > would like to resolve most of the many Python warnings.
>> >
>> > Given the shared source between the tools, it would be easier for me
>> > to do the same for buildman, binman and qconfig. I am thinking that I
>> > might try a move to allow Gitlab pull-requests for reviews on these as
>> > well as the mailing list, if that is useful.
>> >
>> > For tools which need to sync back to Tom's tree (i.e. not patman), I
>> > or Tom could do a pull request every now and then, omitting any
>> > changes that relate to pylint.
>> >
>> > Please let me know your thoughts. The timing is good as I am going to
>> > be sending out a new Patman feature in the next few weeks and it is a
>> > few thousand more lines of code.
>>
>> I have a preference for binman staying in the U-Boot upstream (Tom's)
>> tree. AFAIK, binman is used by the CI and is also very useful for composing
>> "complex" bootloader images (For example for the TI k3 architecture).
>> I don't know a good replacement of binman and I'm afraid that people
>> will go back to ad-hoc scripts if binman gets removed from the tree :(
>>
>> On the other hand, patman is a workflow tool that's not (I think) that
>> specific to U-Boot and is (to me) replaceable by b4.
>>
>> I understand that code sharing makes it more difficult to only move
>> buildman out of upstream, but in a perfect world, I'd like binman to
>> stay in upstream.
>
> Just to clarify this, I'm not suggesting removing binman. It's just
> the maintenance and development of new features that I'm referring to.
> We would still sync source back to Tom's tree.

Got it, thanks.

Wouldn't moving the binman development out of upstream reduce
contributions/visibility?
Or do you think that proposing alternative development process (like
Gitlab merge requests) would attract more folks?

What would be the policy for development/syncing back to upstream?

What happens if binman evolves in a way that's not aligned/practical for
upstream (Tom's tree) ?

Would that mean that we would have to maintain a fork in upstream?

>
> Regards,
> SImon
>
>> > [1] https://lore.kernel.org/u-boot/CAFLszTg7-yM0L8uuJyN7Jpsb1LbvOYO76cUWj+H719mfc97mMQ@mail.gmail.com/

Re: Maintenance of Python tools

[Simon Glass]

Hi Mattijs,

On Wed, 23 Apr 2025 at 06:43, Mattijs Korpershoek
<mkorpershoek@redhat.com> wrote:
>
> Hi Simon,
>
> On mer., avril 23, 2025 at 06:28, Simon Glass <sjg@chromium.org> wrote:
>
> > Hi Mattijs,
> >
> > On Wed, 23 Apr 2025 at 01:07, Mattijs Korpershoek
> > <mkorpershoek@kernel.org> wrote:
> >>
> >> Hi Simon,
> >>
> >> On mar., avril 22, 2025 at 17:39, Simon Glass <sjg@chromium.org> wrote:
> >>
> >> > Hi,
> >> >
> >> > Tom has indicated that he would like Patman to move out of his tree. I
> >> > suggested on another thread[1] that I maintain it in my 'sjg' tree, so
> >> > here is a new thread to discuss this.
> >> >
> >> > I have already done this for the qemu/efi/coreboot scripts as Tom has
> >> > NAK'ed patches for those.
> >> >
> >> > For the other tools there is going to be quite a bit of churn, as I
> >> > would like to resolve most of the many Python warnings.
> >> >
> >> > Given the shared source between the tools, it would be easier for me
> >> > to do the same for buildman, binman and qconfig. I am thinking that I
> >> > might try a move to allow Gitlab pull-requests for reviews on these as
> >> > well as the mailing list, if that is useful.
> >> >
> >> > For tools which need to sync back to Tom's tree (i.e. not patman), I
> >> > or Tom could do a pull request every now and then, omitting any
> >> > changes that relate to pylint.
> >> >
> >> > Please let me know your thoughts. The timing is good as I am going to
> >> > be sending out a new Patman feature in the next few weeks and it is a
> >> > few thousand more lines of code.
> >>
> >> I have a preference for binman staying in the U-Boot upstream (Tom's)
> >> tree. AFAIK, binman is used by the CI and is also very useful for composing
> >> "complex" bootloader images (For example for the TI k3 architecture).
> >> I don't know a good replacement of binman and I'm afraid that people
> >> will go back to ad-hoc scripts if binman gets removed from the tree :(
> >>
> >> On the other hand, patman is a workflow tool that's not (I think) that
> >> specific to U-Boot and is (to me) replaceable by b4.
> >>
> >> I understand that code sharing makes it more difficult to only move
> >> buildman out of upstream, but in a perfect world, I'd like binman to
> >> stay in upstream.
> >
> > Just to clarify this, I'm not suggesting removing binman. It's just
> > the maintenance and development of new features that I'm referring to.
> > We would still sync source back to Tom's tree.
>
> Got it, thanks.
>
> Wouldn't moving the binman development out of upstream reduce
> contributions/visibility?
> Or do you think that proposing alternative development process (like
> Gitlab merge requests) would attract more folks?

I'm not sure, which is why I am asking about it here, to get feedback.
I like patches on the mailing list myself, but perhaps others don't?

>
> What would be the policy for development/syncing back to upstream?
>
> What happens if binman evolves in a way that's not aligned/practical for
> upstream (Tom's tree) ?
>
> Would that mean that we would have to maintain a fork in upstream?

My thinking here is that U-Boot would simply use binman / buildman as
they are, similar to how dts-upstream (91MB), lwip (9MB) and mbedtls
(48MB) work. But yes, if Tom decides that Binman (3MB) / Buildman
(700KB) / other tools (small) have hared off in an undesirable
direction, then it would be tricky.

Regards,
Simon

> >> > [1] https://lore.kernel.org/u-boot/CAFLszTg7-yM0L8uuJyN7Jpsb1LbvOYO76cUWj+H719mfc97mMQ@mail.gmail.com/
>

Re: Maintenance of Python tools

[Heinrich Schuchardt]

On 23.04.25 15:05, Simon Glass wrote:
> Hi Mattijs,
> 
> On Wed, 23 Apr 2025 at 06:43, Mattijs Korpershoek
> <mkorpershoek@redhat.com> wrote:
>>
>> Hi Simon,
>>
>> On mer., avril 23, 2025 at 06:28, Simon Glass <sjg@chromium.org> wrote:
>>
>>> Hi Mattijs,
>>>
>>> On Wed, 23 Apr 2025 at 01:07, Mattijs Korpershoek
>>> <mkorpershoek@kernel.org> wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>> On mar., avril 22, 2025 at 17:39, Simon Glass <sjg@chromium.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Tom has indicated that he would like Patman to move out of his tree. I
>>>>> suggested on another thread[1] that I maintain it in my 'sjg' tree, so
>>>>> here is a new thread to discuss this.
>>>>>
>>>>> I have already done this for the qemu/efi/coreboot scripts as Tom has
>>>>> NAK'ed patches for those.
>>>>>
>>>>> For the other tools there is going to be quite a bit of churn, as I
>>>>> would like to resolve most of the many Python warnings.
>>>>>
>>>>> Given the shared source between the tools, it would be easier for me
>>>>> to do the same for buildman, binman and qconfig. I am thinking that I
>>>>> might try a move to allow Gitlab pull-requests for reviews on these as
>>>>> well as the mailing list, if that is useful.
>>>>>
>>>>> For tools which need to sync back to Tom's tree (i.e. not patman), I
>>>>> or Tom could do a pull request every now and then, omitting any
>>>>> changes that relate to pylint.
>>>>>
>>>>> Please let me know your thoughts. The timing is good as I am going to
>>>>> be sending out a new Patman feature in the next few weeks and it is a
>>>>> few thousand more lines of code.
>>>>
>>>> I have a preference for binman staying in the U-Boot upstream (Tom's)
>>>> tree. AFAIK, binman is used by the CI and is also very useful for composing
>>>> "complex" bootloader images (For example for the TI k3 architecture).
>>>> I don't know a good replacement of binman and I'm afraid that people
>>>> will go back to ad-hoc scripts if binman gets removed from the tree :(
>>>>
>>>> On the other hand, patman is a workflow tool that's not (I think) that
>>>> specific to U-Boot and is (to me) replaceable by b4.
>>>>
>>>> I understand that code sharing makes it more difficult to only move
>>>> buildman out of upstream, but in a perfect world, I'd like binman to
>>>> stay in upstream.
>>>
>>> Just to clarify this, I'm not suggesting removing binman. It's just
>>> the maintenance and development of new features that I'm referring to.
>>> We would still sync source back to Tom's tree.
>>
>> Got it, thanks.
>>
>> Wouldn't moving the binman development out of upstream reduce
>> contributions/visibility?
>> Or do you think that proposing alternative development process (like
>> Gitlab merge requests) would attract more folks?
> 
> I'm not sure, which is why I am asking about it here, to get feedback.
> I like patches on the mailing list myself, but perhaps others don't?
> 
>>
>> What would be the policy for development/syncing back to upstream?
>>
>> What happens if binman evolves in a way that's not aligned/practical for
>> upstream (Tom's tree) ?
>>
>> Would that mean that we would have to maintain a fork in upstream?
> 
> My thinking here is that U-Boot would simply use binman / buildman as
> they are, similar to how dts-upstream (91MB), lwip (9MB) and mbedtls
> (48MB) work. But yes, if Tom decides that Binman (3MB) / Buildman
> (700KB) / other tools (small) have hared off in an undesirable
> direction, then it would be tricky.
> 
> Regards,
> Simon
> 
>>>>> [1] https://lore.kernel.org/u-boot/CAFLszTg7-yM0L8uuJyN7Jpsb1LbvOYO76cUWj+H719mfc97mMQ@mail.gmail.com/
>>

Which projects beyond U-Boot use buildman or binman?

* If there are none, we should maintain the tools inside the U-Boot
   code.
* If there are other uses, we should still keep a copy inside U-Boot to
   ensure that we can build U-Boot no matter what the upstream
   maintainer decides to change.

Patman is not needed for maintaining the U-Boot project and can be used 
for other purposes. Moving it out makes sense.

Best regards

Heinrich

Re: Maintenance of Python tools

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]

On Tue, Apr 22, 2025 at 05:39:30PM -0600, Simon Glass wrote:

> Hi,
> 
> Tom has indicated that he would like Patman to move out of his tree. I
> suggested on another thread[1] that I maintain it in my 'sjg' tree, so
> here is a new thread to discuss this.
> 
> I have already done this for the qemu/efi/coreboot scripts as Tom has
> NAK'ed patches for those.
> 
> For the other tools there is going to be quite a bit of churn, as I
> would like to resolve most of the many Python warnings.
> 
> Given the shared source between the tools, it would be easier for me
> to do the same for buildman, binman and qconfig. I am thinking that I
> might try a move to allow Gitlab pull-requests for reviews on these as
> well as the mailing list, if that is useful.
> 
> For tools which need to sync back to Tom's tree (i.e. not patman), I
> or Tom could do a pull request every now and then, omitting any
> changes that relate to pylint.
> 
> Please let me know your thoughts. The timing is good as I am going to
> be sending out a new Patman feature in the next few weeks and it is a
> few thousand more lines of code.

My biggest objection to all of this is that you should NOT use
sjg.u-boot.org as that perpetuates your abusing owning u-boot.org. As I
said in the thread, it should be under https://source.denx.de/u-boot/
somewhere and you should be the one to own it there. They should be
managed like normal python projects and we could "pip install" what's
needed. But yes, I do think them being managed like a regular python
project instead will make your life, and also the rest of the
communities life, easier.

Un-bundling binman and making it a standalone tool might help make it
easier for other projects to utilize it instead of reinventing the
tooling themselves.

I'm not sure why buildman and qconfig would need to be pulled out, but
if it's just a matter of a "pip install", sure, fine.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Maintenance of Python tools

[Simon Glass]

Hi Tom,

On Wed, 23 Apr 2025 at 08:08, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Apr 22, 2025 at 05:39:30PM -0600, Simon Glass wrote:
>
> > Hi,
> >
> > Tom has indicated that he would like Patman to move out of his tree. I
> > suggested on another thread[1] that I maintain it in my 'sjg' tree, so
> > here is a new thread to discuss this.
> >
> > I have already done this for the qemu/efi/coreboot scripts as Tom has
> > NAK'ed patches for those.
> >
> > For the other tools there is going to be quite a bit of churn, as I
> > would like to resolve most of the many Python warnings.
> >
> > Given the shared source between the tools, it would be easier for me
> > to do the same for buildman, binman and qconfig. I am thinking that I
> > might try a move to allow Gitlab pull-requests for reviews on these as
> > well as the mailing list, if that is useful.
> >
> > For tools which need to sync back to Tom's tree (i.e. not patman), I
> > or Tom could do a pull request every now and then, omitting any
> > changes that relate to pylint.
> >
> > Please let me know your thoughts. The timing is good as I am going to
> > be sending out a new Patman feature in the next few weeks and it is a
> > few thousand more lines of code.
>
> My biggest objection to all of this is that you should NOT use
> sjg.u-boot.org as that perpetuates your abusing owning u-boot.org. As I
> said in the thread, it should be under https://source.denx.de/u-boot/
> somewhere and you should be the one to own it there.

I wish you would stop bringing this up. Until things change, that is
unfortunately what I have to do, to avoid being blocked.

> They should be
> managed like normal python projects and we could "pip install" what's
> needed. But yes, I do think them being managed like a regular python
> project instead will make your life, and also the rest of the
> communities life, easier.
>
> Un-bundling binman and making it a standalone tool might help make it
> easier for other projects to utilize it instead of reinventing the
> tooling themselves.
>
> I'm not sure why buildman and qconfig would need to be pulled out, but
> if it's just a matter of a "pip install", sure, fine.

Actually, for me, I quite like being able to do a release with a
single 'make' command for all tools. I was not thinking of having
completely different repos. So this isn't really about 'pip install'.

Sadly I doubt other projects will adopt Binman so we are going to have
lots of firmware-packaging tools eventually*. After all, we have Arm's
FIP file format, Linaro wrote a new bloblist implementation, etc.

Regards,
Simon

* although we did use it with Zephyr in ChromeOS

Re: Maintenance of Python tools

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]

On Thu, Apr 24, 2025 at 12:34:23PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 23 Apr 2025 at 08:08, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Apr 22, 2025 at 05:39:30PM -0600, Simon Glass wrote:
> >
> > > Hi,
> > >
> > > Tom has indicated that he would like Patman to move out of his tree. I
> > > suggested on another thread[1] that I maintain it in my 'sjg' tree, so
> > > here is a new thread to discuss this.
> > >
> > > I have already done this for the qemu/efi/coreboot scripts as Tom has
> > > NAK'ed patches for those.
> > >
> > > For the other tools there is going to be quite a bit of churn, as I
> > > would like to resolve most of the many Python warnings.
> > >
> > > Given the shared source between the tools, it would be easier for me
> > > to do the same for buildman, binman and qconfig. I am thinking that I
> > > might try a move to allow Gitlab pull-requests for reviews on these as
> > > well as the mailing list, if that is useful.
> > >
> > > For tools which need to sync back to Tom's tree (i.e. not patman), I
> > > or Tom could do a pull request every now and then, omitting any
> > > changes that relate to pylint.
> > >
> > > Please let me know your thoughts. The timing is good as I am going to
> > > be sending out a new Patman feature in the next few weeks and it is a
> > > few thousand more lines of code.
> >
> > My biggest objection to all of this is that you should NOT use
> > sjg.u-boot.org as that perpetuates your abusing owning u-boot.org. As I
> > said in the thread, it should be under https://source.denx.de/u-boot/
> > somewhere and you should be the one to own it there.
> 
> I wish you would stop bringing this up. Until things change, that is
> unfortunately what I have to do, to avoid being blocked.

I really wish you would stop holding the project domain hostage. I will
not stop bringing up that you are holding the project domain hostage
because you are holding the project domain hostage.

I am in fact getting close to my breaking point of you and your holding
of the project domain hostage.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Maintenance of Python tools

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]

On Thu, Apr 24, 2025 at 12:55:15PM -0600, Tom Rini wrote:
> On Thu, Apr 24, 2025 at 12:34:23PM -0600, Simon Glass wrote:
> > Hi Tom,
> > 
> > On Wed, 23 Apr 2025 at 08:08, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, Apr 22, 2025 at 05:39:30PM -0600, Simon Glass wrote:
> > >
> > > > Hi,
> > > >
> > > > Tom has indicated that he would like Patman to move out of his tree. I
> > > > suggested on another thread[1] that I maintain it in my 'sjg' tree, so
> > > > here is a new thread to discuss this.
> > > >
> > > > I have already done this for the qemu/efi/coreboot scripts as Tom has
> > > > NAK'ed patches for those.
> > > >
> > > > For the other tools there is going to be quite a bit of churn, as I
> > > > would like to resolve most of the many Python warnings.
> > > >
> > > > Given the shared source between the tools, it would be easier for me
> > > > to do the same for buildman, binman and qconfig. I am thinking that I
> > > > might try a move to allow Gitlab pull-requests for reviews on these as
> > > > well as the mailing list, if that is useful.
> > > >
> > > > For tools which need to sync back to Tom's tree (i.e. not patman), I
> > > > or Tom could do a pull request every now and then, omitting any
> > > > changes that relate to pylint.
> > > >
> > > > Please let me know your thoughts. The timing is good as I am going to
> > > > be sending out a new Patman feature in the next few weeks and it is a
> > > > few thousand more lines of code.
> > >
> > > My biggest objection to all of this is that you should NOT use
> > > sjg.u-boot.org as that perpetuates your abusing owning u-boot.org. As I
> > > said in the thread, it should be under https://source.denx.de/u-boot/
> > > somewhere and you should be the one to own it there.
> > 
> > I wish you would stop bringing this up. Until things change, that is
> > unfortunately what I have to do, to avoid being blocked.
> 
> I really wish you would stop holding the project domain hostage. I will
> not stop bringing up that you are holding the project domain hostage
> because you are holding the project domain hostage.
> 
> I am in fact getting close to my breaking point of you and your holding
> of the project domain hostage.

And since you don't like me pointing this out, would you transfer the
domain to either:

- Myself (the head of the project)

- DENX (whom I am volunteering on the spur of the moment, sorry) who
  otherwise run the projects general infrastructure

?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]