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 > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 12-31-2007, 04:37 AM
Paul Mattal
 
Default dependency rebuilds

When package y depends on package x and package x is updated, there are
essentially two clean ways to divide up responsibility for rebuilding
dependent package(s) y:


1) the package y maintainer(s) notices package x in testing and rebuilds
package y


2) the package x maintainer(s) is responsible to find all packages y and
rebuilds all such packages y against the new package x


I've seen many variations on how this gets handled over the last three
or four years as a a developer, and we usually just try to do what makes
things best for most people, but it's good to have some idea what to
expect in general. We all want to do what's best for the most people,
but it's not always clear what that is.


A merit of #1 is that the actual maintainers of the dependent packages,
who can sanity check and test the new dependency, are involved in making
sure the packages get built and function correctly against the new
version of dependent software. A downside is that this is likely to take
some time-- the dependent package maintainers need to notice the
dependency update, have time, and do the update properly.


A merit of #2 is that the updates get done quickly. A disadvantage is
that they may not be done correctly, possibly even introducing uncaught
security holes or result in data loss. Another disadvantage is that for
really core low-level packages (like glibc or even something like
sqlite), the number of rebuilds is potentially huge and the likelihood
of getting things wrong is even larger, and it will be increasingly hard
to get people to agree to maintain those low-level packages because of
the amount of work involved.


How have people generally been approaching this issue and with what
rationale? As a starting point, in absence of other communication, I
generally expect developers to rebuild and test their own packages when
their dependencies are upgraded, but perhaps I'm in the minority.


I think we should be sensitive to the general number and kind of
dependencies we have on packages we maintain, and make sure to put those
things into testing to give other developers lots of time to rebuild and
test against them, but not assume we each have sufficient knowledge and
experience to rebuild any of the potentially vast spectrum of dependent
packages with any reasonable certainty they will work.


- P
 
Old 01-03-2008, 10:36 PM
"Aaron Griffin"
 
Default dependency rebuilds

On Dec 30, 2007 11:37 PM, Paul Mattal <paul@mattal.com> wrote:
> 1) the package y maintainer(s) notices package x in testing and rebuilds
> package y
>
> 2) the package x maintainer(s) is responsible to find all packages y and
> rebuilds all such packages y against the new package x

There's a middle-ground here which I like, myself.
1.5) the package x maintainer(s) is responsible to find all packages
y and posts a todo list on the dashboard

I like this method, but at the same time, it requires one to
constantly scan the todo lists to see if a package of yours is there.

Do we have any other options, or is it just there 2 (3) ?

I'd prefer to go with "easiest" in these cases, because some of these
rebuilds can be big.
 
Old 01-04-2008, 02:18 PM
Paul Mattal
 
Default dependency rebuilds

Aaron Griffin wrote:

On Dec 30, 2007 11:37 PM, Paul Mattal <paul@mattal.com> wrote:

1) the package y maintainer(s) notices package x in testing and rebuilds
package y

2) the package x maintainer(s) is responsible to find all packages y and
rebuilds all such packages y against the new package x


There's a middle-ground here which I like, myself.
1.5) the package x maintainer(s) is responsible to find all packages
y and posts a todo list on the dashboard

I like this method, but at the same time, it requires one to
constantly scan the todo lists to see if a package of yours is there.


A slight variation on this is to the todo list + what Damir did..
post to a todo list and *also* put a post on the arch-dev-public
list. This way people get push notification, and also a place to
track what they've done and what they haven't.


- P
 
Old 01-04-2008, 06:36 PM
"Aaron Griffin"
 
Default dependency rebuilds

On Jan 4, 2008 9:18 AM, Paul Mattal <paul@mattal.com> wrote:
> Aaron Griffin wrote:
> > On Dec 30, 2007 11:37 PM, Paul Mattal <paul@mattal.com> wrote:
> >> 1) the package y maintainer(s) notices package x in testing and rebuilds
> >> package y
> >>
> >> 2) the package x maintainer(s) is responsible to find all packages y and
> >> rebuilds all such packages y against the new package x
> >
> > There's a middle-ground here which I like, myself.
> > 1.5) the package x maintainer(s) is responsible to find all packages
> > y and posts a todo list on the dashboard
> >
> > I like this method, but at the same time, it requires one to
> > constantly scan the todo lists to see if a package of yours is there.
>
> A slight variation on this is to the todo list + what Damir did..
> post to a todo list and *also* put a post on the arch-dev-public
> list. This way people get push notification, and also a place to
> track what they've done and what they haven't.

I like this one.

