[gentoo-dev] Uncoordinated changes

[gentoo-dev] Uncoordinated changes

[Patrick Lauer]

... or why just changing stuff is not enough:

A few days ago I was told that
http://euscan.gentooexperimental.org/herds/ was displaying an empty
list. Which is annoying because people sometimes want to see what
upstream updates are available for their herd.

Well, we renamed herd to project. Because reasons.

I don't care how it is named, but this change broke euscan in a
user-visible way. Now I could just try to rename things there too, but
that won't work:

euscan uses gentoolkit for parsing metadata.xml and herds.xml
(Since herds.xml is basically unmaintained cruft at this point this will
break soon anyway ... but ...)
Changing gentoolkit to use projects.xml instead of herds.xml won't be a
simple migration since the data organization changed.

Now instead of looking up [metadata.xml] -> (herd name) -> [herds.xml]
-> email it goes backwards:
[metadata.xml] -> (maintainer type=project) -> email -> [projects.xml]
-> Project name

Since this involves XML and python's ElementTree library it's a
nontrivial change that also removes a few now useless helpers
(_get_herd_email has no reason to be, but we'd need a _get_herd_name
helper instead. Err, get_proj ... ah well, whatever name works)

And all that just so (1) gentoolkit output works and (2) euscan updates
properly. Both of which I don't really care about much, but now that
I've invested ~4h into debugging and trying to fix it I'm a tiny bit
IRRITATED.



Please, next time someone has the brilliant idea of changing stuff just
to change it (I still don't see a reason why we had to change
metadata.xml?), it should be required that support tools are fixed
*before* the change, and working versions released. This avoids grumpy
people and makes it harder for those that change things to head-in-sand
and claim everything works as expected when it obviously doesn't.


And this, again, supports my default phrase: "Change is not Progress",
because now we have regressions and user-visible breakage, and it's hard
to qualify how the change actually improved anything because we haven't
actually *finished* the change. (Like the git migration that is still
ongoing ...)

Do the needfull! Be of excellent moral person!

Re: [gentoo-dev] Uncoordinated changes

[Rich Freeman]

On Thu, Feb 11, 2016 at 3:15 PM, Patrick Lauer <patrick@gentoo.org> wrote:
>
> Please, next time someone has the brilliant idea of changing stuff just
> to change it (I still don't see a reason why we had to change
> metadata.xml?), it should be required that support tools are fixed
> *before* the change, and working versions released. This avoids grumpy
> people and makes it harder for those that change things to head-in-sand
> and claim everything works as expected when it obviously doesn't.
>

A few comments:
This change has been a long time in the making, with plenty of notice.
It even went through the formal GLEP process.  It isn't like there
wasn't ample notice.

If we didn't allow anybody to make any change without taking upon
themselves the responsibility to fix any tool anybody had created that
would be affected, then nobody would change anything, and we'd be
reduced to bitrot.  If anything I think the rate of change in Gentoo
is probably a bit low.  I don't propose changing things for the sake
of change, but contributors should feel free to propose changes and
not expect that they will have to shoulder 100% of the burden of
completely supporting those changes.

It is far more reasonable to provide notice of change, and then the
onus is on those who want specific tools to work to fix them.  If
there is a concern that more time is needed/etc this could be raised
with the council before the change.  I'm sure if the eudev maintainers
had raised a concern at any point the council would have worked with
them.

Ultimately, the only way anybody can be assured that their favorite
Gentoo tool will work in a year is if they're maintaining it.  It
sounds like nobody was really paying attention to it, which is why
nobody noticed that it was going to break.

--
Rich

Re: [gentoo-dev] Uncoordinated changes

[Michał Górny]

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

Dear Ignorant Patrick,

On Thu, 11 Feb 2016 21:15:34 +0100
Patrick Lauer <patrick@gentoo.org> wrote:

> ... or why just changing stuff is not enough:
> 
> A few days ago I was told that
> http://euscan.gentooexperimental.org/herds/ was displaying an empty
> list. Which is annoying because people sometimes want to see what
> upstream updates are available for their herd.
> 
> Well, we renamed herd to project. Because reasons.

No, we didn't. Herd was collection a packages. Project is a collection
of developers. Project coexisted with herds for a long time. As it was
explained already in length. Multiple times.

> I don't care how it is named, but this change broke euscan in a
> user-visible way. Now I could just try to rename things there too, but
> that won't work:
> 
> euscan uses gentoolkit for parsing metadata.xml and herds.xml
> (Since herds.xml is basically unmaintained cruft at this point this will
> break soon anyway ... but ...)
> Changing gentoolkit to use projects.xml instead of herds.xml won't be a
> simple migration since the data organization changed.
> 
> Now instead of looking up [metadata.xml] -> (herd name) -> [herds.xml]
> -> email it goes backwards:  
> [metadata.xml] -> (maintainer type=project) -> email -> [projects.xml]
> -> Project name  
> 
> Since this involves XML and python's ElementTree library it's a
> nontrivial change that also removes a few now useless helpers
> (_get_herd_email has no reason to be, but we'd need a _get_herd_name
> helper instead. Err, get_proj ... ah well, whatever name works)
> 
> And all that just so (1) gentoolkit output works and (2) euscan updates
> properly. Both of which I don't really care about much, but now that
> I've invested ~4h into debugging and trying to fix it I'm a tiny bit
> IRRITATED.

You are completely incorrect, as you have been told already multiple
times. People would really appreciate if you spent at least a little
part of the time you spend complaining, inventing issues and insulting
others listening to what they're telling you.

So let me repeat, again. euscan works. Want packages from Python
project? Then select the appropriate maintainer from the 'maintainers'
section:

http://euscan.gentooexperimental.org/maintainers/python@gentoo.org/

Done. Was it that hard? Now the big surprise: you didn't have to create
some convoluted logic to get that! You don't need projects.xml to get
that! Of course, you'd know that if you would listen for a single
minute instead of throwing insults at others.

> Please, next time someone has the brilliant idea of changing stuff just
> to change it (I still don't see a reason why we had to change
> metadata.xml?), it should be required that support tools are fixed
> *before* the change, and working versions released. This avoids grumpy
> people and makes it harder for those that change things to head-in-sand
> and claim everything works as expected when it obviously doesn't.

The fact is: things *work as expected*. If you have problem accepting
reality as it is, then it's your fault, not ours. Herds no longer
exist. Everything is based on *maintainers* now. Tools are not supposed
to magically turn project information back into herd-oriented design.

As I said before, please direct any further complaints directly to
the Council, and stop insulting the messenger. The Council has banned
herds explicitly before I even started working on GLEP 67. It was
the guideline I had to follow.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Uncoordinated changes

