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 > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 06-09-2008, 06:19 PM
Jesse Keating
 
Default Requirements gathering for new package source control

At the upcoming FUDCon I plan to hold a session or two regarding
requirements and discussions about the future of our package source
control. This is NOT a time to argue about one SCM being "better" than
another. I don't really want to hear any SCM names at all, rather I'm
interested purely in only what we require and what we'd like out of our
package source control. I'm sending this mail to get people thinking
about it, and to give the people who won't be at FUDCon a chance at
dropping their thoughts in.

To get the ball rolling, here are a few of my requirements:

Be able to track patches separately from the upstream source so that
source rpms can easily be created.

Be able to have a continuous development "branch"

Be able to create release "branches" for doing updates for existing
Fedora releases. Release "branches" should inherit history of the repo
up until the release happened.

Be able to re-create source rpm used to generate any shipped build at
any time later, including same version of any helper scripts or metadata
used.

Be able to checkout only a given package and not the entire package tree

Be able to support fine grained enough rights down to different release
"branches" of a given package

be able to be queried and pulled from anonymously (by the buildsystem,
by the web, etc.

Be able to trigger scripts such as pre/post commit

be able to reliably disseminate commits as they happen to a selected
group of people (per package & branch)

Be useful for offline development

Cheap "branches"

Consistency across all modules for scripted actions like rebuilds

easy between-branch merging for those who like to ship the same source
rpm everywhere

ideally, not rely on magic 'branch' files for the build & tag-fu to work


I'll be gathering feedback over the next few days and putting them into
a not as of yet created wiki page.

Thank you all for your thoughtful consideration.

--
Jesse Keating
Fedora -- Freedom² is a feature!
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-09-2008, 06:32 PM
Jochen Schmitt
 
Default Requirements gathering for new package source control

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

Jesse Keating schrieb:
> I'll be gathering feedback over the next few days and putting them into
> a not as of yet created wiki page.
One requirement from my side is the ability to check out one or more
modules without the requirement to download the whole repository.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhNdyIACgkQT2AHK6txfgx/mgCfcC3JhSmEOAu73fmNiPR42acs
r6UAoIXv7GW7sA9PI8tmAPGJJ5swTJ3h
=IEst
-----END PGP SIGNATURE-----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-09-2008, 06:46 PM
Jesse Keating
 
Default Requirements gathering for new package source control

On Mon, 2008-06-09 at 20:32 +0200, Jochen Schmitt wrote:
> One requirement from my side is the ability to check out one or more
> modules without the requirement to download the whole repository.


I do believe that's covered in my requirement:

Be able to checkout only a given package and not the entire package tree

--
Jesse Keating
Fedora -- Freedom² is a feature!
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-09-2008, 07:08 PM
Christoph Höger
 
Default Requirements gathering for new package source control

Hi,

while maintaining only one small package for some releases I would like
to see some decentral version management.

My current work looks like that:

- checkout current source code
- apply changes to .spec
- move things to ~/rpmbuild
- test build
- repeat until things work
- move things back to current SCM

It would be a great thing, if I could control all that from my own
versioned repository copy with some 'make <USUAL_STEP>' commands and
finally merge my changes back especially when testing builds for
multiple releases.

The new workflow would look like:

- replace source code with current (ideally by using a handcrafted
expansion to make e.g. make source revision 3456)
- commit that change locally
- commit changes to local .spec file locally
- make test
- merge final changes

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-09-2008, 07:16 PM
Jesse Keating
 
Default Requirements gathering for new package source control

On Mon, 2008-06-09 at 21:08 +0200, Christoph Höger wrote:
> Hi,
>
> while maintaining only one small package for some releases I would
> like
> to see some decentral version management.
>
> My current work looks like that:
>
> - checkout current source code
> - apply changes to .spec
> - move things to ~/rpmbuild
> - test build
> - repeat until things work
> - move things back to current SCM
>
> It would be a great thing, if I could control all that from my own
> versioned repository copy with some 'make <USUAL_STEP>' commands and
> finally merge my changes back especially when testing builds for
> multiple releases.

Any reason why you're not using make test-srpm and rpmbuild or just make
local? (see make help for a trove of options)

--
Jesse Keating
Fedora -- Freedom² is a feature!
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-09-2008, 09:09 PM
Christoph Höger
 
Default Requirements gathering for new package source control

Am Montag, den 09.06.2008, 15:16 -0400 schrieb Jesse Keating:
> On Mon, 2008-06-09 at 21:08 +0200, Christoph Höger wrote:
> > Hi,
> >
> > while maintaining only one small package for some releases I would
> > like
> > to see some decentral version management.
> >
> > My current work looks like that:
> >
> > - checkout current source code
> > - apply changes to .spec
> > - move things to ~/rpmbuild
> > - test build
> > - repeat until things work
> > - move things back to current SCM
> >
> > It would be a great thing, if I could control all that from my own
> > versioned repository copy with some 'make <USUAL_STEP>' commands and
> > finally merge my changes back especially when testing builds for
> > multiple releases.
>
> Any reason why you're not using make test-srpm and rpmbuild or just make
> local? (see make help for a trove of options)

Err, well, .... oohmpf, I just did not know about ...

So forget about the script wishes and just think of giving everyone his
own local repository to make maintainers life a little bit more
comfortable.

>
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-09-2008, 09:12 PM
Till Maas
 
Default Requirements gathering for new package source control

On Mon June 9 2008, Jesse Keating wrote:
> At the upcoming FUDCon I plan to hold a session or two regarding
> requirements and discussions about the future of our package source
> control. This is NOT a time to argue about one SCM being "better" than
> another. I don't really want to hear any SCM names at all, rather I'm
> interested purely in only what we require and what we'd like out of our
> package source control. I'm sending this mail to get people thinking
> about it, and to give the people who won't be at FUDCon a chance at
> dropping their thoughts in.

I would like to have a way so easily track patches against the cvs state of a
package with the possibility to do private commits and an easy way to merge
them to the official branch or show them others in a way that they can easily
merge them. This would make co-maintaining packages a lot easier imho.

Also it should not take that long to to get a diff like it does with cvs.

It would be also helpful, if it was possible to checkout only the active
branches of a package instead and when this would be the default beheaviour
when one checks out a package. Maybe this could be achieved with an "active"
and an "archive" branch of /rpms/<package> for each package in some scms. The
active branch would currently only include F-{7,8,9} EL-{4,5} and devel.

Another thing that comes to my mind, would be an easy way to merge changes
from devel to the F-? branches. E.g. the scm could track when one merged from
devel to F-9 the last time and make it possible to merge these changes to the
F-9 branch easily, even when the F-9 branch contains changes that are not in
devel.

Regards,
Till

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-09-2008, 09:21 PM
Jesse Keating
 
Default Requirements gathering for new package source control

On Mon, 2008-06-09 at 23:09 +0200, Christoph Höger wrote:
> Err, well, .... oohmpf, I just did not know about ...
>
> So forget about the script wishes and just think of giving everyone his
> own local repository to make maintainers life a little bit more
> comfortable.


Indeed. I do believe that would fall under my requirement for being
usable offline.

--
Jesse Keating
Fedora -- Freedom² is a feature!
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-09-2008, 09:30 PM
Jesse Keating
 
Default Requirements gathering for new package source control

These are good, albeit a bit lengthy. Lets see what we can do here.

On Mon, 2008-06-09 at 23:12 +0200, Till Maas wrote:
>
> I would like to have a way so easily track patches against the cvs state of a
> package with the possibility to do private commits and an easy way to merge
> them to the official branch or show them others in a way that they can easily
> merge them. This would make co-maintaining packages a lot easier imho.

I think I know what you're talking about here, but I want to clarify.
You get a copy of the "upstream" frob module. You then do some local
changes and even local commits against frob. You can query upstream
"frob" to see if anything changed upstream and integrate those into your
copy. Eventually you take your local changes and push them 'upstream',
right?


>
> Also it should not take that long to to get a diff like it does with cvs.

This is a nice easy concise one, and should fall under the 'offline use'
case, but I'll spell it out explicitly.

>
> It would be also helpful, if it was possible to checkout only the active
> branches of a package instead and when this would be the default beheaviour
> when one checks out a package. Maybe this could be achieved with an "active"
> and an "archive" branch of /rpms/<package> for each package in some scms. The
> active branch would currently only include F-{7,8,9} EL-{4,5} and devel.

Good suggestion! I'll add it into the lists, maybe a bit more terse.

>
> Another thing that comes to my mind, would be an easy way to merge changes
> from devel to the F-? branches. E.g. the scm could track when one merged from
> devel to F-9 the last time and make it possible to merge these changes to the
> F-9 branch easily, even when the F-9 branch contains changes that are not in
> devel.

Ok, I think I follow that.

--
Jesse Keating
Fedora -- Freedom² is a feature!
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-09-2008, 10:02 PM
Till Maas
 
Default Requirements gathering for new package source control

On Mon June 9 2008, Jesse Keating wrote:
> These are good, albeit a bit lengthy. Lets see what we can do here.
>
> On Mon, 2008-06-09 at 23:12 +0200, Till Maas wrote:
> > I would like to have a way so easily track patches against the cvs state
> > of a package with the possibility to do private commits and an easy way
> > to merge them to the official branch or show them others in a way that
> > they can easily merge them. This would make co-maintaining packages a lot
> > easier imho.
>
> I think I know what you're talking about here, but I want to clarify.
> You get a copy of the "upstream" frob module. You then do some local
> changes and even local commits against frob. You can query upstream
> "frob" to see if anything changed upstream and integrate those into your
> copy. Eventually you take your local changes and push them 'upstream',
> right?

If upstream here is the Fedora scm, then this is what I mean.

Regards,
Till
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 04:31 PM.

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