So ok, let me propose this:
With rebuilds, it's the library maintainer's job to find all dep packages.
There are then two choices:
* build everything yourself, if you feel like it (yay!)
* make a todolist and post on the arch-dev-public ML so we know
that there is a new rebuild todolist.

Sound like a good process?
 
Old 01-04-2008, 06:40 PM
"Travis Willard"
 
Default dependency rebuilds

On Jan 4, 2008 2:36 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:

On Jan 4, 2008 9:18 AM, Paul Mattal <paul@mattal.com> wrote:
> Aaron Griffin wrote:
> > On Dec 30, 2007 11:37 PM, Paul Mattal <
paul@mattal.com> wrote:
> >> 1) the package y maintainer(s) notices package x in testing and rebuilds
> >> package y
> >>
> >> 2) the package x maintainer(s) is responsible to find all packages y and

> >> rebuilds all such packages y against the new package x
> >
> > There's a middle-ground here which I like, myself.
> > 1.5) *the package x maintainer(s) is responsible to find all packages

> > y and posts a todo list on the dashboard
> >
> > I like this method, but at the same time, it requires one to
> > constantly scan the todo lists to see if a package of yours is there.

>
> A slight variation on this is to the todo list + what Damir did..
> post to a todo list and *also* put a post on the arch-dev-public
> list. This way people get push notification, and also a place to

> track what they've done and what they haven't.

I like this one.

So ok, let me propose this:
With rebuilds, it's the library maintainer's job to find all dep packages.

There are then two choices:
* * build everything yourself, if you feel like it (yay!)
* * make a todolist and post on the arch-dev-public ML so we know
that there is a new rebuild todolist.

Sound like a good process?

+1 from me.
 
Old 01-04-2008, 06:53 PM
Jason Chu
 
Default dependency rebuilds

On Fri, Jan 04, 2008 at 01:36:03PM -0600, Aaron Griffin wrote:
> On Jan 4, 2008 9:18 AM, Paul Mattal <paul@mattal.com> wrote:
> > Aaron Griffin wrote:
> > > On Dec 30, 2007 11:37 PM, Paul Mattal <paul@mattal.com> wrote:
> > >> 1) the package y maintainer(s) notices package x in testing and rebuilds
> > >> package y
> > >>
> > >> 2) the package x maintainer(s) is responsible to find all packages y and
> > >> rebuilds all such packages y against the new package x
> > >
> > > There's a middle-ground here which I like, myself.
> > > 1.5) the package x maintainer(s) is responsible to find all packages
> > > y and posts a todo list on the dashboard
> > >
> > > I like this method, but at the same time, it requires one to
> > > constantly scan the todo lists to see if a package of yours is there.
> >
> > A slight variation on this is to the todo list + what Damir did..
> > post to a todo list and *also* put a post on the arch-dev-public
> > list. This way people get push notification, and also a place to
> > track what they've done and what they haven't.
>
> I like this one.
>
> So ok, let me propose this:
> With rebuilds, it's the library maintainer's job to find all dep packages.
> There are then two choices:
> * build everything yourself, if you feel like it (yay!)
> * make a todolist and post on the arch-dev-public ML so we know
> that there is a new rebuild todolist.
>
> Sound like a good process?

+1

Jason
 
Old 01-04-2008, 06:54 PM
"Dan McGee"
 
Default dependency rebuilds

On Jan 4, 2008 1:36 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
>
> On Jan 4, 2008 9:18 AM, Paul Mattal <paul@mattal.com> wrote:
> > Aaron Griffin wrote:
> > > On Dec 30, 2007 11:37 PM, Paul Mattal <paul@mattal.com> wrote:
> > >> 1) the package y maintainer(s) notices package x in testing and rebuilds
> > >> package y
> > >>
> > >> 2) the package x maintainer(s) is responsible to find all packages y and
> > >> rebuilds all such packages y against the new package x
> > >
> > > There's a middle-ground here which I like, myself.
> > > 1.5) the package x maintainer(s) is responsible to find all packages
> > > y and posts a todo list on the dashboard
> > >
> > > I like this method, but at the same time, it requires one to
> > > constantly scan the todo lists to see if a package of yours is there.
> >
> > A slight variation on this is to the todo list + what Damir did..
> > post to a todo list and *also* put a post on the arch-dev-public
> > list. This way people get push notification, and also a place to
> > track what they've done and what they haven't.
>
> I like this one.
>
> So ok, let me propose this:
> With rebuilds, it's the library maintainer's job to find all dep packages.
> There are then two choices:
> * build everything yourself, if you feel like it (yay!)
> * make a todolist and post on the arch-dev-public ML so we know
> that there is a new rebuild todolist.
>
> Sound like a good process?