[Patrick Lauer]

On 02/12/2016 08:48 AM, Michał Górny wrote:
> Dear Ignorant Patrick,
Hello human! Your politeness module seems to have crashed.

And thanks for making me do a quintuple facepalm with backflip. I think
that's a new record. So anyway ...
> On Thu, 11 Feb 2016 21:15:34 +0100
> Patrick Lauer <patrick@gentoo.org> wrote:
>
>> ... or why just changing stuff is not enough:
>>
>> A few days ago I was told that
>> http://euscan.gentooexperimental.org/herds/ was displaying an empty
>> list. Which is annoying because people sometimes want to see what
>> upstream updates are available for their herd.
>>
>> Well, we renamed herd to project. Because reasons.
> No, we didn't. Herd was collection a packages. Project is a collection
> of developers. Project coexisted with herds for a long time. As it was
> explained already in length. Multiple times.
So you just pivoted the organization from A->B to B->A.

I still don't see the advantage in that. Maybe I should have expressed
my concerns more vocally, but in general I don't have time to worry
about all the little things.

>
>> I don't care how it is named, but this change broke euscan in a
>> user-visible way. Now I could just try to rename things there too, but
>> that won't work:
>>
>> euscan uses gentoolkit for parsing metadata.xml and herds.xml
>> (Since herds.xml is basically unmaintained cruft at this point this will
>> break soon anyway ... but ...)
>> Changing gentoolkit to use projects.xml instead of herds.xml won't be a
>> simple migration since the data organization changed.
>>
>> Now instead of looking up [metadata.xml] -> (herd name) -> [herds.xml]
>> -> email it goes backwards:  
>> [metadata.xml] -> (maintainer type=project) -> email -> [projects.xml]
>> -> Project name  
>>
>> Since this involves XML and python's ElementTree library it's a
>> nontrivial change that also removes a few now useless helpers
>> (_get_herd_email has no reason to be, but we'd need a _get_herd_name
>> helper instead. Err, get_proj ... ah well, whatever name works)
>>
>> And all that just so (1) gentoolkit output works and (2) euscan updates
>> properly. Both of which I don't really care about much, but now that
>> I've invested ~4h into debugging and trying to fix it I'm a tiny bit
>> IRRITATED.
> You are completely incorrect, as you have been told already multiple
> times. People would really appreciate if you spent at least a little
> part of the time you spend complaining, inventing issues and insulting
> others listening to what they're telling you.
>
> So let me repeat, again. euscan works. Want packages from Python
> project? Then select the appropriate maintainer from the 'maintainers'
> section:
So you're saying I have no way to search by herd, err, project now.
And I can't even find projects in the soup of maintainers.

... and metadata is now partially broken.

*ahem* This not of good idea sounding.
>
> http://euscan.gentooexperimental.org/maintainers/python@gentoo.org/
>
> Done. Was it that hard? Now the big surprise: you didn't have to create
> some convoluted logic to get that! You don't need projects.xml to get
> that! Of course, you'd know that if you would listen for a single
> minute instead of throwing insults at others.
If you had actually understood my criticism you would understand why I
might be a tiny bit irritated.

Some functionality is now actively *gone*, and that's not a feature.
>
>> Please, next time someone has the brilliant idea of changing stuff just
>> to change it (I still don't see a reason why we had to change
>> metadata.xml?), it should be required that support tools are fixed
>> *before* the change, and working versions released. This avoids grumpy
>> people and makes it harder for those that change things to head-in-sand
>> and claim everything works as expected when it obviously doesn't.
> The fact is: things *work as expected*. If you have problem accepting
> reality as it is, then it's your fault, not ours. Herds no longer
> exist. Everything is based on *maintainers* now. Tools are not supposed
> to magically turn project information back into herd-oriented design.
Right, so gentoolkit returning bad info is a good thing. I find that
hard to integrate into my understanding of the world ...


Please don't redefine what 'expected' means to suit your limited
usecases. It just causes friction and unhappy response from people that
now have to spend lots of time figuring out how things diverge from
their 'expected', which usually ends in *facepalm* omg how did that happen.

Plus the usual sequence of strongly-worded letters to the UN ;)
>
> As I said before, please direct any further complaints directly to
> the Council, and stop insulting the messenger. The Council has banned
> herds explicitly before I even started working on GLEP 67. It was
> the guideline I had to follow.
>
Hey thanks for publically demonstrating your unwillingness to cooperate
with others.

So now I know that in the future I will

(1) categorically deny any change requests coming from you and
(2) block/revert any changes that I don't like or understand.

Nothing personal, just basic sanity.


Have fun not being a team player,

Patrick

Re: [gentoo-dev] Uncoordinated changes

[Rich Freeman]

On Fri, Feb 12, 2016 at 4:07 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>
> I still don't see the advantage in that. Maybe I should have expressed
> my concerns more vocally, but in general I don't have time to worry
> about all the little things.
>

https://wiki.gentoo.org/wiki/GLEP:67#Issues_with_the_current_system

It is OK to disagree with the decision, but having gone through the
GLEP process this is about as deliberative and formal as it gets
around here.

It is pretty rare for the council to be asked to approve a change that
isn't controversial.  For the most part devs are fairly free to just
implement non-controversial changes by announcing them on -dev and
proceeding if there seems to be consensus.

We're a community-based distro.  We're all here because we care a lot
- not for the paycheck.  I think feeling passionate about
changes/issues/etc is pretty normal.

-- 
Rich

Re: [gentoo-dev] Uncoordinated changes

[Paul Varner]

On 02/11/2016 07:34 PM, Rich Freeman wrote:
> Ultimately, the only way anybody can be assured that their favorite
> Gentoo tool will work in a year is if they're maintaining it.  It
> sounds like nobody was really paying attention to it, which is why
> nobody noticed that it was going to break.

Not completely true in this case.  Gentoolkit is maintained, just slowly
due to lack of time.  For this migration, there is a bug for it (Bug
573030) that was filed by me before the migration was complete.  The
problem here is that there are two devs that primarily work on the
package and both of us currently are busy with other things in our
work/life balance.

With that said, Patrick has attached a patch to the bug and I will take
a look at it and if it works, put it in and generate a release.

As a side note, any Gentoo developer is authorized to work on
Gentoolkit, the restrictions are don't make a new release without
asking, and fix any accidental breakage. With regards to releases, it is
fine to release a rev-bumped ebuild with patches as long as the patch is
in the git repository and you follow the second rule of fixing
accidental breakage.

Regards,
Paul

Re: [gentoo-dev] Uncoordinated changes

[Michał Górny]

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

