Re: Focus of MOTU (Was: NEW Packages process)
On Fri, Apr 18, 2008 at 08:51:29AM +0200, Stephan Hermann wrote: > > > Priority 5: > > [...] > > > Today, we need at least to look at two places, MoM+DaD, > > > asking the old uploader, eventually waiting too long for an answer. > > > This slows us down. > > > > AFAIK DaD was introduced because MoM was missing the comment feature. Not only, but yes. > > Now that MoM is open source, DaD should be merged with MoM. > > Well, I don't want to look at two places in general for one work. Work is in progress for merging DaD's features into MoM. > > We need a mechanism to "lock" merges so others know someone is working > > on it and can select an other merge. And currently it is to ping the > > last uploader. > > Yes...when you can get hands on the last uploader... > > Ad least adding a lock checkbox on a website should be enough...where > do we get the source of MoM now? Everything is on Launchpad (product: merge-o-matic): bzr branch of the source code, bugs with patches waiting for review. I don't think we need a lock checkbox. Comments are perfect for that (they are already used that way in DaD) and MoM should have them as well really soon (hopefully before merging for intrepid starts). -- Adrien Cunin aka Adri2000 signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Focus of MOTU (Was: NEW Packages process)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Hermann ha scritto: | Ad least adding a lock checkbox on a website should be enough...where | do we get the source of MoM now? I guess source code is here: https://launchpad.net/merge-o-matic Regards, - -- Luca Falavigna Ubuntu MOTU Developer GPG Key: 0x86BC2A50 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgIRrIACgkQnXjXEYa8KlD1SgCgsjM/6vrtDtQr0VKuRrhDUMDe gI4An3egaHrLmBc90Gr+hwvqvrAcdqxy =itMK -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Focus of MOTU (Was: NEW Packages process)
Stephan Hermann wrote: > Ad least adding a lock checkbox on a website should be enough...where > do we get the source of MoM now? https://code.launchpad.net/merge-o-matic/ -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Focus of MOTU (Was: NEW Packages process)
Moins, On Thu, 17 Apr 2008 23:02:17 +0200 Michael Bienia <[EMAIL PROTECTED]> wrote: > On 2008-04-17 10:25:27 +0200, Stephan Hermann wrote: > > Priority 1a: > > > > I think our main focus should still be to fix > > Universe/Multiverse packages for the actual development > > release. That means, merging, syncing, fixing packages > > which we are importing from Debian or from older times from > > apt-get.org. > > > > This will eat most of our time during a release. > > I see it the same way. We have already enough to do with the packages > in our archive and those uploaded to Debian (sync, merge) and I see no > reason to add even more packages to our workload. We already don't > manage to keep the packages uploaded through REVU uptodate (you will > easily find packages which were uploaded once and never again). > Therefore I don't concentrate to do reviews. Yes, most of the time I don't spend time on reviews, too, only when I know the guy who wants to add a package and I know that the software is valuable. > I'd even prefer if new MOTU contributors would start with syncs, > (easy) merges, bug fixing, etc. instead of packaging new software. Agreed > > Priority 5: > [...] > > Today, we need at least to look at two places, MoM+DaD, > > asking the old uploader, eventually waiting too long for an answer. > > This slows us down. > > AFAIK DaD was introduced because MoM was missing the comment feature. > Now that MoM is open source, DaD should be merged with MoM. Well, I don't want to look at two places in general for one work. > > > During Merging Time, it's important that we get hands on > > many packages as we can manage, and just fix them, or file a sync > > report for it. This gives us more time to fix stuff in the > > later stage of development. > > Communication is done via IRC and a MOTU should take care > > about the last uploaded packages he/she touched in the first place. > > When he/she's done with it, he/she can take whatever package > > is left, without further written or spoken permission of the > > last uploader. > > IMHO this is the most important rule, nothing else. > > Yes, but we still should avoid to do duplicate work given our > insufficient manpower. > It would be really bad to spend one or two hours on a bigger merge > just to see that someone else was 5 minutes faster. > We need a mechanism to "lock" merges so others know someone is working > on it and can select an other merge. And currently it is to ping the > last uploader. Yes...when you can get hands on the last uploader... Ad least adding a lock checkbox on a website should be enough...where do we get the source of MoM now? Regards, \sh -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Focus of MOTU (Was: NEW Packages process)
On 2008-04-17 10:25:27 +0200, Stephan Hermann wrote: > Priority 1a: > > I think our main focus should still be to fix > Universe/Multiverse packages for the actual development > release. That means, merging, syncing, fixing packages which we > are importing from Debian or from older times from apt-get.org. > > This will eat most of our time during a release. I see it the same way. We have already enough to do with the packages in our archive and those uploaded to Debian (sync, merge) and I see no reason to add even more packages to our workload. We already don't manage to keep the packages uploaded through REVU uptodate (you will easily find packages which were uploaded once and never again). Therefore I don't concentrate to do reviews. I'd even prefer if new MOTU contributors would start with syncs, (easy) merges, bug fixing, etc. instead of packaging new software. > Priority 5: [...] > Today, we need at least to look at two places, MoM+DaD, asking > the old uploader, eventually waiting too long for an answer. > This slows us down. AFAIK DaD was introduced because MoM was missing the comment feature. Now that MoM is open source, DaD should be merged with MoM. > During Merging Time, it's important that we get hands on many > packages as we can manage, and just fix them, or file a sync > report for it. This gives us more time to fix stuff in the > later stage of development. > Communication is done via IRC and a MOTU should take care about > the last uploaded packages he/she touched in the first place. > When he/she's done with it, he/she can take whatever package > is left, without further written or spoken permission of the > last uploader. > IMHO this is the most important rule, nothing else. Yes, but we still should avoid to do duplicate work given our insufficient manpower. It would be really bad to spend one or two hours on a bigger merge just to see that someone else was 5 minutes faster. We need a mechanism to "lock" merges so others know someone is working on it and can select an other merge. And currently it is to ping the last uploader. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On 2008-04-18 01:48:20 +1000, Sarah Hobbs wrote: > I can see a whole lot of people submitting checkinstalled binaries, and > then dh-make template packages as a "source", as an afterthought. Even > checkinstalled packages built "somewhere". That's not so helpful. I assume the idea is to upload binary+source and not a seperate upload for binary and a seperate upload for source. Those people who want to upload a checkinstalled binary and a dh-make templated source would need to know how to build a *_i386.changes file for such uploads. And I hope such people would use their knowledge to build a proper package than doing such things. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Sarah Hobbs wrote: > I don't see how binary > uploads, even when accompanied by sources, buy us anything at all. At the very least they bring the possibility to run lintian against the binaries on REVU, and IMHO that's just enough. That's one of the first things I do when reviewing a package and it almost always shows some mistakes. And if the binaries are broken or haven't been built from the sources... no problem. They won't be available to the public. signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Stefan Potyra a écrit : > Hi, > > On Wednesday 16 April 2008 18:51:36 Loïc Martin wrote: > [..] >> >> 1. Is it possible to review what are the most frequent packaging errors, >> and how much of these can be picked up by a few scripts? >> >> IMHO, most new contributors would omit debian/copyright, or tend to >> indicate the wrong Ubuntu version (i.e. the stable release instead of >> the development one, since at first you're not going to know about SRU >> policy), leave the Debian one, forget to fill some fields in >> debian/control, include binaries, etc... >> >> Could it be possible to automate most of these checks and others, so >> each uploader would get feedback on the first screening errors ( a >> process which, at the moment, can take 2+ weeks)? The system could point >> to the relevant parts of the documentation (hypertext links or extracts) >> for each problem, and provide information on how to receive human >> interaction if necessary - irc, mailing list or, better, a packaging >> forum since Windows users aren't used to irc and mailing lists). In >> short, a kind of lintian for common mortals, but server-side. > > hm... that's tough. Well, there is lintian, but not all of lintian output is > always correct for each source package (that's why you can override parts of > it). So the tricky part here is: What to do with the result of a package > checker? (should it reject the package, which would be wrong for some, should > it leave a negative reviewing comment, same problem, or should it just be > informational, which is what we have right now, though not really presented > very nicely). lintian output is informative only if you already know how to correctly build a package (and most first-time uploaders won't understand much of what lintian is talking about). I like lintian, and I use it, even when the package is for my own use (f.e. new version of programs that I know are going to appear in Debian then in Ubuntu's development version, but that I nedd right now in stable). However, most of the time people won't know what to do with the error descriptions, and from what I could understand reading some MOTU's description of their work, they end up pointing the same things lintian did on their first reviews. If it is possible to give a human understandable descriptions of the problems, accompanied with a how-to extract on the steps required to fix the problems, would it save MOTU's time and give all uploaders the means to improve their packaging practices without burdening MOTU? Ubuntu documentation is really good at explaining things, and the quality of the wikis could prove a good starting point compared to lintian's output. Ubuntu's wiki are usually done bearing first time users in mind, and that's really what most first-time uploaders are (else they'd be uploading to Debian in the first place). The revision process for new package doesn't have the same landscape as lintian's main use. The most common packaging errors aren't necessarily the same problems that lintian checks, and the experience in years of REVU could be used to adapt the tools. Another aspect lintian won't adress is that most users would package an application for the version of Ubuntu they are using, thus providing incorrect debian/control. However, it is the version they able to test the application the best with, while pbuilding a package for a development version of Ubuntu nobody uses yet only proves that the package builds. If it is possible to replace gutsy by hardy automatically, then check if it builds, packages could be accepted more easily, without having to just reject the package till the uploader has understood completely Ubuntu's policy. It's not going to degrade/dumb uploaders. Between an uploader that just checks if a package build and one that actually runs the application and use it everyday, which one is going to give the best feedback/testing? In later stages, they're going to learn how to build a package for other versions of Ubuntu. Some jobs can be made simpler by applying some computer power. It can be too much for a server at the moment, but processor power is cheaper than MOTU's time. At the moment, whatever lintian's input, a reviewer still has to point the problem to the uploader when this uploader isn't already familiar with the system. > Others than that, someone would have to write such a checker, in case lintian > doesn't fulfill the needs. Running that on the server - given that it's > particular secure to do so - shouldn't be a problem. > >> Result : the packager gets immediate input, and reviewers know that >> they're only reviewing pre-screened packages which should already build >> and meet a few basic standards. How costly would it be for the server to >> try and test building each upload - getting the tarball, applying the >> patches, trying to build the package, and even trying to run it?) > > Autobuilding: autobuilding is basically ha
Re: NEW Packages process
James Westby wrote: Isn't the proposal to accept only uploads that also have binary packages, like the Debian archive does? They can be discarded (perhaps after a lintian check), but at least you know they built once somewhere. The source package that comes with it can then be used for the rest of the process. Possibly. But I still have no confidence that the binary provided actually has anything to do with the source, let alone that the source being built contains the exact same output as the binary (in terms of files, etc). I can see a whole lot of people submitting checkinstalled binaries, and then dh-make template packages as a "source", as an afterthought. Even checkinstalled packages built "somewhere". That's not so helpful. This also wouldn't fix the "it worked on my machine, where I didn't use pbuilder, but the source doesn't build when pbuilder is used" problem. I think far more people build the packages on their own machines, without using pbuilder/sbuild/clean chroot, than not attempting to build their own packages at all, before submitting them to REVU. Good idea - but wouldn't work in practice. I don't see how binary uploads, even when accompanied by sources, buy us anything at all. Hobbsee signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Thu, 2008-04-17 at 23:14 +1000, Sarah Hobbs wrote: > Scott Kitterman wrote: > > If we go down this road, I'd suggest accepting only binary uploads. That'd > > make sure the package at least builds before MOTUs waste time reviewing it. > Can you imagine just how many checkinstall-built packages we'd get from > doing that? Hi, Isn't the proposal to accept only uploads that also have binary packages, like the Debian archive does? They can be discarded (perhaps after a lintian check), but at least you know they built once somewhere. The source package that comes with it can then be used for the rest of the process. Thanks, James -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Moins, On Thu, 17 Apr 2008 23:14:19 +1000 Sarah Hobbs <[EMAIL PROTECTED]> wrote: > Scott Kitterman wrote: > > If we go down this road, I'd suggest accepting only binary > > uploads. That'd make sure the package at least builds before MOTUs > > waste time reviewing it. > > > > Scott K > > > > Don't be a fool. :) > > Can you imagine just how many checkinstall-built packages we'd get > from doing that? > > Here's your large bottle of alcohol. Please drink it. Then come up > with a saner idea. :) In the end, Scott is right on this one.we need some barriers before we even start reviewing ;) \sh -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Scott Kitterman wrote: If we go down this road, I'd suggest accepting only binary uploads. That'd make sure the package at least builds before MOTUs waste time reviewing it. Scott K Don't be a fool. :) Can you imagine just how many checkinstall-built packages we'd get from doing that? Here's your large bottle of alcohol. Please drink it. Then come up with a saner idea. :) Hobbsee signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Focus of MOTU (Was: NEW Packages process)
Hi There,
this whole discussion actually freaked me out a bit. I don't know how
you feel about it, but I think we (as the MOTU team) need to come back
to our main focus:
Get Universe/Multiverse as shiny as possible !
Ok, here it goes...
Priority 1a:
I think our main focus should still be to fix
Universe/Multiverse packages for the actual development
release. That means, merging, syncing, fixing packages which we
are importing from Debian or from older times from apt-get.org.
This will eat most of our time during a release.
Priority 1b:
Recruite New Blood !
Yes, we are lacking of Menpower. We need more active people,
who are working on Prio 1a !
This we can only achieve, with more PR. Furthermore, we need
smart people and people who will stay focused, and even when
"older" MOTUs are showing some "Burn Out" symptoms, we need to
help them to come over this situation.
("older" doesn't mean here: Age, it means Time being involved
in the Ubuntu MOTU Project)
Priority 2:
Fixing universe/multiverse even for older releases.
This includes StableReleaseUpdates, Backports and as well
Security Fixes.
Backports are quiet easy to achieve, but SRUs and
Security Fixes are serious and difficult. We should try to find
people, who are trustable and sensible for those areas. Here,
I think we should recruit this group of people from the already
existent MOTU Crew.
Priority 3:
New Packages !
Ah yes, our actual problem. I do think it's more wise to point
people to the mentor/sponsor project of Debian. But
nevertheless, we are responsible to push interesting Software
into Ubuntu, even before they hit Debian.
But this should be, until we are more active people working on
Prio 1 and 2, low prio.
New Packages are sometimes probelmatic, regarding the time and
quality. Quality means here, not the packaging quality, but
more important the quality of upstream projects.
As I explained in one of yesterdays replies, many packaged
software has not the quality upstream wise. We should ask us,
if we want short living upstream software packaged, or if we
push those packages towards Debian. If there is interest in
Debian, we can adopt this packages later on.
In my opinion, we shouldn't have a strong focus on new packages
at all. And yes, there are cornercases where I want to see
packages, which are not in Debian yet, in Ubuntu. But this
should be an exception for special areas, e.g. xfce, kde or
gnome, when people are coming to us with special software,
which would give us a worthable addon to fix bug no. 1
I don't think, that we need all shiny, only used by a minority
(means less then < 100 users), software in our archives. If
it's important for the packager to include it into Ubuntu, IMHO
there is need for it in Debian too, so that should be the first
way to push this software.
Priority 4:
Training !
Training is important. Knowledge transfer is important.
I would like to see more MOTU-School/Ubuntu-School
sessions. Not only for packaging and other development stuff,
but also e.g. regarding Virtualization, Buildserver Setup,
Server Setup in general, Automatic Deployment of Debian/Ubuntu
releases, License Knowledge, etc...
I know, some of these topics are also covered by our Sponsors
business, but not everybody has the opportunity to spend money
for trainings. Therefore we should be able to concentrate some
of our knowledge into a training session and explain the world
how things are working in real life environments.
Priority 5:
Decreasing Red Tape (Bureaucracy) !
In the last year we saw a lot of bureaucracy added to the MOTU
team. I do think, this stops us a lot.
I know, without some bureaucracy we would sink in chaos, but
too much bureaucracy is bad.
We should try to stop this, before it gives us more problems,
and scaring away people.
Instead of introducing new barriers for old behaviour, we
should try to renew some of our processes to be adapted for
the situation now.
An example:
in the beginning, during the merging time, we just went through
MergeOMatics list of packages, and everybody was catching at
least a package. No need to think about/ping the last uploader.
"Just get our work done these days", was the devise.
Today, we need at least to look at two places, MoM+DaD, asking
the old uploader, eventually waiting too long for an answer.
This
Re: NEW Packages process
On Thu, 17 Apr 2008 00:22:08 +0200 Soren Hansen <[EMAIL PROTECTED]> wrote: >On Wed, Apr 16, 2008 at 10:09:13AM -0300, Cody A.W. Somerville wrote: >> One of the reasons Open Source software *works* is because it employs >> the scientific method. That process relies heavily on peer review. I >> don't think we should remove that, discourage that, or ever consider >> it unimportant. If everyone had unlimited time and resources, I would >> get every single one of my packages reviewed. No, not because I don't >> think I'm not competent enough to make the upload myself alone but >> because I consider peer review the corner stone of our development >> model. >> >> Maybe the issue here isn't a philosophical one but more of a technical >> one? Maybe we should focus, as you suggested, on improving and >> innovating review infrastructure? > >I don't think anyone's really suggesting not doing peer reviews. The >question is more about whether to require it before it enters the >archive to begin with or to recommend and encourage it after the fact. The proposal only removed before upload reviews and added an unenforceable suggest about people signing up for bugmail. I don't see where the proposal does anything except remove reviews. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wed, Apr 16, 2008 at 10:09:13AM -0300, Cody A.W. Somerville wrote: > One of the reasons Open Source software *works* is because it employs > the scientific method. That process relies heavily on peer review. I > don't think we should remove that, discourage that, or ever consider > it unimportant. If everyone had unlimited time and resources, I would > get every single one of my packages reviewed. No, not because I don't > think I'm not competent enough to make the upload myself alone but > because I consider peer review the corner stone of our development > model. > > Maybe the issue here isn't a philosophical one but more of a technical > one? Maybe we should focus, as you suggested, on improving and > innovating review infrastructure? I don't think anyone's really suggesting not doing peer reviews. The question is more about whether to require it before it enters the archive to begin with or to recommend and encourage it after the fact. -- Soren Hansen | Virtualisation specialist | Ubuntu Server Team Canonical Ltd. | http://www.ubuntu.com/ signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wed, Apr 16, 2008 at 02:40:51PM +0200, Daniel Holbach wrote: > If I submitted a package, had to wait weeks to get it reviewed, then > got a reply "please fix this triviality" I wasn't sure if I made it my > first priority to come up with a fix. What if inclusion in the final release was dependent on certain things being fixed? That would be quite an incentive to make sure it got fixed, I think. Kind of like broken packages in Debian can be removed from testing (and hence will never be in stable), while staying in unstable. -- Soren Hansen | Virtualisation specialist | Ubuntu Server Team Canonical Ltd. | http://www.ubuntu.com/ signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Hi, Am Wed, 16 Apr 2008 22:34:34 +0200 schrieb Soren Hansen <[EMAIL PROTECTED]>: > On Wed, Apr 16, 2008 at 07:40:48PM +0200, Stefan Potyra wrote: > > Autobuilding: autobuilding is basically handing out a root shell on > > the box, so this won't happen. > > I hear virtualisation is all the rage these days. Yes..right...opensuses buildservice got HW sponsored from amd for this to happen (afaik)...(they are using xen images for their chroot cages) and those servers are mounted somewhere in novell/suses DCs or at sponsord places by IP Exchange (Nuernberg) with enough power to play with. (AMD Machines Sponsoring: http://news.opensuse.org/2007/08/07/opensuse-build-service-gains-momentum-with-amd-sponsorship/) regarding ubuntuwires hardware farm, I wonder if this will be a reasonable fundraiser idea. or we could beg amazon for some spare elastic cloud power... /me really needs a life now ;) \sh -- SysAdmin, OSS Developer GPG-Key ID: 0xC098EFA8 Fingerprint: 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 http://www.sourcecode.de/ -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wednesday 16 April 2008 17:19, Stefan Potyra wrote: > Hi, > > Am Mittwoch 16 April 2008 22:34:34 schrieb Soren Hansen: > > On Wed, Apr 16, 2008 at 07:40:48PM +0200, Stefan Potyra wrote: > > > Autobuilding: autobuilding is basically handing out a root shell on > > > the box, so this won't happen. > > > > I hear virtualisation is all the rage these days. > > Bah... virtualisation is overrated :P > > Seriously, it's a sparc box, what would work there OOTB? qemu? > > I think going for PPAs might be an easier way to get packages built, given > that we can get permissions to do so. > > Finally someone would still need to fiddle with REVU, any volunteers? > I think binary uploads would be a better choice. Then there's nothing to review until it at least builds. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Hi, Am Mittwoch 16 April 2008 22:34:34 schrieb Soren Hansen: > On Wed, Apr 16, 2008 at 07:40:48PM +0200, Stefan Potyra wrote: > > Autobuilding: autobuilding is basically handing out a root shell on > > the box, so this won't happen. > > I hear virtualisation is all the rage these days. Bah... virtualisation is overrated :P Seriously, it's a sparc box, what would work there OOTB? qemu? I think going for PPAs might be an easier way to get packages built, given that we can get permissions to do so. Finally someone would still need to fiddle with REVU, any volunteers? Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wed, Apr 16, 2008 at 07:40:48PM +0200, Stefan Potyra wrote: > Autobuilding: autobuilding is basically handing out a root shell on > the box, so this won't happen. I hear virtualisation is all the rage these days. -- Soren Hansen | Virtualisation specialist | Ubuntu Server Team Canonical Ltd. | http://www.ubuntu.com/ signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Emilio Pozuelo Monfort <[EMAIL PROTECTED]> writes: > So I think mailing lintian's output to the uploader would be a good idea. And > ideally that would be against source and binaries, at least for the first > upload... although that would place a high load on REVU's host. Please be assured that the load is not the issue for not mailing uploaders. I am more concernced about spamming uninvoled persons. This can easily happen if someone finds some random package on the net (like packages.debian.org), wants to see it in ubuntu and decides to upload it to review without updating debian/changelog properly. Even worse, the email address could be even faked and innocent people be confused pretty badly, which would then blame us, the revu administrators. Note that we don't have any verification of the contributor. We don't even check the email address on the key used to upload. We therefore need to be very careful with uploaded package on revu. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
2008/4/16, Stefan Potyra <[EMAIL PROTECTED]>: > hm... that's tough. Well, there is lintian, but not all of lintian output is > always correct for each source package (that's why you can override parts of > it). So the tricky part here is: What to do with the result of a package > checker? (should it reject the package, which would be wrong for some, should > it leave a negative reviewing comment, same problem, or should it just be > informational, which is what we have right now, though not really presented > very nicely). I'm thinking about adding a "Automatic checks have detected X problems with this package." message (linking to lintian's result) on the top of the details.py page (in a rectangular box like those in Launchpad). Do you think this would help raise awareness about those problems? -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Hi, On Wednesday 16 April 2008 18:51:36 Loïc Martin wrote: [..] > > > 1. Is it possible to review what are the most frequent packaging errors, > and how much of these can be picked up by a few scripts? > > IMHO, most new contributors would omit debian/copyright, or tend to > indicate the wrong Ubuntu version (i.e. the stable release instead of > the development one, since at first you're not going to know about SRU > policy), leave the Debian one, forget to fill some fields in > debian/control, include binaries, etc... > > Could it be possible to automate most of these checks and others, so > each uploader would get feedback on the first screening errors ( a > process which, at the moment, can take 2+ weeks)? The system could point > to the relevant parts of the documentation (hypertext links or extracts) > for each problem, and provide information on how to receive human > interaction if necessary - irc, mailing list or, better, a packaging > forum since Windows users aren't used to irc and mailing lists). In > short, a kind of lintian for common mortals, but server-side. hm... that's tough. Well, there is lintian, but not all of lintian output is always correct for each source package (that's why you can override parts of it). So the tricky part here is: What to do with the result of a package checker? (should it reject the package, which would be wrong for some, should it leave a negative reviewing comment, same problem, or should it just be informational, which is what we have right now, though not really presented very nicely). Others than that, someone would have to write such a checker, in case lintian doesn't fulfill the needs. Running that on the server - given that it's particular secure to do so - shouldn't be a problem. > > Result : the packager gets immediate input, and reviewers know that > they're only reviewing pre-screened packages which should already build > and meet a few basic standards. How costly would it be for the server to > try and test building each upload - getting the tarball, applying the > patches, trying to build the package, and even trying to run it?) Autobuilding: autobuilding is basically handing out a root shell on the box, so this won't happen. > > > 2. When the new package is uploaded, the uploader's email could be added > as a bug contact, while all reviewing comments (including the automated > screening results) are forwarded to its email address, ensuring nobody > loses touch with their package unless they'd really have no interest in > it (which I assume isn't the case in the first place). Well, we have the motu-reviewers mailing list. I'm not sure if I'd like to get an additional email myself, but this shouldn't be too tough to do in case other people feel the same way. (I guess the hardest part is finding out where to send the email, since it involves looking up the signature of the changes file and finding out the email address of the signature). Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Am Wed, 16 Apr 2008 18:27:05 +0200 schrieb Emilio Pozuelo Monfort <[EMAIL PROTECTED]>: > Stephan Hermann wrote: > > On Wed, 16 Apr 2008 17:52:45 +0200 > > Emilio Pozuelo Monfort <[EMAIL PROTECTED]> wrote: > >> Anyway, should I see a package for which the packager says he won't > >> look at it anymore when it hits the archive because it's not his > >> duty, I won't upload it. With those arguments, it's not his duty to > >> package it and get it into the archive either way, so why should he > >> be allowed to do one but not the other if he doesn't care for the > >> package? > > > > Well, you don't know the guy who wants to get his package uploaded > > to the archive.. > > I may know him :) Yes :) But mostly the majority of uploaders to revu are pieces of blank paper...:) > > > so after the package hit the archive, the whole MOTU team > > is responsible to "support" the package anyways...just because "the > > former guy who proposed the package doesn't want to maintain it > > anymore" is no reason to drop the package from the archive... > > Right. I meant if the packager said it beforehand. But I agree with > you that if he doesn't say anything and I upload it, you're right he > disappearing wouldn't be a (good enough) reason to remove the package. But gives us , the MOTU team, more work, which actually could be better invested in real important packages, if someone can say that about universe...actually we know the really important packages well enough to take care about them. > This makes me (sadly?) want to concentrate on packages for which I > know the packager will keep the interest on them. You are not alone with this feeling...for me, I can say, every package with my name tag on it (regarding XSBC-Original-Maintainer) I uploaded to Ubuntu Universe is maintained (my very first package even went to main and is now maintained in bzr without my work ;))) because I have interest in them to have them in a good shape and up2date, just let's say I need them in my real life work, too ;) (hah, there is always a catch). Even when there are bugs in the upstream source, I'm able to fix them (most of the time) by myself, but if it's really not maintainable anymore, I'm the first one who files a removal request for it. Regards, \sh -- SysAdmin, OSS Developer GPG-Key ID: 0xC098EFA8 Fingerprint: 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 http://www.sourcecode.de/ -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Hi, Am Wed, 16 Apr 2008 11:45:31 -0500 schrieb "Justin Dugger" <[EMAIL PROTECTED]>: > On Wed, Apr 16, 2008 at 11:20 AM, Stephan Hermann <[EMAIL PROTECTED]> > wrote: > > We need a barrier, to not let all software into Ubuntu, which will > > only live for a couple of months. > > On the contrary, while I agree that review is good and necessary, many > upstreams view individual distributions as testing grounds for > patches. Linus has often said historically that if he rejects your > patch, maybe have the redhat tree carry it for a while. Upstream is > the spring from which all software flows, so it's safer to place the > risk with a single distro than push a bad patch out to everyone. Of > course, this sort of system requires people capable of evaluating and > fixing software and patches. If MOTU doesn't have that kind of human > capital, then it's probably better that this sort of work be left to > Gentoo, Debian etc and let upstream handle applying patches when > they're ready. No...I'm not talking about "patches towards already existent packages". I think we have valuable people, who are even involved in upstream projects, to judge about a patch, the quality of it and the usefullness for the distro. Some patches are useful for distros, but not actually for upstream...we see that every day :) But the whole thread is about something else. Actually, what I saw in the past is, that many upstream developers of small projects are just coming by and packaging their stuff, actually this is a good thing, but when you see, that a project with one upstream developer, who happens to be the packager who proposed the package to revu, only lives for a couple of weeks or months, just because there is no interest in the upstream project itself, then it makes no sense, to push the package into the archive, actually it's a waste of time and a waste of bandwidth and storage. People, who are reviewing the packages, are investing valuable time into this, and the result of their work should be valuable, too. A package where the upstream project dies after a countable timeframe is not worth to be in any distro. Now, what's left. We have packages with upstream projects which are valuable. But the guy who proposed and packaged the software in the first place, runs away after the software is in the archive, or he/she runs away even before the package is ready...hell, this is wasted time, too, because now the active motus have one package more to take care of (when it was acked even by 2 MOTUs and uploaded by a MOTU), and we don't even get the other packages, coming from debian, in shape for every release. But it's not against our policy, we don't force the initial packager to stay with us...he/she can come and go as he/she wants. If we would have a process of automatic removal of packages which are not maintained over a certain ammount of time, that would be great...we have many dead packages in our archives...;) It's a problem of the ammount of packages, the ammount of time to get things done (remember it's community which means people have also a real life, a life which earns money and real life love actually) and (sry for the word) human resources. Therefore, having a high barrier for eventually not needed software, is good, and we should see that at least some of the well known lower barriers (lintian etc.) are taken automatically before the human MOTU resource starts to work on that. Regards, \sh -- SysAdmin, OSS Developer GPG-Key ID: 0xC098EFA8 Fingerprint: 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 http://www.sourcecode.de/ -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wednesday 16 April 2008 13:45, Emilio Pozuelo Monfort wrote: > Scott Kitterman wrote: > > On Wednesday 16 April 2008 13:07, Emilio Pozuelo Monfort wrote: > >> So I think mailing lintian's output to the uploader would be a good > >> idea. And ideally that would be against source and binaries, at least > >> for the first upload... although that would place a high load on REVU's > >> host. But maybe with the new one Stefan just announced, we could change > >> this? :) > > > > Except we don't do binary uploads in Ubuntu. Even in Debian where they > > do, they stopped taking binary uploads on mentors because of problems > > with people trying to use broken packages. > > Sorry for being unclear. I meant REVU building the packages, not users > uploading them. OTOH, we could allow (or even 'force') users to make binary > uploads, run lintian (and maybe piuparts too) on them, but don't show > binaries to the public (only to devs an to the uploader maybe). If we go down this road, I'd suggest accepting only binary uploads. That'd make sure the package at least builds before MOTUs waste time reviewing it. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Scott Kitterman wrote: > On Wednesday 16 April 2008 13:07, Emilio Pozuelo Monfort wrote: > >> So I think mailing lintian's output to the uploader would be a good idea. >> And ideally that would be against source and binaries, at least for the >> first upload... although that would place a high load on REVU's host. But >> maybe with the new one Stefan just announced, we could change this? :) > > Except we don't do binary uploads in Ubuntu. Even in Debian where they do, > they stopped taking binary uploads on mentors because of problems with people > trying to use broken packages. Sorry for being unclear. I meant REVU building the packages, not users uploading them. OTOH, we could allow (or even 'force') users to make binary uploads, run lintian (and maybe piuparts too) on them, but don't show binaries to the public (only to devs an to the uploader maybe). > If people can't be bothered to click on the link on their package page in > REVU > to see what the lintian errors are, I doubt an email will help much. I think an email is way more 'discoverable' than a link on the package page on REVU. We could of course improve its place/presentation, but I think a mail will always be more prominent. Cheers, Emilio signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wednesday 16 April 2008 13:17, Jordan Mantha wrote: > Daniel Holbach wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Hello everybody, > > > > after a recent discussion about a perceived disconnect between "main > > processes" and "universe processes", I thought a bit about the process > > for NEW Packages. > > Well, just to be clear, there is no disconnect between Main and Universe > when it comes to NEW packages because there is only one "policy". > Packages go through Universe to get to Main. There is no Main NEW > processes (unless you count MIR but I don't think we want to go there). > > > Historically it was introduced to make sure that new packages are of > > tip-top quality when they enter the archive. We started with 3 necessary > > ACKs and changed it to 2 ACKs for non-MOTUs and encouraged MOTUs to get > > an ACK from other MOTUs. I feel we've been very successful with the work > > we've put into Universe and the quality of new packages. > > Entirely too successful, IMO. Around 1/3 of all Universe Ubuntu packages > (ubuntu versioned) are not in Debian which means MOTU is the sole > maintainer. Even if we say 10% are Ubuntu-specific that leaves something > around 700 packages we have to maintain by ourselves or probably at > least 10 packages/MOTU. This is pretty much nuts if you ask me. But > that's another discussion so I won't go any further with that. I think it's entirely on point. I don't think easier to get new packages into Ubuntu is a problem that really needs solving. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wednesday 16 April 2008 13:07, Emilio Pozuelo Monfort wrote: > So I think mailing lintian's output to the uploader would be a good idea. > And ideally that would be against source and binaries, at least for the > first upload... although that would place a high load on REVU's host. But > maybe with the new one Stefan just announced, we could change this? :) Except we don't do binary uploads in Ubuntu. Even in Debian where they do, they stopped taking binary uploads on mentors because of problems with people trying to use broken packages. If people can't be bothered to click on the link on their package page in REVU to see what the lintian errors are, I doubt an email will help much. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Daniel Holbach wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello everybody, > > after a recent discussion about a perceived disconnect between "main > processes" and "universe processes", I thought a bit about the process > for NEW Packages. Well, just to be clear, there is no disconnect between Main and Universe when it comes to NEW packages because there is only one "policy". Packages go through Universe to get to Main. There is no Main NEW processes (unless you count MIR but I don't think we want to go there). > Historically it was introduced to make sure that new packages are of > tip-top quality when they enter the archive. We started with 3 necessary > ACKs and changed it to 2 ACKs for non-MOTUs and encouraged MOTUs to get > an ACK from other MOTUs. I feel we've been very successful with the work > we've put into Universe and the quality of new packages. Entirely too successful, IMO. Around 1/3 of all Universe Ubuntu packages (ubuntu versioned) are not in Debian which means MOTU is the sole maintainer. Even if we say 10% are Ubuntu-specific that leaves something around 700 packages we have to maintain by ourselves or probably at least 10 packages/MOTU. This is pretty much nuts if you ask me. But that's another discussion so I won't go any further with that. > I propose the following changes: > 1) cut down the requirement to one ACK of a ubuntu-dev member Which will honestly get you many fewer reviews and many more rejections from the archive admins. > 2) requirement for the person who packaged the new software to become > bug contact Seems reasonable, though not really enforceable. Definitely a "best practice" sort of thing. > These changes would have a number of benefits: > - it would cut down the review overhead and the time of waiting Well, yes and no. There is certainly waiting time involved with having to get 2 acks, however I think having 2 MOTUs going sort of working as a team to tackle a package can be pretty darn quick and gives you a much better package. > - instead of a high entry barrier, have a higher emphasis on fixing > problems of packages in Universe Well, to be honest, I consider what we do on REVU to be the *minimum* barrier. I agree that we really need to emphasis fixing problems in packages *already* in the archive. For instance, how are those 700+ packages from REVU that we already are maintaining on our own doing? > - higher similarity between NEW Packages process and Sponsoring process I'm afraid I don't get that. Really if you're going by similarity the only thing you *want* to be different is the number of acks because that is reflecting there much greater review it takes to introduce a NEW package versus a typo fix or something. I think contributors find the complete disconnect in tools used (REVU vs. u-u-s) to be much more confusing that needing 1 ack vs. 2. > - accredit technical skills of approved ubuntu-dev members and don't > require re-review I don't think it's really about not trusting or crediting the technical skills of other MOTUS. My thinking goes like this, I don't really trust myself to be able to properly review any package that's on REVU. I often miss things and there is *so* much to look at. OK, I know this is a long email already but I had a couple thoughts on the larger issue of getting REVU running better: 1) can we pair the 2 MOTUs doing the reviews? What I mean is I would go on review and "sign" up for packages I'm interested in reviewing. Once there are two MOTUs signed up they work together as a team to get that package ready to go. This would eliminate a lot of the waiting I would think. 2) to do the above we need to triage REVU so that packages are in a state where they're most likely not going to be flat-out rejected before 2 MOTUs devote time to them. If we made sure that lintian wouldn't give spurious warnings would it be unreasonable to ask that packages be lintian clean before MOTUs would look at them? Perhaps this is a perfect task for the Ubuntu Apprentices (or whatever we're gonna call them). 3) Perhaps it wouldn't hurt to also ask the question, "Why should we have this software in Universe?". People tend to package up either "latest crack" or "dead, unmaintained, and useful to all of 10 people in the entire world". I don't think we need to get nit-picky, but I firmly believe that every packager should be able to give some reason why we should ship a package other than "dunno, something to do". It gives people motivation to move on the maintaining the package. enough from me already, -Jordan -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Reinhard Tartler wrote: > Emilio Pozuelo Monfort <[EMAIL PROTECTED]> writes: > >> Reinhard Tartler wrote: >>> * for NEW packages, there is obviously no LP entry yet. >> Actually there is, just after the package hits NEW. And you can at >> that point subscribe to bug mail, so this shouldn't be an issue. > > Sorry, I wasn't clear enough. Daniel's requirement for an upload was > that the contributor needs to be a bug contact for a package. My point > is that there is no way to ensure this prior to uploading. Oh, indeed. There's been a suggestion on this thread for Launchpad to automatically subscribe the Maintainer to the package. That wouldn't solve this as usually the Maintainer is MOTU, but perhaps we could find a solution which solves this and is likely to be accepted by the Launchpad crew. signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Loïc Martin wrote: > 1. Is it possible to review what are the most frequent packaging errors, > and how much of these can be picked up by a few scripts? > > IMHO, most new contributors would omit debian/copyright, or tend to > indicate the wrong Ubuntu version (i.e. the stable release instead of > the development one, since at first you're not going to know about SRU > policy), leave the Debian one, forget to fill some fields in > debian/control, include binaries, etc... > > Could it be possible to automate most of these checks and others, so > each uploader would get feedback on the first screening errors ( a > process which, at the moment, can take 2+ weeks)? There's lintian for this, which runs on REVU against the source packages (not the binaries). Unfortunately, most packagers don't seem to check lintian output against their packages (including binaries). That's usually the first comment some reviewers leave (including myself), and in some cases that's most of what needs to be fixed. So I think mailing lintian's output to the uploader would be a good idea. And ideally that would be against source and binaries, at least for the first upload... although that would place a high load on REVU's host. But maybe with the new one Stefan just announced, we could change this? :) signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Emilio Pozuelo Monfort <[EMAIL PROTECTED]> writes: > Reinhard Tartler wrote: >> * for NEW packages, there is obviously no LP entry yet. > > Actually there is, just after the package hits NEW. And you can at > that point subscribe to bug mail, so this shouldn't be an issue. Sorry, I wasn't clear enough. Daniel's requirement for an upload was that the contributor needs to be a bug contact for a package. My point is that there is no way to ensure this prior to uploading. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
I'm no MOTU and just speak from a newbie uploader's perspective. Daniel Holbach wrote : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Stefan Potyra schrieb: >> One argument against it raised in the past is, that this might lead to fewer >> people reviewing a package (or giving an ACK for a package), as they might >> be >> unsure about it. > > Maybe the right fix for this the situation is to establish an easy way to > - solicit feedback about a packaging situation one is unsure about > - document the "best way to solve problem X" either in > https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews or > https://wiki.ubuntu.com/PackagingGuide > > I can see a number of additional benefits in this solution. I'm no MOTU or REVU expert, so I might be completely OT (if so, just disregard my comment) but from what I've understood from scarce contacts with uploading a new package and uploading one packaging patch in Launchpad, there's a few questions/suggestions : 1. Is it possible to review what are the most frequent packaging errors, and how much of these can be picked up by a few scripts? IMHO, most new contributors would omit debian/copyright, or tend to indicate the wrong Ubuntu version (i.e. the stable release instead of the development one, since at first you're not going to know about SRU policy), leave the Debian one, forget to fill some fields in debian/control, include binaries, etc... Could it be possible to automate most of these checks and others, so each uploader would get feedback on the first screening errors ( a process which, at the moment, can take 2+ weeks)? The system could point to the relevant parts of the documentation (hypertext links or extracts) for each problem, and provide information on how to receive human interaction if necessary - irc, mailing list or, better, a packaging forum since Windows users aren't used to irc and mailing lists). In short, a kind of lintian for common mortals, but server-side. Result : the packager gets immediate input, and reviewers know that they're only reviewing pre-screened packages which should already build and meet a few basic standards. How costly would it be for the server to try and test building each upload - getting the tarball, applying the patches, trying to build the package, and even trying to run it?) The system could even replace all Debian versions or wrong Ubuntu versions in debian/control by the development one, and see if it still builds/run. 2. When the new package is uploaded, the uploader's email could be added as a bug contact, while all reviewing comments (including the automated screening results) are forwarded to its email address, ensuring nobody loses touch with their package unless they'd really have no interest in it (which I assume isn't the case in the first place). I can imagine lots of people disappear after having uploaded a package because they just stopped checking everyday for feedback after 2 weeks or so. Having an email appear in your letterbox even when you'd long forgotten you ever uploaded a package could solve that problem (who in their right mind would force themselves spending 10 min a day on that when there's no indication you'll ever receive an answer before upstream releases a new version, forcing you to restart the counters - 2+ weeks wait before any new review). After 2 weeks, either you imagine nobody's going to review your package, or - at best - you imagine there's always going to be a 2+ weeks delay at each step of the process. Having automated screening/answering could save a lot of unproductive time from MOTU. It would be a guaranty that they'll never be spending time on a package whose uploader might disappear, since they'd known the uploader was willing to fix the first packaging errors and has already learnt a bit in the process. First-time uploaders don't have a break between the upload and the fixes, so their interest is keen. A 2 weeks wait also does a lot of harm in any learning process (ask any teacher) since you'll have forgotten most of what you already had to learn in order to build your first package - that means losing a few days again just to get to the level you were when you uploaded the package in the first place, then learning new information to fix your errors. Having an email process also ensures no uploaders forget their uploads, while Help - and explanations on how to get it - is available to the uploader. That's a long email for what is just my two cents. Loïc -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Stephan Hermann wrote: > On Wed, 16 Apr 2008 17:52:45 +0200 > Emilio Pozuelo Monfort <[EMAIL PROTECTED]> wrote: >> Anyway, should I see a package for which the packager says he won't >> look at it anymore when it hits the archive because it's not his >> duty, I won't upload it. With those arguments, it's not his duty to >> package it and get it into the archive either way, so why should he >> be allowed to do one but not the other if he doesn't care for the >> package? > > Well, you don't know the guy who wants to get his package uploaded to > the archive.. I may know him :) > so after the package hit the archive, the whole MOTU team > is responsible to "support" the package anyways...just because "the > former guy who proposed the package doesn't want to maintain it > anymore" is no reason to drop the package from the archive... Right. I meant if the packager said it beforehand. But I agree with you that if he doesn't say anything and I upload it, you're right he disappearing wouldn't be a (good enough) reason to remove the package. This makes me (sadly?) want to concentrate on packages for which I know the packager will keep the interest on them. Cheers, Emilio signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Hi, On Wed, 16 Apr 2008 18:03:44 +0200 Soren Hansen <[EMAIL PROTECTED]> wrote: > On Wed, Apr 16, 2008 at 04:37:00PM +0200, Stephan Hermann wrote: > >>> * for NEW packages, there is obviously no LP entry yet. > >> Actually there is, just after the package hits NEW. And you can at > >> that point subscribe to bug mail, so this shouldn't be an issue. > > "Why should I care about a package which I want in Ubuntu? The MOTU > > Team is responsible for Universe...so I'm out of the chain there" > > > > This would be my thinking...if I'm not "chained" to Ubuntu. > > This may surprise you: Not everyone's like that. Well, after a decade dealing with different communities regarding OSS projects, I would say, that 75% of all contributing people in our business are "fire and forget" only 15% of all people contributing to FOSS are staying and doing more work. I could be wrong, but that's my view of the situation, and actually it was matching the situation since it became a "hype" to push packages into Ubuntu, because it was much faster then pushing them into Debian. Why? Because when I propose a patch to an upstream project, this patch is not going through directly...the patch is being discussed...(actually it's a review of the contents of the patch). This discussion is, for many people, a burden, because other people are judging your knowledge, your experience, your code. the judges are people with even more knowledge or less, depends on the project. After all that, many people will go, because their patch was not pushed into this project, because of some very serious reasons and objections from long standing contributors. Those contributors are not coming back... TBH, this behaviour is quiet known in every community which has nothing to do with IT or software or whatever technical stuff is out there. But actually that's my opinion...I saw it while REVU was evolving..and I stand to my point, that most people are going away, after the goal is reached, to get their package in our archives...after that the MOTU team has the responsibility to take care about that package... We need a barrier, to not let all software into Ubuntu, which will only live for a couple of months. Anyways...heading home now... later, \sh -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wed, Apr 16, 2008 at 04:37:00PM +0200, Stephan Hermann wrote: >>> * for NEW packages, there is obviously no LP entry yet. >> Actually there is, just after the package hits NEW. And you can at >> that point subscribe to bug mail, so this shouldn't be an issue. > "Why should I care about a package which I want in Ubuntu? The MOTU > Team is responsible for Universe...so I'm out of the chain there" > > This would be my thinking...if I'm not "chained" to Ubuntu. This may surprise you: Not everyone's like that. -- Soren Hansen | Virtualisation specialist | Ubuntu Server Team Canonical Ltd. | http://www.ubuntu.com/ signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
This is another response from the beginner packager's POV. When I first submitted my package, probably four or five different people looked at it, and every one of them found something different to comment on. The process was fairly nerve-wracking and I lost some sleep since I was close to the freeze deadline, but the result was a better package. Even then, having a watch file wasn't caught until more recently. Some of the comments given were critical kinds of items, but others were more subjective, informational kinds of things, and by getting the input of lots of people I learned a lot more about the packaging process overall than I would have with just one, or even two. So, while we _could_ probably get by with one ACK, I don't think it would be the most beneficial way of doing things. -- Tony Yarusso http://tonyyarusso.com/ -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wed, 16 Apr 2008 17:52:45 +0200 Emilio Pozuelo Monfort <[EMAIL PROTECTED]> wrote: > Stephan Hermann wrote: > > On Wed, 16 Apr 2008 16:08:10 +0200 > > Emilio Pozuelo Monfort <[EMAIL PROTECTED]> wrote: > > > >> Reinhard Tartler wrote: > >>> * for NEW packages, there is obviously no LP entry yet. > >> Actually there is, just after the package hits NEW. And you can at > >> that point subscribe to bug mail, so this shouldn't be an issue. > > > > "Why should I care about a package which I want in Ubuntu? The MOTU > > Team is responsible for Universe...so I'm out of the chain there" > > I was speaking about Reinhard's problem. Of course if you don't want > to subscribe to bug mail there's nothing we can do about it, or if > you subscribe and unsubscribe after that... Ok, I thought it was more general :) > > Anyway, should I see a package for which the packager says he won't > look at it anymore when it hits the archive because it's not his > duty, I won't upload it. With those arguments, it's not his duty to > package it and get it into the archive either way, so why should he > be allowed to do one but not the other if he doesn't care for the > package? Well, you don't know the guy who wants to get his package uploaded to the archive..so after the package hit the archive, the whole MOTU team is responsible to "support" the package anyways...just because "the former guy who proposed the package doesn't want to maintain it anymore" is no reason to drop the package from the archive... Regards, \sh -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Stephan Hermann wrote: > On Wed, 16 Apr 2008 16:08:10 +0200 > Emilio Pozuelo Monfort <[EMAIL PROTECTED]> wrote: > >> Reinhard Tartler wrote: >>> * for NEW packages, there is obviously no LP entry yet. >> Actually there is, just after the package hits NEW. And you can at >> that point subscribe to bug mail, so this shouldn't be an issue. > > "Why should I care about a package which I want in Ubuntu? The MOTU > Team is responsible for Universe...so I'm out of the chain there" I was speaking about Reinhard's problem. Of course if you don't want to subscribe to bug mail there's nothing we can do about it, or if you subscribe and unsubscribe after that... Anyway, should I see a package for which the packager says he won't look at it anymore when it hits the archive because it's not his duty, I won't upload it. With those arguments, it's not his duty to package it and get it into the archive either way, so why should he be allowed to do one but not the other if he doesn't care for the package? Emilio signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
IMHO there are many good reasons to maintain the 2 ACK requirement for new packages. As someone who has contributed several packages through the REVU system, I admit that I was initially frustrated with the slow and circumstantial reviewing procedure. However, the advantage of the system gradually became clear to me, and I became quite impressed with the great care and professionalism that was put into the review of each and every package. Needing two advocates for my packages forced me to use IRC and get to know people. It quickly became clear to me as a contributor that "getting your stuff into Ubuntu" is not something you "just do". It takes perseverance and hard work. This contributes to giving the Universe a good reputation in the free software world. And, it ensures a top notch repo. Needing two ACKs from MOTUs has nothing to do with "not being able to trust just one".The scientific world uses a peer review system, with two, three or more reviewers involved, and that system is not based on a lack of trust. It's simply a sensible QA procedure. For the MOTUs, there is an additional advantage involved in requiring co-sponsors, and that is the development and maintenance of an interacting and collaborating culture. If MOTUs could simply grab an upload from REVU, review and sponsor it, they could in practice work in parallel universes without ever having to interact. The package review system may need a service check, and it is always constructive to see if a workflow can be improved. But let's not abolish a reasonable up-front QA procedure. Cheers, Morten (mok0) -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wed, 16 Apr 2008 16:08:10 +0200 Emilio Pozuelo Monfort <[EMAIL PROTECTED]> wrote: > Reinhard Tartler wrote: > > * for NEW packages, there is obviously no LP entry yet. > > Actually there is, just after the package hits NEW. And you can at > that point subscribe to bug mail, so this shouldn't be an issue. "Why should I care about a package which I want in Ubuntu? The MOTU Team is responsible for Universe...so I'm out of the chain there" This would be my thinking...if I'm not "chained" to Ubuntu. Regards, \sh -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Disclaimer: I am not a MOTU, but rather just a fresh, minor contributor since Ubuntu Hardy. So I can give my point of view from the other part of the fence. On Wed, Apr 16, 2008 at 3:14 PM, Scott Kitterman <[EMAIL PROTECTED]> wrote: > There is a tension in the new package process between teaching about > packaging > and getting new packages in. If all we care about was getting new packages > in, we'd take the 5 minutes it takes to fix up the details and upload, but we > don't just care about that, so we pitch it back to the contributor to fix so > they learn better. This is sometimes frustrating for the student, but that's > part of the learning process. I agree with this. After I've submitted a package, I got after some weeks the notice that the debian/copyright was not correct. Of course this was frustrating and irritating for a first contribution. As I am as well the upstream author of the package, I considered if I should not put my time in developing the application rather than packaging it. But getting all kind of emails about installation problems is also frustrating. So I decided to fix the issue, which even involved finding new icons with a clear origin. After that my package got accepted and was successfully updated with help from MOTU's and DD. After the whole process, my conclusion is: - The frustration was 'worth' it. I simply did not know enough and it is not that difficult in the end. A psychological aspect is that I was afraid that every other update would be such a painful process. What as a new contributor you don't realise as that getting your package accepted is the hardest thing (because you have to learn) and that afterwards things go (more) smoothly (because you have learnt). So pointing that out to newcomers could have already a relaxing effect. - As a newcomer I would not like that my packages are accepted with (un)noticed bugs. I always thought that MOTU's are Masters of the Universe and I wouldn't like to be proven wrong. Right now you hope when your packages are accepted they are ok. As soon as bugs start to be accepted I guess it only becomes more confusing as it seems more random. It is always better first to go through hell to paradise than the opposite. Also in the whole discussion no MOTU stepped forward to state he can or wants to do package reviews alone. So nobody seems to consider peer reviewing as bureaucracy. If you want to prevent newcomers from being demotivated, I think this is another goal and there are other means to achieve that (especially documentation and example projects). Just my 2 cents, Stani -- http://pythonide.stani.be -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wednesday 16 April 2008 09:51, Daniel Holbach wrote: > Scott Kitterman schrieb: > > On Wednesday 16 April 2008 08:15, Daniel Holbach wrote: > >> I personally ask and have seen others actively asking for changes to > >> patches if they were not ready to go yet. (Be it packaging problems, > >> policy problems or not adhering to processes.) > > > > So the frustration gets pushed from the New package process into bug > > fixing if we end up with more of this. I think that's the LAST thing we > > want. > > What I said was in reply to the point that education happens less in the > sponsoring process, which I disagree with. > > If a package is not ready, it's not ready. If there are mistakes that > were overlooked (or things that could be improved) it's more likely to > get fixed once it's in the archive and bug fixing is "open for all". > > > Currently I think we are expending not nearly enough effort on > > maintaining what we have and really need to make that easier/smoother. > > We could move this out into a separate thread and discuss concrete > problems and solutions for them for Intrepid. > Fine, when I've got some ideas I'll bring it up, but for this thread, I think uploading less reveiwed packages is definitely a stop in the wrong direction. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Reinhard Tartler wrote: > * for NEW packages, there is obviously no LP entry yet. Actually there is, just after the package hits NEW. And you can at that point subscribe to bug mail, so this shouldn't be an issue. Emilio signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Side note (was: NEW Packages process)
Hi, On Wednesday 16 April 2008 14:06:59 Daniel Holbach wrote: [..] > > > (Side note: since when became the guideline criteria in CodeReviews > > stable? There used to be a note stating that these are not stable and > > links to the ml discussion in the wiki page which are gone now). > > Can you elaborate? sorry, seems like I recalled that wrongly. The guidelines started as a proposal from Emmet with some discussion on the mailing list, and I was very sure that we didn't finalize that yet in the wiki and have a note there as well. However I must have mixed this up with s.th. else, sorry. Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Kitterman schrieb: > On Wednesday 16 April 2008 08:15, Daniel Holbach wrote: >> I personally ask and have seen others actively asking for changes to >> patches if they were not ready to go yet. (Be it packaging problems, >> policy problems or not adhering to processes.) >> > So the frustration gets pushed from the New package process into bug fixing > if > we end up with more of this. I think that's the LAST thing we want. What I said was in reply to the point that education happens less in the sponsoring process, which I disagree with. If a package is not ready, it's not ready. If there are mistakes that were overlooked (or things that could be improved) it's more likely to get fixed once it's in the archive and bug fixing is "open for all". > Currently I think we are expending not nearly enough effort on maintaining > what we have and really need to make that easier/smoother. We could move this out into a separate thread and discuss concrete problems and solutions for them for Intrepid. Have a nice day, Daniel - -- My 5 today: #210449 (network-manager-applet), #215043, #193764 (evolution-scalix), #215472 (gnome-themes-extras), #205756 (gnome- subtitles) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBgRQRjrlnQWd1esRAuMVAJ9DnuqKq0bd0kYNPJ7OQhLYCERTegCfWTfW NzsGDNHpwxagEK41Vuryt4U= =O2BN -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Moins, On Wed, 16 Apr 2008 15:28:30 +0200 Reinhard Tartler <[EMAIL PROTECTED]> wrote: > > Daniel Holbach writes: > >> > 2) requirement for the person who packaged the new software to > >> > become bug contact > > Cesare Tirabassi <[EMAIL PROTECTED]> writes: > > I thought that was the norm ... > > I agree that this is a very good idea, but I don't rememer if or when > we did make that a requirement. It's not...because there is no automatism for this. Regarding LP, we could honour XSBC-Original-Maintainer from debian control, because NEW packages for universe should be: Maintainer: Ubuntu MOTU XSBC-Original-Maintainer: With this, we could automatically push as bug contact. Additionally we could have a Origin header or something similar where we can filter for in LP. Well, regarding the non-direct-maintainership in Ubuntu, i don't think there is really a sane way of achieving those goals, or we move from team maintaining to single package maintainer methods, for packages uploaded to Ubuntu and not coming from debian.. which then brings us to another problem... Bah, \sh -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Daniel Holbach writes: >> > 2) requirement for the person who packaged the new software to become >> > bug contact Cesare Tirabassi <[EMAIL PROTECTED]> writes: > I thought that was the norm ... I agree that this is a very good idea, but I don't rememer if or when we did make that a requirement. Anyways, let me think aloud about this. We want to have good packages contributed to the universe. By making it mandatory to become a bug contact for a package, we defact demand from the contributor to continue caring for the package. Issues I see with this: * for NEW packages, there is obviously no LP entry yet. This means manual for the sponsor to periodically check the package to become accepted and the contributor to sign up as bug contact. (which means additional work for the sponsor). How should the sponsor handle that case that the contributor fails to sign up as bug contact? (e.g. the contributor looses interest in the package right after uploading). * the contributor is asked to actually look at the bugs and care for them. What is the procedure if he is not able to properly maintain it? This point is obviously not a regression as we used to not care about having broken packages removed from universe. Instead we hope that someone stands up to fix it. Still, Daniels proposal is about a policy for accepting NEW packages, and preventing poor packages from entering the archive IS a valid concern. We need to find a balance between the following goals: 1. having a lot of shiny new packages in universe 2. encouring contributors to join MOTU 3. keeping broken packages out of universe FWIW, I think points 2 and 3 should have a priority. I don't think point 1 should be a priority. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Daniel Holbach wrote: > [snip] > I believe there are a lot of cases where REVU uploads are "triaged" (as > part of the long long list) and simply comment on the few obvious things > that could be improved. If the MOTU felt empowered to make the decision > right now and not leave the upload waiting for another ACK we would come > down to high-quality reviews quicker. ... how exactly do single-person impulse decisions improve the quality of reviews? >> We get a lot of drive by packagers who >> really won't come back and fix it. > > Right, that happens and is a problem. I'm just not sure how the NEW > packages process can make them more interested in packaging and maintaining. Showing them that it's fine to upload buggy packages is not going to make them more interested. >>> It all boils down to the question: "Why don't we trust one MOTU to get >>> it right?" >>> >> Because historically they don't (myself included). > > What can we do to > - strengthen the culture of "clean up after breaking stuff" I'd prefer to strengthen the culture of "not breaking things in the first place." Uploading known-buggy packages seems to violate this. I am thoroughly against this proposal. Although I haven't given too many reviews, for each I have found issues that thorough review by the previous acks. No single person can pick up everything. What's wrong with having more eyes on a package initially? Fixing things before upload is good, particularly if it tests the patience of the contributor. They need patience, or they'll do a drive-by NEW package, which we really, *really* don't need. -- William Grant signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wednesday 16 April 2008 08:59, Daniel Holbach wrote: > Scott Kitterman schrieb: > > I did in fact upload some packages > > with comment on stuff that ought to be fixed in the next revision. > > That sounds to me like a good solution. But only one where the contributor is known and is in my opinion reliable about coming back to do it. There's nothing in current policy that prohibits it and so MOTUs can, to the extent they feel comfortable, do it now. They can also fix the trivialities and upload if they care to. There is a tension in the new package process between teaching about packaging and getting new packages in. If all we care about was getting new packages in, we'd take the 5 minutes it takes to fix up the details and upload, but we don't just care about that, so we pitch it back to the contributor to fix so they learn better. This is sometimes frustrating for the student, but that's part of the learning process. > > In general, the only thing missing in you scenario was the MOTU > > advocating after the fixed upload. Of course your scenario also didn't > > include the contributor ping the MOTU on irc/email saying 'I've fixed > > your issues, please look again and see if it's ready.' > > I believe there are a lot of cases where REVU uploads are "triaged" (as > part of the long long list) and simply comment on the few obvious things > that could be improved. If the MOTU felt empowered to make the decision > right now and not leave the upload waiting for another ACK we would come > down to high-quality reviews quicker. True. When I do that, I also make it clear that I haven't done a full review. The issue isn't that people don't feel like doing a careful review, it's that they often don't have sufficient experience. Before going further with this idea, you might check with the archive admins and see how they feel about having to look at packages with even less reviewing. > > We get a lot of drive by packagers who > > really won't come back and fix it. > > Right, that happens and is a problem. I'm just not sure how the NEW > packages process can make them more interested in packaging and > maintaining. > > >> It all boils down to the question: "Why don't we trust one MOTU to get > >> it right?" > > > > Because historically they don't (myself included). > > What can we do to > - strengthen the culture of "clean up after breaking stuff" > - make it easier to spot real problems? (I don't see much public > discussion about things we've learned or much exchange of information.) For the first point, I'd suggest pointing people at the mess and tell them it's their responsibility to clean it up is generally enough. After a few times they generally get the idea. For the second, I think it's pretty common when I'm active on IRC, but those times don't seem to overlap much with yours. > > It occurs to me that if you really believe that the new package process > > should be the same as the sponsorship process, then you ought to discuss > > eliminating manual New review with the archive admins. > > I mentioned a "higher similarity" between the processes, but we won't > get around an archive admin review. Agreed. My real point is that they are in fact different for good reasons and those reasons haven't changed. > > It's very > > frustrating after having finally gotten your package uploaded to have to > > wait for two seperate and sequential New reviews. > > Do you mean source new and binary new or do I miss something here? Yes. That was it. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wed, Apr 16, 2008 at 9:40 AM, Daniel Holbach <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Cesare Tirabassi schrieb: > > Its not a question of trust, its a question that 4 eyes see better than > 2. I > > know I don't rely on my packaging skills alone, no matter how much I > work I > > will always miss something. > > Right. That happens to upstreams, happens to uploads of existing > packages and happens in uploads of new packages. Whenever somebody is > made member of ubuntu-dev they have the chance to break packages (and > embarrass themselves) with every single upload. > > I guess my question is two-fold: 1) how can we improve our existing ways > to collaborate on packaging to be less error-prone, 2) why do we deem > the reviewing of new packages different than uploading for example new > packages versions, etc.? > > > >> Is the quality of packaging our main concern? > > > > Definitively. > > Then what can we do to improve it? Is "I will have to ask my colleague" > the only way to do that? > > > > Very good example, and a showcase of why devs are not very keen in > reviewing. > > First, the contributor missed even the more fundamentals of a package > (other > > examples are native packages which are not, wrong standards, wrong > > distribution, etc.), so the reviewer instead of spending a whole morning > > reviewing the package just points out the more obvious (I would and > never > > have done this by the way, this is a side product of having one reviewer > > trying to "triage" a long queue). > > I picked the example to illustrate that sometimes trivialities which > don't really have a large impact block the upload. > > > > Even then the contributor waits two weeks > > to make a fix which just takes 5 minutes at the most. Is he really > interested > > in packaging? If I were the reviewer I don't think I will want to spend > my > > time in reviewing things that will eventually just get thrown out of the > > window. > > If I submitted a package, had to wait weeks to get it reviewed, then got > a reply "please fix this triviality" I wasn't sure if I made it my first > priority to come up with a fix. > > > > By the way, how will lowering the required acks to one solve the above > > example? > > If the reviewer feels empowered to make the decision right now and the > contributor is responsible for incoming bugs, chances are higher to > directly come to the beef of the packaging problems. > > > > Should I ack a package that I know doesn't meet the required standards? > I, for > > one, will not want to see Universe become another automatix or > deb-o-matic. > > The right approach here (and this is quite often used) is to say: this > is > > wrong but I'm not blocking for this so that the contributor knows about > it > > (and a good contributor will upload a fix shortly after). > > Right, not-blocking-but-mentioning makes perfect sense. > > > > Having gone very recently through this, yes, it adds frustration and is > as > > much a fault of the contributor as of the reviewer. By lowering the bar > we > > are not doing anyone a favour, just lowering the quality of the archive. > > I still believe that saying "one MOTU's decision is not enough" does not > fix the problem and that there are better ways to get high quality > packages into the archive and have responsive people fixing them as > problems come up. One of the reasons Open Source software *works* is because it employs the scientific method. That process relies heavily on peer review. I don't think we should remove that, discourage that, or ever consider it unimportant. If everyone had unlimited time and resources, I would get every single one of my packages reviewed. No, not because I don't think I'm not competent enough to make the upload myself alone but because I consider peer review the corner stone of our development model. Maybe the issue here isn't a philosophical one but more of a technical one? Maybe we should focus, as you suggested, on improving and innovating review infrastructure? > > > Have a nice day, > Daniel > > - -- > My 5 today: #210449 (network-manager-applet), #215043, #193764 > (evolution-scalix), #215472 (gnome-themes-extras), #205756 (gnome- > subtitles) > Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIBfPSRjrlnQWd1esRAsC7AJ993DNk9MgkZHsRj6NUN7qaFROXhgCfXQic > mLIOv2PDRll0NGBfnup+caI= > =/vos > -END PGP SIGNATURE- > > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Fax: 506-453-9112 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- Ubuntu-motu mailing list Ubuntu-motu@lists.u
Re: NEW Packages process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Kitterman schrieb: > I did in fact upload some packages > with comment on stuff that ought to be fixed in the next revision. That sounds to me like a good solution. > In general, the only thing missing in you scenario was the MOTU advocating > after the fixed upload. Of course your scenario also didn't include the > contributor ping the MOTU on irc/email saying 'I've fixed your issues, > please look again and see if it's ready.' I believe there are a lot of cases where REVU uploads are "triaged" (as part of the long long list) and simply comment on the few obvious things that could be improved. If the MOTU felt empowered to make the decision right now and not leave the upload waiting for another ACK we would come down to high-quality reviews quicker. > We get a lot of drive by packagers who > really won't come back and fix it. Right, that happens and is a problem. I'm just not sure how the NEW packages process can make them more interested in packaging and maintaining. >> It all boils down to the question: "Why don't we trust one MOTU to get >> it right?" >> > Because historically they don't (myself included). What can we do to - strengthen the culture of "clean up after breaking stuff" - make it easier to spot real problems? (I don't see much public discussion about things we've learned or much exchange of information.) > It occurs to me that if you really believe that the new package process > should be the same as the sponsorship process, then you ought to discuss > eliminating manual New review with the archive admins. I mentioned a "higher similarity" between the processes, but we won't get around an archive admin review. > It's very > frustrating after having finally gotten your package uploaded to have to > wait for two seperate and sequential New reviews. Do you mean source new and binary new or do I miss something here? Have a nice day, Daniel - -- My 5 today: #210449 (network-manager-applet), #215043, #193764 (evolution-scalix), #215472 (gnome-themes-extras), #205756 (gnome- subtitles) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBfggRjrlnQWd1esRAkm0AKCC9OfhcB17H8zG6hNFBtIObBQ3EQCfe8zJ krUc6KkfVRJj4CUDCLrKpKs= =mrZ5 -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wednesday 16 April 2008 08:15, Daniel Holbach wrote: ... > I personally ask and have seen others actively asking for changes to > patches if they were not ready to go yet. (Be it packaging problems, > policy problems or not adhering to processes.) > So the frustration gets pushed from the New package process into bug fixing if we end up with more of this. I think that's the LAST thing we want. Currently I think we are expending not nearly enough effort on maintaining what we have and really need to make that easier/smoother. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wednesday 16 April 2008 08:06, Daniel Holbach wrote: > Stefan Potyra schrieb: ... > > Having recipes, how to solve a problem is imho orthogonal to the question > > of reviewing. It's good to be able to point people to these, if they have > > questions on how to do it, but in my experience, that's not the problem > > when reviewing a package. > > Why don't "reviewing tips" help? Because the problem isn't reviewers not knowing how to solve the problem, the problem is that reviewers don't always look for the right things/know enough. Even the Debian NM process isn't enough to ensure people know enough to get all aspects of a package correct. Multiple reviews are needed. I don't think they are a cause of slack reviews. I don't think people advocate packages thinking someone else will catch any problems. I'll say again that I think we ought to require MOTUs to get another MOTU to review their new package prior to upload. I've certainly always done it. It has long seemed and odd hole in our policy to not require it. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Hi, On Wed, 16 Apr 2008 13:28:20 +0200 Daniel Holbach <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Cesare Tirabassi schrieb: > > If the purpose of this proposal is to reduce the idle time for new > > packages in the REVU queue than I think there are better ways, the > > best imho would be to make it more attractive for devs to actually > > review new packages. > > In an IRC conversation some days ago it was Colin Watson who said > "every item of bureaucracy should be justified" - this got me > thinking about this process as we hear a lot of frustration about it. from whom? > > How do we justify "this needs two reviewers - we don't trust one of > them to do it right"? Is the quality of packaging our main concern? > Which parts are we most concerned about? Actually, the problem between reviewing and NEW packages are: 1. Reviewing takes time, time which is not invested in merging, bugfixing etc. the usual work to be done during the first weeks of development. 2. Even with two or more people acking a package on REVU, after it's uploaded, most people who were providing those packages to REVU are disappearing just because: task accomplished, package is in the archive. There is no bug contact for this package, even if there is a name to it on the LP page. > > Please decide on your own how common a situation like this is on REVU: > - comment by a MOTU: "Could you add a watch file? Please move > Homepage URL to its own Homepage field.", no ACK > - two weeks of inactivity > - upload archived > - some days later: new upload fixing the issues > - ... > - maybe an ACK, maybe not > Two differences: 1. ubuntu-dev people uploading new packages to the archive, are taking care about them, even after the upload. It's incoorporated into the normal work 2. non-ubuntu-dev people and people which are not interested in becoming a MOTU but wants to push their packages into our archives, are not taking care about the package after upload, because of the MOTU. So, when we are reviewing the package, and asking for fixing the package because of public viewable bugs inside the packaging, and the revu-uploader is not bugfixing the package in time, I won't think about it anymore...and hopefully the package just disappears. > I'm convinced that fixes (fixing the Homepage field, bumping up the > Standards-Version, etc) above are written quickly once the package is > in the archive and should not block an upload. We are a distributed > team which maintains packages in the team and round-trips because of > such things merely add frustration. Not from the initial revu uploader...this needs to be done by MOTU people, which decreases the time for other, sometimes more important, work. > > It all boils down to the question: "Why don't we trust one MOTU to get > it right?" Because MOTUs are human beings, and I trust 2 pairs of eyes more then only my pair of eyes. Even old fart MOTUs are asking sometimes for a review of another colleague, even when they are good packaging people and trusted deeply :) Regards, \sh -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cesare Tirabassi schrieb: > Its not a question of trust, its a question that 4 eyes see better than 2. I > know I don't rely on my packaging skills alone, no matter how much I work I > will always miss something. Right. That happens to upstreams, happens to uploads of existing packages and happens in uploads of new packages. Whenever somebody is made member of ubuntu-dev they have the chance to break packages (and embarrass themselves) with every single upload. I guess my question is two-fold: 1) how can we improve our existing ways to collaborate on packaging to be less error-prone, 2) why do we deem the reviewing of new packages different than uploading for example new packages versions, etc.? >> Is the quality of packaging our main concern? > > Definitively. Then what can we do to improve it? Is "I will have to ask my colleague" the only way to do that? > Very good example, and a showcase of why devs are not very keen in reviewing. > First, the contributor missed even the more fundamentals of a package (other > examples are native packages which are not, wrong standards, wrong > distribution, etc.), so the reviewer instead of spending a whole morning > reviewing the package just points out the more obvious (I would and never > have done this by the way, this is a side product of having one reviewer > trying to "triage" a long queue). I picked the example to illustrate that sometimes trivialities which don't really have a large impact block the upload. > Even then the contributor waits two weeks > to make a fix which just takes 5 minutes at the most. Is he really interested > in packaging? If I were the reviewer I don't think I will want to spend my > time in reviewing things that will eventually just get thrown out of the > window. If I submitted a package, had to wait weeks to get it reviewed, then got a reply "please fix this triviality" I wasn't sure if I made it my first priority to come up with a fix. > By the way, how will lowering the required acks to one solve the above > example? If the reviewer feels empowered to make the decision right now and the contributor is responsible for incoming bugs, chances are higher to directly come to the beef of the packaging problems. > Should I ack a package that I know doesn't meet the required standards? I, > for > one, will not want to see Universe become another automatix or deb-o-matic. > The right approach here (and this is quite often used) is to say: this is > wrong but I'm not blocking for this so that the contributor knows about it > (and a good contributor will upload a fix shortly after). Right, not-blocking-but-mentioning makes perfect sense. > Having gone very recently through this, yes, it adds frustration and is as > much a fault of the contributor as of the reviewer. By lowering the bar we > are not doing anyone a favour, just lowering the quality of the archive. I still believe that saying "one MOTU's decision is not enough" does not fix the problem and that there are better ways to get high quality packages into the archive and have responsive people fixing them as problems come up. Have a nice day, Daniel - -- My 5 today: #210449 (network-manager-applet), #215043, #193764 (evolution-scalix), #215472 (gnome-themes-extras), #205756 (gnome- subtitles) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBfPSRjrlnQWd1esRAsC7AJ993DNk9MgkZHsRj6NUN7qaFROXhgCfXQic mLIOv2PDRll0NGBfnup+caI= =/vos -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Potyra schrieb: > No, I very much doubt that actually. Once a package leaves revu, usually > packaging bugs are not fixed afterwards (contrary to application bugs). From > the very early days I can recall one example, where I used to heavily insist > on man pages for each binary, and once made an exception right before > FeatureFreeze. I've even filed bugs after uploading, which are unfortunately > still open. I have seen lots of sponsoring bugs where the examples I mentioned (watch file, Standards-Version, Homepage field, etc.) were fixed alongside package updates and so on. > Oh, and imho reviewing doesn't only serve the purpose of getting new packages > in, but much more about teaching people about packaging. I doubt that the > sponsoring workflow for existing packages will have the same effect. (In the > few times I sponsor existing packages, I don't do packaging reviews, but only > review a given change to a package... I could imagine other people to do the > same). I personally ask and have seen others actively asking for changes to patches if they were not ready to go yet. (Be it packaging problems, policy problems or not adhering to processes.) Have a nice day, Daniel - -- My 5 today: #210449 (network-manager-applet), #215043, #193764 (evolution-scalix), #215472 (gnome-themes-extras), #205756 (gnome- subtitles) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBe3LRjrlnQWd1esRAkyLAJ4vWZxjhxfE0k2kdtWQeLXuCNSrcwCfVxb9 ELG3a2+bl9G3C3NJwXc3jTI= =IvEm -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wed, 16 Apr 2008 13:28:20 +0200 Daniel Holbach <[EMAIL PROTECTED]> wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >Cesare Tirabassi schrieb: >> If the purpose of this proposal is to reduce the idle time for new packages in >> the REVU queue than I think there are better ways, the best imho would be to >> make it more attractive for devs to actually review new packages. +1 >In an IRC conversation some days ago it was Colin Watson who said "every >item of bureaucracy should be justified" - this got me thinking about >this process as we hear a lot of frustration about it. I agree with this idea. In this case it's fully justified. >How do we justify "this needs two reviewers - we don't trust one of them >to do it right"? Is the quality of packaging our main concern? Which >parts are we most concerned about? We have plenty of experience with them not doing it right. I didn't have a lot of new package review time in Hardy and tended to concentrate on packages needing second advocates. I found a lot with what I would consider serious problems. >Please decide on your own how common a situation like this is on REVU: > - comment by a MOTU: "Could you add a watch file? Please move Homepage >URL to its own Homepage field.", no ACK > - two weeks of inactivity > - upload archived > - some days later: new upload fixing the issues > - ... > - maybe an ACK, maybe not First uploads get archived after months, not two weeks. Second, this is the time to fix these issues. If the contributor won't fix them before upload when he wants the package uploaded, they're pretty unlikely to come back and fix it later. For a known contributor who will come back, I tend to be more flexible. I did in fact upload some packages with comment on stuff that ought to be fixed in the next revision. In general, the only thing missing in you scenario was the MOTU advocating after the fixed upload. Of course your scenario also didn't include the contributor ping the MOTU on irc/email saying 'I've fixed your issues, please look again and see if it's ready.' >I'm convinced that fixes (fixing the Homepage field, bumping up the >Standards-Version, etc) above are written quickly once the package is in >the archive and should not block an upload. We are a distributed team >which maintains packages in the team and round-trips because of such >things merely add frustration. They can be, but often are not. We get a lot of drive by packagers who really won't come back and fix it. >It all boils down to the question: "Why don't we trust one MOTU to get >it right?" > Because historically they don't (myself included). It occurs to me that if you really believe that the new package process should be the same as the sponsorship process, then you ought to discuss eliminating manual New review with the archive admins. It's very frustrating after having finally gotten your package uploaded to have to wait for two seperate and sequential New reviews. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Potyra schrieb: > Maybe I don't understand what you are meaning: I thought reviewing was that > feedback? To me it sounds like a major problem is uncertainty of ubuntu-dev members who are about to ACK a package. This is understandable because of a lot of reasons (short time somebody is a developer, lack of experience in a certain area of packages, etc.) and a problem that we should strive to fix. If we can make it easier for reviewers to either look up how to (better) solve certain problems or ask for feedback, that'd solve a lot of problems at the same time. For example I haven't seen emails requesting feedback for a solution on [EMAIL PROTECTED] yet. > Having recipes, how to solve a problem is imho orthogonal to the question of > reviewing. It's good to be able to point people to these, if they have > questions on how to do it, but in my experience, that's not the problem when > reviewing a package. Why don't "reviewing tips" help? > Also, from my experience, usually many different > solution to a problem X exist, so I guess saying that there is a "best" way > might even result in reviewers stating s.th. like: "do it that way", even if > it's equally right to be done differently. (cdbs vs. plain debhelper for > example). Ok, please replace "best way to fix A" with "one obvious way to fix A". > (Side note: since when became the guideline criteria in CodeReviews stable? > There used to be a note stating that these are not stable and links to the ml > discussion in the wiki page which are gone now). Can you elaborate? > Do you mean feedback loop from ubuntu-archive to reviewers? Yes, that would > be > very good! The archive admins do give feedback on broken packages. I feel it should be the responsibility of the uploader or whoever did the packaging to document how to get better debian/copyright (or packaging in general) quality. Some information about getting debian/copyright right already exists on https://wiki.ubuntu.com/PackagingGuide/Howtos/DebianCopyright Have a nice day, Daniel - -- My 5 today: #210449 (network-manager-applet), #215043, #193764 (evolution-scalix), #215472 (gnome-themes-extras), #205756 (gnome- subtitles) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBevjRjrlnQWd1esRAllqAJsGv4Ze3LCHYcUziJpPGgMcyrYyWQCfYUw1 aO8uWgEGY/+ywnUBONR7BTM= =AtJE -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wednesday 16 April 2008 13:28:20 Daniel Holbach wrote: > How do we justify "this needs two reviewers - we don't trust one of them > to do it right"? > It all boils down to the question: "Why don't we trust one MOTU to get > it right?" Its not a question of trust, its a question that 4 eyes see better than 2. I know I don't rely on my packaging skills alone, no matter how much I work I will always miss something. > Is the quality of packaging our main concern? Definitively. > Please decide on your own how common a situation like this is on REVU: > - comment by a MOTU: "Could you add a watch file? Please move Homepage > URL to its own Homepage field.", no ACK > - two weeks of inactivity > - upload archived > - some days later: new upload fixing the issues > - ... > - maybe an ACK, maybe not Very good example, and a showcase of why devs are not very keen in reviewing. First, the contributor missed even the more fundamentals of a package (other examples are native packages which are not, wrong standards, wrong distribution, etc.), so the reviewer instead of spending a whole morning reviewing the package just points out the more obvious (I would and never have done this by the way, this is a side product of having one reviewer trying to "triage" a long queue). Even then the contributor waits two weeks to make a fix which just takes 5 minutes at the most. Is he really interested in packaging? If I were the reviewer I don't think I will want to spend my time in reviewing things that will eventually just get thrown out of the window. By the way, how will lowering the required acks to one solve the above example? > I'm convinced that fixes (fixing the Homepage field, bumping up the > Standards-Version, etc) above are written quickly once the package is in > the archive and should not block an upload. Should I ack a package that I know doesn't meet the required standards? I, for one, will not want to see Universe become another automatix or deb-o-matic. The right approach here (and this is quite often used) is to say: this is wrong but I'm not blocking for this so that the contributor knows about it (and a good contributor will upload a fix shortly after). > We are a distributed team which maintains packages in the team and > round-trips because of such things merely add frustration. Having gone very recently through this, yes, it adds frustration and is as much a fault of the contributor as of the reviewer. By lowering the bar we are not doing anyone a favour, just lowering the quality of the archive. Cesare -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Hi, On Wednesday 16 April 2008 12:48:35 Daniel Holbach wrote: [..] > > Bugs that might have been overlooked in the initial review are very > likely to be fixed quickly in the normal sponsoring process. Having > people as a bug contact for the package will help with that too. No, I very much doubt that actually. Once a package leaves revu, usually packaging bugs are not fixed afterwards (contrary to application bugs). From the very early days I can recall one example, where I used to heavily insist on man pages for each binary, and once made an exception right before FeatureFreeze. I've even filed bugs after uploading, which are unfortunately still open. Oh, and imho reviewing doesn't only serve the purpose of getting new packages in, but much more about teaching people about packaging. I doubt that the sponsoring workflow for existing packages will have the same effect. (In the few times I sponsor existing packages, I don't do packaging reviews, but only review a given change to a package... I could imagine other people to do the same). Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wed, 16 Apr 2008 10:45:22 +0200 Daniel Holbach <[EMAIL PROTECTED]> wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >Hello everybody, > >after a recent discussion about a perceived disconnect between "main >processes" and "universe processes", I thought a bit about the process >for NEW Packages. > >Historically it was introduced to make sure that new packages are of >tip-top quality when they enter the archive. We started with 3 necessary >ACKs and changed it to 2 ACKs for non-MOTUs and encouraged MOTUs to get >an ACK from other MOTUs. I feel we've been very successful with the work >we've put into Universe and the quality of new packages. > >I propose the following changes: > 1) cut down the requirement to one ACK of a ubuntu-dev member > 2) requirement for the person who packaged the new software to become >bug contact > >These changes would have a number of benefits: > - it would cut down the review overhead and the time of waiting > - instead of a high entry barrier, have a higher emphasis on fixing >problems of packages in Universe > - higher similarity between NEW Packages process and Sponsoring process > - accredit technical skills of approved ubuntu-dev members and don't >require re-review > >I'd like to hear feedback from regular reviewers, REVU admins, our REVU >coordinator and people who contribute new packages. There are a lot of packages that get a single advocate that still have very serious problems (particularly in copyright/licensing). I'm against dropping to a single advocate. If I were to make a change in this area I'd change it to require MOTUs get an upcheck from another MOTU instead of just suggesting it. This change would, I believe, have a significant impact on archive admin workload. They'd get a lot more packages and have to deal with more rejections and multiple reviews. In effect this would shift work from MOTU to the archive. I don't think it's a good idea. We don't have as extensive a process as Debian NM and some MOTUs do not have the breadth of experience to be the sole package reviewers. I also disagree with the idea of upload and fix it later. When the package is being developed is the best time to get it right. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cesare Tirabassi schrieb: > If the purpose of this proposal is to reduce the idle time for new packages > in > the REVU queue than I think there are better ways, the best imho would be to > make it more attractive for devs to actually review new packages. In an IRC conversation some days ago it was Colin Watson who said "every item of bureaucracy should be justified" - this got me thinking about this process as we hear a lot of frustration about it. How do we justify "this needs two reviewers - we don't trust one of them to do it right"? Is the quality of packaging our main concern? Which parts are we most concerned about? Please decide on your own how common a situation like this is on REVU: - comment by a MOTU: "Could you add a watch file? Please move Homepage URL to its own Homepage field.", no ACK - two weeks of inactivity - upload archived - some days later: new upload fixing the issues - ... - maybe an ACK, maybe not I'm convinced that fixes (fixing the Homepage field, bumping up the Standards-Version, etc) above are written quickly once the package is in the archive and should not block an upload. We are a distributed team which maintains packages in the team and round-trips because of such things merely add frustration. It all boils down to the question: "Why don't we trust one MOTU to get it right?" Have a nice day, Daniel - -- My 5 today: #210449 (network-manager-applet), #218074, #215043, #205756 (gnome-subtitles), #149677 (svn-load, subversion-helper- scripts) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBeLTRjrlnQWd1esRAhKdAJ9v4JmQZ2r0+aIddIP1EsorRY7VNACdFK2R lonzio/Eb3l24/u5wgGzivY= =OALT -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Hi, On Wednesday 16 April 2008 12:31:59 James Westby wrote: > On Wed, 2008-04-16 at 11:38 +0200, Stefan Potyra wrote: > > One argument against it raised in the past is, that this might lead to > > fewer people reviewing a package (or giving an ACK for a package), as > > they might be unsure about it. Actually, I believe that reviewing a > > package is actually a more difficult task then to create a new package > > from scratch, and so I think that this argument might still be true. > > > > As I've often cherrypicked reviews in the past (that is reviewed > > packages, which had one ACK already), and very often found issues with > > these, I fear that the package quality might get worse, and the rejection > > count from ubuntu-archive might increase. Now I wouldn't think, that I'm > > a so good reviewer, but rather that this is basically just, because > > different people spot different issues in packages. > > Hi, > > Do you think that this could perhaps be because some people don't > review the package as thoroughly as they know that someone else will > look at it first? From my experience: No, I don't think that people were less thorough with a review just because someone else would look at a package, but rather ... > > Increasing the quality of reviews is great, but just having a second > reviewer doesn't necessarily guarantee that. As well as each reviewer > knowing that someone else will look, the responsibility is diluted. > If I were to miss something in a review when I was the only reviewer > then it would be my omission, but with two reviewers both missed it, so > it's not really one persons fault. ... yes, exactly. Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Hi, On Wednesday 16 April 2008 12:07:46 Daniel Holbach wrote: > Stefan Potyra schrieb: > > One argument against it raised in the past is, that this might lead to > > fewer people reviewing a package (or giving an ACK for a package), as > > they might be unsure about it. > > Maybe the right fix for this the situation is to establish an easy way to > - solicit feedback about a packaging situation one is unsure about Maybe I don't understand what you are meaning: I thought reviewing was that feedback? > - document the "best way to solve problem X" either in > https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews or > https://wiki.ubuntu.com/PackagingGuide Having recipes, how to solve a problem is imho orthogonal to the question of reviewing. It's good to be able to point people to these, if they have questions on how to do it, but in my experience, that's not the problem when reviewing a package. Also, from my experience, usually many different solution to a problem X exist, so I guess saying that there is a "best" way might even result in reviewers stating s.th. like: "do it that way", even if it's equally right to be done differently. (cdbs vs. plain debhelper for example). (Side note: since when became the guideline criteria in CodeReviews stable? There used to be a note stating that these are not stable and links to the ml discussion in the wiki page which are gone now). > > I can see a number of additional benefits in this solution. > > > As I've often cherrypicked reviews in the past (that is reviewed > > packages, which had one ACK already), and very often found issues with > > these, I fear that the package quality might get worse, and the rejection > > count from ubuntu-archive might increase. > > Also in this case a feedback loop would help to educate the whole team. Do you mean feedback loop from ubuntu-archive to reviewers? Yes, that would be very good! Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Westby schrieb: > Increasing the quality of reviews is great, but just having a second > reviewer doesn't necessarily guarantee that. Agreed. Stefan said in his last mail that we should not upset the archive admins. I very much agree with his point and we should definitely avoid round-trips there. We should do all it takes to make this happen, improving documentation regarding debian/copyright, not shipping binary stuff, etc should be an obvious fix. Bugs that might have been overlooked in the initial review are very likely to be fixed quickly in the normal sponsoring process. Having people as a bug contact for the package will help with that too. Have a nice day, Daniel - -- My 5 today: #210449 (network-manager-applet), #215043, #193764 (evolution-scalix), #215472 (gnome-themes-extras), #205756 (gnome- subtitles) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBdmCRjrlnQWd1esRAm4HAJ0WpoD35RPLGw1Sthn0juKgJKbFSACfWhVj aLyJmDWiVQGpfe6k43bdFWg= =RrOH -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wednesday 16 April 2008 11:38:19 Stefan Potyra wrote: > > > > I propose the following changes: > > 1) cut down the requirement to one ACK of a ubuntu-dev member > > I don't think, that's a good idea. I'm with Stefan here, from personal experience as a packager and reviewer one ACK is almost never enough; I know that I want somebody else reviewing my packages (still, there are always things to correct once they hit the archive). If the purpose of this proposal is to reduce the idle time for new packages in the REVU queue than I think there are better ways, the best imho would be to make it more attractive for devs to actually review new packages. It takes an awful lot of time to properly review these packages (most often than not as much as making them from scratch), and this is not recognised in any way. > > 2) requirement for the person who packaged the new software to become > > bug contact > > Yes, that sounds very good! > I thought that was the norm ... Cesare -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wed, 2008-04-16 at 11:38 +0200, Stefan Potyra wrote: > One argument against it raised in the past is, that this might lead to fewer > people reviewing a package (or giving an ACK for a package), as they might be > unsure about it. Actually, I believe that reviewing a package is actually a > more difficult task then to create a new package from scratch, and so I think > that this argument might still be true. > > As I've often cherrypicked reviews in the past (that is reviewed packages, > which had one ACK already), and very often found issues with these, I fear > that the package quality might get worse, and the rejection count from > ubuntu-archive might increase. Now I wouldn't think, that I'm a so good > reviewer, but rather that this is basically just, because different people > spot different issues in packages. Hi, Do you think that this could perhaps be because some people don't review the package as thoroughly as they know that someone else will look at it first? Increasing the quality of reviews is great, but just having a second reviewer doesn't necessarily guarantee that. As well as each reviewer knowing that someone else will look, the responsibility is diluted. If I were to miss something in a review when I was the only reviewer then it would be my omission, but with two reviewers both missed it, so it's not really one persons fault. It's not clear to me where the best compromise is here. Thanks, James -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Potyra schrieb: > One argument against it raised in the past is, that this might lead to fewer > people reviewing a package (or giving an ACK for a package), as they might be > unsure about it. Maybe the right fix for this the situation is to establish an easy way to - solicit feedback about a packaging situation one is unsure about - document the "best way to solve problem X" either in https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews or https://wiki.ubuntu.com/PackagingGuide I can see a number of additional benefits in this solution. > As I've often cherrypicked reviews in the past (that is reviewed packages, > which had one ACK already), and very often found issues with these, I fear > that the package quality might get worse, and the rejection count from > ubuntu-archive might increase. Also in this case a feedback loop would help to educate the whole team. Have a nice day, Daniel - -- My 5 today: #210449 (network-manager-applet), #215043, #193764 (evolution-scalix), #215472 (gnome-themes-extras), #205756 (gnome- subtitles) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBc/yRjrlnQWd1esRAp6OAJ4uDi0g1YerErKWf6dCv0uCp9x3OQCdEzs5 b4uirRnEQjA62970RGSkse8= =bGZm -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Hi, On Wednesday 16 April 2008 10:45:22 Daniel Holbach wrote: > Hello everybody, > > after a recent discussion about a perceived disconnect between "main > processes" and "universe processes", I thought a bit about the process > for NEW Packages. > > Historically it was introduced to make sure that new packages are of > tip-top quality when they enter the archive. We started with 3 necessary > ACKs and changed it to 2 ACKs for non-MOTUs and encouraged MOTUs to get > an ACK from other MOTUs. I feel we've been very successful with the work > we've put into Universe and the quality of new packages. > > I propose the following changes: > 1) cut down the requirement to one ACK of a ubuntu-dev member I don't think, that's a good idea. One argument against it raised in the past is, that this might lead to fewer people reviewing a package (or giving an ACK for a package), as they might be unsure about it. Actually, I believe that reviewing a package is actually a more difficult task then to create a new package from scratch, and so I think that this argument might still be true. As I've often cherrypicked reviews in the past (that is reviewed packages, which had one ACK already), and very often found issues with these, I fear that the package quality might get worse, and the rejection count from ubuntu-archive might increase. Now I wouldn't think, that I'm a so good reviewer, but rather that this is basically just, because different people spot different issues in packages. Overall, I believe we should encourage non-motus to go for reviews, now that anyone can comment on REVU to weed out basic packaging problems. The only downside to this is imho, that sometimes pseudo-knowledge starts to spread about issues of a package (I've seen wrong comments in the past, which got picked up by other reviewers and got commented to other packages. I'd need to look a little bit, to find concrete examples of this happening though). > 2) requirement for the person who packaged the new software to become > bug contact Yes, that sounds very good! Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Daniel Holbach wrote: > - higher similarity between NEW Packages process and Sponsoring process I see no reason why they shouldn't be completely identical, really. Thanks, Scott Ritchie -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
NEW Packages process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello everybody, after a recent discussion about a perceived disconnect between "main processes" and "universe processes", I thought a bit about the process for NEW Packages. Historically it was introduced to make sure that new packages are of tip-top quality when they enter the archive. We started with 3 necessary ACKs and changed it to 2 ACKs for non-MOTUs and encouraged MOTUs to get an ACK from other MOTUs. I feel we've been very successful with the work we've put into Universe and the quality of new packages. I propose the following changes: 1) cut down the requirement to one ACK of a ubuntu-dev member 2) requirement for the person who packaged the new software to become bug contact These changes would have a number of benefits: - it would cut down the review overhead and the time of waiting - instead of a high entry barrier, have a higher emphasis on fixing problems of packages in Universe - higher similarity between NEW Packages process and Sponsoring process - accredit technical skills of approved ubuntu-dev members and don't require re-review I'd like to hear feedback from regular reviewers, REVU admins, our REVU coordinator and people who contribute new packages. Have a nice day, Daniel - -- My 5 today: #210449 (network-manager-applet), #215043, #193764 (evolution-scalix), #215472 (gnome-themes-extras), #205756 (gnome- subtitles) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBbyhRjrlnQWd1esRAphWAJ0Yo6qLOEIZi8kyZh/VJA/oXjkz1wCdFBBL 9l41voVpa3g/U3fAtp1Q4kg= =g9ya -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
