Greetings, I'm going to start work on the next Fedora Account System release targetting the couple weeks after the Fedora release. I don't know of any blocker bugs that still need to be fixed so it may be that I'll just be making sure that what's in the repository now is set to be translated and then pushed out after release.
If anyone either: * has patches that they want to get in and tested * bugs that they think I might be able to fix before the release * bugs that they think should be blockers to release
Please let me know (on this list or IRC).
This release is intended mostly for getting the majority of hotfixes that are in infrastructure's puppet repository into an rpm package as well as pulling some other features (like a more readable captcha) into production.
If anyone would like to work on additional features for the next release, please let me know and I'll help get you up to speed.
-Toshio
Hello, can you please tell me about the FAS (architecture and development : languages, persistence support, ...). I would like to contribute to this work.
best regards.
On Thu, Oct 27, 2011 at 10:20 PM, Toshio Kuratomi a.badger@gmail.comwrote:
Greetings, I'm going to start work on the next Fedora Account System release targetting the couple weeks after the Fedora release. I don't know of any blocker bugs that still need to be fixed so it may be that I'll just be making sure that what's in the repository now is set to be translated and then pushed out after release.
If anyone either:
- has patches that they want to get in and tested
- bugs that they think I might be able to fix before the release
- bugs that they think should be blockers to release
Please let me know (on this list or IRC).
This release is intended mostly for getting the majority of hotfixes that are in infrastructure's puppet repository into an rpm package as well as pulling some other features (like a more readable captcha) into production.
If anyone would like to work on additional features for the next release, please let me know and I'll help get you up to speed.
-Toshio
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Thu, Oct 27, 2011 at 11:44:08PM +0000, Bousselham EL HADDAOUI wrote:
Hello, can you please tell me about the FAS (architecture and development : languages, persistence support, ...). I would like to contribute to this work.
Sure. FAS is written in python using the TurboGears web framework. You can look at the code here:
http://git.fedorahosted.org/git/?p=fas.git
If you think that this will interest you, you can look at the tickets here for something to work on: https://fedorahosted.org/fas/report/3
Or find me on irc (abadger1999) and we can figure out what level of task you would like to work on.
-Toshio
Hello Toshio, thank you for the response :), actually I'm not a Python programmer :s , I now Java, C, PHP, Lisp ... that can take some time to learn Python and get an advanced level. I will try to look at the links. and I will see if can do some thing ( I hope so :) ).
best regards.
On Fri, Oct 28, 2011 at 12:46 AM, Toshio Kuratomi a.badger@gmail.comwrote:
On Thu, Oct 27, 2011 at 11:44:08PM +0000, Bousselham EL HADDAOUI wrote:
Hello, can you please tell me about the FAS (architecture and development :
languages,
persistence support, ...). I would like to contribute to this work.
Sure. FAS is written in python using the TurboGears web framework. You can look at the code here:
http://git.fedorahosted.org/git/?p=fas.git
If you think that this will interest you, you can look at the tickets here for something to work on: https://fedorahosted.org/fas/report/3
Or find me on irc (abadger1999) and we can figure out what level of task you would like to work on.
-Toshio
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Fri, Oct 28, 2011 at 02:20:43AM +0000, Bousselham EL HADDAOUI wrote:
Hello Toshio, thank you for the response :), actually I'm not a Python programmer :s , I now Java, C, PHP, Lisp ... that can take some time to learn Python and get an advanced level. I will try to look at the links. and I will see if can do some thing ( I hope so :) ).
Excellent. If you'd like to start learning python, starting with a sys-admin scripting task might be easier. I opened one last night that could fit:
https://fedorahosted.org/fedora-infrastructure/ticket/2997
If you take that on, you'd need to learn how to:
* import libraries in python * instantiate an object * call a method on the object * work with python lists and dicts * basic looping and conditional structures * print to the screen
The script itself should be pretty short so this would be a good intro-to-python task if python is something you want to learn.
-Toshio
Thank you. Now I must learn first Python and I will see if I can do this task. I have a question : what is the procedure of resolving task or tickets ( for example: the task is open to every one ? or it's assigned to a specified member and he must do it! ).
On Fri, Oct 28, 2011 at 2:12 PM, Toshio Kuratomi a.badger@gmail.com wrote:
On Fri, Oct 28, 2011 at 02:20:43AM +0000, Bousselham EL HADDAOUI wrote:
Hello Toshio, thank you for the response :), actually I'm not a Python programmer :s ,
I now
Java, C, PHP, Lisp ... that can take some time to learn Python and get an advanced level. I will try to look at the links. and I will see if can do some thing ( I
hope
so :) ).
Excellent. If you'd like to start learning python, starting with a sys-admin scripting task might be easier. I opened one last night that could fit:
https://fedorahosted.org/fedora-infrastructure/ticket/2997
If you take that on, you'd need to learn how to:
- import libraries in python
- instantiate an object
- call a method on the object
- work with python lists and dicts
- basic looping and conditional structures
- print to the screen
The script itself should be pretty short so this would be a good intro-to-python task if python is something you want to learn.
-Toshio
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Fri, Oct 28, 2011 at 02:44:23PM +0000, Bousselham EL HADDAOUI wrote:
Thank you. Now I must learn first Python and I will see if I can do this task. I have a question : what is the procedure of resolving task or tickets ( for example: the task is open to every one ? or it's assigned to a specified member and he must do it! ).
A mixture :-). Tasks are open to everyone. Not everyone has permission to perform a fix or not everyone has permission to commit a fix. In the latter case, adding the fix as an attachment to the ticket and/or pinging someone on IRC to review and commit it is what happens (and as you start doing that, your name becomes well known and you become a candidate for getting more permission).
Usually, people assign tickets to themselves when they take on the task. That way other people know that you are working on it. Once in a while, if we don't hear back from you, we may ping to see if you're still working on it or if we should open it up for someone else to take a crack at.
(Speaking of which, go ahead and assign that ticket to yourself :-)
-Toshio
Hello, Thank you for the explanation, it was brief and good. I hope you hear something good from me next days ;) !.
On Fri, Oct 28, 2011 at 4:41 PM, Toshio Kuratomi a.badger@gmail.com wrote:
On Fri, Oct 28, 2011 at 02:44:23PM +0000, Bousselham EL HADDAOUI wrote:
Thank you. Now I must learn first Python and I will see if I can do this
task.
I have a question : what is the procedure of resolving task or tickets (
for
example: the task is open to every one ? or it's assigned to a specified
member
and he must do it! ).
A mixture :-). Tasks are open to everyone. Not everyone has permission to perform a fix or not everyone has permission to commit a fix. In the latter case, adding the fix as an attachment to the ticket and/or pinging someone on IRC to review and commit it is what happens (and as you start doing that, your name becomes well known and you become a candidate for getting more permission).
Usually, people assign tickets to themselves when they take on the task. That way other people know that you are working on it. Once in a while, if we don't hear back from you, we may ping to see if you're still working on it or if we should open it up for someone else to take a crack at.
(Speaking of which, go ahead and assign that ticket to yourself :-)
-Toshio
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Thu, 27 Oct 2011 15:20:43 -0700 Toshio Kuratomi wrote:
This release is intended mostly for getting the majority of hotfixes that are in infrastructure's puppet repository into an rpm package as well as pulling some other features (like a more readable captcha) into production.
Also the bugzilla plugin for changing the mail address there? It would be really nice to have that feature.
Tom
On Sun, Oct 30, 2011 at 12:58:02AM +0200, Thomas Spura wrote:
On Thu, 27 Oct 2011 15:20:43 -0700 Toshio Kuratomi wrote:
This release is intended mostly for getting the majority of hotfixes that are in infrastructure's puppet repository into an rpm package as well as pulling some other features (like a more readable captcha) into production.
Also the bugzilla plugin for changing the mail address there? It would be really nice to have that feature.
It would be but as far as I know, no one has done any work to create that. Any interested takers? It's not an easy fix but it would be a very, very helpful feature to have.
-Toshio
On Sun, 30 Oct 2011 10:07:02 -0700 Toshio Kuratomi wrote:
On Sun, Oct 30, 2011 at 12:58:02AM +0200, Thomas Spura wrote:
On Thu, 27 Oct 2011 15:20:43 -0700 Toshio Kuratomi wrote:
This release is intended mostly for getting the majority of hotfixes that are in infrastructure's puppet repository into an rpm package as well as pulling some other features (like a more readable captcha) into production.
Also the bugzilla plugin for changing the mail address there? It would be really nice to have that feature.
It would be but as far as I know, no one has done any work to create that. Any interested takers? It's not an easy fix but it would be a very, very helpful feature to have.
And what's this? http://git.fedorahosted.org/git/?p=fas.git;a=tree;f=plugins/fas-plugin-bugzi...
When I was looking into it, I wasn't able to get a local fas instance running. (But was some really long time ago)
Tom
On Sun, Oct 30, 2011 at 06:17:51PM +0100, Thomas Spura wrote:
On Sun, 30 Oct 2011 10:07:02 -0700 Toshio Kuratomi wrote:
On Sun, Oct 30, 2011 at 12:58:02AM +0200, Thomas Spura wrote:
On Thu, 27 Oct 2011 15:20:43 -0700 Toshio Kuratomi wrote:
This release is intended mostly for getting the majority of hotfixes that are in infrastructure's puppet repository into an rpm package as well as pulling some other features (like a more readable captcha) into production.
Also the bugzilla plugin for changing the mail address there? It would be really nice to have that feature.
It would be but as far as I know, no one has done any work to create that. Any interested takers? It's not an easy fix but it would be a very, very helpful feature to have.
And what's this? http://git.fedorahosted.org/git/?p=fas.git;a=tree;f=plugins/fas-plugin-bugzi...
When I was looking into it, I wasn't able to get a local fas instance running. (But was some really long time ago)
I hadn't seen that before... Mike, is that code finished and ready, just needs to be packaged?
We'd also need to figure out how to get that information out to the bugzilla syncing scripts/other users who need to access this.... We could special case it on the servers (kinda defeats the purpose of having it in a plugin), add it to the client code in python-fedora (but, at least with the methods I see exposed right now, that means an extra query per user returned which will be unacceptably slow -- probably needs a method to return all the bugzilla emails which would mean client-side we'd have to wait for one extra query per request -- that could be cached on the client-side which would make it faster for scripts that make many calls to one fas objects but still slower for scripts that either run once and then exit or have to use separate fas instances (for instance, for threadsafety)).
(Now that I'm going over the problems... I have a vague recollection that Mike might have queried me about these same topics long ago and pinged me about it... if that's correct, maybe we never came up with good answers to this and that's why we've never deployed this.)
Another option would be to break backwards compatibility and tell people that bugzilla_email addresses have to be queried separately. It's been quite a while since we had an API break so it's not out of the question to do that. We might want to look at whether there's some other low hanging fruit that we've put off due to API breakage at the same time, though.
-Toshio
On Sun, Oct 30, 2011 at 11:29 AM, Toshio Kuratomi a.badger@gmail.com wrote:
On Sun, Oct 30, 2011 at 06:17:51PM +0100, Thomas Spura wrote:
On Sun, 30 Oct 2011 10:07:02 -0700 Toshio Kuratomi wrote:
We'd also need to figure out how to get that information out to the bugzilla syncing scripts/other users who need to access this.... We could special case it on the servers (kinda defeats the purpose of having it in a plugin), add it to the client code in python-fedora (but, at least with the methods I see exposed right now, that means an extra query per user returned which will be unacceptably slow -- probably needs a method to return all the bugzilla emails which would mean client-side we'd have to wait for one extra query per request -- that could be cached on the client-side which would make it faster for scripts that make many calls to one fas objects but still slower for scripts that either run once and then exit or have to use separate fas instances (for instance, for threadsafety)).
(Now that I'm going over the problems... I have a vague recollection that Mike might have queried me about these same topics long ago and pinged me about it... if that's correct, maybe we never came up with good answers to this and that's why we've never deployed this.)
Another option would be to break backwards compatibility and tell people that bugzilla_email addresses have to be queried separately. It's been quite a while since we had an API break so it's not out of the question to do that. We might want to look at whether there's some other low hanging fruit that we've put off due to API breakage at the same time, though.
Another thing we'd need to look at is how to change the code that modifies bugzilla when email addresses are updated. The code presently lives in core fas and updates a table when an email address changes. The table lists email addresses that need to have permissions in bugzilla changed. Then a cron job goes through that table and adds and removes bugzilla permissions.
With bugzilla addresses in a plugin, the plugin would need to somehow monitor changes to email addresses or that table and decide whether to use the bugzilla email or main fas email when updating permissions. FAS core doesn't currently provide event-type hooks for plugins. It only provides the means for plugins to register that they want to be included in the FAS UI and tables to save any data to.
One option that was tossed out a while ago is whether to give up on having this in a plugin; instead making it part of FAS core. Doing that, there would be no separation between parts so the code that updated an email address would know about both the main FAS email address and the bugzilla email address and be able to update the queue of email addresses to change appropriately.
-Toshio
infrastructure@lists.fedoraproject.org
-
Bousselham EL HADDAOUI -
Thomas Spura -
Toshio Kuratomi