6:08 a.m.
I've orphaned python2-matplotlib.
Nobody replied to my previous heads up e-mails.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:32 a.m.
>>>> "MH" == Miro Hrončok
<mhroncok(a)redhat.com> writes:
MH> I've orphaned python2-matplotlib. Nobody replied to my previous
MH> heads up e-mails.
So that nobody is confused by this, the python2-matplotlib package was
previously an EPEL-only stub package maintained by me that existed so
packagers could simply depend on python2-matplotlib in both Fedora and
EPEL. (See
https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages.) The
orphaning of this package had the result of removing my access from the
package entirely, on all branches.
Fortunately I have sufficient privileges so I gave access back to
myself, and then removed everything which was checked into HEAD and went
back to the original dead.package file with "This is an EPEL-only
package." I cannot remove the errant F29 branch which was created but I
will try to get it all blocked the way it was previously.
- J<
10:36 a.m.
On 1.10.2018 17:32, Jason L Tibbitts III wrote:
>>>>> "MH" == Miro Hrončok
<mhroncok(a)redhat.com> writes:
MH> I've orphaned python2-matplotlib. Nobody replied to my previous
MH> heads up e-mails.
So that nobody is confused by this, the python2-matplotlib package was
previously an EPEL-only stub package maintained by me that existed so
packagers could simply depend on python2-matplotlib in both Fedora and
EPEL. (See
https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages.) The
orphaning of this package had the result of removing my access from the
package entirely, on all branches.
Fortunately I have sufficient privileges so I gave access back to
myself, and then removed everything which was checked into HEAD and went
back to the original dead.package file with "This is an EPEL-only
package."
Could you please explain why did you do that?
I've orphaned that package (as I don't have desire to take care of it),
but it certainly does not deserve retirement (aka somebody should
hopefully take it).
There are packages depending on it.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:48 a.m.
On Mon, 1 Oct 2018 at 11:36, Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 1.10.2018 17:32, Jason L Tibbitts III wrote:
>>>>>> "MH" == Miro Hrončok <mhroncok(a)redhat.com>
writes:
>
> MH> I've orphaned python2-matplotlib. Nobody replied to my previous
> MH> heads up e-mails.
>
> So that nobody is confused by this, the python2-matplotlib package was
> previously an EPEL-only stub package maintained by me that existed so
> packagers could simply depend on python2-matplotlib in both Fedora and
> EPEL. (See
> https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages.) The
> orphaning of this package had the result of removing my access from the
> package entirely, on all branches.
>
> Fortunately I have sufficient privileges so I gave access back to
> myself, and then removed everything which was checked into HEAD and went
> back to the original dead.package file with "This is an EPEL-only
> package."
Could you please explain why did you do that?
I've orphaned that package (as I don't have desire to take care of it),
Why was it your package? It was originally tibbs.
but it certainly does not deserve retirement (aka somebody should
hopefully take it).
There are packages depending on it.
What packages? And where are they depending on it?
This was supposed to be an EPEL only package so they should only be
EPEL packages which depend on it. If there are packages in other trees
depending on it, then how because it should not have been built for
it.
--
Stephen J Smoogen.
10:55 a.m.
>>>> "SJS" == Stephen John Smoogen
<smooge(a)gmail.com> writes:
SJS> What packages? And where are they depending on it?
I believe the underlying issue is that previously the Fedora
python-matplotib package produced both python2 and python3 subpackages.
But recently it dropped support for python2.
What I don't understand is:
1) Why my access was removed from the package and set to 'orphan'.
There is no separate set of permissions for EPEL branches but I'd think
that the new Fedora maintainer would have been simply added to the list
of admins.
2) Why a package was added and then immediately orphaned. In an attempt
to clean up the mess I'm told that there's now a six week period of time
during which the package has to stay live. So this package was imported
with no expectation that it would be maintained only to start some
running clock. And for the duration of that clock, I get to keep the
mess by default?
I'm rather unhappy about this. I had previously raised my objection to
this and requested coordination in this FESCo comment:
https://pagure.io/fesco/issue/1970#comment-532232 but it appears to have
happened anyway.
- J<
11:29 a.m.
On 1.10.2018 17:55, Jason L Tibbitts III wrote:
>>>>> "SJS" == Stephen John Smoogen
<smooge(a)gmail.com> writes:
SJS> What packages? And where are they depending on it?
I believe the underlying issue is that previously the Fedora
python-matplotib package produced both python2 and python3 subpackages.
But recently it dropped support for python2.
Yes.
What I don't understand is:
1) Why my access was removed from the package and set to 'orphan'.
There is no separate set of permissions for EPEL branches but I'd think
that the new Fedora maintainer would have been simply added to the list
of admins.
I haven't in any way removed you form the package. I simply followed
this procedure:
1. package review: https://bugzilla.redhat.com/show_bug.cgi?id=1630799
2. requesting a dist-git repo:
https://pagure.io/releng/fedora-scm-requests/issue/8211
3. the repo exists, unretire on Fedora: https://pagure.io/releng/issue/7826
("It doesn't really exist in EPEL; the current EPEL package is just a
stub that depends on python-matplotlib. The Fedora package will be a
completely different thing. There shouldn't be any conflict between them.")
4. imported with history
https://src.fedoraproject.org/rpms/python2-matplotlib/pull-request/1
5. built
6. announced
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
7. orphaned when I no longer wanted to maintain it. no other maintainers
were present at this point.
If at any point of the process you got kicked out of the package, this
was certainly not my intent.
2) Why a package was added and then immediately orphaned. In an
attempt
to clean up the mess I'm told that there's now a six week period of time
during which the package has to stay live. So this package was imported
with no expectation that it would be maintained only to start some
running clock. And for the duration of that clock, I get to keep the
mess by default?
The package was added because it was needed. It was orphaned because I
don't want to maintain it. Or do I have to maintain the package for ever
juts because I've put it in there? What's the difference between
orphaning it 1 week after introducing it, 1 year or a decade?
My idea and motivation here was that somebody who needs it will take it.
I've tried. Nobody wanted it. I've orphaned it, hoping that once it
appears in the "orphaned packages in need for maintainers" announcement,
somebody will take it.
The "mess" was not "yours" to keep. There was never any mess in the
EPEL
branch(es). The only mess that exists now is that the package was
retired and things will start FTBFS and have broken deps (on Fedora),
how can we sort this mess out, I have no idea. Certainly we can unretire
it, but I won't do it just to have it retired again as a mess that needs
to get out.
I'm rather unhappy about this. I had previously raised my
objection to
this and requested coordination in this FESCo comment:
https://pagure.io/fesco/issue/1970#comment-532232 but it appears to have
happened anyway.
I haven't read that as objection. I've understand it as confusion.
You've asked to tell you if there is somebody to give this package to.
There is nobody. Nobody wants it.
Also, in the releng ticket you've pointed out that this will in no way
clash with the EPEL package. Yet now it seems you retired the package
only because you are the maintainer of the EPEL package (or at least you
should have remained the maintainer).
I don't understand what I've done wrong. I think that every maintainer
has a right to orphan a package at any time.
On the other hand, just retiring a package that other packages depend on
seems like a weird way of dealing with a problem.
I'm sorry that you were removed form the package. It was not by my
action. It might have been a side effect of the unretirement (I haven't
anticipated that side effect).
I'm very sorry that you feel like I went behind your back and like I did
a wrong thing here. This was no trick, this was no calculated move to
strip the package from you or to create a pressure on some other
packagers. This was a simple scenario:
* split a package into two halves
* orphan one of the halves that I don't want to maintain
In fact, I was planning to this for python-SecretStorage as well. Should
I rather not? What should be the correct way of doing this?
And what shall happen with python2-matplotlib in Fedora?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
12:29 p.m.
On 1.10.2018 18:29, Miro Hrončok wrote:
On 1.10.2018 17:55, Jason L Tibbitts III wrote:
>>>>>> "SJS" == Stephen John Smoogen <smooge(a)gmail.com>
writes:
> SJS> What packages? And where are they depending on it?
>
> I believe the underlying issue is that previously the Fedora
> python-matplotib package produced both python2 and python3 subpackages.
> But recently it dropped support for python2.
Yes.
> What I don't understand is:
>
> 1) Why my access was removed from the package and set to 'orphan'.
> There is no separate set of permissions for EPEL branches but I'd think
> that the new Fedora maintainer would have been simply added to the list
> of admins.
I haven't in any way removed you form the package. I simply followed
this procedure:
1. package review: https://bugzilla.redhat.com/show_bug.cgi?id=1630799
2. requesting a dist-git repo:
https://pagure.io/releng/fedora-scm-requests/issue/8211
3. the repo exists, unretire on Fedora: https://pagure.io/releng/issue/7826
("It doesn't really exist in EPEL; the current EPEL package is just a
stub that depends on python-matplotlib. The Fedora package will be a
completely different thing. There shouldn't be any conflict between them.")
So apparently, this is where you were removed, because I wrote:
FAS username of the new maintainer? churchyard
And that simply meant "replace current main admin with me".
This was certainly not intended. I've also cced you in the request so
you are aware of the unretirement. Neither of us noticed the consequence.
4. imported with history
https://src.fedoraproject.org/rpms/python2-matplotlib/pull-request/1
5. built
6. announced
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
7. orphaned when I no longer wanted to maintain it. no other maintainers
were present at this point.
Note that at the point, I haven't noticed that this is weird. I should
have. I've only seen it as an action that removes me.
If at any point of the process you got kicked out of the package, this
was certainly not my intent.
> 2) Why a package was added and then immediately orphaned. In an attempt
> to clean up the mess I'm told that there's now a six week period of time
> during which the package has to stay live. So this package was imported
> with no expectation that it would be maintained only to start some
> running clock. And for the duration of that clock, I get to keep the
> mess by default?
The package was added because it was needed. It was orphaned because I
don't want to maintain it. Or do I have to maintain the package for ever
juts because I've put it in there? What's the difference between
orphaning it 1 week after introducing it, 1 year or a decade?
My idea and motivation here was that somebody who needs it will take it.
I've tried. Nobody wanted it. I've orphaned it, hoping that once it
appears in the "orphaned packages in need for maintainers" announcement,
somebody will take it.
The "mess" was not "yours" to keep. There was never any mess in the
EPEL
branch(es). The only mess that exists now is that the package was
retired and things will start FTBFS and have broken deps (on Fedora),
how can we sort this mess out, I have no idea. Certainly we can unretire
it, but I won't do it just to have it retired again as a mess that needs
to get out.
> I'm rather unhappy about this. I had previously raised my objection to
> this and requested coordination in this FESCo comment:
> https://pagure.io/fesco/issue/1970#comment-532232 but it appears to have
> happened anyway.
I haven't read that as objection. I've understand it as confusion.
You've asked to tell you if there is somebody to give this package to.
There is nobody. Nobody wants it.
Also, in the releng ticket you've pointed out that this will in no way
clash with the EPEL package. Yet now it seems you retired the package
only because you are the maintainer of the EPEL package (or at least you
should have remained the maintainer).
I don't understand what I've done wrong. I think that every maintainer
has a right to orphan a package at any time.
On the other hand, just retiring a package that other packages depend on
seems like a weird way of dealing with a problem.
I'm sorry that you were removed form the package. It was not by my
action. It might have been a side effect of the unretirement (I haven't
anticipated that side effect).
I'm very sorry that you feel like I went behind your back and like I did
a wrong thing here. This was no trick, this was no calculated move to
strip the package from you or to create a pressure on some other
packagers. This was a simple scenario:
* split a package into two halves
* orphan one of the halves that I don't want to maintain
In fact, I was planning to this for python-SecretStorage as well. Should
I rather not? What should be the correct way of doing this?
And what shall happen with python2-matplotlib in Fedora?
Proposal:
We revert the "Undo the mess that was checked in." commit.
We unblock the package in Koji (if blocked).
I'll add:
bugzilla_contact:
Fedora: orphan
To
https://pagure.io/releng/fedora-scm-requests/blob/master/f/rpms/python2-m...
You stay as the main admin, to keep the EPEL branches.
Or we could add:
bugzilla_contact:
Fedora EPEL: tibbs
And make orphan the main admin.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
12:22 a.m.
On 1.10.2018 19:29, Miro Hrončok wrote:
On 1.10.2018 18:29, Miro Hrončok wrote:
> On 1.10.2018 17:55, Jason L Tibbitts III wrote:
>>>>>>> "SJS" == Stephen John Smoogen
<smooge(a)gmail.com> writes:
>> SJS> What packages? And where are they depending on it?
>>
>> I believe the underlying issue is that previously the Fedora
>> python-matplotib package produced both python2 and python3 subpackages.
>> But recently it dropped support for python2.
>
> Yes.
>
>> What I don't understand is:
>>
>> 1) Why my access was removed from the package and set to 'orphan'.
>> There is no separate set of permissions for EPEL branches but I'd think
>> that the new Fedora maintainer would have been simply added to the list
>> of admins.
>
> I haven't in any way removed you form the package. I simply followed
> this procedure:
>
> 1. package review: https://bugzilla.redhat.com/show_bug.cgi?id=1630799
>
> 2. requesting a dist-git repo:
> https://pagure.io/releng/fedora-scm-requests/issue/8211
>
> 3. the repo exists, unretire on Fedora:
> https://pagure.io/releng/issue/7826
>
> ("It doesn't really exist in EPEL; the current EPEL package is just a
> stub that depends on python-matplotlib. The Fedora package will be a
> completely different thing. There shouldn't be any conflict between
> them.")
So apparently, this is where you were removed, because I wrote:
> FAS username of the new maintainer? churchyard
And that simply meant "replace current main admin with me".
This was certainly not intended. I've also cced you in the request so
you are aware of the unretirement. Neither of us noticed the consequence.
> 4. imported with history
> https://src.fedoraproject.org/rpms/python2-matplotlib/pull-request/1
>
> 5. built
>
> 6. announced
>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>
>
> 7. orphaned when I no longer wanted to maintain it. no other
> maintainers were present at this point.
Note that at the point, I haven't noticed that this is weird. I should
have. I've only seen it as an action that removes me.
>
> If at any point of the process you got kicked out of the package, this
> was certainly not my intent.
>
>> 2) Why a package was added and then immediately orphaned. In an attempt
>> to clean up the mess I'm told that there's now a six week period of time
>> during which the package has to stay live. So this package was imported
>> with no expectation that it would be maintained only to start some
>> running clock. And for the duration of that clock, I get to keep the
>> mess by default?
>
> The package was added because it was needed. It was orphaned because I
> don't want to maintain it. Or do I have to maintain the package for
> ever juts because I've put it in there? What's the difference between
> orphaning it 1 week after introducing it, 1 year or a decade?
>
> My idea and motivation here was that somebody who needs it will take it.
> I've tried. Nobody wanted it. I've orphaned it, hoping that once it
> appears in the "orphaned packages in need for maintainers"
> announcement, somebody will take it.
>
> The "mess" was not "yours" to keep. There was never any mess in
the
> EPEL branch(es). The only mess that exists now is that the package was
> retired and things will start FTBFS and have broken deps (on Fedora),
> how can we sort this mess out, I have no idea. Certainly we can
> unretire it, but I won't do it just to have it retired again as a mess
> that needs to get out.
>
>> I'm rather unhappy about this. I had previously raised my objection to
>> this and requested coordination in this FESCo comment:
>> https://pagure.io/fesco/issue/1970#comment-532232 but it appears to have
>> happened anyway.
>
> I haven't read that as objection. I've understand it as confusion.
> You've asked to tell you if there is somebody to give this package to.
> There is nobody. Nobody wants it.
>
> Also, in the releng ticket you've pointed out that this will in no way
> clash with the EPEL package. Yet now it seems you retired the package
> only because you are the maintainer of the EPEL package (or at least
> you should have remained the maintainer).
>
> I don't understand what I've done wrong. I think that every maintainer
> has a right to orphan a package at any time.
>
> On the other hand, just retiring a package that other packages depend
> on seems like a weird way of dealing with a problem.
>
> I'm sorry that you were removed form the package. It was not by my
> action. It might have been a side effect of the unretirement (I
> haven't anticipated that side effect).
>
> I'm very sorry that you feel like I went behind your back and like I
> did a wrong thing here. This was no trick, this was no calculated move
> to strip the package from you or to create a pressure on some other
> packagers. This was a simple scenario:
>
> * split a package into two halves
> * orphan one of the halves that I don't want to maintain
>
> In fact, I was planning to this for python-SecretStorage as well.
> Should I rather not? What should be the correct way of doing this?
>
> And what shall happen with python2-matplotlib in Fedora?
Proposal:
We revert the "Undo the mess that was checked in." commit.
We unblock the package in Koji (if blocked).
It's blocked:
$ koji list-pkgs --show-blocked --tag f30 --package python2-matplotlib
Package Tag Extra Arches Owner
----------------------- ----------------------- ----------------
---------------
python2-matplotlib f30 releng
[BLOCKED]
python2-matplotlib-2.2.3-2.fc30 is untagged.
I'll add:
bugzilla_contact:
Fedora: orphan
To
https://pagure.io/releng/fedora-scm-requests/blob/master/f/rpms/python2-m...
You stay as the main admin, to keep the EPEL branches.
Or we could add:
bugzilla_contact:
Fedora EPEL: tibbs
And make orphan the main admin.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2030
days inactive
2032
days old
7 comments
3 participants
participants (3)
-
Jason L Tibbitts III -
Miro Hrončok -
Stephen John Smoogen