bodhi interface changes

[Luke Macken]

Hey everyone,

I recently made some UI modifications to my bodhi development branch that, in my opinion,
make things a bit more elegant, and remove a lot of unnecessary data.

    http://lmacken.fedorapeople.org/before.png
    http://lmacken.fedorapeople.org/after.png

So, with regard to the left side menu, I re-organized it by Release, instead of by update
status.  This not only makes things less redundant, but will also allow us to know exactly
what release an update is getting pushed for in the New Update Form -- which will let us
remove the release dropdown[0], and auto-complete *only* builds that *can* be pushed for
that specific release.

Regarding the update list.. I removed the Release column and the status, because that can
be implied by the title of the list.  I also added a submitter column, because
accountability is a good thing.  With the pending screen, I added a Request column, so
people can get a quick glance as to where the updates are going.

I wanted to run this by everyone, to avoid any OMGWTFREGRESSION!1 emails, and to see if
anyone has any comments/suggestions/oppositions.

luke

[0]: https://hosted.fedoraproject.org/projects/bodhi/ticket/84

[Jon Ciesla]

>  Hey everyone,
>
>  I recently made some UI modifications to my bodhi development branch that,
>  in my opinion, make things a bit more elegant, and remove a lot of
>  unnecessary data.
>
>      http://lmacken.fedorapeople.org/before.png
>      http://lmacken.fedorapeople.org/after.png
>
>  So, with regard to the left side menu, I re-organized it by Release,
>  instead of by update status.  This not only makes things less redundant,
>  but will also allow us to know exactly what release an update is getting
>  pushed for in the New Update Form -- which will let us remove the release
>  dropdown[0], and auto-complete *only* builds that *can* be pushed for that
>  specific release.
>
>  Regarding the update list.. I removed the Release column and the status,
>  because that can be implied by the title of the list.  I also added a
>  submitter column, because accountability is a good thing.  With the
>  pending screen, I added a Request column, so people can get a quick glance
>  as to where the updates are going.
>
>  I wanted to run this by everyone, to avoid any OMGWTFREGRESSION!1 emails,
>  and to see if anyone has any comments/suggestions/oppositions. 
+1 helpful

>  luke
>
>  [0]: https://hosted.fedoraproject.org/projects/bodhi/ticket/84
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  

-- 
novus ordo absurdum

[Till Maas]

On Mi September 19 2007, Luke Macken wrote:

>  pushed for in the New Update Form -- which will let us remove the
> release
>  dropdown[0], and auto-complete *only* builds that *can* be pushed for that
>  specific release. 
>  I wanted to run this by everyone, to avoid any OMGWTFREGRESSION!1
> emails,
>  and to see if anyone has any comments/suggestions/oppositions. 
Imho there should be also a way to createa an update for two releases at once. 
E.g. when Fedora 8 is out, and a package is updated for it, often there will 
be the same update for Fedora 7. It seems that this was easier possible with 
the old interface, because one should be able to just go back and change the 
release and the build, but keep the bugs / cves and notice. But for a 
complete support of "identical" updates for two releases, I guess there needs 
to be changed a lot more, anyway, e.g. when one wants to edit both updates.

Regards,
Till

[Luke Macken]

On Wed, Sep 19, 2007 at 07:41:12PM +0200, Till Maas wrote:
>  On Mi September 19 2007, Luke Macken wrote:
>  
>  > pushed for in the New Update Form -- which will let us remove the release
>  > dropdown[0], and auto-complete *only* builds that *can* be pushed for that
>  > specific release.
>  
>  > I wanted to run this by everyone, to avoid any OMGWTFREGRESSION!1 emails,
>  > and to see if anyone has any comments/suggestions/oppositions.
>  
>  Imho there should be also a way to createa an update for two releases at once. 
>  E.g. when Fedora 8 is out, and a package is updated for it, often there will 
>  be the same update for Fedora 7. It seems that this was easier possible with 
>  the old interface, because one should be able to just go back and change the 
>  release and the build, but keep the bugs / cves and notice. But for a 
>  complete support of "identical" updates for two releases, I guess there needs 
>  to be changed a lot more, anyway, e.g. when one wants to edit both updates. 
In that case it may be best to make a single generic update form
that will accept any candidate build, and will imply the Release(s) from
there.

luke

[Thorsten Leemhuis]

