Kubuntu Policies (for council consideration)
Harald Sitter
apachelogger at ubuntu.com
Tue Feb 25 08:35:12 UTC 2014
On Mon, Feb 24, 2014 at 5:55 PM, Jonathan Riddell <jr at jriddell.org> wrote:
>> > It is useful to be able to add people to these teams where it eases beginning to contribute to Kubuntu (thinking sgclark currently), bzr branches can be easily reviewed.
>> > ~kubuntu-packagers
>>
>> Indeed. There is a very discrete work flow for how one easily reviews
>> a branch. That's a merge, and adding people to pseudo teams at the
>> discretion of one council member is completely bypassing that. So, all
>> that does is make it very convenient for people to not easily review
>> the bzr branch at all, then upload, break things, giving me a
>> heartattack.
>
> it's far more hassle to merge in a new branch, doing that 50 times makes a lot of hassle.
- bzr qdiff --new $REMOTE
- (review)
- bzr merge $REMOTE
that seems considerably more convenient than:
- bzr qlog
- (find revisions that are different)
- (review)
former even can be scripted easily?
>> > Merging
>> > "When merging with Debian's packaging, each Kubuntu (and preferably Debian) patch must be reviewed"
>>
>> ^ I think reviewing Debian's patches is out of scope TBH. While nice,
>> it is completely pointless additional work we'd burden ourselfs with,
>> which in turn will lead to people being sloppy about it and then
>> retaining overall review quality at what we have right now with random
>> patches doing random things floating about randomly for no reason
>> whatsoever (e.g. the netbook favorites patch I recently ripped out
>> workspace)
>
> that's why I say preferably, it's not a hard requirement, but it's not
> uncommon to review Debian patches and find ones which should go
> upstream.
Why mention it then? If someone feels like reviewing those patches
than they will do it anyway.
Perhaps we shouldn't do review as part of merges to begin with but
instead have a card for global patch review. That would reduce the
time it takes to get merges done and at the same time makes us take
the time to actually review all patches, not just ours (e.g. there's
also upstream patches that somehow never actually got into upstream or
weird stuff like that).
HS
More information about the kubuntu-devel
mailing list