I hope you are all well.
I would like to invite you to contribute to our new initiative: AAA
Currently, we have a team of 4 Red Hatters working on this. We have chosen
to work within a Scrum framework. Our first ( 2 week) sprint kicked off
last week 1/7/20 with a sprint planning session. Our first sprint review
will take place on Tuesday 1/21/20.
We will be publishing a blog each fortnight on community forums with a
summary of our sprint review and sprint planning session for the upcoming
sprint. You are invited to provide feedback on your review/plan for our
consideration. The first blog will be published Wednesday 1/22/20.
You will find our backlog ( issues ) here
<https://github.com/fedora-infra/securitas/issues> and our scrum board with
current sprint user stories here
<https://github.com/orgs/fedora-infra/projects/6>. Our Tech lead, will be
refining/prioritising the backlog as we work our way through each sprint,
preparing for the next sprint. The issues/user stories at the top of the
backlog are the user stories that have been flagged as must do/ high value
tasks to complete by the Tech lead. We do welcome your input on the backlog
(Issues) , so please add your thoughts, ideas, questions as a comment for
the Tech lead and team to review. These will be reviewed prior to each
sprint planning session for consideration.
We have a Freenode IRC channel #fedora-aaa where we welcome you to join. We
will be discussing ad hoc items regarding this project here. We also meet
regularly on this channel for stand up's four times a week. Mon & Wed at
0915 UTC and Tues &Thurs at 1530 UTC for 15 minutes.
I will be updating the Wiki page over the next couple of days with a high
level overview of the project and our communication plan. As with Scrum, we
may tweak our process as we progress through the project. If our process
does change, I will update the Wiki page.
If you have questions relating to an issue( user story ) on the backlog (
issues ) please comment on it, and tag a team member , we will revert back.
If you would like to add an issue, please create and issue, give as much
detail as possible and tag a team member so we can review.
If you have questions relating to anything else, please reply to this
Thanks a mill,
Red Hat <https://www.redhat.com/>
@RedHat <https://twitter.com/redhat> Red Hat
<https://www.linkedin.com/company/red-hat> Red Hat
It's become clear that I haven't had the time I thought I'd have this past
year due to $life ...
These are in a bit of a broken state and right now I'd advise people that
need them to use upstream packages/containers.
I don't foresee sufficient time coming in the near future with family needs
in advance of hobbies like Fedora of course.
I'll give it a week or so for anyone to contact me who wants to pick them
up, otherwise I'll update pagure to assign them to "orphan"
Hello piotrp, I see that you maintain a lot of packages and I am looking for some new ones to start with. I have a PR in for nagios-plugins-check-updates and will happily adopt it or comaintain it if you’re still interested in it.
Sent from my iPhone
as you maybe know the BerkeleyDB 6.x has a more restrictive license than
the previous versions (AGPLv3 vs. LGPLv2), and due to that many projects
cannot use it.
Few years ago there was an effort to reduce the number of dependent
packages on BerkeleyDB(libdb). And nowadays situation seems to be almost
the same. Here is
the link with packages dependent on libdb from previous effort, which is
truthful for nowadays situation. As a member of the database team which is
responsible for libdb, I would like to know your opinions on this problem,
because many components have many specific cases where is libdb used.
Nowadays we would like to remove libdb from Fedora as soon as possible, in
the best case from Fedora 33. But I am afraid, that it isn't real.
I have discussed this issue with my colleagues and we propose an approach.
We found that the biggest problem would occur in updating components from
versions that support libdb to versions without this support. Here could
arise problems of inconsistency.
Our approach assumes to convert old libdb databases to other supported
database format in each package related to this libdb issue. Result would
be Fedora without libdb.
I know that this approach probably isn't perfect.
Therefore I would like to ask for Your opinions, suggestions and every
Thank you very much for any help. I welcome every opinion.
Fiip Januš - Red Hat Associate Developer Engineer - Databases Team