On 19.09.2007 19:41, Till Maas wrote:
>  On Mi September 19 2007, Luke Macken wrote:
> > pushed for in the New Update Form -- which will let us remove the release
> > dropdown[0], and auto-complete *only* builds that *can* be pushed for that
> > specific release.
> > I wanted to run this by everyone, to avoid any OMGWTFREGRESSION!1 emails,
> > and to see if anyone has any comments/suggestions/oppositions.
>  Imho there should be also a way to createa an update for two releases at once. 
>  E.g. when Fedora 8 is out, and a package is updated for it, often there will 
>  be the same update for Fedora 7. It seems that this was easier possible with 
>  the old interface, because one should be able to just go back and change the 
>  release and the build, but keep the bugs / cves and notice. But for a 
>  complete support of "identical" updates for two releases, I guess there needs 
>  to be changed a lot more, anyway, e.g. when one wants to edit both updates. 
While I agree in general to make stuff easier: Wouldn't it be better to
normally ship the F7 update some days after shipping the one for F8 (and
that itself some days after it hit devel)?

That IMHO has a important benefit: if a crucial bug made it into F8
because it was not noticed in devel or updates-testing earlier there is
still time left to *not* ship that update for F7.

Cu
knurd

[Luke Macken]

On Wed, Sep 19, 2007 at 08:04:16PM +0200, Thorsten Leemhuis wrote:
>  On 19.09.2007 19:41, Till Maas wrote:
>  > On Mi September 19 2007, Luke Macken wrote:
>  >> pushed for in the New Update Form -- which will let us remove the release
>  >> dropdown[0], and auto-complete *only* builds that *can* be pushed for that
>  >> specific release.
>  >> I wanted to run this by everyone, to avoid any OMGWTFREGRESSION!1 emails,
>  >> and to see if anyone has any comments/suggestions/oppositions.
>  > Imho there should be also a way to createa an update for two releases at once. 
>  > E.g. when Fedora 8 is out, and a package is updated for it, often there will 
>  > be the same update for Fedora 7. It seems that this was easier possible with 
>  > the old interface, because one should be able to just go back and change the 
>  > release and the build, but keep the bugs / cves and notice. But for a 
>  > complete support of "identical" updates for two releases, I guess there
> needs 
>  > to be changed a lot more, anyway, e.g. when one wants to edit both updates.
>  
>  While I agree in general to make stuff easier: Wouldn't it be better to
>  normally ship the F7 update some days after shipping the one for F8 (and
>  that itself some days after it hit devel)?
>  
>  That IMHO has a important benefit: if a crucial bug made it into F8
>  because it was not noticed in devel or updates-testing earlier there is
>  still time left to *not* ship that update for F7. 
Agreed.  Stuffing multiple releases into a single update would make the
whole karma/updates-testing thing painful.  Maybe the best solution is
to make it trivial to "clone" an update for another release ?  Or we
could have the form automatically clone the update for each release
based on the provided builds ?

luke

[Jonathan Steffan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luke Macken wrote:
[...]
>  Agreed.  Stuffing multiple releases into a single update would make
> the
>  whole karma/updates-testing thing painful.  Maybe the best solution is
>  to make it trivial to "clone" an update for another release ?  Or we
>  could have the form automatically clone the update for each release
>  based on the provided builds ? 
I might have missed this... What is karma, how do we use it? How do we
increase our packages' karma? What is karma currently used for?

Jonathan Steffan
daMaestro

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFG8XjOrRJs5w2Gr1kRAqS+AJ91vZZu291JbYYXxYyuFRlUF2kUiwCgkDRw
> EIcpEhzCY47KSDYUCY7Y518=
> =BZiH
> -----END PGP SIGNATURE-----

[Rahul Sundaram]

Jonathan Steffan wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Luke Macken wrote:
>  [...]
> > Agreed.  Stuffing multiple releases into a single update would make the
> > whole karma/updates-testing thing painful.  Maybe the best solution is
> > to make it trivial to "clone" an update for another release ?  Or we
> > could have the form automatically clone the update for each release
> > based on the provided builds ?
>  
>  I might have missed this... What is karma, how do we use it? How do we
>  increase our packages' karma? What is karma currently used for? 
See http://bpepple.fedorapeople.org/FESCo-2007-09-06.html. It is a 
feedback/voting mechanism for pushing packages from updates-testing to 
updates.

Rahul

[Luke Macken]

On Wed, Sep 19, 2007 at 01:30:23PM -0600, Jonathan Steffan wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Luke Macken wrote:
>  [...]
>  > Agreed.  Stuffing multiple releases into a single update would make the
>  > whole karma/updates-testing thing painful.  Maybe the best solution is
>  > to make it trivial to "clone" an update for another release ?  Or we
>  > could have the form automatically clone the update for each release
>  > based on the provided builds ?
>  
>  I might have missed this... What is karma, how do we use it? How do we
>  increase our packages' karma? What is karma currently used for? 
It's a simple integer that is incremented/decremented based on if
the update works or not for the tester.  Right now, when an update
reaches a karma of 3, it is automatically pushed to stable.

This mechanism is definitely subject to change over time, so feedback is
welcome :)

