Re: Reevaluating the "Ubuntu Contributing Developer" status
On 10/06/2011 03:31 PM, Scott Kitterman wrote: On Thursday, October 06, 2011 08:13:21 PM Michael Bienia wrote: UCD is in line with the other membership granting councils: - Kubuntu council -> ~kubuntu-members - Edubuntu council -> ~edubuntu-members - Forum council -> ~ubuntu-forum-members - IRC council -> ~ubuntu-irc-members Only ~ubuntu-forum-members and ~ubuntu-irc-members seem to give additional rights compared to ~ubuntumembers. ~kubuntu-members grants additional rights too. So I think it's only ~edubuntu-members that doesn't. Scott K If you count an @edubuntu.org e-mail address as additional right, then we do too. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Reevaluating the "Ubuntu Contributing Developer" status
On Thursday, October 06, 2011 11:34:32 AM Steve Langasek wrote: > Do the other councils refer to themselves as "Kubuntu members" / "Forum > members"? Or do they generally use the title "Ubuntu Members"? I'm a member of the Kubuntu Council, so one of the things I do is evaluate Kubuntu membership applications. In my experience virtually all of the people that apply for Kubuntu membership are very focused on contributing to Kubuntu and identify themselves as Kubuntu members. Because Kubuntu membership grants some additional rights that Ubuntu membership doesn't, exisitng Ubuntu members that want to be Kubuntu members must apply to the KC and demonstrate contribution to Kubuntu. It's more common for people who are interested in Kubuntu to later branch out and contribute to the broader project than the reverse. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Reevaluating the "Ubuntu Contributing Developer" status
On Thursday, October 06, 2011 08:13:21 PM Michael Bienia wrote: > UCD is in line with the other membership granting councils: > - Kubuntu council -> ~kubuntu-members > - Edubuntu council -> ~edubuntu-members > - Forum council -> ~ubuntu-forum-members > - IRC council -> ~ubuntu-irc-members > Only ~ubuntu-forum-members and ~ubuntu-irc-members seem to give > additional rights compared to ~ubuntumembers. ~kubuntu-members grants additional rights too. So I think it's only ~edubuntu-members that doesn't. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Reevaluating the "Ubuntu Contributing Developer" status
On Thu, Oct 06, 2011 at 08:13:21PM +0200, Michael Bienia wrote: > UCD dates back to the time when MOTU Council was granted the right to > grant Ubuntu membership. The idea for a subteam comes from Mark [1,2] > when it was discussed how the membership granting gets implemented for > the MC. > UCD caused already once confusion[3] in the past and it was proposed to > merge UCD with ~ubuntumembers where Mark was against this idea[4] and > prefered to keep the subteams to be able to track which membership > granting council added a person[5]. > UCD is in line with the other membership granting councils: > - Kubuntu council -> ~kubuntu-members > - Edubuntu council -> ~edubuntu-members > - Forum council -> ~ubuntu-forum-members > - IRC council -> ~ubuntu-irc-members But the name is definitely not. Do the other councils refer to themselves as "Kubuntu members" / "Forum members"? Or do they generally use the title "Ubuntu Members"? > Perhaps UCD should get renamed to "Ubuntu Development Members" > (~ubuntu-dev-members) to match the naming scheme of the other teams. But > I'm not sure if the difference to "Ubuntu Developers" will be clear > enough just from the team name. The current name is *definitely* not clear. If a human-readable name is needed, I would strongly recommend either "Ubuntu Development Members" or "Ubuntu Developing Members" over the current name, which wrongly emphasizes "Developer" as the status instead of "Member". -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Kubuntu Documentation
Greetings everyone. I wanted to thank everyone who worked on the Kubuntu Docs for 11.10 (Oneiric Ocelot). Thanks to your dedication and hard work we not only finished on time but, we also got the translations worked on and finished too! Thank you all so much! So, with all of that said, I would like to welcome you all the the development cycle for Kubuntu 12.04 LTS "Precise Pangolin". The BZR branch of lp:kubuntu-docs now reflects precise and is open for editing. Please, please please please use the blueprint for this.[1] I am begging you. :) It makes tracking s much simpler. If you have ANY questions on how to use launchpad blueprints as it relates to work items please read this. [2] Anyway, because this will be a LTS release I want to ensure that this is our best doc cycle yet. This is why I am asking that we all chip in. I will be re- writing the doc guide and have that ready to go shortly. Stay tuned for that. So, in closing, I am looking forward to working with the ones I spent oneiric with in crunch time and I am looking forward to making new friends in this documentation adventure! Cheers! Dave Wonderly Darkwing on FreeNode #kubuntu-devel [1] https://blueprints.launchpad.net/kubuntu-docs/+spec/kubuntu-docs-precise [2] https://wiki.kubuntu.org/WorkItemsHowto -- kubuntu-devel mailing list kubuntu-de...@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Reevaluating the "Ubuntu Contributing Developer" status
On 2011-10-06 12:04:11 -0400, Luke Faraone wrote: > On Thu, Oct 6, 2011 at 10:25, Stephen M. Webb wrote: > > > > Ubuntu Member: a recognized member of the Ubuntu community > > > > Ubuntu Developer: a Ubuntu Member who obtained their recognition through > > contributing software development (patches, sponsored packages, whatever) > > > > I'm not sure there's a need for such a subset of Member which conveys no > additional access. "Contributing Developer" is the only such category that I > know of. Should we create an "Ubuntu Translator" group for those who > obtained their recognition through contributing translations? UCD dates back to the time when MOTU Council was granted the right to grant Ubuntu membership. The idea for a subteam comes from Mark [1,2] when it was discussed how the membership granting gets implemented for the MC. UCD caused already once confusion[3] in the past and it was proposed to merge UCD with ~ubuntumembers where Mark was against this idea[4] and prefered to keep the subteams to be able to track which membership granting council added a person[5]. UCD is in line with the other membership granting councils: - Kubuntu council -> ~kubuntu-members - Edubuntu council -> ~edubuntu-members - Forum council -> ~ubuntu-forum-members - IRC council -> ~ubuntu-irc-members Only ~ubuntu-forum-members and ~ubuntu-irc-members seem to give additional rights compared to ~ubuntumembers. If translation contributions get their own council, it should IMHO get moved into their own subteam. Perhaps UCD should get renamed to "Ubuntu Development Members" (~ubuntu-dev-members) to match the naming scheme of the other teams. But I'm not sure if the difference to "Ubuntu Developers" will be clear enough just from the team name. Michael 1: https://lists.ubuntu.com/archives/motu-council/2008-March/000931.html 2: https://lists.ubuntu.com/archives/motu-council/2008-March/000933.html 3: https://lists.ubuntu.com/archives/technical-board/2010-March/000124.html 4: https://lists.ubuntu.com/archives/technical-board/2010-March/000137.html 5: https://lists.ubuntu.com/archives/technical-board/2010-March/000139.html -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Reevaluating the "Ubuntu Contributing Developer" status
On Thu, Oct 6, 2011 at 10:25, Stephen M. Webb wrote: > > Ubuntu Member: a recognized member of the Ubuntu community > > Ubuntu Developer: a Ubuntu Member who obtained their recognition through > contributing software development (patches, sponsored packages, whatever) > I'm not sure there's a need for such a subset of Member which conveys no additional access. "Contributing Developer" is the only such category that I know of. Should we create an "Ubuntu Translator" group for those who obtained their recognition through contributing translations? -- Luke Faraone;; Debian & Ubuntu Developer; Sugar Labs, Systems lfaraone on irc.[freenode,oftc].net -- http://luke.faraone.cc PGP fprint: 5189 2A7D 16D0 49BB 046B DC77 9732 5DD8 F9FD D506 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Reevaluating the "Ubuntu Contributing Developer" status
On 5 October 2011 16:35, Scott Kitterman wrote: > This a problem I believe. I've thought about it and I think most any name we > could come up with is problematic. There are a number of ways people get > membership and we don't generally give them a special name. My proposal is > rename Ubuntu Contributing Developer to Ubuntu Member. I agree with this, and have always thought so. -- Matthew East http://www.mdke.org gnupg pub 1024D/0E6B06FF -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Reevaluating the "Ubuntu Contributing Developer" status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/06/2011 02:34 AM, David Henningsson wrote: > > We should probably change one of "Ubuntu Contributing Developers" and > "Ubuntu Developers" to reduce confusion - maybe "Ubuntu Developers" > should be renamed to "Ubuntu Uploading Developers", and let "Ubuntu > Developers" mean the combination of both "Ubuntu Contributing > Developers" and "Ubuntu Uploading Developers"? Perhaps using a name that describes exactly what the ranking entails would be more effective. Ubuntu Member: a recognized member of the Ubuntu community Ubuntu Developer: a Ubuntu Member who obtained their recognition through contributing software development (patches, sponsored packages, whatever) Ubuntu Uploader: a Ubuntu Developer who has upload permissions PPU, MOTU, CoreDev, etc: a refinement of Ubuntu Uploader that describes which packages can be uploaded - -- Stephen M. Webb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6NukEACgkQTLRKqWcl7vNk2gCeKMqgn13utAIy4tVs6MI4esNY qh0An1NInqHzJFAz97tttA73VQjfxnjl =MDT1 -END PGP SIGNATURE- -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposal do disallow syncs of library packages from experimental without approval
On Thursday, October 06, 2011 10:03:26 AM Matthias Klose wrote: > On 10/05/2011 10:47 PM, Scott Kitterman wrote: > > On Wednesday, October 05, 2011 09:30:22 PM Sebastien Bacher wrote: > >> To take an example I think porting universe GNOME2 applets to GNOME3 > >> wouldn't be a good use of our time, we better spend the resources we > >> have making sure our current desktop version is great. > >> If some people want to work on porting the applications they care > >> about, > >> great, otherwise the source can be dropped and will come back once its > >> upstream or somebody else pick it up and update the code. > > > > I think Gnome2 -> Gnome3 is an exceptional case where that is > > particularly true. In general either all that's needed are rebuilds or > > digging for patches. I think if we're going to do a transition the > > developer needs to at least follow through and try to deal with > > Universe and file bugs where things fail. I don't think just fixing > > Main and then saying "Meh, Universe, Whatever" is appropriate. > > We do have more "exceptional cases" like compiler and linker changes, other > major version changes which are better handled in that the proposed way > forward is announced (apologies if I did miss it for Gnome2, I only did see > the release goal getting gtk2 off the images). The removal of the GNOME2 > applet related packages was done, which is fine, although I assume that > some effort went into attempts to fix things before the removal of those > packages. > > "all that's needed are rebuilds" is a lot to do, and it doesn't help if > major changes are still done after the last test rebuild. This cycle's > example is the change in gtk/gnome's pkg-config files moving libraries from > the Libs to the Libs.private attribute, resulting in build failures (no, we > don't know which ones are not yet detected, how many, etc, libgnomeprintui > still not fixed). Such a change is appropriate before feature freeze, but > not after. I'd like to challenge the general freeze exception for Gnome > and KDE for the LTS, if changes like this are more or less blindly applied, > even if these are found in upstream release candidates. KDE doesn't need any standing freeze exception now that we are basing exceptions on features and not version numbers. The KDE SC 4.X.0 release comes before feature freeze so upstream is only bug fixing after that. Any case from an upstream update that violated Ubuntu's feature freeze would also violate upstream's maintenance policy. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Reevaluating the "Ubuntu Contributing Developer" status
On Thursday, October 06, 2011 08:34:59 AM David Henningsson wrote: > On 10/05/2011 12:57 PM, Daniel Holbach wrote: > > Hello, > > > > Am 05.10.2011 12:40, schrieb Iain Lane: > >> Please visit the page > >> > >>https://wiki.ubuntu.com/UbuntuDevelopers#Ubuntu_Contributing_Dev > >>elopers>> > >> to see our current documentation about what an Ubuntu Contributing > >> Developer is. > > > > I got an action from the DMB recently to update the page and make it a > > bit clearer. There was a lot of repetition in the old page, so I tried > > to sum it up (without losing content) and explain a bit better which > > options new developers have. > > > > http://pad.ubuntu-uk.org/JzyYyxw0Qb > > > > Let me know what you think. > > I think one source of confusion is that "Ubuntu Contributing Developers" > is not a subset of "Ubuntu Developers": > > According to the link above, "Ubuntu Developers /.../ are granted direct > upload to the Ubuntu archive, according to their application", whereas > "Ubuntu Contributing Developers /.../ still have to get uploads sponsored". > > We should probably change one of "Ubuntu Contributing Developers" and > "Ubuntu Developers" to reduce confusion - maybe "Ubuntu Developers" > should be renamed to "Ubuntu Uploading Developers", and let "Ubuntu > Developers" mean the combination of both "Ubuntu Contributing > Developers" and "Ubuntu Uploading Developers"? I agree with your assessment of the problem, but I think that's the wrong change. The term Ubuntu Developer has had a pretty stable meaning (PPU uploaders have been added) for the five years I've been involved in the project and so I don't think changing that is the right answer. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposal do disallow syncs of library packages from experimental without approval
On Thursday, October 06, 2011 03:27:13 PM Colin Watson wrote: > On Thu, Oct 06, 2011 at 04:00:55PM +0200, Sebastien Bacher wrote: > > Le jeudi 06 octobre 2011 à 13:28 +0100, Iain Lane a écrit : > > > You might not ever hear about it, but every time something is > > > removed you are potentially letting people down. > > > > Right, but every time an annoying but in a software that 90% of our > > users run is not fixed because the time has been spent on a package used > > by a few users in universe how many users do we let down? > > Developers aren't interchangeable. If you don't have time yourself then > it's perfectly reasonable to organise people to help out; you'll > probably save about as much time that way because you won't have to > field so many complaints. > > The problem is when people simply ignore and abandon the problem. +1 Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposal do disallow syncs of library packages from experimental without approval
On Thu, Oct 06, 2011 at 04:00:55PM +0200, Sebastien Bacher wrote: > Le jeudi 06 octobre 2011 à 13:28 +0100, Iain Lane a écrit : > > You might not ever hear about it, but every time something is > > removed you are potentially letting people down. > > Right, but every time an annoying but in a software that 90% of our > users run is not fixed because the time has been spent on a package used > by a few users in universe how many users do we let down? Developers aren't interchangeable. If you don't have time yourself then it's perfectly reasonable to organise people to help out; you'll probably save about as much time that way because you won't have to field so many complaints. The problem is when people simply ignore and abandon the problem. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposal do disallow syncs of library packages from experimental without approval
Le jeudi 06 octobre 2011 à 13:28 +0100, Iain Lane a écrit : > You > might not ever hear about it, but every time something is removed you > are potentially letting people down. Right, but every time an annoying but in a software that 90% of our users run is not fixed because the time has been spent on a package used by a few users in universe how many users do we let down? -- Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Reevaluating the "Ubuntu Contributing Developer" status
On Thu, Oct 6, 2011 at 2:34 AM, David Henningsson wrote: > I think one source of confusion is that "Ubuntu Contributing Developers" is > not a subset of "Ubuntu Developers": > > According to the link above, "Ubuntu Developers /.../ are granted direct > upload to the Ubuntu archive, according to their application", whereas > "Ubuntu Contributing Developers /.../ still have to get uploads sponsored". > > We should probably change one of "Ubuntu Contributing Developers" and > "Ubuntu Developers" to reduce confusion - maybe "Ubuntu Developers" should > be renamed to "Ubuntu Uploading Developers", and let "Ubuntu Developers" > mean the combination of both "Ubuntu Contributing Developers" and "Ubuntu > Uploading Developers"? That's a good point, because https://wiki.ubuntu.com/UbuntuDevelopers includes "prospective" also in the "Ubuntu Developer" category for new contributors, which definitely don't have upload rights (yet). So some wording there needs to change. -- Mackenzie Morgan -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposal do disallow syncs of library packages from experimental without approval
Hello, On Wed, Oct 05, 2011 at 09:30:22PM +0200, Sebastien Bacher wrote: > Le mercredi 05 octobre 2011 à 16:08 +0200, Matthias Klose a écrit : > > > > During the oneiric development cycle we had syncs of library packages > > from > > experimental, introducing new sonames, and changing APIs in a way that > > other > […] > While I agree that people who start a transition should have some > responsibilities in it I also think that we should be ok with dropping > unmaintained code which is not ported at the end of the cycle (and not > especially require that whoever started the transition has to be the one > that should fix the universe). Not ported is not the same as not maintained. It's very easy to be blinkered and assume that Ubuntu is the same as the main component, but that would be doing a disservice to our users. You might not ever hear about it, but every time something is removed you are potentially letting people down. http://kitenet.net/~joey/blog/entry/the_popcon_problem/ I think we owe it to our users to assess the impact of transitions on the entire archive and expend a reasonable amount of effort to not further break things. Saying “I have broken your software with my new library and if you want it in Ubuntu then you must port to the new API in a small number of weeks” is very disappointing. Regards, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] PhD student [ i...@cs.nott.ac.uk ] signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch pilot report: 2011-10-06
Hello everybody, these are the bits I got through today: https://bugs.launchpad.net/ubuntu/+source/gtkguitune/+bug/850791 - unsubscribed sponsors, upload not necessary for oneiric https://bugs.launchpad.net/ubuntu/+source/gramps/+bug/864095 - sync request was ACKed already, unsubscribing sponsors https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/805386 https://bugs.launchpad.net/ubuntu/+source/python-meld3/+bug/749880 - fix was uploaded already, unsubscribed sponsors https://bugs.launchpad.net/ubuntu/natty/+source/singularity/+bug/576504 https://code.launchpad.net/~jbicha/ubuntu/oneiric/gnome-color-manager/3.2/+merge/77637 https://code.launchpad.net/~brunoqc/ubuntu/natty/lfm/lfm-fix-786491/+merge/77859 https://code.launchpad.net/~brunoqc/ubuntu/maverick/lfm/lfm-fix-786491/+merge/77860 - uploaded https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/445849 - superficial review, found a few small mistakes https://code.launchpad.net/~jbicha/ubuntu/oneiric/libgdata/dev-depend-on-gir/+merge/77787 - depends on another fix, marked as 'work-in-progress' https://code.launchpad.net/~cldunlap1/ubuntu/oneiric/alsa-utils/fix-for-816388/+merge/78136 - typo fix, pointed out that it should go upstream first - David Henningson agreed to take it upstream https://bugs.launchpad.net/ubuntu/+bug/852623 - found a missing Depends, checked in with the package maintainer https://code.launchpad.net/~psusi/ubuntu/natty/gnome-power-manager/fix-duplicate-battery/+merge/67466 - asked to set the MP to merged - got uploaded already https://code.launchpad.net/~bones/ubuntu/natty/radiotray/fix-for-722886/+merge/70107 - asked for MP to be rejected, fixed in oneiric, no SRU necessary https://code.launchpad.net/~xerosis/ubuntu/oneiric/cheese/cheese-fix-for-817806/+merge/72246 - set to merged https://bugs.launchpad.net/ubuntu/+source/radiotray/+bug/722886 - marked as Fixed (fix got into Debian and synced from there) Have a great day, Daniel -- Get involved in Ubuntu development! developer.ubuntu.com/packaging Stay up to date: follow @ubuntudev on identi.ca/twitter.com/facebook.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposal do disallow syncs of library packages from experimental without approval
Hello, On Wed, Oct 05, 2011 at 05:21:05PM -0700, Steve Langasek wrote: > On Wed, Oct 05, 2011 at 04:17:43PM +0100, Iain Lane wrote: > > On Wed, Oct 05, 2011 at 03:55:54PM +0100, Colin Watson wrote: > > > […] > > > > All three cases have in common that the packages were left alone for > > > > months. The third example could have been avoided if we could check > > > > build dependencies when syncing, and rejecting the sync when the > > > > b-d's are not fulfilled (although there should be an override > > > > option). > > > > I don't want to add extra archive-admin checking to the sync process; > > > firstly, we're moving towards self-service syncs anyway, and secondly, > > > as the libav example shows, syncs aren't really special here. > > > > More discipline for library upgrades would indeed be a good thing. > > > The main problem seems to be library upgrades that don't really have > > > anyone looking after them (and this is worst when it's Ubuntu-local or > > > from Debian experimental; at least in unstable the Debian release team > > > usually cares to some extent). IMO, we should make it clear that if > > > you sync or merge a library from experimental then it is your > > > responsibility to ensure that all reverse-dependencies are ported. > > > Right: if you introduce a SONAME bump (or similar) you should care for > > it. This cycle the burden has fallen upon those who choose to care for > > the NBS list, and that's neither fair nor sustainable. > > > Most of these uploads will have to go through binary NEW so that is a > > good opportunity to check with the uploader that they plan to address > > the ramifications of the uploads they introduce. > > I don't think this is something archive admins should be expected to do; > it's not in keeping with the other kinds of archive consistency checks > they're responsible for. It's also, in a sense, too late - by the time the > package hits binary new, the source version is already in the archive, so we > have to "deal" with the transition in one way or another. OK. It just seemed like a place where we could have said "has this developer prepared for the transition they are starting?". I didn't think there would be any rejections at this stage, just some basic checks. > Like Scott, I think this needs to be the responsibility of the developer > starting the transition, and this is true regardless of the origin. I think > the point of starting this thread is to get a consensus that this is the > right way to handle transitions and to *raise awareness* of the issue, with > a particular emphasis on experimental because pulling in a transition from > experimental means we effectively have no backing from the Debian > maintainers for getting it done in a timely manner (i.e., within an Ubuntu > release cycle). I'm most definitely not saying that people shouldn't take responsibility for their transitions. That is pretty much the opposite of what I want, which is to socialise the idea that transitions aren't something that you can expect others to clean up after you for — you are responsible for seeing them through. I think a little bit of pushback will get the message out. And if it fails to then we can fetch the bigger hammers. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] PhD student [ i...@cs.nott.ac.uk ] signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
preparing the opening of the P-series
While Oneiric is not yet released, it's time to prepare packages for the opening of the P-series. Please add to the lists at https://wiki.ubuntu.com/P-SeriesOpening what packages to prepare at the beginning of the release cycle, and what to avoid. When adding to this list, please see it as a commitment to have packages ready the day after the oneiric release (e.g. when dropping python2.6 as a supported python version, prepare the python-defaults package). We are likely to see more library packages converted for multiarch. Keep in mind that even syncing/merging a package from Debian testing doesn't mean that all packages with build-dependencies are already fixed. We'll only know in precise (sounds odd :-/) after a test rebuild (either for the distribution, or for the library in a PPA). Matthias -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposal do disallow syncs of library packages from experimental without approval
On 10/05/2011 10:47 PM, Scott Kitterman wrote: > On Wednesday, October 05, 2011 09:30:22 PM Sebastien Bacher wrote: >> To take an example I think porting universe GNOME2 applets to GNOME3 >> wouldn't be a good use of our time, we better spend the resources we >> have making sure our current desktop version is great. >> If some people want to work on porting the applications they care about, >> great, otherwise the source can be dropped and will come back once its >> upstream or somebody else pick it up and update the code. > > I think Gnome2 -> Gnome3 is an exceptional case where that is particularly > true. In general either all that's needed are rebuilds or digging for > patches. I think if we're going to do a transition the developer needs to at > least follow through and try to deal with Universe and file bugs where things > fail. I don't think just fixing Main and then saying "Meh, Universe, > Whatever" is appropriate. We do have more "exceptional cases" like compiler and linker changes, other major version changes which are better handled in that the proposed way forward is announced (apologies if I did miss it for Gnome2, I only did see the release goal getting gtk2 off the images). The removal of the GNOME2 applet related packages was done, which is fine, although I assume that some effort went into attempts to fix things before the removal of those packages. "all that's needed are rebuilds" is a lot to do, and it doesn't help if major changes are still done after the last test rebuild. This cycle's example is the change in gtk/gnome's pkg-config files moving libraries from the Libs to the Libs.private attribute, resulting in build failures (no, we don't know which ones are not yet detected, how many, etc, libgnomeprintui still not fixed). Such a change is appropriate before feature freeze, but not after. I'd like to challenge the general freeze exception for Gnome and KDE for the LTS, if changes like this are more or less blindly applied, even if these are found in upstream release candidates. Matthias -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
