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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