On Fri, 12 Feb 2016 10:07:10 +0100
Patrick Lauer <patrick@gentoo.org> wrote:

> On 02/12/2016 08:48 AM, Michał Górny wrote:
> > Dear Ignorant Patrick,  
> Hello human! Your politeness module seems to have crashed.

Please do not expect politeness when you insult someone.

> > On Thu, 11 Feb 2016 21:15:34 +0100
> > Patrick Lauer <patrick@gentoo.org> wrote:
> >  
> >> ... or why just changing stuff is not enough:
> >>
> >> A few days ago I was told that
> >> http://euscan.gentooexperimental.org/herds/ was displaying an empty
> >> list. Which is annoying because people sometimes want to see what
> >> upstream updates are available for their herd.
> >>
> >> Well, we renamed herd to project. Because reasons.  
> > No, we didn't. Herd was collection a packages. Project is a collection
> > of developers. Project coexisted with herds for a long time. As it was
> > explained already in length. Multiple times.  
> So you just pivoted the organization from A->B to B->A.
>
> I still don't see the advantage in that. Maybe I should have expressed
> my concerns more vocally, but in general I don't have time to worry
> about all the little things.

You still have trouble understanding who did what. I'm tired of being
blamed for something that wasn't my idea.

> >> I don't care how it is named, but this change broke euscan in a
> >> user-visible way. Now I could just try to rename things there too, but
> >> that won't work:
> >>
> >> euscan uses gentoolkit for parsing metadata.xml and herds.xml
> >> (Since herds.xml is basically unmaintained cruft at this point this will
> >> break soon anyway ... but ...)
> >> Changing gentoolkit to use projects.xml instead of herds.xml won't be a
> >> simple migration since the data organization changed.
> >>
> >> Now instead of looking up [metadata.xml] -> (herd name) -> [herds.xml]  
> >> -> email it goes backwards:    
> >> [metadata.xml] -> (maintainer type=project) -> email -> [projects.xml]  
> >> -> Project name    
> >>
> >> Since this involves XML and python's ElementTree library it's a
> >> nontrivial change that also removes a few now useless helpers
> >> (_get_herd_email has no reason to be, but we'd need a _get_herd_name
> >> helper instead. Err, get_proj ... ah well, whatever name works)
> >>
> >> And all that just so (1) gentoolkit output works and (2) euscan updates
> >> properly. Both of which I don't really care about much, but now that
> >> I've invested ~4h into debugging and trying to fix it I'm a tiny bit
> >> IRRITATED.  
> > You are completely incorrect, as you have been told already multiple
> > times. People would really appreciate if you spent at least a little
> > part of the time you spend complaining, inventing issues and insulting
> > others listening to what they're telling you.
> >
> > So let me repeat, again. euscan works. Want packages from Python
> > project? Then select the appropriate maintainer from the 'maintainers'
> > section:  
> So you're saying I have no way to search by herd, err, project now.

Yes, you have. You can use project's e-mail address to find
the project. And as I proved below, it works.

> ... and metadata is now partially broken.

Another of your unclear generic statements that mean nothing.

> *ahem* This not of good idea sounding.
> >
> > http://euscan.gentooexperimental.org/maintainers/python@gentoo.org/
> >
> > Done. Was it that hard? Now the big surprise: you didn't have to create
> > some convoluted logic to get that! You don't need projects.xml to get
> > that! Of course, you'd know that if you would listen for a single
> > minute instead of throwing insults at others.  
> If you had actually understood my criticism you would understand why I
> might be a tiny bit irritated.
> 
> Some functionality is now actively *gone*, and that's not a feature.

Yes, it's gone. However, it's relatively easy to bring it back. All you
have to do is enable filtering by type="". Which is definitely simpler
than having to process two disjoint data structures, one of them
requiring parsing additional XML file. But well, unnecessary complexity
was always considered a feature in Gentoo.

> >> Please, next time someone has the brilliant idea of changing stuff just
> >> to change it (I still don't see a reason why we had to change
> >> metadata.xml?), it should be required that support tools are fixed
> >> *before* the change, and working versions released. This avoids grumpy
> >> people and makes it harder for those that change things to head-in-sand
> >> and claim everything works as expected when it obviously doesn't.  
> > The fact is: things *work as expected*. If you have problem accepting
> > reality as it is, then it's your fault, not ours. Herds no longer
> > exist. Everything is based on *maintainers* now. Tools are not supposed
> > to magically turn project information back into herd-oriented design.  
> Right, so gentoolkit returning bad info is a good thing. I find that
> hard to integrate into my understanding of the world ...

Again.

> Please don't redefine what 'expected' means to suit your limited
> usecases. It just causes friction and unhappy response from people that
> now have to spend lots of time figuring out how things diverge from
> their 'expected', which usually ends in *facepalm* omg how did that happen.
> 
> Plus the usual sequence of strongly-worded letters to the UN ;)

I can't redefine it to suit unlimited usecases. I presume you're
capable of doing that. That's good news. I wonder why you haven't used
that ability to do something good.

> > As I said before, please direct any further complaints directly to
> > the Council, and stop insulting the messenger. The Council has banned
> > herds explicitly before I even started working on GLEP 67. It was
> > the guideline I had to follow.
> >  
> Hey thanks for publically demonstrating your unwillingness to cooperate
> with others.

That's your opinion. Please do not expect people to be willing
and happy to work with toxic personalities like yours. So far you have
put a lot of effort on spreading confusion, making noise and doing no
good. I'd rather focus on doing something useful.

> So now I know that in the future I will
> 
> (1) categorically deny any change requests coming from you and
> (2) block/revert any changes that I don't like or understand.
> 
> Nothing personal, just basic sanity.

If you want to leave Gentoo, please do that without unnecessary drama.
That will reduce the load on ComRel and/or QA resulting from your CoC
violations and childish behavior, and reduce the discouragement you're
causing to other developers.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Uncoordinated changes

[Raymond Jennings]

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

My two cents:
Do it like in linux kernel.

The guys making the API change bear the burden of fixing anything it
breaks, however, if something gets officially deprecated, don't go out of
your way to support continued use.

I for one would consider "ok, this method is not working, deprecate it so
that it doesn't get any worse because we're going to be changing it later"
is quite an appropriate way to bear the burden.

Anyone getting grandfathered from doing it the old way escapes the burden,
but by putting the entire community on notice via the GLEP process, well,
grandpa got put out to pasture and after that point the community inherited
the burden of not deepening the dependency on the freshly deprecated
feature.

Since this is a collective superproject it can also be said that we all
bear the collective burden of cooperating towards a common goal.