luke

[Till Maas]

On Wednesday 19 September 2007 22:10:35 Luke Macken wrote:

>  This mechanism is definitely subject to change over time, so feedback
> is
>  welcome :) 
It would be nice if one could easily change ones karma vote instead of adding 
another value, i.e. each user should only be able to give either +1,0 or -1 
Karma Votes and the last given vote counts. Currently it seems that one can 
only change a -1 vote to +1 with to +1 votes.

Regards,
Till

[Luke Macken]

On Wed, Sep 19, 2007 at 10:24:24PM +0200, Till Maas wrote:
>  On Wednesday 19 September 2007 22:10:35 Luke Macken wrote:
>  
>  > This mechanism is definitely subject to change over time, so feedback is
>  > welcome :)
>  
>  It would be nice if one could easily change ones karma vote instead of adding 
>  another value, i.e. each user should only be able to give either +1,0 or -1 
>  Karma Votes and the last given vote counts. Currently it seems that one can 
>  only change a -1 vote to +1 with to +1 votes. 
Yeah, that definitely sounds reasonable... right now you can only adjust
the karma once in each direction -- thus negating your vote.  Feel free to open
a ticket.

luke

[Jonathan Steffan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luke Macken wrote:
>  On Wed, Sep 19, 2007 at 01:30:23PM -0600, Jonathan Steffan wrote:
> > I might have missed this... What is karma, how do we use it? How do we
> > increase our packages' karma? What is karma currently used for?
>  
>  It's a simple integer that is incremented/decremented based on if
>  the update works or not for the tester.  Right now, when an update
>  reaches a karma of 3, it is automatically pushed to stable.
>  
>  This mechanism is definitely subject to change over time, so feedback is
>  welcome :) 
I think it is awesome. Good work.


Jonathan
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFG8ZQsrRJs5w2Gr1kRAglnAKCDjNEtNTbFxGEhLrqS6yQ+sDsgVgCfQc7W
> zuBGi85VeKKED+cnSWIGes0=
> =5Qb8
> -----END PGP SIGNATURE-----

[Till Maas]

On Wednesday 19 September 2007 20:04:16 Thorsten Leemhuis wrote:

>  While I agree in general to make stuff easier: Wouldn't it be
> better to
>  normally ship the F7 update some days after shipping the one for F8 (and
>  that itself some days after it hit devel)? 
The creation of an update and pushing it to stable or testing are two 
different tasks, even when both updates are created at the same time, this 
does not mean that they need to be pushed to some repository at the same 
time.

Regards,
Till

[Tim Lauridsen]

Luke Macken wrote:
>  Hey everyone,
>
>  I recently made some UI modifications to my bodhi development branch that, in my opinion,
> make things a bit more elegant, and remove a lot of unnecessary data.
>
>      http://lmacken.fedorapeople.org/before.png
>      http://lmacken.fedorapeople.org/after.png
>
>  So, with regard to the left side menu, I re-organized it by Release, instead of by update
> status.  This not only makes things less redundant, but will also allow us to know exactly
> what release an update is getting pushed for in the New Update Form -- which will let us
> remove the release dropdown[0], and auto-complete *only* builds that *can* be pushed for
> that specific release.
>
>  Regarding the update list.. I removed the Release column and the status, because that can
> be implied by the title of the list.  I also added a submitter column, because
> accountability is a good thing.  With the pending screen, I added a Request column, so
> people can get a quick glance as to where the updates are going.
>
>  I wanted to run this by everyone, to avoid any OMGWTFREGRESSION!1 emails, and to see if
> anyone has any comments/suggestions/oppositions.
>
>  luke
>
>  [0]: https://hosted.fedoraproject.org/projects/bodhi/ticket/84
>
>     
Looks good to me.

Tim