Re: orphaning Taskotron-related packages

2020-11-25 Thread Kamil Paral
On Wed, Nov 25, 2020 at 2:29 PM Josef Skladanka  wrote:

> > Orphaning python-mongoquery and retiring everything else makes sense to
> > me.
> >
> > Tim
>
> +1
>

OK, I'll make it happen.
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org


Re: orphaning Taskotron-related packages

2020-11-25 Thread Josef Skladanka
On Mon, Nov 23, 2020 at 7:11 PM Tim Flink  wrote:
>
> On Thu, 12 Nov 2020 18:25:17 +0100
> Kamil Paral  wrote:
>
> > Note: The email subject should have said "retiring" instead of
> > "orphaning". There is little reason to orphan them, retiring is the
> > right approach here. Perhaps except for mongoquery, somebody else
> > could be interested in maintaining that, so that one should be
> > orphaned instead.
>
> Orphaning python-mongoquery and retiring everything else makes sense to
> me.
>
> Tim


+1
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org


Re: orphaning Taskotron-related packages

2020-11-23 Thread Tim Flink
On Thu, 12 Nov 2020 18:25:17 +0100
Kamil Paral  wrote:

> Note: The email subject should have said "retiring" instead of
> "orphaning". There is little reason to orphan them, retiring is the
> right approach here. Perhaps except for mongoquery, somebody else
> could be interested in maintaining that, so that one should be
> orphaned instead.

Orphaning python-mongoquery and retiring everything else makes sense to
me.

Tim


pgpKM0xSB4EP3.pgp
Description: OpenPGP digital signature
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org


Re: orphaning Taskotron-related packages

2020-11-16 Thread Miro Hrončok

On 11/16/20 2:07 PM, Kamil Paral wrote:
I just know that sometimes the retirement process does not happen automatically 
and the packages linger


When that happens, please let me know. For the past ~2 years, I am the 
retirement process.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org


Re: orphaning Taskotron-related packages

2020-11-16 Thread Kamil Paral
On Mon, Nov 16, 2020 at 8:27 AM František Zatloukal 
wrote:

> The "correct" way to do this is to use orphaning procedure. This way,
> anybody interested will have enough time to take over the to-be removed
> packages.
>

"When Fedora maintainers do not want or are not able to maintain a package
any longer, they can orphan or retire
 the
package. When they think that the package is still useful for Fedora, they
should orphan it. Then other maintainers that are interested in maintaining
it, can take ownership of this package. In case the package is no longer
useful for Fedora, e.g. because it was renamed, upstream does not exist
anymore, then it should be retired."
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers

As I said, I think it makes sense to go for orphaning in case of
mongoquery, and retiring for taskotron packages. But as you note:


>
> Also, all packages that are orphaned for 6+ weeks get retired. This will
> happen before F34, so there is no harm in doing this through orphans.
>

Yes, it should be the same anyway, if we do it right now. I just know that
sometimes the retirement process does not happen automatically and the
packages linger, and that's why I suggested retiring the upstream-dead
packages right away. I see no benefit in a two-step process, only potential
issues. But I don't care, really.

Anyway, what do you think about the actual proposal, and not the
technicalities?
Tim, Josef, do you have anything to say here?
Thanks.
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org


Re: orphaning Taskotron-related packages

2020-11-16 Thread Miro Hrončok

On 11/16/20 8:25 AM, František Zatloukal wrote:

Note: The email subject should have said "retiring" instead of
"orphaning".
There is little reason to orphan them, retiring is the right approach here.
Perhaps except for mongoquery, somebody else could be interested in
maintaining that, so that one should be orphaned instead.


The "correct" way to do this is to use orphaning procedure. This way, anybody 
interested will have enough time to take over the to-be removed packages.

Also, all packages that are orphaned for 6+ weeks get retired. This will happen 
before F34, so there is no harm in doing this through orphans.


Actually, if nothing requires it and it is upstream dead, retiring directly is 
fine. So is orphaning I guess.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org


Re: orphaning Taskotron-related packages

2020-11-15 Thread František Zatloukal
> Note: The email subject should have said "retiring" instead of
> "orphaning".
> There is little reason to orphan them, retiring is the right approach here.
> Perhaps except for mongoquery, somebody else could be interested in
> maintaining that, so that one should be orphaned instead.

The "correct" way to do this is to use orphaning procedure. This way, anybody 
interested will have enough time to take over the to-be removed packages.

Also, all packages that are orphaned for 6+ weeks get retired. This will happen 
before F34, so there is no harm in doing this through orphans.
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org


Re: orphaning Taskotron-related packages

2020-11-12 Thread Kamil Paral
Note: The email subject should have said "retiring" instead of "orphaning".
There is little reason to orphan them, retiring is the right approach here.
Perhaps except for mongoquery, somebody else could be interested in
maintaining that, so that one should be orphaned instead.
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org


orphaning Taskotron-related packages

2020-11-12 Thread Kamil Paral
Hello,
our Taskotron-related repositories (with exceptions like resultsdb) have
been marked as EOL and archived more than half a year ago. I believe it's
time to also tidy up our rpm packages in Fedora.

Looking at our group ownership [1] I have identified the following rpms
which could be retired:
* libtaskotron - nothing depends on it
* taskotron-trigger - nothing depends on it
* python-mongoquery - only taskotron-trigger depends on it
* execdb - nothing depends on it

I think we could have a light discussion regarding libtaskotron. The git
repo is marked as EOL and therefore the package should go away. However,
it's easy to flip the git repo back to a live state and it's not that
trivial to bring back an rpm package. So we should at least briefly
consider whether there is anything in that repo that could be useful in
some of our other current efforts. When looking at the code [2], I think
there are a few modules that could be potentially useful elsewhere, like
koji_utils/bodhi_utils/rpm_utils, perhaps a method or two from
os_utils/file_utils, and a perhaps a few directives. The problem is that
the code is not currently designed to work as a standalone library, but as
a runner - it expects a config file present, it expects certain directories
present, etc. The directives are exceptionally horrible if you want to use
them just by importing and not through the runner. It would require a
fairly big rewrite. Also we could drop ca. 70%-80% of the current codebase
(the runner stuff and unuseful modules).

If Tim said he would like to use some of that code in his CI efforts, or
Josef et al. said they would use some of that for oraculum or packager
dashboard etc, we might not retire libtaskotron, but restructure it into
something more useful. I'd be fine helping with that. But, even if we
wanted to do that, I'd honestly consider leaving libtaskotron as it is, and
rather creating a new package instead, something like 'libfedoraqa' or
similar. And only the few useful modules would be transferred there. It
feels to me much cleaner than reusing the libtaskotron name but gutting it
heavily.

What are your thoughts? Do you see any near-term use of some of the
existing code in libtaskotron? Or any other mentioned packages? Or can we
just drop them and bring them back if we ever need them? (If we don't have
an immediate use, there is a high probability we won't ever need them
again).

Thanks,
Kamil

[1] https://src.fedoraproject.org/group/qa-tools-sig
[2] https://pagure.io/taskotron/libtaskotron/blob/develop/f/libtaskotron
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org