[Planetlab-devel] [Fwd: Re: su-like function in plcwww] -- builds
and tags
Thierry Parmentelat
Thierry.Parmentelat at sophia.inria.fr
Wed May 23 05:38:45 EDT 2007
Hi Faiyaz
While I am reading you it occurs to me that I should try to separate
requirements - the good properties that you and I are expecting from the
build system - from the means to achieve them.
As far as I am concerned the requirements would read
- reproducible builds - even daily builds; this basically means, (1)
never force tags (2) never use the HEAD and (3) a much higher number of
tags than what we have now - like, 3 tags in 6 months.
- tracable builds :
from either a build hierarchy, or from the resulting rpm installation, I
want to be able to quickly now what tag(s) was used for building this.
This basically means never using something like make TAG=something since
this is volatile. Or at least write down the actual value of TAG in some
log file. e.g. My own myplc provides an 'About' page where anyone can
access the content of the onelab-tags.mk that was used for building. I
believe there are many occasions when it's simply very helpful to be
able to tell, e.g. that 4-0.rc3 was made with bootcd 3.3. For instance
it would help people understand the versioning scheme in /download/
- tracable changes :
from two given builds, I need to be able to quickly figure the changes.
It's probably the area where my scheme is the most relevant. It's really
frustrating to have to make a diff on such a big scale to figure out the
changes.
- mapping module version - system version
Now in terms of the actual method I propose
- I do not tag twice. I tag independantly modules and the build. Modules
can - and should - get tagged by their developer, not by the
buildmaster. And I do not even need to tag the build for daily builds
because I can get the tags definition file out of a given build if I
need to reproduce it.
- Now it's true that maintaining the tag names in consistance with the
spec file contents is an extra burden, scripting here is required
- You can also have both methods; use the per-module tags for
fine-grained/daily-builds and set an additional system-wide tag for
major releases.
- The branch thing is something entirely different, that I did not
address at all. My personal feeling is that the way branches are used
now is overkill. the kernel definitely requires branches; but they
should be like 2.6.12 and 2.6.17 - having a branch named
planetlab-4_0-branch looks mre a burden than helpful here; when it comes
to for instance the web pages, I dont think anyone is working on
anything disruptive here, so the trunk would be quite OK, and *this*
would really make your life easier. Tags would be quite allright. So the
bottom line, in much the same way as I was proposing a per-module
tagging scheme, you might wish to have a per-module branching scheme as
well. My gut feeling is that maybe only the kernel deserves the headache
of managing several branches.
As far as the requirements are fulfilled somehow it's fine with me. The
proposal that I made is just one possible solution. I just think the
time spent managing this scheme is approx. the same as for the current
method but much more effective.
I'm not available today but if you want we can chat tomorrow -- Thanks
-- Thierry
Faiyaz Ahmed wrote:
> Hi Thierry,
>
> I'm not averse to the idea. I have a few questions, however. So the
> general algorithm is:
>
> Merge changes from head into branch.
> Tag each module independently.
> Move tagged builds into build. That is to say make build module build
> specific tagged version of each module.
> Tag build with as an rc.
>
> I don't understand how this would make live easier since, instead of
> tagging once with a planetlab-rc tag, you're essentially tagging
> twice. Since we're tagging changes in the branch, the tag history
> would be the same in both cases, except in the old method of tagging,
> the all encompassing tag would show up in each individual module's
> history.
>
> If a name change for each package is all you're looking for, we can
> modify the spec files for each module to reflect the tag.
>
> Please clarify. At the surface, I have no objection to changing our
> scheme. Your method would keep us from tagging unchanged code and
> keep the builds small and simple (and above all, fast).
>
> Thanks.
>
>
> Faiyaz
>
> PS. I'll push the relevant parties to move the web sudo patches into
> the branch. Once we sort out how to tag (old method, new method),
> I'll push the tag.
>
>
> Thierry Parmentelat wrote:
>> Hi all
>>
>> As per Marc's suggestion I am posting this message on the devel ML,
>> since it might be of general interest.
>>
>> So the next question, for Marc and Tony, would be about tags - again
>> When is this feature expected to be part of a tag ? - it does not
>> seem that it is in planetlab-4_0-rc3, nor even in the branch as far
>> as I can tell.
>> I am sorry that I have to raise that same issue over again, but I am
>> really relunctant in importing code from an unversioned tree.
>>
>> This ML might be the place to start a discussion on this tagging
>> policy. I would again suggest that you consider to stop tagging the
>> whole planetlab code with a unique tag like you are doing now, and
>> use tags on a per-module basis; IMHO this would help your release
>> management a lot.
>> The idea here would be to put a planetlab-4_0-rcx tag on a single
>> file (or on the build module) that would in turn describe the right
>> combination of tags to use to perform that build.
>> Something like e.g.
>> http://svn.one-lab.org/filedetails.php?repname=OneLab&path=%2Fbuild%2Ftrunk%2Fonelab-tags.mk
>>
>>
>> This way it is natural to map module versions (e.g. from rpm) to the
>> correct cvs tag.
>> And people can more easily track changes from one myplc to another.
>>
>> my 2 cents -- Thierry
>>
>>
>>
>> -------- Original Message --------
>> Subject: Re: su-like function in plcwww
>> Date: Fri, 18 May 2007 12:42:36 -0400
>> From: Tony Mack <tmack at CS.Princeton.EDU>
>> To: Thierry Parmentelat <Thierry.Parmentelat at sophia.inria.fr>
>> CC: Marc E. Fiuczynski <mef at CS.Princeton.EDU>, Faiyaz Ahmed
>> <faiyaza at CS.Princeton.EDU>
>> References: <464D66BF.3050901 at sophia.inria.fr>
>>
>>
>>
>> Hi Thierry,
>>
>> Yes, there is now a 'Become' action on the users account information
>> page that will allow admins to become that user. The basic details are:
>> 1) archive your person and auth information
>> 2) If user is logged in: begin using their session_key to auth
>> else: create a session_key for the user and being using it
>>
>> This involved the following modifications:
>>
>> *API*
>> Added: PLC/Methods/AddSession.py (create a session_key for the
>> specified user)
>> PLC/Methods/GetSessions.py (Search for a users
>> session_key)
>> Updated: PLC/Sessions.py (modifyed the query code to support
>> GetSessions and be more consistent with the other db query entities)
>>
>> *WWW*
>> Added: /web_root/planetlab/sulogout.php (logs admin out of the
>> assumed user account)
>> Updated: /web_root/planetlab/includes/plc_session.php (Added
>> variables alt_person, alt_auth and methods BecomePeson(), BecomeSelf() )
>> /usr/share/plc_api/php/plc_api.php (make php api
>> aware of new api methods AddSession() , GetSessions() )
>> /web_root/planetlab/persons/index.php (Added 'Become'
>> action to 'Choose action' select box)
>> /web_root/planetlab/persons/person_action.php (Added
>> logic for handling 'Become' requests )
>> /web_root/modules/planetlab.module (Added 'logout of
>> ...' side navigation link which forwards to
>> /web_root/planetlab/sulogout.php)
>> Thierry Parmentelat wrote:
>>> Hi all
>>> I've seen recent changes on the cvs ml that suggest you've got a new
>>> feature allowing admins to temporarily have another user's roles; at
>>> least this is what I am assuming.
>>> Could anyone of you guys be kind enough to give me a quick update on
>>> that ?
>>> Thanks in advance -- Thierry
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.planet-lab.org
>> https://lists.planet-lab.org/mailman/listinfo/devel
>
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel
More information about the Devel
mailing list