Working on next FAS release

[Toshio Kuratomi]

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

[Bousselham EL HADDAOUI]

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(a)gmail.com&gt;wrote:

>  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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>  


-- 
Bousselham EL HADDAOUI
Élève ingénieur en 3ème année
École Nationale Supérieure d'Informatique et d'Analyse des
Systèmes<http://www.ensias.ma/>
Tél : [phone]

[Toshio Kuratomi]

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

[Bousselham EL HADDAOUI]

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(a)gmail.com&gt;wrote:

>  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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>  


-- 
Bousselham EL HADDAOUI
Élève ingénieur en 3ème année
École Nationale Supérieure d'Informatique et d'Analyse des
Systèmes<http://www.ensias.ma/>
Tél : [phone]

[Toshio Kuratomi]

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

[Bousselham EL HADDAOUI]

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(a)gmail.com&gt; 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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>  


-- 
Bousselham EL HADDAOUI
Élève ingénieur en 3ème année
École Nationale Supérieure d'Informatique et d'Analyse des
Systèmes<http://www.ensias.ma/>
Tél : [phone]

[Toshio Kuratomi]

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

[Bousselham EL HADDAOUI]

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(a)gmail.com&gt; 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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>  


-- 
Bousselham EL HADDAOUI
Élève ingénieur en 3ème année
École Nationale Supérieure d'Informatique et d'Analyse des
Systèmes<http://www.ensias.ma/>
Tél : [phone]

[Thomas Spura]

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

[Toshio Kuratomi]

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

[Thomas Spura]

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-bu...

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

[Toshio Kuratomi]

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-bu...
>  
>  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

[Toshio Kuratomi]

On Sun, Oct 30, 2011 at 11:29 AM, Toshio Kuratomi <a.badger(a)gmail.com&gt; 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