And yes, the personal attacks probably should die down.  I'm not with
devrel or comrel but even I can tell such sniping and whatnot can decrease
overall productivity of the distro by bringing down morale.

Solution?

If anything broke because herds were removed?  My suggestion is to leave
behind herds as empty stubs somehow, officially deprecate herds (which the
council already did from what I gather), and file a tracking bug to have
herds removed entirely.

Then just do what they do with new versions of gcc, and have existing tools
that break when herds are removed have new bugs filed on them that block
the tracking bug.  The breakage cited in the first post would be a good
example of a dependent bug that ought to block the "we still have herds"
bug.

What do you guys think?  Just use a tracking bug to flush out anything
still using herds like they do when new versions of GCC come out and break
stuff?

On Fri, Feb 12, 2016 at 2:02 PM, Michał Górny <mgorny@gentoo.org> wrote:

> On Fri, 12 Feb 2016 10:07:10 +0100
> Patrick Lauer <patrick@gentoo.org> wrote:
>
> > On 02/12/2016 08:48 AM, Michał Górny wrote:
> > > Dear Ignorant Patrick,
> > Hello human! Your politeness module seems to have crashed.
>
> Please do not expect politeness when you insult someone.
>
> > > On Thu, 11 Feb 2016 21:15:34 +0100
> > > Patrick Lauer <patrick@gentoo.org> wrote:
> > >
> > >> ... or why just changing stuff is not enough:
> > >>
> > >> A few days ago I was told that
> > >> http://euscan.gentooexperimental.org/herds/ was displaying an empty
> > >> list. Which is annoying because people sometimes want to see what
> > >> upstream updates are available for their herd.
> > >>
> > >> Well, we renamed herd to project. Because reasons.
> > > No, we didn't. Herd was collection a packages. Project is a collection
> > > of developers. Project coexisted with herds for a long time. As it was
> > > explained already in length. Multiple times.
> > So you just pivoted the organization from A->B to B->A.
> >
> > I still don't see the advantage in that. Maybe I should have expressed
> > my concerns more vocally, but in general I don't have time to worry
> > about all the little things.
>
> You still have trouble understanding who did what. I'm tired of being
> blamed for something that wasn't my idea.
>
> > >> I don't care how it is named, but this change broke euscan in a
> > >> user-visible way. Now I could just try to rename things there too, but
> > >> that won't work:
> > >>
> > >> euscan uses gentoolkit for parsing metadata.xml and herds.xml
> > >> (Since herds.xml is basically unmaintained cruft at this point this
> will
> > >> break soon anyway ... but ...)
> > >> Changing gentoolkit to use projects.xml instead of herds.xml won't be
> a
> > >> simple migration since the data organization changed.
> > >>
> > >> Now instead of looking up [metadata.xml] -> (herd name) -> [herds.xml]
> > >> -> email it goes backwards:
> > >> [metadata.xml] -> (maintainer type=project) -> email -> [projects.xml]
> > >> -> Project name
> > >>
> > >> Since this involves XML and python's ElementTree library it's a
> > >> nontrivial change that also removes a few now useless helpers
> > >> (_get_herd_email has no reason to be, but we'd need a _get_herd_name
> > >> helper instead. Err, get_proj ... ah well, whatever name works)
> > >>
> > >> And all that just so (1) gentoolkit output works and (2) euscan
> updates
> > >> properly. Both of which I don't really care about much, but now that
> > >> I've invested ~4h into debugging and trying to fix it I'm a tiny bit
> > >> IRRITATED.
> > > You are completely incorrect, as you have been told already multiple
> > > times. People would really appreciate if you spent at least a little
> > > part of the time you spend complaining, inventing issues and insulting
> > > others listening to what they're telling you.
> > >
> > > So let me repeat, again. euscan works. Want packages from Python
> > > project? Then select the appropriate maintainer from the 'maintainers'
> > > section:
> > So you're saying I have no way to search by herd, err, project now.
>
> Yes, you have. You can use project's e-mail address to find
> the project. And as I proved below, it works.
>
> > ... and metadata is now partially broken.
>
> Another of your unclear generic statements that mean nothing.
>
> > *ahem* This not of good idea sounding.
> > >
> > > http://euscan.gentooexperimental.org/maintainers/python@gentoo.org/
> > >
> > > Done. Was it that hard? Now the big surprise: you didn't have to create
> > > some convoluted logic to get that! You don't need projects.xml to get
> > > that! Of course, you'd know that if you would listen for a single
> > > minute instead of throwing insults at others.
> > If you had actually understood my criticism you would understand why I
> > might be a tiny bit irritated.
> >
> > Some functionality is now actively *gone*, and that's not a feature.
>
> Yes, it's gone. However, it's relatively easy to bring it back. All you
> have to do is enable filtering by type="". Which is definitely simpler
> than having to process two disjoint data structures, one of them
> requiring parsing additional XML file. But well, unnecessary complexity
> was always considered a feature in Gentoo.
>
> > >> Please, next time someone has the brilliant idea of changing stuff
> just
> > >> to change it (I still don't see a reason why we had to change
> > >> metadata.xml?), it should be required that support tools are fixed
> > >> *before* the change, and working versions released. This avoids grumpy
> > >> people and makes it harder for those that change things to
> head-in-sand
> > >> and claim everything works as expected when it obviously doesn't.
> > > The fact is: things *work as expected*. If you have problem accepting
> > > reality as it is, then it's your fault, not ours. Herds no longer
> > > exist. Everything is based on *maintainers* now. Tools are not supposed
> > > to magically turn project information back into herd-oriented design.
> > Right, so gentoolkit returning bad info is a good thing. I find that
> > hard to integrate into my understanding of the world ...
>
> Again.
>
> > Please don't redefine what 'expected' means to suit your limited
> > usecases. It just causes friction and unhappy response from people that
> > now have to spend lots of time figuring out how things diverge from
> > their 'expected', which usually ends in *facepalm* omg how did that
> happen.
> >
> > Plus the usual sequence of strongly-worded letters to the UN ;)
>
> I can't redefine it to suit unlimited usecases. I presume you're
> capable of doing that. That's good news. I wonder why you haven't used
> that ability to do something good.
>
> > > As I said before, please direct any further complaints directly to
> > > the Council, and stop insulting the messenger. The Council has banned
> > > herds explicitly before I even started working on GLEP 67. It was
> > > the guideline I had to follow.
> > >
> > Hey thanks for publically demonstrating your unwillingness to cooperate
> > with others.
>
> That's your opinion. Please do not expect people to be willing
> and happy to work with toxic personalities like yours. So far you have
> put a lot of effort on spreading confusion, making noise and doing no
> good. I'd rather focus on doing something useful.
>
> > So now I know that in the future I will
> >
> > (1) categorically deny any change requests coming from you and
> > (2) block/revert any changes that I don't like or understand.
> >
> > Nothing personal, just basic sanity.
>
> If you want to leave Gentoo, please do that without unnecessary drama.
> That will reduce the load on ComRel and/or QA resulting from your CoC
> violations and childish behavior, and reduce the discouragement you're
> causing to other developers.
>
> --
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>
>

