repositories beyond kde-workspace

[Aaron J. Seigo]

here are my current thoughts on these questions:

On Monday, January 14, 2013 17:51:50 Aaron J. Seigo wrote:
> * where should the repositories live?

i'd like to see a single Workspaces category on projects.kde.org. the current 
kde-workspace repo would be moved to it, and we'd add in all the other 
repositories which also make up workspaces.

so instead of having bits in extragear as well as some in the "KDE" area on 
projects.kde.org, we'd have all of our workspace pieces in one place.

of course, projects could keep their repositories elsewhere if they wish. but 
we would only consider repositories maintained in Workspaces as candidates for 
being made a part of our desktop product. repositories elsewhere would be 
considered 3rd party add-ons that others would need to work integration 
strategies out for.

this let us define our scope clearly. right now we have repositories scattered 
in various places and it becomes very difficult to know what all ought to be a 
part of the Workspace releases and strategy.

i think it would make sense to move the Plasma Active related repositories 
there as well (plasma-mobile, plasma-active-maliit, ..)

this would imply other changes related to releases, which i'll cover below.

in the more distant future, i think it would make sense to split up the 
monolithic kde-workspace repository a bit as well .. but we can figure that 
pickle out later.

> * what should the devel strategy of these repositories be?

i'd like to see at most 2 development methods defined and used. this is to 
ballance between the idea that "one method will not fit every project" and 
"having consistency makes it easier to move between and work on different 
projects". these might be:

* "always releasable master" with an integration branch
* feature-branch based devel with merges into master

we would need to explicitly define which each repository is practicing. the 
choice woudl be up to the maintainer of the module.

coding style should also be harmonized across all repositories for similar 
reasons.

> * what should the release cycle of these repositories be?

at least for now, kde-workspace itself will need to maintain the 6 month KDE 
SC release cycle.

for smaller repositories, or repos like plasma-mobile, this just does not make 
sense. they may need to release more often or in response to different external 
needs.

however, when we do an SC release, we should try to include a tarball for 
every module based on their last stable release. the 'C' in 'SC' stands for 
"compilation", after all.

this way every module can do releases at their own pace, and we can still offer 
a twice a year drop of "everything".


i think this could have several useful effects, such as:

it will drive us to include only repositories in these "everything" releases 
that can be co-installed. so, for instance, if we want to be able to switch at 
runtime between a touch focused Plasma Active shell and a Plasma Desktop one, 
then we will need to work on making it possible to ship them together in a way 
that everything can be build accordingly.

it may also give us the needed motivation to document what we consider a 
"Plasma Desktop" configuration. downstreams may not follow this 100% in their 
packaging decisions, of course, but it will give us a clear idea of what we're 
aiming for and help downstream integrators figure out how to deliver our 
offering better as well.

> * how do we want to coordinate on direction, strategy, needs, overall
> composition, etc?

maintainers and communication ... :)

each repository must have a maintainer that needs to be kept somewhere public 
so we all know who those people are, and what their module focuses on. that 
way we can know who should be included in which discussions.

(kde-workspace is a bit complicated: it needs a few maintainers as it contains 
a number of individual projects. this is perhaps a clue that we could/should 
break it up in future.) 

projects may have their own mailing lists, but all maintainers need to be 
subscribed to (and active, as relevant) to a shared workspace mailing list. 
this could be plasma-devel@, or a new mailing list (i don't have strong 
feelings way way or the other on this).

we also should have 2-3 people who take on the role of workspace coordinators. 
one of these people needs to take on the responsibility of ensuring a process 
is carried through for a given Workspace release. they can rotate this role 
between them, and they can of course be replaced as needed. the people doing 
this need to be relatively decent at herding cats (that's us :), organizing 
and holding meetings as needed, ensuring schedules are being adhered to and 
watching goal targets. given that, those who have those skills and can put 
aside the time time and energy to do it would probably give us our 2-3 people 
pretty easily.

then we define a repeatable plan and the coordinators ensure it gets 
implemented (repeatedly :), including:

* at the start of each (shared) release cycle, an irc meeting with as many 
contributors in attendance as possible, esp maintainers. the meeting should 
result in a set of goals and expectations for the release.

* at the SC feature freeze, or if we depart from that then 2/3rd the way 
through the combined release cycle, examine those goals and expectations, see 
where we are, which needs doing, etc.

* coordinate the combined release

* keep an eye on activity in the repositories for big changes that might get 
missed as needing coordination between modules

* try to keep public communication going (e.g. encouraging people to blog ;)

* ensure that cross-repository/project topics are getting attention. 

* ensure that we have at least 1 dev sprint per year.

* ensure that we have ample opportunity to meet and coordinate at Akademy.

note that the coordinators don't necessarily need to do all of the above 
themselves, they just need to ensure that it is getting done.

maintainers would commit to:

* communicating their projects needs and goals (might make sense to gather 
this information somewhere centrally)

* communicating upcoming / ongoing changes to each other via the workspace 
mailing list so we can accomodate changes that may have impacts on others 
(among other things, e.g. they get attention in public announcements)

* contributing to Workspace goal setting exercises

* commit to having releasable results that work well with the rest of the 
Workspace components.

> Are we making a product or a toolbox? e.g.:

i'd like to see us focus more on making a product rather than a collection of 
tools. with a set of tools, you have to gather them and put them together 
yourself. there are weak guarantees that any pieces work perfectly with all 
other pieces. 

if we instead focus on making an actual product, we'll force ourselves to 
think about how things fit together, how they look together, how they work 
together. this will in turn allow our downstream partners to create much 
better results as the tools we give them will actually be designed to work 
well with each other.

we can maintain our philosophy of a highly componentized product. we benefit 
from this because it allows us to keep our product agile and easily changeable 
as needed in the future.

by creating a product, we don't need to weld everything tightly together. we 
just need to think about how things can work together and how well they each 
compliment each other. it will encourage us to build shared goals and work 
towards common results.

this is something we are lacking to some extent outside of a handful of 
projects that work very closely already for Plasma Desktop and the group that 
works on Plasma Active.

> Shared or individual vision?

i'd rather have a shared vision, and I think this will flow naturally from 
focusing on creating a "product" rather than only a "toolbox"

i think each project team needs to self-determine how to achieve that vision 
in their repository.

so we decide where we want to end up together, but we draw the path we take on 
that journey ourselves. as long as we communicate as we're doing so, we'll end 
up with the flexibility to do what we need to do in the project pieces we're 
responsible for without someone dictating to us while also heading along 
similar roads.

> What attributes in our products do we aim for?

power and beauty in a shape anyone can use.
a combination of innovative ideas and adopting best practices.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130115/25620657/attachment-0001.sig>