+1. And if you are unsure about a package rebuild, push it to testing
and ask for a signoff from the maintainer (or anyone else).

-Dan
 
Old 01-04-2008, 07:30 PM
"Varun Acharya"
 
Default dependency rebuilds

On Jan 5, 2008 1:06 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:


So ok, let me propose this:
With rebuilds, it's the library maintainer's job to find all dep packages.
There are then two choices:
* * build everything yourself, if you feel like it (yay!)
* * make a todolist and post on the arch-dev-public ML so we know

that there is a new rebuild todolist.

Sound like a good process?
+1
 
Old 01-04-2008, 08:39 PM
Paul Mattal
 
Default dependency rebuilds

Aaron Griffin wrote:

On Jan 4, 2008 9:18 AM, Paul Mattal <paul@mattal.com> wrote:

Aaron Griffin wrote:

On Dec 30, 2007 11:37 PM, Paul Mattal <paul@mattal.com> wrote:

1) the package y maintainer(s) notices package x in testing and rebuilds
package y

2) the package x maintainer(s) is responsible to find all packages y and
rebuilds all such packages y against the new package x

There's a middle-ground here which I like, myself.
1.5) the package x maintainer(s) is responsible to find all packages
y and posts a todo list on the dashboard

I like this method, but at the same time, it requires one to
constantly scan the todo lists to see if a package of yours is there.

A slight variation on this is to the todo list + what Damir did..
post to a todo list and *also* put a post on the arch-dev-public
list. This way people get push notification, and also a place to
track what they've done and what they haven't.


I like this one.

So ok, let me propose this:
With rebuilds, it's the library maintainer's job to find all dep packages.
There are then two choices:
* build everything yourself, if you feel like it (yay!)
* make a todolist and post on the arch-dev-public ML so we know
that there is a new rebuild todolist.


Sounds good. Put the package list, with the following observations:

* if you decide to build everything yourself, think about that first
and want to take that responsibility; releasing is more than just
rebuilding, and by rebuilding you potentially break something and
thereby take on responsibility to fix it in relatively short order
(even if it's just in testing)
* generally make sure the emailed todo list actually contains the
list of packages, or at minimum a direct link to the todo list; it
gives people no excuse not to notice


Thanks for working this through with me. I hope others will consider
and adopt some of these practices, or make some suggestions for how
to change them.


- P
 
Old 01-04-2008, 09:22 PM
Tom K
 
Default dependency rebuilds

Paul Mattal wrote:
> Aaron Griffin wrote:
>> On Jan 4, 2008 9:18 AM, Paul Mattal <paul@mattal.com> wrote:
>>> Aaron Griffin wrote:
>>>> On Dec 30, 2007 11:37 PM, Paul Mattal <paul@mattal.com> wrote:
>>>>> 1) the package y maintainer(s) notices package x in testing and
>>>>> rebuilds
>>>>> package y
>>>>>
>>>>> 2) the package x maintainer(s) is responsible to find all packages
>>>>> y and
>>>>> rebuilds all such packages y against the new package x
>>>> There's a middle-ground here which I like, myself.
>>>> 1.5) the package x maintainer(s) is responsible to find all packages
>>>> y and posts a todo list on the dashboard
>>>>
>>>> I like this method, but at the same time, it requires one to
>>>> constantly scan the todo lists to see if a package of yours is there.
>>> A slight variation on this is to the todo list + what Damir did..
>>> post to a todo list and *also* put a post on the arch-dev-public
>>> list. This way people get push notification, and also a place to
>>> track what they've done and what they haven't.
>>
>> I like this one.
>>
>> So ok, let me propose this:
>> With rebuilds, it's the library maintainer's job to find all dep
>> packages.
>> There are then two choices:
>> * build everything yourself, if you feel like it (yay!)
>> * make a todolist and post on the arch-dev-public ML so we know
>> that there is a new rebuild todolist.
>
> Sounds good. Put the package list, with the following observations:
>
> * if you decide to build everything yourself, think about that first and
> want to take that responsibility; releasing is more than just
> rebuilding, and by rebuilding you potentially break something and
> thereby take on responsibility to fix it in relatively short order (even
> if it's just in testing)
> * generally make sure the emailed todo list actually contains the list
> of packages, or at minimum a direct link to the todo list; it gives
> people no excuse not to notice

I'm hesitant to suggest this, as I'm not able to actually make it
happen, but could the addition of a package to a to-do list trigger the
same automated-mail thing that is currently used for out-of-date flags?
That would make option two a single task: make a to-do list.

T.
 

Thread Tools




All times are GMT. The time now is 07:53 PM.

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