On Wed, Feb 19, 2014 at 02:05:26PM +0100, Harald Sitter wrote: > > As an exception where upstream bugs are due to be tracked until the current > > release is out they can be filed, linked to upstream, tagged ''kubuntu'' > > and milestoned to the next release. > > What is the benefit of that?
So that bugs which need to be tracked for the release can be easily tracked. > > ~kubuntu-members -> changed 6 months to "significant and sustained" > > ^ IMHO we really should have a hard value there, if 6 months seems to > long then perhaps 3 might be more acceptable, but I think a lot of the > recent candidates had a hard time knowing when exactly their > contirbution was sustained enough. the significance of things are hard > to define anyway, but one hard value seems better than a requirement > jellyfish. I'd prefer 3 months because I don't want to make it too hard to get membership, we should make it pretty easy to make people feel part of the gang. On the other hand I just checked Ubuntu which does say 6 months https://wiki.ubuntu.com/Membership/NewMember > > 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. > > 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. Jonathan -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
