Workflow Idea for 4.10

[Kevin Ottens]

On Friday 16 March 2012 12:58:56 Aaron J. Seigo wrote:
> On Friday, March 16, 2012 00:08:04 Kevin Ottens wrote:
> > I've been thinking about the git workflow to be used in KDE Frameworks in
> > the future. Based on observations and discussions with current and future
> > frameworks maintainer, I think that it would be a mistake to force a
> > single
> > workflow for all the frameworks.
> 
> is this to make life better for the maintainer or the developers?

Both really...

If I was still maintaining libsolid for instance (so putting virtual 
maintainer hat), the very nature of it would make me think that not going for 
feature branches followed by merges in an integration branch would be 
dangerous (and libplasma, akonadi, kio are in a similar corner I think) and 
harder for me to test and review. As a developer? Yes, maybe a bit more work 
than putting stuff into master, but comparatively to the complexity of the 
component it's understandable.

Now, if I want to contribute a feature in karchive (or kdbusaddons, 
kplotting), as a developer it'd look silly to me to have to publish a branch, 
get it merged in an integration branch, push the result, wait for approval and 
then get that merged in master. Hmm, also probably makes it more work for the 
maintainer who'd need to test both the feature branch and the integration 
branch to be able to give a enlightened go/no-go. With the low complexity of 
something like karchive, everyone would be way better off with a private 
branch on the developer side and publishing on reviewboard or discussing on a 
pastebin over IRC.

And we have such different products in frameworks. I don't feel like forcing 
inadequate workflows on them for the sake of it.

> one thing that git as used by kde has done so far for me is severely limit
> my "occasional hacker" pattern where i dive into a given app or library and
> do a bit of work to scratch an itch. this is because we now have a
> gajillion little repositories and as a result i rarely build them these
> days. this is in large part due to me having kdesrc-build around, but not
> really using it much. why? partly because it's a change in my workflow
> (that takes time) and in part because i now have two workflows: one for the
> KDE projects i work on a lot (where i do no use kdesrc-build, because it is
> not appropriate there) and those that i just track.

Of course transition takes time. Now, I wonder what blocks you with kdesrc-
build though. I personally manage to use it for everything just fine, it's 
just that when I jump on a module to work on it I trigger "make" as usual. 
Didn't find it disruptive, but I might be missing something.

> with the "let everyone pick a workflow" approach we'll be making this
> absurdely worse for Frameworks. i won't even know what workflow to be using
> when i work on a library, so wave goodbye to my involvement.

Sure, but there's really no good answer here. It's either "Meh, absurd 
workflow for this component I'm too lazy to comply to it, wave goodbye to my 
involvement" or "Meh, I've to look up the workflow used here I'm too lazy to 
do it, wave goodbye to my involvement".

(Of course replace "lazy", by "overworked", "overcommitted", "overwhelmed" as 
you see fit)

Now if someone can point me to a workflow which will work on all the spectrum 
of components without creating absurd bureaucracy in more than 30% of the 
cases I'm all ears. Currently I don't have one.

> given that Frameworks really benefits from the occassional developers such
> as myself fixing things here and there, implementing missing functionality
> here and there, this should be taken seriously.

And it is, but see above.

> i know when i said in the past that my involvement with other projects would
> disipate due to the choices being made around git nobody really cared :)
> well, it's happened, i'm sure nobody still cares .. and that makes me sad.
> because i'm one of many. and by being too focused on tools and maintainers
> rather than developers we are screwing ourselves over.

I'm definitely not focused on tools, hoped my previous email made that clear.

> please disabuse yourself of the notion of "maintainer chooses"

I'll just add a few more thoughts regarding that because of your first 
question in this email, which I think was a bait to make me claim that it's to 
allow the maintainer to make his life easier against the developer comfort (in 
case anyone still wonder: no it's not the motive).

As I tried to make clear above, I think what's critical is to have for a given 
component the right workflow for it. The nature of the components varying 
greatly, their needs regarding the workflow vary as well. So a workflow will 
have to balance quality of the outcome vs level of bureaucracy.

Now the component itself not being able to tell us what workflow fits best, we 
have to rely on someone ultimately making the choice. And here the assumption 
is that the maintainer is among the people with the best overview of the 
component hence relying on him to pick a solution out of the shortlist. Now of 
course I'd rather encourage people doing that by consensus instead, but you 
need to bootstrap somehow.

> and work on a
> single workflow that all of Frameworks will adhere to for the sanity of all
> future developers.

Well, I'm not yet loosing hope to find one in the end. :-)

But my email was more to point out that a) there's a dimension we forgot to 
take into account when designing the current workflow (the large variability 
of the components we produce) and b) the current proposed "one size fit all" 
workflow doesn't cut it for every cases.

I discovered that while discussing with people who will end up being either 
maintainers or developers in the KDE Frameworks world (I find important to 
have both views for decision taking). That's why on that topic for now I've 
not been pushing hard in frameworks yet. Ideally we'll settle on a final 
solution (be it an ultimate workflow, or a shortlist, or something else) when 
we split the repositories.

Your email sounded a bit like "here, here people we have a definitive solution 
used by frameworks as well" so it felt sane to counter balance a bit because 
of what got found in the trenches in the meantime. We're not there yet 
unfortunately.

> seriously, this is the "should we have a coding style?" discussion all over
> again, isn't it?

Not really IMO. The coding style is about the look of the outcome, while the 
workflow is about how one works. And that makes quite a difference IMO.

> > [1] And before any "we should always branch" zealot cringe (not blaming
> > you, been there as well), please take a few minutes and read[2]:
> > http://martinfowler.com/bliki/FeatureToggle.html
> 
> i honestly can't imagine a worse idea for a library like libplasma.

Hehe, I didn't mean to imply it'd be relevant to libplasma specifically. It 
was meant for emphasizing the fact that "merging feature branch" as the one 
true ways to do things "because we now have git" is likely a wrong position.

That's why I generally like Fowler's writings, they're non dogmatic. And he 
tries to point out in which scope a given technique will work or not, so that 
you can choose what's right for your context.

Regards.

PS: As you can see from my email the trail I'm following ATM is "profile of 
the component" to pick a workflow. I think there's still one or two trails I 
can look at (profile of the contributor, profile of the contribution). So 
yeah, still some options...
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- 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/20120316/2ac6c71e/attachment-0001.sig>