[Modularity] BPO - the great UI that shows you everything

[Adam Samalik]

Hi everyone,

I would like to hear your opinion/need your help!

I am working on a component of the Fedora Modularity[1] project, called
Build Pipeline Overview (BPO). It will be a single user interface (probably
both web and API) that would give you information about "everything".  And
I would like your help with defining what that "everything" means.

To make the definition of "everything" easier, we are using a concept of
personas. These are basically groups of people that would use the BPO UI
that will help us to identify possible use-cases.

@threebean have identified four personas:
 - Engineers/packagers
 - Release Engineering
 - QA
 - Project Management

I have put them into an Etherpad document [2].


What I'm asking from you: Could you please discuss here or in the document
what would you like to see in the BPO UI? Or what do you think should be
there. I would like to get as much input as possible.

Thanks!
Adam


[1] https://fedoraproject.org/wiki/Modularization
[2] http://piratepad.nl/3h3lMUwld3

-- 

Adam Šamalík
---------------------------
Associate Software Engineer
Red Hat

[Adam Williamson]

On Wed, 2016-06-29 at 18:18 +0200, Adam Samalik wrote:
>  Hi everyone,
>  
>  I would like to hear your opinion/need your help!
>  
>  I am working on a component of the Fedora Modularity[1] project, called
>  Build Pipeline Overview (BPO). It will be a single user interface (probably
>  both web and API) that would give you information about "everything".  And
>  I would like your help with defining what that "everything" means.
>  
>  To make the definition of "everything" easier, we are using a concept of
>  personas. These are basically groups of people that would use the BPO UI
>  that will help us to identify possible use-cases.
>  
>  @threebean have identified four personas:
>   - Engineers/packagers
>   - Release Engineering
>   - QA
>   - Project Management
>  
>  I have put them into an Etherpad document [2].
>  
>  
>  What I'm asking from you: Could you please discuss here or in the document
>  what would you like to see in the BPO UI? Or what do you think should be
>  there. I would like to get as much input as possible. 
For the record, as a QA person, I find this kind of squishy 'I'm
building a thing, tell me what it should look like' question just
impossible to answer. I cannot come up with anything until there's
something more concrete to look at. Other QA folks may have better
input, but it would be a good idea to send this mail to test@, since
that is the official QA list.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kevin Fenzi]

On Wed, 29 Jun 2016 10:51:13 -0700
Adam Williamson <adamwill(a)fedoraproject.org&gt; wrote:

>  On Wed, 2016-06-29 at 18:18 +0200, Adam Samalik wrote:
>  > Hi everyone,
>  > 
>  > I would like to hear your opinion/need your help!
>  > 
>  > I am working on a component of the Fedora Modularity[1] project,
>  > called Build Pipeline Overview (BPO). It will be a single user
>  > interface (probably both web and API) that would give you
>  > information about "everything".  And I would like your help with
>  > defining what that "everything" means.
>  > 
>  > To make the definition of "everything" easier, we are using a
>  > concept of personas. These are basically groups of people that
>  > would use the BPO UI that will help us to identify possible
>  > use-cases.
>  > 
>  > @threebean have identified four personas:
>  >  - Engineers/packagers
>  >  - Release Engineering
>  >  - QA
>  >  - Project Management
>  > 
>  > I have put them into an Etherpad document [2].
>  > 
>  > 
>  > What I'm asking from you: Could you please discuss here or in the
>  > document what would you like to see in the BPO UI? Or what do you
>  > think should be there. I would like to get as much input as
>  > possible.  
>  
>  For the record, as a QA person, I find this kind of squishy 'I'm
>  building a thing, tell me what it should look like' question just
>  impossible to answer. I cannot come up with anything until there's
>  something more concrete to look at. Other QA folks may have better
>  input, but it would be a good idea to send this mail to test@, since
>  that is the official QA list. 
Yeah, it's a bit hard when we don't know what "everything" means
here. :) 

That said a few comments: 

* Should there be a 'developer' or 'end user' type here? Ie, is it
  expected that they would want to look at this to see what the latest
  version of some module they care about is, or if there's new ones
  that might be coming along soon? Or is that another tool?

* Depending again on the kinds of things this can report on,
  infrastructure might be interested in it. Could we query it via
  nagios to let us know about problems in module building or testing ? 

* Modules can depend on other modules right? If so, a way to see that
  tree of dependencies in building would be nice (ie, moduleA depends
  on moduleB, and moduleB is currently rebuilding for foo, moduleA
  should show that it's pending rebuilding after that, etc)

I'm not sure I can provide much more until we have more information on
what information we can have there. ;) 

kevin

[Adam Samalik]

Thanks for the response. I agree, asking you "I am building something I
haven't described, how do you want to use it?" might have not been the best
idea... So please, let me try that again and better. :-)

