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
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
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
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
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
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
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
-----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
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
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
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
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
-----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
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
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
Looks good to me.
Tim