reflecting on 4.10

[Alex Fiestas]

On Saturday 12 January 2013 17:57:37 Aaron J. Seigo wrote:
> On Saturday, January 12, 2013 17:38:03 Marco Martin wrote:
> > wonder how much scales for something as big as the kde-workspace repo...
> 
> my experience with plasma-mobile seems to indicate that it is easily done by
> one person. i wouldn't want to see one person doing all of kdelibs, kde-
> runtime, kde-workspace, kdeplasma-addons, plasma-mobile, etc ;) that woudl
> be a bit much, to say the least. but kde-workspace as a repo, no problem.
> 
> it would probably take a couple hours per week maximum.
> 
> keeping record of which branches are being merge (and sometimes in which
> order), what conflict resolution choices are made (when needed) and what
> cherry-picks (if any) are done seems to be the biggest chore.
> 
> the next biggest job is when merging a new branch in, sometimes there are
> conflicts or a newer version of master is needed, or ... and that can take a
> few minutes at times. once the first merge is done, it tends to be a
> cakewalk after that.
> 
> i was honestly pretty hesitant about how much work it would be at first, but
> it's proving to be very, very little work compared to what i was expecting.
> 
> actually *testing* the results takes far, far more time and that is
> something that must be parallelized anyways so we cover as many different
> configurations and hit as many code paths as possible.
> 
> so i think it is reasonable and possible to see one integration branch
> maintainer per repository, with a backup person for each repo.
> 
> > also, for maintaining integration merged.. woder if there could be a bit
> > of
> > automation ivolved?
> 
> probably, but git already makes it so fast that i think little more is
> really needed. i'm more interested in tools for nominating branches as
> merge candidates.

I like what I read we can use this experience as a base to specify a new way 
of working in kde-workspace.

In the recent past, we have had people giving "ship it" in reviewboard to code 
that was not maintained by them and what is worst modifications that broke (or 
still breaks) stuff, we should prevent this from happening.

Some extra information I think can be useful to brainstorm about this is how 
we work in Solid, let me show it with a practical example:

Somebody creates a reviewrequest for PowerDevil which ideally should be 
reviewed by Dario since he's the master of it (even though it is within solid 
umbrella). The community waits for Dario to show up and review the 
modification. Given an unspecified amount of time Lukáš will jump and review 
it since he's kind of the "second aboard" on PowerDevil.
If more time passes and neither Lukáš or Dario has review it, I take it as my 
responsibility (as Solid maintainer) to review it.

Of course int he dead times I will poke Dario/Lukáš to remember them that 
there is a review that should be attended.

In the case of Solid, this has been happening organically we haven't had the 
need to specify it anywhere, I suspect Kevin made the community work that way 
before I join.

This way of working has worked great for us and I can see it working great in 
kde-workspace.