[-- Attachment #2: Type: text/html, Size: 11250 bytes --]

Re: [gentoo-dev] Uncoordinated changes

[Rich Freeman]

On Sat, Feb 13, 2016 at 4:47 PM, Raymond Jennings <shentino@gmail.com> wrote:
> The guys making the API change bear the burden of fixing anything it breaks,
> however, if something gets officially deprecated, don't go out of your way
> to support continued use.

We tend to do this already for things like PMS, which is as close as
Gentoo gets to something like the kernel API.

However, sometimes a gradual transition doesn't always make as much
sense, and Gentoo doesn't always have the manpower to make every
change a pretty one.

And there is a cost to maintaining that kind of backwards
compatibility.  For example, debian chose to keep its LSB init scripts
and write systemd unit wrappers around them.  If they had chosen
openrc instead I wouldn't be surprised if they kept the LSB init
scripts and wrote an openrc compatibility layer around that.  While
this does provide a more stable experience, it also leaves around a
ton of cruft.

In general I tend to favor a balance.  Trying to get everything just
right was why the git migration literally took years, and even that in
the end had a few bumps.  Gentoo users need to be willing to deal with
the occasionally bump in the road - we try to provide a fairly cutting
edge experience, with minimal layers in integration.

But, there is nothing really wrong with your suggestion, and we try to
accommodate that approach when we can.

> And yes, the personal attacks probably should die down.

++

-- 
Rich

Re: [gentoo-dev] Uncoordinated changes

[Raymond Jennings]

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

So what do you guys think of leaving behind empty stubs for compatibility
and then simply filing a tracking bug blocked by any packages that removing
herds broke?

On Sat, Feb 13, 2016 at 2:44 PM, Rich Freeman <rich0@gentoo.org> wrote:

> On Sat, Feb 13, 2016 at 4:47 PM, Raymond Jennings <shentino@gmail.com>
> wrote:
> > The guys making the API change bear the burden of fixing anything it
> breaks,
> > however, if something gets officially deprecated, don't go out of your
> way
> > to support continued use.
>
> We tend to do this already for things like PMS, which is as close as
> Gentoo gets to something like the kernel API.
>
> However, sometimes a gradual transition doesn't always make as much
> sense, and Gentoo doesn't always have the manpower to make every
> change a pretty one.
>
> And there is a cost to maintaining that kind of backwards
> compatibility.  For example, debian chose to keep its LSB init scripts
> and write systemd unit wrappers around them.  If they had chosen
> openrc instead I wouldn't be surprised if they kept the LSB init
> scripts and wrote an openrc compatibility layer around that.  While
> this does provide a more stable experience, it also leaves around a
> ton of cruft.
>
> In general I tend to favor a balance.  Trying to get everything just
> right was why the git migration literally took years, and even that in
> the end had a few bumps.  Gentoo users need to be willing to deal with
> the occasionally bump in the road - we try to provide a fairly cutting
> edge experience, with minimal layers in integration.
>
> But, there is nothing really wrong with your suggestion, and we try to
> accommodate that approach when we can.
>
> > And yes, the personal attacks probably should die down.
>
> ++
>
> --
> Rich
>
>

[-- Attachment #2: Type: text/html, Size: 2351 bytes --]

Re: [gentoo-dev] Uncoordinated changes

[Rich Freeman]

On Sat, Feb 13, 2016 at 7:58 PM, Raymond Jennings <shentino@gmail.com> wrote:
> So what do you guys think of leaving behind empty stubs for compatibility
> and then simply filing a tracking bug blocked by any packages that removing
> herds broke?

It isn't entirely clear that anything is actually broken at the
moment, but if distributing an empty herds.xml file makes somebody's
life easier I have no objections.  I don't think it would have
alleviated Patrick's original concerns in this case.

-- 
Rich

Re: [gentoo-dev] Uncoordinated changes

[Raymond Jennings]

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

Speaking of which is there a bug filed for that?

On Sat, Feb 13, 2016 at 5:16 PM, Rich Freeman <rich0@gentoo.org> wrote:

> On Sat, Feb 13, 2016 at 7:58 PM, Raymond Jennings <shentino@gmail.com>
> wrote:
> > So what do you guys think of leaving behind empty stubs for compatibility
> > and then simply filing a tracking bug blocked by any packages that
> removing
> > herds broke?
>
> It isn't entirely clear that anything is actually broken at the
> moment, but if distributing an empty herds.xml file makes somebody's
> life easier I have no objections.  I don't think it would have
> alleviated Patrick's original concerns in this case.
>
> --
> Rich
>
>

[-- Attachment #2: Type: text/html, Size: 1137 bytes --]

[gentoo-dev] herds.xml removal (was: Re: Uncoordinated changes)

[Ulrich Mueller]

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

>>>>> On Sat, 13 Feb 2016, Rich Freeman wrote:

> It isn't entirely clear that anything is actually broken at the
> moment, but if distributing an empty herds.xml file makes somebody's
> life easier I have no objections.

In fact, GLEP 67 implies that the herds.xml file is to be removed
altogether, which would be a cleaner solution than leaving a stub.
Citing the GLEP: "The Gentoo systems using e.g. CVS checkouts were
already missing the file, and therefore the tools needed to handle
that case gracefully."

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Uncoordinated changes

[Patrick Lauer]

On 02/11/2016 09:15 PM, Patrick Lauer wrote:
> Now instead of looking up [metadata.xml] -> (herd name) -> [herds.xml]
> -> email it goes backwards:
> [metadata.xml] -> (maintainer type=project) -> email -> [projects.xml]
> -> Project name
>
> Since this involves XML and python's ElementTree library it's a
> nontrivial change that also removes a few now useless helpers
> (_get_herd_email has no reason to be, but we'd need a _get_herd_name
> helper instead. Err, get_proj ... ah well, whatever name works)
>
> And all that just so (1) gentoolkit output works and (2) euscan updates
> properly. Both of which I don't really care about much, but now that
> I've invested ~4h into debugging and trying to fix it I'm a tiny bit
> IRRITATED.
>
So this turns out to be more fun than expected.

Having spent a little bit of time staring at XML, DTDs and wondering why
we do things the most difficult way ...

Previously the herd tag was defined as:
<!ELEMENT herd (#PCDATA)>

So we end up with, for example:
<herd>kde</herd>

The new schema collapses herd (err, project!) into maintainers (err,
sustainers ... staff ... linchpin?)
And maintainer is defined as:
<!ELEMENT maintainer ( email, (description| name)* )>

Which means that only email is mandatory. So instead of search by name
you are now required to search by email.
And it leads to inconsistent (partial) duplication: Some metadata.xml
entries carry Name, some Description, and some are Email only.

For example for gentoolkit this means that instead of search by name now
it needs to be search by email, and the previous search by name
functionality requires herds.xml, err, projects.xml to figure out the
name of a project. Which might not match the one in metadata.xml!
(And you may need to filter out maintainers-that-are-not-projects, and
what about maintainers that are undefined? So much extra code complexity!)

And this is why I avoided the topic and hoped that the 'migration' would
make sense:
(1) Using XML is mildly insane. Neither machine- nor human-readable
(2) The DTD is even more insane, and few people have the patience to
figure it out
(3) The recent changes to the DTD change the data model in subtle ways
so that there's even *more* denormalization possible
(4) The tooling is, due to XML, wonderfully horrible and requires things
like XPATH to get the required data (because query by attribute is
harder than query by tag)

There's fundamental questions that should be handled before doing more
modifications - for example, should the data be more normalized (e.g.
name only in projects.xml / maintainers.xml and only email in
metadata.xml)? If we allow denormalization, do we have tools to check
and autocorrect (e.g. a maintainer changing name)?

Once we decide to abstract it away so that people should use tools and
not mangle it manually (have you looked at herds.xml ?! omg ...) there's
the question ... why XML? It's about the worst format for this job, INI
format is sufficient and easier to parse. Or JSON, or YAML, or whatever
is trendy now. Or do we autogenerate from templates?

Another funny thing: projects.xml is not in the same repository, so
synchronizing changes gets more tricky. And the metadata.dtd is in yet
another place. Wouldn't it make sense to have this organized in a less
confusing way?

You see where this is going - and why I didn't object loud enough to the
changes: I want to not care about this whole cluster of topics and do
things that are more rewarding. But that choice got taken away when
things broke (oh, they didn't break, they Function Differently now) and
I had to spend some time investigating why things deviate.

Sigh.


Am I grumpy?

Re: [gentoo-dev] Uncoordinated changes

[Rich Freeman]

On Sun, Feb 14, 2016 at 6:37 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>
> The new schema collapses herd (err, project!) into maintainers (err,
> sustainers ... staff ... linchpin?)
> And maintainer is defined as:
> <!ELEMENT maintainer ( email, (description| name)* )>
>
> Which means that only email is mandatory. So instead of search by name
> you are now required to search by email.
> And it leads to inconsistent (partial) duplication: Some metadata.xml
> entries carry Name, some Description, and some are Email only.
>
> For example for gentoolkit this means that instead of search by name now
> it needs to be search by email, and the previous search by name
> functionality requires herds.xml, err, projects.xml to figure out the
> name of a project. Which might not match the one in metadata.xml!

This is all correct and intentional.  I actually didn't care for
having the name in metadata.xml for exactly that reason, but the
intent of having it there (and optional) was to make the file more
human-readable.  Tools that intend to search by name should obtain the
name from the authoritative source (ultimately the Wiki, but mirrored
in projects.xml).

If we made metadata.xml the source of project names then your search
would break anytime a maintainer spells a name differently.  If we
imagine building a bunch of tools to prevent this from happening, we
might as well build a bunch of tools that just references the name
from projects.xml (which is what they'd have to do to prevent the
breakage anyway).

Feel free to peruse the various list discussions and council logs.
Most of what you're bringing up has come up before.

-- 
Rich

Re: [gentoo-dev] Uncoordinated changes

[Kent Fredric]

On 15 February 2016 at 00:37, Patrick Lauer <patrick@gentoo.org> wrote:
> Or JSON, or YAML, or whatever
> is trendy now.


I would love a JSON form. I tried doing my own stuff with XML and I
gave up in the complexity factory I found myself building around it :(

Just ... not YAML. The YAML spec is much less well defined and much
less "regular", and much less ubiquitous as a transport.

And if you standardize on JSON,  JSON is valid YAML 1.2, but not vice versa.

And so as long as you don't do any cute things like permit different
structures in the same slots like:

{ author => "foo@bar.com" }
{ author => { email => "foo@bar.com" , name => ... }}

You'll be fine, Because you get nice messes when code expects a value
to be a hash instead of a scalar and try to keep the data
self-consistent. Its just not worth the programming expense in every
single implementation just to provide a little sugar syntax.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Uncoordinated changes

[Michał Górny]

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

On Sun, 14 Feb 2016 12:37:33 +0100
Patrick Lauer <patrick@gentoo.org> wrote:

> On 02/11/2016 09:15 PM, Patrick Lauer wrote:
> > Now instead of looking up [metadata.xml] -> (herd name) -> [herds.xml]  
> > -> email it goes backwards:  
> > [metadata.xml] -> (maintainer type=project) -> email -> [projects.xml]  
> > -> Project name  
> >
> > Since this involves XML and python's ElementTree library it's a
> > nontrivial change that also removes a few now useless helpers
> > (_get_herd_email has no reason to be, but we'd need a _get_herd_name
> > helper instead. Err, get_proj ... ah well, whatever name works)
> >
> > And all that just so (1) gentoolkit output works and (2) euscan updates
> > properly. Both of which I don't really care about much, but now that
> > I've invested ~4h into debugging and trying to fix it I'm a tiny bit
> > IRRITATED.
> >  
> So this turns out to be more fun than expected.
> 
> Having spent a little bit of time staring at XML, DTDs and wondering why
> we do things the most difficult way ...
> 
> Previously the herd tag was defined as:
> <!ELEMENT herd (#PCDATA)>
> 
> So we end up with, for example:
> <herd>kde</herd>
> 
> The new schema collapses herd (err, project!) into maintainers (err,
> sustainers ... staff ... linchpin?)
> And maintainer is defined as:
> <!ELEMENT maintainer ( email, (description| name)* )>
> 
> Which means that only email is mandatory. So instead of search by name
> you are now required to search by email.

Congratulations! After the whole discussion, GLEP, explanatory blog
post and explanatory mails, you finally figured out how things work!

> And it leads to inconsistent (partial) duplication: Some metadata.xml
> entries carry Name, some Description, and some are Email only.
> 
> For example for gentoolkit this means that instead of search by name now
> it needs to be search by email, and the previous search by name
> functionality requires herds.xml, err, projects.xml to figure out the
> name of a project. Which might not match the one in metadata.xml!
> (And you may need to filter out maintainers-that-are-not-projects, and
> what about maintainers that are undefined? So much extra code complexity!)

Everything becomes complex if you try hard to make it sound complex.

Maintainer is a single entity, and it's identified by e-mail. So if you
want to group packages, you just group by e-mail. Simple as that. No
special magic needed. No extra files needed. The basic functionality
works without any special needs. You can also use it straight to
contact the maintainer or assign bugs.

If you want to split maintainers into people and projects, you've got
type="". Which is also in-place, with no extra files needed.

If you want pretty project names, then you can use projects.xml.
Or the name in metadata.xml. Both are fine by definition.

Now, the surprise: current people-maintainers could already have
different (or no) names in different metadata.xml files! You didn't
expect that, did you? In other words, that's not a new issue, neither
a major problem.

> And this is why I avoided the topic and hoped that the 'migration' would
> make sense:
> (1) Using XML is mildly insane. Neither machine- nor human-readable

Wrong. It works for machines well.

> (2) The DTD is even more insane, and few people have the patience to
> figure it out

And what do you need the DTD for? Furthermore, it's in process of being
replaced.

> (3) The recent changes to the DTD change the data model in subtle ways
> so that there's even *more* denormalization possible
> (4) The tooling is, due to XML, wonderfully horrible and requires things
> like XPATH to get the required data (because query by attribute is
> harder than query by tag)

Of course it does. Because no modern programming languages provide such
complex features as conditionals!

> There's fundamental questions that should be handled before doing more
> modifications - for example, should the data be more normalized (e.g.
> name only in projects.xml / maintainers.xml and only email in
> metadata.xml)? If we allow denormalization, do we have tools to check
> and autocorrect (e.g. a maintainer changing name)?
>
> Once we decide to abstract it away so that people should use tools and
> not mangle it manually (have you looked at herds.xml ?! omg ...) there's
> the question ... why XML? It's about the worst format for this job, INI
> format is sufficient and easier to parse. Or JSON, or YAML, or whatever
> is trendy now. Or do we autogenerate from templates?

What is the gain? Who is going to fix all the tools?

> Another funny thing: projects.xml is not in the same repository, so
> synchronizing changes gets more tricky. And the metadata.dtd is in yet
> another place. Wouldn't it make sense to have this organized in a less
> confusing way?

projects.xml is autogenerated from wiki. Yes, the place you refuse to
visit. Which means you'll never exist in projects.xml.

DTDs are not needed for anything, except for doing poor man's
correctness verification.

> You see where this is going - and why I didn't object loud enough to the
> changes: I want to not care about this whole cluster of topics and do
> things that are more rewarding. But that choice got taken away when
> things broke (oh, they didn't break, they Function Differently now) and
> I had to spend some time investigating why things deviate.

Of course you had to. Because reading is hard.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Uncoordinated changes

[Patrick Lauer]

On 02/14/2016 02:16 AM, Rich Freeman wrote:
> On Sat, Feb 13, 2016 at 7:58 PM, Raymond Jennings <shentino@gmail.com> wrote:
>> So what do you guys think of leaving behind empty stubs for compatibility
>> and then simply filing a tracking bug blocked by any packages that removing
>> herds broke?
> It isn't entirely clear that anything is actually broken at the
> moment, but if distributing an empty herds.xml file makes somebody's
> life easier I have no objections.  I don't think it would have
> alleviated Patrick's original concerns in this case.
>
Nope :)

But it would have made debugging easier.

Re: [gentoo-dev] Uncoordinated changes

[Rich Freeman]

On Sun, Feb 14, 2016 at 10:30 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 02/14/2016 02:16 AM, Rich Freeman wrote:
>> On Sat, Feb 13, 2016 at 7:58 PM, Raymond Jennings <shentino@gmail.com> wrote:
>>> So what do you guys think of leaving behind empty stubs for compatibility
>>> and then simply filing a tracking bug blocked by any packages that removing
>>> herds broke?
>> It isn't entirely clear that anything is actually broken at the
>> moment, but if distributing an empty herds.xml file makes somebody's
>> life easier I have no objections.  I don't think it would have
>> alleviated Patrick's original concerns in this case.
>>
> Nope :)
>
> But it would have made debugging easier.
>

Well, if debugging is your only concern, on the system you're going to
debug from:
touch herds.xml

-- 
Rich

Re: [gentoo-dev] Uncoordinated changes

[Patrick Lauer]

On 02/12/2016 11:02 PM, Michał Górny wrote:
> On Fri, 12 Feb 2016 10:07:10 +0100
> Patrick Lauer <patrick@gentoo.org> wrote:
>
>> On 02/12/2016 08:48 AM, Michał Górny wrote:
>>> Dear Ignorant Patrick,  
>> Hello human! Your politeness module seems to have crashed.
> Please do not expect politeness when you insult someone.
>
>
>> So now I know that in the future I will
>>
>> (1) categorically deny any change requests coming from you and
>> (2) block/revert any changes that I don't like or understand.
>>
>> Nothing personal, just basic sanity.
> If you want to leave Gentoo, please do that without unnecessary drama.
> That will reduce the load on ComRel and/or QA resulting from your CoC
> violations and childish behavior, and reduce the discouragement you're
> causing to other developers.
>
Now now. That's a severe case of projection, and I should take offense
at it. But that's silly, so please stop being such a drama queen and
maybe don't start yet another project this month until you've finised at
least one of the half dozen unfinished things that you started.


If you feel insulted because I pointed out some breakage caused by you
(which now you claimed you did against your wishes, which is a strange
thing for voluntary work) then I suggest you hide breakage (oh wait,
"differently behaving") better so I don't notice it. And if I
discouraged you from working on more things then that's good too ...

Re: [gentoo-dev] Uncoordinated changes

[Andreas K. Hüttel]

On Sunday 14 February 2016 13:18:30 Rich Freeman wrote:
> 
> Feel free to peruse the various list discussions and council logs.
> Most of what you're bringing up has come up before.

Thanks rich0, you seem to be reading my mind.

This is turning into a severe case of "I didn't bother to speak up earlier or 
volunteer to improve something, and now I'm unhappy with what was decided and 
implemented."

-- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfridge@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] Uncoordinated changes

[Patrick Lauer]

On 02/14/2016 07:44 PM, Andreas K. Hüttel wrote:
> On Sunday 14 February 2016 13:18:30 Rich Freeman wrote:
>> Feel free to peruse the various list discussions and council logs.
>> Most of what you're bringing up has come up before.
> Thanks rich0, you seem to be reading my mind.
>
> This is turning into a severe case of "I didn't bother to speak up earlier or 
> volunteer to improve something, and now I'm unhappy with what was decided and 
> implemented."
>
Silly me for assuming that changes to metadata would not affect me.
Or that tools would be adapted to the changes.

Or that the changes would make sense.

I don't have time to follow every little change, so it's quite annoying
to reverse-engineer this change that apparently is a compromise that no
one actually wanted, and hasn't really been finished yet. Sigh.

Re: [gentoo-dev] Uncoordinated changes

[Ciaran McCreesh]

On Sun, 14 Feb 2016 19:53:56 +0100
Patrick Lauer <patrick@gentoo.org> wrote:
> I don't have time to follow every little change, so it's quite
> annoying to reverse-engineer this change that apparently is a
> compromise that no one actually wanted, and hasn't really been
> finished yet. Sigh.

Why reverse engineer it? It's all documented.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Uncoordinated changes

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/14/2016 10:53 AM, Patrick Lauer wrote:
> On 02/14/2016 07:44 PM, Andreas K. Hüttel wrote:
>> On Sunday 14 February 2016 13:18:30 Rich Freeman wrote:
>>> Feel free to peruse the various list discussions and council
>>> logs. Most of what you're bringing up has come up before.
>> Thanks rich0, you seem to be reading my mind.
>> 
>> This is turning into a severe case of "I didn't bother to speak
>> up earlier or volunteer to improve something, and now I'm unhappy
>> with what was decided and implemented."
>> 
> Silly me for assuming that changes to metadata would not affect
> me. Or that tools would be adapted to the changes.
> 
> Or that the changes would make sense.
> 
> I don't have time to follow every little change, so it's quite
> annoying to reverse-engineer this change that apparently is a
> compromise that no one actually wanted, and hasn't really been
> finished yet. Sigh.
> 
To be fair, if you're working on a piece of software that depends on
parsing metadata from ebuild directories, it's reasonable to assume
that one would want to keep tabs on metadata.xml or any other topic
dealing with the problem space.

A simple, "My project depends on metadata.xml and I use it in X way;
will I be affected?" may have added to the discussion.

As it stands, I believe we're moving to maintainer types. So selecting
via `type="project"` should be able to fetch the project that an
ebuild belongs to. We (i.e. Gentoo) are in the middle of deciding
whether to keep going with DTD or switch to another method (from what
I gather, to support this very case), so since you actually depend on
these files, why not educate yourself on the conversation and see if
you can contribute? It does nobody any good to sit and sulk while the
world changes around you.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWwUTMAAoJEAEkDpRQOeFwIFsP/1AZH4QcJp0hW7gv4CmO55wd
yzuuwW4iDzswX8cUfmkJdkar/OVapUo0I0xuh/7dniUF9Yoj9vuN1m7f4z9VTQeh
YrzbxKe/YVt8wO+2e2YxohIsybQTycG/0yKdcJN9NjNreo04fA80WUu9NYXEavk5
frfGqVaThhPXjIqQRJAq9V0UraqjU/SNy9xQAHMUtjnW5q4svPs3QTRP93+hqYg6
7Kzr8ssRGhq1N8A9lnZrkXfVkBmHOQ/Pol1d/ci+xRryYerVDlM7pGFW2mEdbtp2
jobryJMUjoUtdp8bxWgt+55X9fu4STPtyvq27n/ac4dXl2hs039iDLIdgyioR+id
X7pa6qmqeDVVT4vKNaFXa6PLF6K/OgNyp5l8M8Yctv9TJ0ppOX4WJ9bosivyAtBX
93w5Gu7G8arkZaJfpZDwf551Zn7qNaeR+ipArfy+kzn81zWogrrvBFPJ4JYP9qdL
iFEPVSH14seh7mRZOKhMzzMvfLAarQF5paZmwqCceCzEzIauMlGVT0xDEjansAUK
qewS2pWJ8yELL2kohq8yuP/3/qplgW2gVUK58b5+PpdOB/i5fdNVX5FwaNg3TBt/
4LALTeNdtgFDXL/5y8YdJu+yn6QlBEgxP2uo8me8CPFexsZRe8XRHO15WNnAhFIL
48rujyhN02LbnsD+0LV1
=onzY
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Uncoordinated changes

[Ryan Hill]

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

On Sun, 14 Feb 2016 10:58:10 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> Well, if debugging is your only concern, on the system you're going to
> debug from:
> touch herds.xml

Don't do that.

rhill@tundra /usr/portage/dev-util/creduce $ repoman

RepoMan scours the neighborhood...
[INFO] checking package dev-util/creduce
Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.4/repoman", line 37, in <module>
    repoman_main(sys.argv[1:])
  File "/usr/lib64/python3.4/site-packages/repoman/main.py", line 104, in
repoman_main qatracker, can_force = scanner.scan_pkgs(can_force)
  File "/usr/lib64/python3.4/site-packages/repoman/scanner.py", line 281, in
scan_pkgs self.pkgmeta.check(xpkg, checkdir, checkdirlist, self.repolevel)
  File
"/usr/lib64/python3.4/site-packages/repoman/checks/ebuilds/pkgmetadata.py",
line 165, in check self.repoman_settings)) File
"/usr/lib64/python3.4/site-packages/repoman/checks/herds/herdbase.py", line
111, in get_herd_base os.path.join(repoman_settings["PORTDIR"],
"metadata/herds.xml")) File
"/usr/lib64/python3.4/site-packages/repoman/checks/herds/herdbase.py", line 73,
in make_herd_base target=_HerdsTreeBuilder())) File
"/usr/lib64/python3.4/xml/etree/ElementTree.py", line 1187, in parse
tree.parse(source, parser) File
"/usr/lib64/python3.4/xml/etree/ElementTree.py", line 605, in parse self._root
= parser.close() xml.etree.ElementTree.ParseError: no element found: line 1,
column 0




-- 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] Re: Uncoordinated changes

[Rich Freeman]

On Tue, Feb 16, 2016 at 5:55 PM, Ryan Hill <rhill@gentoo.org> wrote:
> On Sun, 14 Feb 2016 10:58:10 -0500
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> Well, if debugging is your only concern, on the system you're going to
>> debug from:
>> touch herds.xml
>
> Don't do that.
>
> rhill@tundra /usr/portage/dev-util/creduce $ repoman
>
> RepoMan scours the neighborhood...
> [INFO] checking package dev-util/creduce
> Traceback (most recent call last):

See, you're uncovering bugs already.  :)

I wasn't really serious.  The suggestion was to stick an empty
herds.xml in the tree, and my point was that anybody can basically do
that already.

-- 
Rich