Re: [gentoo-dev] Uncoordinated changes

[Raymond Jennings]

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@g.o> wrote:

> On Fri, 12 Feb 2016 10:07:10 +0100
> Patrick Lauer <patrick@g.o> 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@g.o> 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@g.o/
> > >
> > > 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/>
>