I have created a wiki page [1] that briefly describes the BPO component,
what data would be available, and the main three possible functions.



>  * Should there be a 'developer' or 'end user' type here? Ie, is it
>    expected that they would want to look at this to see what the latest
>    version of some module they care about is, or if there's new ones
>    that might be coming along soon? Or is that another tool?
>  
It would be probably both. But I would focus mainly on developers in the
early stage. Later, there might be something similar to what you described
for the end user.


>  * Depending again on the kinds of things this can report on,
>    infrastructure might be interested in it. Could we query it via
>    nagios to let us know about problems in module building or testing ?
>  
If you would use something like this, I would be happy to include it in the
BPO.


>  * Modules can depend on other modules right? If so, a way to see that
>    tree of dependencies in building would be nice (ie, moduleA depends
>    on moduleB, and moduleB is currently rebuilding for foo, moduleA
>    should show that it's pending rebuilding after that, etc)
>  
Yes. This should also be there.



[1] https://fedoraproject.org/wiki/Modularity/BPO

-- 

Adam Šamalík
---------------------------
Associate Software Engineer
Red Hat

[Ralph Bean]

On Fri, Jul 01, 2016 at 06:14:00PM +0200, Adam Samalik wrote:
>  Thanks for the response. I agree, asking you "I am building
> something I
>  haven't described, how do you want to use it?" might have not been the best
>  idea... So please, let me try that again and better. :-) 
Thanks Adam :)

>  I have created a wiki page [1] that briefly describes the BPO
> component,
>  what data would be available, and the main three possible functions.
>  
>  
>  
>  >
>  > * Should there be a 'developer' or 'end user' type here? Ie, is it
>  >   expected that they would want to look at this to see what the latest
>  >   version of some module they care about is, or if there's new ones
>  >   that might be coming along soon? Or is that another tool?
>  >
>  It would be probably both. But I would focus mainly on developers in the
>  early stage. Later, there might be something similar to what you described
>  for the end user.
>  
>  
>  >
>  > * Depending again on the kinds of things this can report on,
>  >   infrastructure might be interested in it. Could we query it via
>  >   nagios to let us know about problems in module building or testing ?
>  >
>  If you would use something like this, I would be happy to include it in the
>  BPO.
>  
>  
>  >
>  > * Modules can depend on other modules right? If so, a way to see that
>  >   tree of dependencies in building would be nice (ie, moduleA depends
>  >   on moduleB, and moduleB is currently rebuilding for foo, moduleA
>  >   should show that it's pending rebuilding after that, etc)
>  >
>  Yes. This should also be there.
>  
>  
>  
>  [1] https://fedoraproject.org/wiki/Modularity/BPO 
Here are some thoughts on the context.

Currently, when a packager packages a new upstream release, then build
it for rawhide and then they think "what stable releases to I want to
also build and ship this for?"  Maybe all of them?  Maybe just F24?
The point is that the packager thinks about it, knows what they're
doing, and then does it.

Then, about 24 hours later, releng scoops up whatever has been done.

- For rawhide, pungi builds the repos and ships it out.
- For stable releases, bodhi mashes repos, and ships them out.

The most grizzled veterans will rightly balk when I say, "it's easy to
know what state an update is in."  But.. it's more or less linear.
Was it patched but not built?  Was it built but not added to an
update?  Was it in an update but not yet pushed?  Is it pushed but not
yet on the secondary mirrors?  Etc..

In the Modularity Working Group (for various reasons) we're talking
about building automation services on top of koji that will
automatically rebuild modules based on new available components (these
are rpms) (and only sometimes, based on policy).

Furthermore, we're hoping to break some of the releng tasks (like the
24 hour nightly compose/push) out into ad hoc tasks that happen
alongside, shortly after builds of intermediary components are done
(triggered by message bus events).

So, that's hard to do.  We're working on trying to get it right.  One
side effect of deploying it is that it's going to be super confusing
for packagers to look at this whole thing and figure out what state a
patch is in.  Say I patched a CVE in component X.  Has it been rebuilt
into modules L, M, and N?  Did it fail in module O's buildroot?  If
those have been built, which have been shipped?  That's all from the
developer standpoint who starts from a patch.  Release engineering
would want a similar kind of question to be answerable:  if we have a
patch that fixes CVE blah-blah-blah, has that been built into all the
artifacts we ship now?  Can we say that we've fixed it across the
board so we can write a press release?

We'll have data scattered all over the place that, when put together,
can answer questions like this:  some in koji, some in PDC, some in
bodhi, some in mirrormanager.  The idea here is to make this 'BPO'
service (the Build Pipeline Overview service) something that can make
those questions easily answerable in one place.

In architecture terms, it is like a 'data mart' (convenient access to
data that comes from the 'data warehouse', which is bigger and harder
to interface with).