FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Development

 
 
LinkBack Thread Tools
 
Old 10-23-2008, 10:39 AM
Daniel Holbach
 
Default UbuntuDevelopment/CodeReviews

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello everybody,

I just updated SponsorshipProcess and UbuntuDevelopment/CodeReviews on
the wiki. After the recent discussion of the debdiff proposal, I added a
few sections (especially about being picky and sending patches upstream)
and removed old cruft on there. Also I moved all the content on
SponsorshipProcess related to Reviewing to UbuntuDevelopment/CodeReviews
(so it's only about process itself and a nice lightweight page).

If you have the chance, please check out
https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews?action=diff&rev2=26&rev1=24
and
https://wiki.ubuntu.com/SponsorshipProcess?action=diff&rev2=39&rev1=36
and see if I missed something obvious or if we should be clearer.

Have a nice day,
Daniel

- --
My 5 today: #286620 (vinagre), #287315 (example-content), #208561
(example-content), #287221 (gnome-applets), #286829 (ubuntu-docs)
Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkAVHMACgkQRjrlnQWd1eudhQCfZW5XN3cjts uhPrJrcqM1cxRg
qw4AnRQUgvM7W17SO1YAk9WhMF9Q4da5
=8GO2
-----END PGP SIGNATURE-----

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 10-23-2008, 11:12 AM
James Westby
 
Default UbuntuDevelopment/CodeReviews

On Thu, 2008-10-23 at 12:39 +0200, Daniel Holbach wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello everybody,
>
> I just updated SponsorshipProcess and UbuntuDevelopment/CodeReviews on
> the wiki. After the recent discussion of the debdiff proposal, I added a
> few sections (especially about being picky and sending patches upstream)
> and removed old cruft on there. Also I moved all the content on
> SponsorshipProcess related to Reviewing to UbuntuDevelopment/CodeReviews
> (so it's only about process itself and a nice lightweight page).
>
> If you have the chance, please check out
> https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews?action=diff&rev2=26&rev1=24
> and
> https://wiki.ubuntu.com/SponsorshipProcess?action=diff&rev2=39&rev1=36
> and see if I missed something obvious or if we should be clearer.

Thanks Daniel,

I'm glad something came out of the discussion.

I still think finding ways to have contributors forward the patch before
seeking sponsorship will improve the situation. Clearly my suggestion
wasn't going to get very far, but I'd love to discuss any ideas that
anyone else has.

Thanks,

James


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 10-23-2008, 02:22 PM
Bryce Harrington
 
Default UbuntuDevelopment/CodeReviews

On Thu, Oct 23, 2008 at 12:12:18PM +0100, James Westby wrote:
> I still think finding ways to have contributors forward the patch before
> seeking sponsorship will improve the situation. Clearly my suggestion
> wasn't going to get very far, but I'd love to discuss any ideas that
> anyone else has.

Well, one idea I've batted around is not so much to change the
sponsorship process, but to augment it with tools that come into play
when a patch is uploaded.

Basically, the idea would be to have a build farm routinely scan
launchpad for patches and attempt to apply / build / test them. It
would then mark patches PASS/FAIL appropriately for each build or test
run done.


So, like apport-retracer, but with a test/build farm as its backend.

In addition to giving mechanical feedback about patches (applies,
builds, passes smoke tests, etc.) as byproducts it could provide .debs
for testing. In fact, I would suspect this latter feature could
stimulate a lot of LP usage by itself.

Bryce



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 10-23-2008, 03:47 PM
Jordan Mantha
 
Default UbuntuDevelopment/CodeReviews

On Thu, Oct 23, 2008 at 07:22:41AM -0700, Bryce Harrington wrote:
> On Thu, Oct 23, 2008 at 12:12:18PM +0100, James Westby wrote:
> > I still think finding ways to have contributors forward the patch before
> > seeking sponsorship will improve the situation. Clearly my suggestion
> > wasn't going to get very far, but I'd love to discuss any ideas that
> > anyone else has.
>
> Well, one idea I've batted around is not so much to change the
> sponsorship process, but to augment it with tools that come into play
> when a patch is uploaded.
>
> Basically, the idea would be to have a build farm routinely scan
> launchpad for patches and attempt to apply / build / test them. It
> would then mark patches PASS/FAIL appropriately for each build or test
> run done.
>
>
> So, like apport-retracer, but with a test/build farm as its backend.
>
> In addition to giving mechanical feedback about patches (applies,
> builds, passes smoke tests, etc.) as byproducts it could provide .debs
> for testing. In fact, I would suspect this latter feature could
> stimulate a lot of LP usage by itself.
>

This is an interesting idea, but seems like it would take quite a lot of
resources and would be kind of fragile. The kind of issues that come to mind are:
* Somebody puts up a OO.o or kernel patch, we're utilizing a lot of CPU
resources for a relatively low rate of return. We'd perhaps have to work out
a good queue structure.
* Often people upload patches based on the current stable version of the
package, which may not apply cleanly.
* Often people upload patches that are not against the root of the source
tree, we might have to play around with patch -p to get it to apply cleanly.

The nice thing about your proposal is that would allow us to fairly easily
identify "good" patches. There are currently 1817 patches in Ubuntu bugs
according to Launchpad. I doubt there are all that many that are real patches
that apply and build cleanly, but it sure would be nice to know which ones do
:-)

I think as a first step we need an automated way to identify true patches
though. It would really be a big help no matter what we do. The current patch
flag system is really not working well (and hasn't for some time, if ever).

-Jordan

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 10-23-2008, 04:26 PM
Jordan Mantha
 
Default UbuntuDevelopment/CodeReviews

On Thu, Oct 23, 2008 at 07:22:41AM -0700, Bryce Harrington wrote:
> On Thu, Oct 23, 2008 at 12:12:18PM +0100, James Westby wrote:
> > I still think finding ways to have contributors forward the patch before
> > seeking sponsorship will improve the situation. Clearly my suggestion
> > wasn't going to get very far, but I'd love to discuss any ideas that
> > anyone else has.
>
> Well, one idea I've batted around is not so much to change the
> sponsorship process, but to augment it with tools that come into play
> when a patch is uploaded.
>
> Basically, the idea would be to have a build farm routinely scan
> launchpad for patches and attempt to apply / build / test them. It
> would then mark patches PASS/FAIL appropriately for each build or test
> run done.
>
>
> So, like apport-retracer, but with a test/build farm as its backend.
>
> In addition to giving mechanical feedback about patches (applies,
> builds, passes smoke tests, etc.) as byproducts it could provide .debs
> for testing. In fact, I would suspect this latter feature could
> stimulate a lot of LP usage by itself.

This is an interesting idea, but seems like it would take quite a lot of
resources and would be kind of fragile. The kind of issues that come to mind are:
* Somebody puts up a OO.o or kernel patch, we're utilizing a lot of CPU
resources for a relatively low rate of return. We'd perhaps have to work out
a good queue structure.
* Often people upload patches based on the current stable version of the
package, which may not apply cleanly.
* Often people upload patches that are not against the root of the source
tree, we might have to play around with patch -p to get it to apply cleanly.

The nice thing about your proposal is that would allow us to fairly easily
identify "good" patches. There are currently 1817 patches in Ubuntu bugs
according to Launchpad. I doubt there are all that many that are real patches
that apply and build cleanly, but it sure would be nice to know which ones do
:-)

I think as a first step we need an automated way to identify true patches
though. It would really be a big help no matter what we do. The current patch
flag system is really not working well (and hasn't for some time, if ever).

-Jordan

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 10-23-2008, 04:28 PM
Jordan Mantha
 
Default UbuntuDevelopment/CodeReviews

On Thu, Oct 23, 2008 at 07:22:41AM -0700, Bryce Harrington wrote:
> On Thu, Oct 23, 2008 at 12:12:18PM +0100, James Westby wrote:
> > I still think finding ways to have contributors forward the patch before
> > seeking sponsorship will improve the situation. Clearly my suggestion
> > wasn't going to get very far, but I'd love to discuss any ideas that
> > anyone else has.
>
> Well, one idea I've batted around is not so much to change the
> sponsorship process, but to augment it with tools that come into play
> when a patch is uploaded.
>
> Basically, the idea would be to have a build farm routinely scan
> launchpad for patches and attempt to apply / build / test them. It
> would then mark patches PASS/FAIL appropriately for each build or test
> run done.
>
>
> So, like apport-retracer, but with a test/build farm as its backend.
>
> In addition to giving mechanical feedback about patches (applies,
> builds, passes smoke tests, etc.) as byproducts it could provide .debs
> for testing. In fact, I would suspect this latter feature could
> stimulate a lot of LP usage by itself.

This is an interesting idea, but seems like it would take quite a lot of
resources and would be kind of fragile. The kind of issues that come to mind are:
* Somebody puts up a OO.o or kernel patch, we're utilizing a lot of CPU
resources for a relatively low rate of return. We'd perhaps have to work out
a good queue structure.
* Often people upload patches based on the current stable version of the
package, which may not apply cleanly.
* Often people upload patches that are not against the root of the source
tree, we might have to play around with patch -p to get it to apply cleanly.

The nice thing about your proposal is that would allow us to fairly easily
identify "good" patches. There are currently 1817 patches in Ubuntu bugs
according to Launchpad. I doubt there are all that many that are real patches
that apply and build cleanly, but it sure would be nice to know which ones do
:-)

I think as a first step we need an automated way to identify true patches
though. It would really be a big help no matter what we do. The current patch
flag system is really not working well (and hasn't for some time, if ever).

-Jordan

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 10-23-2008, 05:11 PM
Bryce Harrington
 
Default UbuntuDevelopment/CodeReviews

On Thu, Oct 23, 2008 at 08:47:58AM -0700, Jordan Mantha wrote:
> On Thu, Oct 23, 2008 at 07:22:41AM -0700, Bryce Harrington wrote:
> > On Thu, Oct 23, 2008 at 12:12:18PM +0100, James Westby wrote:
> > Basically, the idea would be to have a build farm routinely scan
> > launchpad for patches and attempt to apply / build / test them. It
> > would then mark patches PASS/FAIL appropriately for each build or test
> > run done.
>
> This is an interesting idea, but seems like it would take quite a lot of
> resources and would be kind of fragile. The kind of issues that come to mind are:
> * Somebody puts up a OO.o or kernel patch, we're utilizing a lot of CPU
> resources for a relatively low rate of return. We'd perhaps have to work out
> a good queue structure.
> * Often people upload patches based on the current stable version of the
> package, which may not apply cleanly.
> * Often people upload patches that are not against the root of the source
> tree, we might have to play around with patch -p to get it to apply cleanly.

When I was at OSDL we built a test/build system that did
multi-architecture builds for each commit to the kernel, across several
different branches, with several module build strategies. The rate of
patches it handled far exceeds what we're talking about here, and this
was with hardware from about 5 years ago. So not to minimize the
resource requirements of this idea too much, but I don't think it's the
hard part.

Regarding patches that don't apply cleanly or that are not applied to
the root, the system would obviously catch and mark those cases as FAIL;
indeed, being able to quickly flag patches with these kinds of issues is
the primary value of this tool - it gives rapid feedback to the patch
submitter and thus encourages them to redo the patch (while it's fresh
in their mind) to fix.

The hard part in such systems is generally the development work, and
solving all the corner cases. For example, across all of Ubuntu there's
probably at least half a dozen different patching systems, and the tool
would need to be smart enough to know how to apply patches in each
system.

> The nice thing about your proposal is that would allow us to fairly easily
> identify "good" patches. There are currently 1817 patches in Ubuntu bugs
> according to Launchpad. I doubt there are all that many that are real patches
> that apply and build cleanly, but it sure would be nice to know which ones do
> :-)
>
> I think as a first step we need an automated way to identify true patches
> though. It would really be a big help no matter what we do. The current patch
> flag system is really not working well (and hasn't for some time, if ever).

How would you define "true patch" in this case?

Bryce

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 10-23-2008, 08:11 PM
Jordan Mantha
 
Default UbuntuDevelopment/CodeReviews

On Thu, Oct 23, 2008 at 10:11:19AM -0700, Bryce Harrington wrote:
> On Thu, Oct 23, 2008 at 08:47:58AM -0700, Jordan Mantha wrote:
> > On Thu, Oct 23, 2008 at 07:22:41AM -0700, Bryce Harrington wrote:
> > > On Thu, Oct 23, 2008 at 12:12:18PM +0100, James Westby wrote:
> > > Basically, the idea would be to have a build farm routinely scan
> > > launchpad for patches and attempt to apply / build / test them. It
> > > would then mark patches PASS/FAIL appropriately for each build or test
> > > run done.
> >
> > This is an interesting idea, but seems like it would take quite a lot of
> > resources and would be kind of fragile. The kind of issues that come to mind are:
> > * Somebody puts up a OO.o or kernel patch, we're utilizing a lot of CPU
> > resources for a relatively low rate of return. We'd perhaps have to work out
> > a good queue structure.
> > * Often people upload patches based on the current stable version of the
> > package, which may not apply cleanly.
> > * Often people upload patches that are not against the root of the source
> > tree, we might have to play around with patch -p to get it to apply cleanly.
>
> When I was at OSDL we built a test/build system that did
> multi-architecture builds for each commit to the kernel, across several
> different branches, with several module build strategies. The rate of
> patches it handled far exceeds what we're talking about here, and this
> was with hardware from about 5 years ago. So not to minimize the
> resource requirements of this idea too much, but I don't think it's the
> hard part.

Right, but we regularly have a queue waiting during heavy development as is,
where will this build farm come from? Of course if Canonical feels like doing it
I wouldn't say no.

> Regarding patches that don't apply cleanly or that are not applied to
> the root, the system would obviously catch and mark those cases as FAIL;
> indeed, being able to quickly flag patches with these kinds of issues is
> the primary value of this tool - it gives rapid feedback to the patch
> submitter and thus encourages them to redo the patch (while it's fresh
> in their mind) to fix.

That is an interesting point. It'd be an interesting filter and feedback
mechanism for contributors.

> The hard part in such systems is generally the development work, and
> solving all the corner cases. For example, across all of Ubuntu there's
> probably at least half a dozen different patching systems, and the tool
> would need to be smart enough to know how to apply patches in each
> system.

Well, if we're talking about patches and not debdiffs I think we can have a
pretty standard "policy". I think it would be wise to stick to straight patches
and not try to wade into the patch system mess if we can help it.

> > The nice thing about your proposal is that would allow us to fairly easily
> > identify "good" patches. There are currently 1817 patches in Ubuntu bugs
> > according to Launchpad. I doubt there are all that many that are real patches
> > that apply and build cleanly, but it sure would be nice to know which ones do
> > :-)
> >
> > I think as a first step we need an automated way to identify true patches
> > though. It would really be a big help no matter what we do. The current patch
> > flag system is really not working well (and hasn't for some time, if ever).
>
> How would you define "true patch" in this case?

I'm am so far from being an expert here, but IMO a "true" patch must be:
* a diff, not just a copy of the file(s) with changes made
* be against the source package tree and not the files shipped in the .deb
* must be self-contained and not depend on other patches

This rules out thing like screenshots and "here's the version of that file I
have on my system".

Specifically though, you want to test for an actual diff format (which I think
should be fairly easy to do) and that it can actually apply to an existing
source package.

So I'd, perhaps naively, think it would run something like:
1. attachment gets add with patch flag
2. grab attachment and see if it's in diff format
3. iteratively try to apply the patch to a source package. It should try all
source packages that are listed as tasks in the bug report and (optionally)
decend versions from development release through all currently supported
versions
4. report PASS/FAIL

-Jordan

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 10-23-2008, 11:07 PM
Onno Benschop
 
Default UbuntuDevelopment/CodeReviews

On 23/10/08 22:22, Bryce Harrington wrote:
> Basically, the idea would be to have a build farm routinely scan
> launchpad for patches and attempt to apply / build / test them. It
> would then mark patches PASS/FAIL appropriately for each build or test
> run done.
>
>
> So, like apport-retracer, but with a test/build farm as its backend.
>
> In addition to giving mechanical feedback about patches (applies,
> builds, passes smoke tests, etc.) as byproducts it could provide .debs
> for testing. In fact, I would suspect this latter feature could
> stimulate a lot of LP usage by itself.
>

I wonder if this level of automation comes with some hidden land-mines.

How would you protect against rogue code in this scenario - both from a
licensing and a malicious perspective?

If you are going to mark a patch as PASS/FAIL, it's only a short step
(potentially a mouse-click) from there into acceptance.

If you go on to build a .deb, you're even closer.

I'm not saying the idea is bad, in fact I really like the idea, it would
help me as a contributor test my patches before I need to knock on
someone's door to get them to have a look at it.

There are resource implications as well. I think your idea might be used
differently than you expect. I find myself thinking about patches I've
made in the past and how I felt limited in my contributions by the fact
that I refuse to run an unstable OS (as-in, not yet released, as opposed
to crashing all the time on my income generating workstation. This
idea would allow me to make a patch, then upload it to LP and have it
come up with all the bits that it needs to build the package and then
tell me that I made an error.

--
Onno Benschop

Connected via Optus B3 at S3154'06" - E11550'39" (Yokine, WA)
--
()/)/)() ..ASCII for Onno..
|>>? ..EBCDIC for Onno..
--- -. -. --- ..Morse for Onno..

ITmaze - ABN: 56 178 057 063 - ph: 04 1219 8888 - onno@itmaze.com.au



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 10-24-2008, 07:30 AM
Daniel Holbach
 
Default UbuntuDevelopment/CodeReviews

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jordan Mantha schrieb:
> 3. iteratively try to apply the patch to a source package. It should try all
> source packages that are listed as tasks in the bug report and (optionally)
> decend versions from development release through all currently supported
> versions

Some 'exceptions' come to my mind:

- In cases of merges, patches that are meant to be applied against the
Debian source package are attached to the bug.
- In cases of upgrades .diff.gz and .dsc files are attached (meant to
be used with the new upstream tarball).
- Sometimes branches are attached to the bug.
- Sometimes updated packages are available in a PPA or REVU.

Everything-in-a-branch (one day) will hopefully solve this. :-)

Have a nice day,
Daniel

- --
My 5 today: #286620 (vinagre), #287315 (example-content), #208561
(example-content), #287221 (gnome-applets), #286829 (ubuntu-docs)
Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkBeYsACgkQRjrlnQWd1euVwQCfVyDZdfKOBp NVmox2soTCyuLj
aI4An0pvvVbZBtWdi52jeIntjcuC5Hsn
=Z83M
-----END PGP SIGNATURE-----

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 

Thread Tools




All times are GMT. The time now is 01:05 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org